低代码，无服务器，就像火与冰?

冰与火之歌

低代码和无服务器技术都旨在简化应用开发过程，从而加速新应用的交付。Serverless通过缓解服务器管理负担的开发人员来实现这一点。虽然这个名字可能意味着没有任何服务器，涉及到服务器。从开发人员的角度来看，它看起来不如意，因为她可以简单地专注于开发应用程序而不是担心配置，管理或缩放服务器。

另一方面，low-code都是通过将开发者从代码中抽象出来来简化应用开发。其思路是，如果开发人员可以拖拽GUI组件来创建用户界面，然后使用类似流程图的图表来创建业务逻辑，他将能够更快地交付应用程序。

这两种技术的存在是为了解决一个基本相同的问题——加速应用程序开发。然而，这些技术背后的公司采取了截然不同的方法，这使得无服务器和低代码看起来更像是冰与火。

公共云供应商，如AWS、谷歌、Azure和IBM都提供了无服务器的选项，但在大多数情况下，它们专注于较低级别的功能，大多数组织无法解决构建在这些技术上的复杂性。直接与这些供应商合作的组织对输出有更大的控制，但它需要更多的开发工作。

与此同时，传统的低码供应商正在覆盖“公民的开发者“让商业用户也能访问应用程序开发。考虑到大多数商业用户没有计算机科学学位，low-code方法对他们来说是完美的。与无服务器产品不同，低码允许更快的应用程序交付，但是以控制成本为准 - 开发人员在供应商设置的低码环境可以做的方面非常有限。

异性相吸:冰与火的结合

通过压力安装，找出应用程序开发挑战的解决方案，没有理由这些技术不能共存。这只是传统的低码供应商预测无服务器的概念并使用需要App Server的旧技术。是的，即使他们是开源的，也是被认为的应用程序服务器也被视为遗留技术！为公民开发人员提供低码方法只是不在AWS，Google或IBM中的DNA。微软有点不同，但它的业务发展努力目前并未与其无服务员的工作相关联。

那么，这带来了什么问题呢?对于寻找低代码选项的人来说，他们应该仔细考虑系统的架构。这可能很困难，因为供应商喜欢到处乱取技术名称，这使研究复杂化。不幸的是，事实是许多传统的低代码供应商常常依赖于旧的技术。与无服务器相比，您可以将它们视为单片架构——这意味着您不具备独立设计、开发、测试、部署和扩展功能的灵活性。

好消息是，现在还有低代码选项，也基于无服务器。这些选项采用了不同的方法，专注于使专业开发人员更加富有成效，而不是将App Dev的责任转移到公民开发人员。实质上，它们旨在通过使用为现有工具和流程设计的常用Web技能提供具有更高级别控制水平的开发人员。

无服务器、低代码和物联网应用体验

那么，为什么这一切对物联网很重要呢?传统的低代码支持物联网应用，但它们仅限于调用打包服务(如分析)和在应用程序内消费服务。

另一方面，无操作系统是IoT的伟大架构，因为基于事件的工作负载在无服务器环境中运行得很好。基于事件的是IoT应用程序的关键，因为从传感器数据的分析导出的事件可以实现更自然，中断驱动的应用体验。这允许应用程序代表用户采取行动，最大限度地减少用户必须执行的工作。

所以，如果你在考虑低代码，确保你也仔细考虑系统的架构，而不是只关注拖放式的用户界面——它会对最终产品产生很大的影响。

所有IoT Agenda网络贡献者都对其帖子的内容和准确性负责。意见是作者的，不一定传达物联网议程的想法。