如果我们能回到过去，在2009年开始使用公共云，我们今天可能会更好。AWS beta版开始于2006年，完全是由api驱动的，没有控制台或命令行接口来让与服务的交互比我们现在所熟知的更容易。三年后，它变得更加成熟。早期的采用者开始用它解决真正的问题，填充他们的简历，以以前似乎不可能的方式为他们的组织带来价值。
2018年的无服务器计算相当于2009年的云计算。但无服务器到底是什么意思，开始使用它的一些简单方法是什么?
功能即服务:使无服务器架构成为可能
尽管这项技术很酷，但无服务器计算是一个可怕的名字，因为(剧透警告)实际上，它背后有服务器。这个名字来源于这样一种想法，即开发者不再需要担心服务器，甚至容器，作为一个计算单元，而像AWS Lambda, IBM OpenWhisk，谷歌cloud Functions和Azure Functions这样的公共云服务将处理细节。
考虑无服务器计算的一个更好的方法是，无服务器是构建在功能即服务(FaaS)之上的软件体系结构，FaaS是使小块软件能够在几毫秒内从磁盘加载到内存中的基础。
如何?
想象一下，有许多容器处于待机状态，并装载了像Node.js、Java、Go、. net或Python这样的语言运行时，但其中还没有应用程序代码。只有当某些事件发生时，比如写入数据库表或在对象存储中出现文件，以函数形式出现的应用程序代码片段才会被加载到备用容器中。它在那里执行，当完成时，整个容器被删除，尽管在某些情况下它可能被缓存以供以后重用。公共云提供商只根据计算时间和内存使用量的毫秒数向您收费，否则您的函数将停留在磁盘上，等待以低得多的成本执行。
在这种设计中，函数是没有状态的小代码段，它们根据触发它们的事件接受输入。通过将事件和功能链接在一起，就形成了一个更大的应用程序体系结构——但它的各个部分要小得多，并且更容易迭代。考虑这样一个场景:有人将一个映像文件放入对象存储桶中。该操作触发三个函数并行运行，每个函数负责获取原始图像并创建三种不同大小的缩略图。当每个函数将其结果写入第二个对象存储桶时，另一个函数接受结果并将其缓存到CDN上。
第一个函数不知道第二个函数，第二个函数也不知道第一个函数如何完成它的工作。组件块不是通过API契约相互依赖，而是通过事件触发器相互通信。使用第四个图像缩略图转换器来扩展这个架构，它独立于其他三个，并利用相同的CDN转发功能，使架构的更改更加简单。
学习无服务器与管理自动化
无服务器提供的好处是有权衡的。通常，每个函数的执行被限制在5分钟内，可用内存也受到限制。并不是所有的功能都可以是无状态的，所以通过数据库调用获取上下文，给定通过事件触发器传递的键，可能会占用5分钟的时间限制。它需要一种不同的思维方式来利用这些新的限制带来的好处。
幸运的是，如果您已经是公共云用户，那么您可能已经在日常操作中生成了各种事件。学习无服务器的容易实现的目标是使用这些事件来找到自动化公共管理功能的方法。
例如，您可能希望在EC2实例出现时自动化它们的DNS名称。您可以在CloudWatch上设置一个触发器，一旦实例达到运行状态，将执行Lambda函数，该函数可以与Route 53对话，从您的自定义域发出一个新的子域名。在这个场景的一个更复杂的版本中，在调用Lambda中的Route 53之前，您可能会使用DynamoDB表来跟踪唯一的DNS名称使用情况。
简单的任务，比如您通常在EC2实例中使用的bash shell脚本，可以外部化，并更容易作为Lambda函数重用。这让您可以使用简单的、已知的任务，并将它们作为学习这种新的编程范式的机会，而且风险较低。
从那里你可能毕业于批处理工作，然后毕业于成熟的多层web应用程序。
FaaS和无服务器的未来?
除了将基于使用的成本分割为毫秒，FaaS和无服务器显示了编程的前景，因为它们能够将组件彼此解耦，使开发团队能够构建更小、更独立、可以更快迭代的部分。这可能会带来创新成果，即使是微服务和容器也不可能实现，但这还为时过早。您会发现缺少测试和调试工具、可靠的CI/CD，以及当今VM和容器世界中常见的其他工具。不过，现在是时候通过一些简单的用例学习无服务器了，这样您就可以保持个人和组织的领先地位。这将确保你处于有利位置，能够利用下一轮创新收益。