01
亚马逊宣布终止低代码 Honeycode 服务
近日，亚马逊宣布将终止其低代码 Honeycode 服务，用户注册现已关闭，且客户的现有应用程序只能继续运行至 2024 年 2 月 29 日。
Honeycode 于 2020 年 6 月发布 beta 版，作为“一项完全托管的服务，允许客户快速构建起强大的移动和 Web 应用程序，且无需编程过程”。
据了解，Honeycode 应用程序的开发模型类似于电子表格，设计团队可能是基于这样的假设：对于想使用此类服务的高级业务用户来说，电子表格应该是种熟悉的操作载体。
2022 年 4 月，该团队又公布了“下一代 Honeycode”，希望通过新的构建器用户界面和更好的图像支持能力进一步降低开发复杂性。但此时，Honecode 仍处于 beta 版阶段，其新模板涵盖的应用程序包括费用报告、库存系统、活动规划器、休假报告和反馈调查等。
值得注意的是，这并不是 Honeycode 的完整形态，原本的不少功能反而不见了踪影。开发团队当时解释称，“在发布新的体验时，并没能提供与此前 Honeycode 经典体验相同的全部功能，这是为了尽快收集到用户的早期反馈”。
亚马逊一位发言人证实了此次关闭，称“亚马逊 Honeycode beta 版将于 2024 年 2 月 29 日关闭，且从现在起不再接受新客户注册。我们正在帮助客户迁移至他们选定的工具，并在 2023 年 7 月 31 日之后不再向他们收取 Honeycode 使用费。”亚马逊建议那些收到影响的用户使用 Honeycode 的“导出数据”选项，并表示“我们将保留您的数据直到 2024 年 4 月 29 日。如果您不采取任何行动，您的数据将在 2024 年 4 月 30 日被删除。”
亚马逊补充表示，Honeycode（RIP，2020-2024）的精神将在其其他产品中延续：“我们正在将亚马逊 Honeycode Beta 版的经验教训融入现有服务当中，并将继续致力于支持无 / 低代码服务，包括 Amazon SageMaker Canvas、AWS Amplify Studio 和 AWS AppFabric”。“亚马逊的 Day 1 文化使我们能够为客户快速进行实验和创新，其中部分原因就是我们为自己的服务设定了很高的标准，同时保持着强烈的自我批评精神，随时关注项目无法满足客户期望的现实迹象。我们非常感谢客户在测试期间分享的反馈意见。”
02
一个早就存在的问题：Honeycode 保留还是关停？
Honeycode 的关闭并非毫无征兆，甚至部分用户也早有预感。从社区论坛（包括主要文档）上的真实状况来看，Honeycode 最大的问题就是使用率有限，而这样惨淡经营的局面自然导致亚马逊必须做出一个艰难的决定：保留，还是关停？
在 Honeycode 宣布正式关停之前，Honeycode 社区论坛出现过一篇名为“死或生”的帖子，用户 Roma-d7d2 提到自己在过去的两天里热衷于从头开始构建一个应用程序，但他发现他使用的 Honeycode 这个项目几年来一直处于测试阶段，最后一次更新是在去年 9 月，于是提出了“这个平台还活着，还是正在慢慢消亡”的疑问。
在 Honeycode 社区论坛上，每个月只有少数新话题出现。到目前为止，连终止公告也只收到了 7 条评论。
用户 Eric0 表示：“感谢 Honeycode 团队的辛勤工作和支持，感谢您给用户一个迁移和备份数据的窗口。我公司的整个基础设施都是围绕 AWS Honeycode 构建的（考虑到 Hoeycode 的测试性质，事后看来这个选型有点愚蠢），因此我们需要很长时间才能迁移我们的服务和流程。我不能说我的团队对 AWS 的这一决定不感到失望，但还是表示理解。”
至于关闭原因，外媒 Devclass 认为，Honeycode 的问题可能是过于关注可用性，而对功能丰富度重视不足——特别是在项目早期，它与其他服务和目录的集成度都很有限。此外，亚马逊在设计上似乎一直在倾向 IT 专家，而非真正对低代码工具更感兴趣的普通用户。
Hacker News 上的一位评论者 Honeycode_eng 自称是“2017 年负责过 Honeycode 项目的工程师”，他表示：
我最初加入该项目是因为最优秀的人才蜂拥而至，最终为开发人员打造了一个前端构建器。我在那里工作时，愿景就在那里（允许人们使用电子表格技能构建应用程序），但执行却是一团糟：我们的工程师最感兴趣的是升职，所以这是超级政治性的。我记得每个团队都有自己的 redux 商店（包括一个用于导航栏、一个用于登录屏幕、一个用于主屏幕等）。它完全不起作用，但很多人得到了晋升。一直以来我们都没有一个顾客！
如今，我对无代码这个概念非常怀疑，感觉开发的大众化趋势已经走进了死胡同。Honeycode 就像是计算机视觉中的「恐怖谷效应」，虽然看似真实有效，但却无法被应用于实际场景。Honeycode 既没有源代码控制、自定义 React 组件，也缺乏测试工具。
03
低代码软件开发是谎言吗？
从 2020 年低代码盛行以来，围绕低代码的争议从未停止过。有观点认为，低代码是 IT 革命，将“重塑整个中国软件的格局”，也有观点认为低代码是旧瓶装“新酒”，是炒作噱头而已。
此前，博主 Jay Little 曾在一篇名为《低代码软件开发是一个谎言》的文章中提到，有些低代码工具虽然能帮助一些非开发人员生成自定义逻辑和屏幕，但实际上并没有消除设计正确的数据结构、编写容错软件和验证最终软件的质量所固有的复杂性。由于许多相关编码员不具备这种专业知识，因此最终结果是一个脆弱的定制软件系统，需要团队未来成员不断进行救火。
Jay Little 表示：
“像这样的工具并不便宜，而且它们倾向于构建许可证 / 计费，只要你使用通过该工具生成的软件，最终就需要付费。最重要的是，所有这些工具似乎都涉及接受某种程度的供应商锁定。因此，你在此类工具上投入的时间越多，它们对你的控制就越紧。
在人工智能聊天机器人和低代码工具场景中，每个解决方案都承诺提供一条绕过非从业者所感知的复杂性的捷径。这就是陷阱的本质。从业者知道，代码的编写只是一个漫长过程中的最后一步，这个过程涉及大量的思考、讨论和规划。代码通常是最终结果，一旦你真正理解了手头的问题，生成代码就会相对容易。”
也有用户与 Jay Little 意见相左，用户 JimDabell 认为抱怨低代码开发工具的本质是，有些人认为代码是偶然的复杂性，而不是本质的复杂性。采用低代码工具可以帮助不会编程的用户做很多自己以前做不到的事情，从这个角度来看，低代码开发并不是谎言。但如果你想解决一个大而复杂的问题，即便不用考虑编程问题，也要管理大量的复杂性。这个时候，低代码工具并不是最佳选择，最好聘请专门的开发人员。
“我见过一些人使用低代码工具构建非常复杂的项目，但在规模和复杂性达到一定程度后，使用低代码工具会带来更多麻烦。但这并不意味着低代码工具毫无用处——它们非常适合解决第一组问题，其中所需的代码只是偶然的复杂性。不应该仅仅因为人们在使用它们来解决不适合的问题时遇到麻烦，而放弃采用低代码工具。”JimDabell 评论道。
参考链接：
https://devclass.com/2023/08/30/muted-response-speaks-volumes-as-aws-scraps-low-code-honeycode/
https://honeycodecommunity.aws/t/dead-or-alive/28334
https://news.ycombinator.com/item?id=34008506
https://jaylittle.com/post/view/2023/4/low-code-software-development-is-a-lie
文章来源：InfoQ，整理：凌敏、核子可乐，如有侵权，请联系删除。
– END –
报告下载
大佬观点
