一個潮流的終結？推出僅 3 年后，亞馬遜宣布終止低代碼 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 文化使我們能夠為客戶快速進行實驗和創新，其中部分原因就是我們為自己的服務設定了很高的標準，同時保持著強烈的自我批評精神，隨時關注項目無法滿足客戶期望的現實跡象。我們非常感謝客戶在測試期間分享的反饋意見。” 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 組件，也缺乏測試工具。 從 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 該文章在 2023/9/4 11:16:42 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
