对于业务应用程序的要求不断提高，但是 IT 部门困于大量的应用程序积压的工作而不可能很快的完成工作。而且，目前面临的挑战是，IT 需要重新思考提高交付速度的方法。有两个解决方案：low-code 和 serverless。
但什么是 low-code 和 serverless？还有更重要的是，这一切又与 IoT 有什么关系？放轻松，我最终会解释。但是首先，让我们看一下 low-code 和 serveless，如果你还不熟悉这些技术，能让你快速熟悉起来。
冰与火之歌
low-code 和 serverless 技术同样都是为了简化应用开发流程而设计的，从而加速新应用程序的交付。serverless 通过减轻开发人员的服务器管理负担来做到这一点。虽然 serverless 的名字可能暗示没有任何服务器，但是还是需要服务器的。只是从开发者的角度来看，他只需要简单地专注于应用的开发而不是要担心部署、管理和扩容服务器。
另一方面，low-code 通过从代码中抽象出开发人员来简化应用程序开发。思路是，如果开发人员可以拖放 GUI 组建来创建用户界面，然后用类似流程图的方式来创建业务逻辑，他将更快的交付应用程序。
两个技术的存在都是为了解决同样的问题：加速应用程序开发。然而，两项技术背后的公司可能会采取截然不同的方法，导致 serverless 和 low-code 看起来像是冰与火。
公有云供应商比如 AWS、Google、Azure 和 IBM 都提供 serverless 选择，但是对于他们的大多数，他们只关注于低等级功能，大多数组织无法基于这些技术解决复杂的问题。直接与这些供应商合作的组织可以更好的控制输出，但是这需要更多的开发工作。
同时，传统的 low-code 供应商通过让商业用户可以访问应用程序的开发，来预示着“全民开发者“的兴起。鉴于大多数商业用户都没有计算机相关学位，low-code 的方法非常适合他们。不像 serverless 那样，low-cdoe 让应用程序交付更快，但是以可控性为代价 – 开发者在供应商设置的 low-code 环境下可做的事情受到很大限制。
异性相吸：冰与火的结合
随着找到应用程序开发挑战解决方案的压力越来越大，这些技术没有理由不能共存。只是传统 low-code 供应商早于 serverless 的概念，并使用需要应用服务器的传统技术。是的，应用服务器被认为是过时的技术，即使他们是开源的！而且给全民开发者提供 low-code 的方法也不是 AWS、Google 或 IBM 的 DNA。 Microsoft 有一点不同，但其业务开发工作目前并未与 serverless 相关联。
所以，这回带来什么问题？对于寻找 low-code 选项的人来说，他们应该仔细考虑系统的架构。这可能会很难，因为供应商喜欢到处乱用技术名称，那将会让调研变得复杂。不幸的是，实际上很多传统的 low-code 供应商都依赖较旧的技术。相比于 serverless，你可以认为他们是单体架构 – 那意味着你没有对于 设计、开发、测试、部署、独立扩展能力的可灵活性。
好消息是，现在有很多 low-code 的可选项是基于 serverless 的。它们采取不同的方法，通过关注于提高专业开发人员的生产力而不是将应用程序开发人员的责任转移给全民开发者。本质上，它们旨在通过使用现有的工具和流程设计的通用 web 技能为开发人员提供更高级别的控制。
Serverless、low-code 和 IoT 应用程序经验
所以，为什么这一切对于 IoT 很重要？传统的 low-code 吹捧支持 IoT 应用程序的能力。但是他们仅限于调用打包的服务（比如 分析）和在应用程序中使用服务。
另一方面，serverless 对于 IoT 来说是非常好的架构，因为 event-based 工作方式在 serverless 环境运行的非常好。而且 event-based 是 IoT 应用程序的关键，因为来自传感器数据分析的事件可以实现更自然的、中断驱动的应用体验。这允许应用程序代表用户执行操作，从而最大限度地减少用户必须做的工作。
因此，如果您正在考虑 low-code ，请确保要仔细考虑系统的架构，而不是只关注拖放式 UI —— 它可以对最终产品产生重大影响。