业务逻辑从单片整体架构到微服务再到函数的演变
在过去十年中技术不断发展，我们看到了应用程序从单片monolithic到微服务的演进，现在看到AWS Lambda领导的函数驱动的无服务器Serverless事件的兴起。 什么因素推动了这种演变？
从技术上看，低延迟的消息传递技术实现了从单片到微服务的转变，低延迟配置技术又能转移到Lambda。
软件的重点是提供业务价值。这个业务价值是通过创建业务逻辑和操作来实现的，业务逻辑和操作是通过为用户提供某个服务实现的。 但是在创建业务逻辑和向用户提供具有该逻辑的服务之间存在时间差，这个时间是追求价值的所要花费的价值时间，该成本是创造成本加上交货成本。下面讨论都是基于如何提高这种价值时间为主线。
十年前，因为时间的限制，单片应用程序是交付业务逻辑的最好方法。大约五年前这些限制改变了，，最好的选择是转向微服务。
新的应用程序开始在微服务架构上构建，在过去几年中，工具和开发实践为支持微服务改变。 今天，正在发生另一个转变，转向事件驱动的函数，因为潜在的约束又已经改变，成本降低，并且在价值时间上的根本改进变得有可能。
接下来，我们将从不同维度详细介绍这些变化：交付技术，硬件功能和组织实践，并了解如何结合它们以推动这一变化。
首先，交付成本占据主导地位。采购，配置和部署硬件需要很长时间，软件安装本身就是手工作坊式的项目。为了优化交付，最佳做法是在每个发行版中对大量业务逻辑分摊，并且相对不频繁地发布，许多公司是以月为单位发布版本，也就是以月为时间衡量的价值时间。 由于基础设施变化导致交付周期较长，因此有必要提前预先提供额外容量，但这又会导致利用率非常低。
降低交付成本的第一步是倾向于过程自动化。许多公司开发了自定义脚本来部署新硬件，以及安装和更新应用程序。最终，Puppet和Chef等常见框架变得流行起来，“基础设施作为代码”加快了更新的交付。
DevOps运动开始于运营团队采用敏捷软件的开发实践，并与开发人员密切合作，将价值时间从几个月缩短到几天。
脚本可以改变已经存在的，但快速增长的企业或具有不可预测工作负载的企业很难快速提供新容量。 引入自助服务API调用，也就是使用Amazon EC2自动配置云容量解决了这个问题。
当开发人员能够使用Web服务直接自动化许多操作任务时，发生了第二波DevOps。
运营团队在云服务之上构建和运行高度自动化的API驱动平台，为开发团队提供自助服务部署和自动扩展的能力。 能够即时部署容量并按实际需要支付时间，能够实现更高的平均利用率，并自动处理工作负载中的意外峰值。
另一波优化又到达了，docker使得容器更容易使用。 Docker容器提供了一种方便的捆绑包格式，包括一组固定的依赖关系，一旦运行，提供比进程更多的隔离，但少于一个虚拟机实例。启动时间以秒为单位，节省大量内存占用。 通过将多个容器打包到实例上，并且将运行时间提高到分钟或秒级别而不是几小时，甚至更高的利用率也是可能的。
基于容器的连续交付工具还加快了开发人员的工作，减少了价值时间。
当有合理可预测的工作量发生时，容器可以在高利用率水平上运行，但是工作负载变得要么尖峰要么长期下降到零。 例如，某应用程序只能在一周168小时中的40个时段处于活动状态。为了保持高可用性，通常将应用程序实例分布在三个可用区域上，甚至每个区域需要多个实例。因此，服务的最小覆盖区是六个实例。 如果我们想没有访问负载时容量缩小到零，我们就需要一种方法以便在有访问高峰事件发生时触发应用程序的一部分，并在完成后将其关闭（如同连接池）。 这是AWS Lambda函数的关键部分，它仅通过对所使用的容量以0.1秒的增量进行计费，并根据需要从零扩展到非常高的容量，将尖端工作负载和低使用率工作负载的两个极端转换为平滑有效的恒定的100％利用率。 因此，就没有必要考虑增加服务器了，这就是为什么这通常被称为无服务器Serverless模式。
交付技术的进步为改进价值时间提供了基石，但是还有其他潜在的变化，导致了过去十年中最佳实践的一系列转变。
业务逻辑捆绑的最佳大小取决于CPU，网络，内存和磁盘资源的金钱消耗、访问时间的成本以及服务的延迟等目标。
在过去十年中，CPU速度增长相当缓慢，因为时钟速率在几GHz的频率下达到了一个壁垒，然而芯片上的缓存要大得多，并且内核数量增加。 内存速度和大小也进展相对缓慢。
网络现在速度更快，常见的部署已经从1GBit移动到10GBit，现在是25GBit，而且软件通讯协议更加高效。 过去通常的做法是通过1GBit网络发送XML，XML导致的网络通信开销使得人们只能将业务逻辑限制在大型单片服务中，并且直接连接到数据库（SOA）。
十年后，25Gbit网络意味着通信成本减少了两个数量级以上。这是远离单片应用程序的关键推动因素。
存储和数据库也经历了过去十年的革命。
单片应用程序将其业务逻辑映射到相应的复杂关系数据库（RDBMS）事务中，这些事务模式将所有表链接在一起，并允许协调的原子更新。 十年前，最佳实践是实现少量大型集中式关系数据库，使用昂贵的磁盘阵列实现存储，并使用大量缓存。
今天，高速缓存的磁盘已被固态磁盘取代。 读取速度从过去慢且价格昂贵且不可预测发展到- 随着缓存命中率的变化，读取速度持续快速且几乎无限。 由于磨损均衡算法和其他效应，写入和更新从缓存磁盘的快速变为固态磁盘的不可预测的速度。（代价平衡）
由于几个原因，新的“NoSQL”数据库体系结构已经变得流行，但是我们这里关注的是他们有简单的模式模型和利用固态存储的特点。 简单模式强制将原来在同一关系数据库中链接在一起的数据表分离成多个独立的NoSQL数据库，从而驱动业务逻辑的分散。
Amazon DynamoDB数据存储区服务从一开始就设计为仅在固态磁盘上运行，为请求提供极为一致的低延迟。 Apache Cassandra的存储模型是能够生成大量的随机读取，并且不经常进行无更新的大型写入（大量读少数写的模型），这非常适合固态磁盘。 与关系数据库相比，NoSQL数据库提供简单但极具成本效益，高可用性和可扩展的数据库，延迟非常低。
NoSQL数据库的受欢迎程度的增长是另一个关键的推动力，它更容易扩展，并正在迁移到诸如Amazon的RDS和Aurora之类的服务。
当我们看看IT这种变化时，常常谈论“人，过程和技术”。 我们刚刚看到了技术如何利用AWS Lambda将部署的利用率和速度降至极限，在几分之一秒内有效地实现了100％的部署利用率。 它也使得将单片整体代码库分解成数百个微服务和函数，并将单片RDBMS反规范化为许多简单的可扩展和高可用性的NoSQL和关系数据存储。
在过去十年里，“人和过程”也发生了巨大变化。
让我们考虑由100个开发人员一起构建的假设整体。 为了协调，在单片架构下需要每几个月进行测试和交付，常见的是有更多的人在处于做测试和交付的过程中，而不是专心编写代码中。 企业管理者，测试人员，数据库管理员，运营商等组织都处于孤岛中，由行政单据驱动，并且管理层次要求每个人每周写报告和参加大量的会议，开发人员只能加班找时间来编码实际的业务逻辑！
DevOps实践、微服务架构和云部署的结合以及持续交付流程的应用，基于蜂窝的“两个比萨团队”团队（每个团队小到只要叫一份披萨就可以吃饱）紧密结合，并大大减少了部门之间协调、会议和管理开销。小组的开发人员和产品经理独立地编码、测试和部署他们自己的微服务，只要他们需要。
每个开发人员花费更少的时间在会议和等待上一轮工序完成，获得两倍的做得更好的百倍的价值时间。
这种变化的是从项目到产品的转变。 大量的项目经理被更少的产品经理取代。
在某些例子中，150人的产量竟然是300人的两倍。 双倍回报一百倍，投资仅需一半。许多组织都一直在进行这种转型 ，也有类似改进的实例 。
基于Lambda的应用程序是由单个事件驱动的函数构建的，这些函数几乎完全是业务逻辑，而且管理的样板和平台代码要少得多。 这虽然是起步，但这似乎正在推动另一个根本性的变化。
小团队的开发人员能够在几天内从零开始构建具备能够立即投入生产运行的应用程序。
他们使用简单的简单函数和事件来将坚固的API驱动的数据存储和服务粘合在一起。完成的应用程序已经是高度可用和可扩展，高利用率，低成本和快速部署。
作为一个类比，考虑构建一个模型房子，如果从一个粘土开始需要多少时间？而用一堆乐高积木开始构建则需要花费多长时间？
如果有足够的时间，你可以几乎什么东西都从粘土开始做，但它可能是一个反模式的单片整体应用程序，称为“ 大泥球 ”。 乐高积木配合在一起，形成一个有限的，块状的模型房子，也很容易扩展和修改，而且花费很小部分的时间。 任何一种标准的砖系统将比定制的粘土快得多。
当然，事件驱动函数的调用延迟是限制复杂应用程序的关键限制之一，但随着时间的推移，这些延迟会减少。
我要说的真正的一点是，现有的单片应用程序是否不必改变地被移动到云，或者重写，这种选择衡量标准是取决于重写它们需要多少工作量。 典型的从数据中心迁移云计算时，选择需要高度扩展和经常需要变更的应用代码，将其单片架构重写到微服务，但是AWS Lambda改变了这种情况，很可能默认方式是新的和实验性应用程序将被从头构建，同时也推动更多的重写变得值得。