深入研究无服务器架构

播客成绩单

迈克·梅森:

大家好，欢迎来到Thoughtworks播客。188bet宝金博app下载这一集将讨论无服务器和无服务器架构。我是来自Thoughtworks的Mike188bet宝金博app下载 Mason。我是其中一位主持人，和我一起的还有其他几位嘉宾。首先是我的搭档，Zhamak Dehghani。

Zhamak Dehghani:

大家好，嗨，迈克。

迈克·梅森:

Zhamak是我的搭档之一。她是Thoughtworks的技术负责人。我还将介绍来自Thoughtworks的客人，他们是P188bet宝金博app下载aula Paul。葆拉，你能给我们介绍一下你自己吗？

宝拉保罗:

你好，迈克，谢谢你的邀请。我也是一个技术负责人Thoughtworks,我想在过去的十188bet宝金博app下载年左右的时间我一直与客户合作,帮助他们采用云,不管他们需要有,在此之前我曾在数据中心和在物理服务器上,我的手做了很多服务器整合等。

迈克·梅森:

我很高兴地告诉大家，今天我们迎来了一位外宾。他的名字叫迈克·罗伯茨。我认识迈克很长时间了，我们是大学同学。他是思想工场的188bet宝金博app下载校友。迈克，你为什么不打个招呼并介绍一下自己呢?你好。

麦克罗伯茨:

谢谢你迈克。你好,每个人。是的，我叫迈克·罗伯茨。我曾经在Thoughtworks工作过，很久很久以前，188bet宝金博app下载早在21世纪初。但从那以后，我设法与Thoughtworks Folk保持了一些友好的关系。188bet宝金博app下载我在金融行业工作了很长一段时间。然后，就在几年前，我开始了自己的咨询业务，在云工程和云架构方面帮助人们。

迈克·梅森:

今天的主题是无服务器和无服务器架构。我认为一个很好的出发点是讨论一下我们所说的无服务器是什么意思。因为我认为在我们的行业中，几乎所有事情都是如此，一旦某件事引起了轰动，它就会变得有点模糊，或者某个东西的最初意图已经变成了别的东西。我们看到很多像敏捷和微服务这样的东西。我认识的人都在构建一个基于微服务的系统。不管怎样，Mike，你为什么不给我们一个快速的纲要，你对无服务器的定义，以及定义中的重要部分。

麦克罗伯茨:

是的，谢谢你，迈克。因此，无服务器对于不同的人来说是一种不同的东西。对我来说，关于无服务器的最重要的一点是使用服务的想法，在这种情况下，您不需要负责管理运行这些服务的基础架构。现在，很多时候，这意味着类似于使用函数作为服务平台，类似于lambda。这就是为什么无服务器变得非常流行的原因，因为lambda和类似的东西与我们过去构建应用程序的方式非常不同。但同样重要的是，在某些方面，在无服务器的世界中，这些服务有时更为重要，我们称之为后端即服务。这些都是类似于软件即服务的东西，但我们将这些服务合并到应用程序中。

麦克罗伯茨:

在新的世界里，比如使用，外部托管用户管理，比如Auth0服务。还有谷歌的Firebase，这是一个数据库应用程序，你不需要自己运行数据库，谷歌会帮你。你可以直接从一个移动应用程序或一个网页应用程序集成这个数据库。但这里也有一大堆较老的服务。实际上，如果我们开始考虑Amazon S3这样的东西，它本身就是一个无服务器的后端服务。这时人们可能会问，“为什么?”这看起来像是你在淡化这个词。”有趣的是，当涉及到资源管理时，S3有许多与lambda和其他东西共享的属性。

麦克罗伯茨:

我认为无服务器服务有很多明显的区别。首先，它不需要你管理任何服务器主机或服务器进程。因此，当您使用S3时，您不会考虑单个存储节点，您只会考虑桶这个抽象概念，您可以在其中存储对象。没有网络或存储主机之类的概念。与之相关的，是一个无服务器的服务，基于负载的自动缩放和自动供应。再说一次，当你使用S3这样的东西时，你可以在这里存储一个kb，或者你可以在这里存储一个pb。你不需要负责计算，自动缩放它需要多大。它需要存储多少容量，您也不负责计算需要多少S3实例来管理负载。

麦克罗伯茨:

这种完全不可见的自动伸缩对于无服务器的服务非常重要。使用无服务器的服务也会带来相应的成本。关于它的另一件事是，它有隐含的高可用性。因此，您不必担心设置高可用性的实例集来照顾您的服务。所有这些都是我们可以应用到S3, Amazon Lambda, Microsoft Azure Functions，谷歌Firebase等的标准。

迈克·梅森:

我的意思是，如果你想想云的最初承诺，它是……我的意思是，我认为有很多不同的承诺。但我记得，10年前，人们希望能够在Slashdot效应中幸存下来，或者建造一个……我知道我们已经建立了一些东西，你需要非常非常快地运行，可以扩展到高负载，然后可能一夜之间又消失了。我们在澳大利亚做了一个赈灾慈善项目。我的想法是，这个东西可以收集捐款。我认为这是一种很容易自动缩放的东西。但你得自己处理。就像那是…对我来说，云的最初承诺之一就是你可以获得这种可伸缩性。 And you also got somebody else to manage the infrastructure. I mean, so serverless is just that plus or is there a bigger difference there?

麦克罗伯茨:

我认为有一个更大的区别。首先，是的。您可以使用EC2和各种容器服务进行自动伸缩。但是，通常组织中仍然有人负责实际管理这种伸缩或基础设施。所以想想什么是扩大和缩小规模，特别是缩小规模，当你缩小你的基础设施，当你开始想要关闭一些东西时，会发生什么。这里面肯定有一些想法，云计算会支持它。但您仍然需要团队来管理这种扩展，并仍然管理实际的个人资源。但这里还有另一件事，当你使用这样的系统时，你仍然会考虑你运行的服务器主机。

麦克罗伯茨:

所以你仍然在考虑操作系统之类的东西，以及系统如何在第4层IP级上相互作用之类的东西，你仍然在考虑IP地址之类的东西。无服务器的承诺是，A，你真的提高了你的抽象，在某些方面类似于平台作为服务，你不再考虑底层服务器托管服务器进程。其次，你真的是从网络的层面思考，一个更高的层面，我们通常只考虑第7层的互动。基于HTTP的交互，除非我们需要考虑安全和虚拟私有云之类的东西。但我们通常不需要担心那种较低层次的IP级网络。这是两个地方，是的，这是云的承诺。但我们现在不用担心其中一些问题了，那仍然是我们所关心的。

宝拉保罗:

你有什么担忧的可见性,汽车,没有任何的视线,下游过程可能需要被告知如果你serverless能力大规模自动伸缩功能是由于一些意想不到的负载,如果会发生自动伸缩功能,就其本身而言,下游开始造成问题吗?

麦克罗伯茨:

是的，我是说，我们绝对可以…有一大堆我喜欢称之为无服务器的火灾沼泽，这些东西很危险，你需要意识到，当然，这种方式……例如，AWS Lambda可以水平自动伸缩，非常非常广泛，非常快，在某些情况下可能会很可怕。所以我们可以做很多事情，或者限制这种规模，或者意识到这种规模，或者设计允许这种规模。

Zhamak Dehghani:

迈克的定义,我完全同意迈克的泛化,需要控制一切的连续体,金属液面到现在你写的函数,函数作为一种服务,你真的不在乎它的运行,它是如何运行,鳞片。在这个连续体的某个地方，人们开始放弃无服务器的定义，这就是无服务器。因为这是一个时髦的短语，你有时你伸展，我们是连续的无服务器，但实际上是无服务器，你需要抽象出多少，潜在的操作。我认为这是一种很棒的方式。这是一个很好的视角。但是从桶里……在无服务器中，你提到的那些东西。尽管它们都具有相同的属性，即从构建功能的团队中移除一些操作开销和依赖。

Zhamak Dehghani:

它们完全不同。后端服务,你知道,(听不清00:10:31)所提到的,会导致不同的发展模式,不同的结构在某种程度上,它有自己的含义,像,暴露你的数据或者删除一些抽象层和功能作为服务,对一个事件和执行一个函数和消失。尽管它们有相同的性质。我们可能，当我们选择一个建筑和我们选择的东西时，我们可能会。我们可能喜欢使用功能作为服务，因为它适合事件驱动的体系结构，而且非常适合。但后端作为服务，或数据库作为服务可能不适合这种架构，或可能不是我们想要选择的东西。因此，如果你选择无服务器架构，它们并不会同时出现。

麦克罗伯茨:

是的，我认为，在某些方面，他们是非常不同的。比如，一个定制的计算平台。我们想要编写应用程序代码，这是运行应用程序代码的另一种方式。另一个，就像你说的，是关于管理那些我们还没有写代码的服务。这是FaaS和BaaS的区别之一，写代码，后端作为服务，我们没有。但我认为有趣的是，尽管从建筑的角度来看它们看起来非常非常不同，但我们使用它们的原因是非常非常相似的。这就是我们开始探讨无服务器的好处以及人们为什么关心它的原因。对我来说，使用这两种类型的服务有两个主要原因。一个是纯粹的经济问题。

麦克罗伯茨:

一个是，我们看的是运行一个应用的总拥有成本。这包括行动，包括灾难恢复和多地区，以及与之相关的一切。如果我们使用无服务器服务，这是否会让我们以更低的成本操作应用程序?在这个过程中，你可以仔细分析，然后决定是否使用lambda, S3，和其他服务来省钱。这是人们对无服务器感兴趣的原因之一，经济方面。在经济方面。另一方面，也可以说是经济方面的，但不是建筑方面的，是上市的时候了。这是关于，我们能多快，将一个想法，概念化并投入生产。

麦克罗伯茨:

同时将功能服务和后端作为服务的想法是，因为在支持应用程序和编写应用程序所需的代码时，需要做的工作更少，我们可以缩短交付时间。这让人们有了更快速的实验周期。这就是我对无服务器最感兴趣的原因。我认为在很多情况下，这是可以节省成本的，不是全部，但很多。但是我认为这种更快速的实验的想法，与我们在15到20年里一直在谈论的敏捷非常一致。敏捷并不是要更快。敏捷是关于我们如何进行更快速的迭代，以及如何尝试更多的想法。对我来说，无服务器就像敏捷的技术等级物，提升到了下一个层次，

迈克·梅森:

这很有趣。我想深入研究这两方面的好处并把它们区分开来因为这是很多事情的关键所在。速度更快的能力。我们与很多企业客户合作，很多企业，有很多部门的人在构建，合理的东西，内部平台，各种各样的东西。我想他们会说，“嗯，我们的内部平台是有意或确实提供了一些这样的好处。你应该能够在我们的内部平台上部署一些东西，它不是使用全部零，而是使用一个内部……”或者，不管是什么。所以,只是,因为这是即插即用,使用第三方服务在现实世界中,你真的得到了好处,而反对,很多这些内部平台,他们很难使用,它们可以有点笨重?

麦克罗伯茨:

这和我想的论点是一样的，关于prem和cloud，对吧?有很多足够大的组织会说，“嘿，我们不需要使用云。我们相信，我们的规模经济是这样的，我们可以运行自己的内部服务，我们自己的数据中心，我们自己的运营团队在低水平上。”假设这是成本原因。其他组织则因为安全原因而处于prem状态。这完全是另一回事。但是很多组织，传统上说他们是出于经济原因。他们相信他们可以做的事情比云更便宜。在过去的5到10年里，我们看到，越来越多的组织在说，“你知道吗，我们可以像其他组织一样便宜地做这件事。”

麦克罗伯茨:

你知道，你甚至可以看看像Netflix这样的组织，他们已经在云服务上很多年了。他们正在大规模地运作。所以你会认为他们可以获得规模经济他们可以运营自己的基础设施。他们说:“不，你知道吗，亚马逊可以做得比我们自己更有效。此外，我们还可以得到一些创新的东西，我们可以马上讨论。”所以，我认为这整个，无服务器的事情，人们说，“嘿，我们可以提供我们自己的内部平台。”是的，你可以，你绝对可以。但在某种程度上，经济会变得更划算，让云提供商为你管理平台，比你试图内部管理更划算。

Zhamak Dehghani:

与此相关的一件事，我想是我在上一个项目中观察到的，我很想听听其他人对此的看法。就像迈克说的，我们确实有…客户和我们已经投资了Kubernetes集群，在该平台上创建了很多功能，有点像自助服务。我们有…服务Mashup为我们提供了所有的可观察性，路由和增量地向我们推出服务。它真的……对于我们来说，把服务作为一个容器出来，需要几个小时，就像从一个想法开始，“哦，我想，写一个可以做什么的服务。”我不得不承认，我们当时还没有做到。但是，在生产阶段，服务大概需要6到7个小时。

Zhamak Dehghani:

然后在那个建筑里，他们…因为它是非常事件驱动的架构服务，所以我们通过事件流彼此交流。有一些地方是无服务器的，我们想使用无服务器，它做了这个很小的适配器功能，获取一个事件并在一个不理解事件的第三方应用程序上调用RSAPI。所以就有了这些粘合功能，让我们尝试无服务器，我们面临的挑战是，你试图标准化基础设施的一部分，而生态系统的一部分，你试图区分并成为多语言系统。基础设施的一部分，你试图标准化的是操作层，由Kubernetes管理，服务会话和其他一些提供可观察性的东西。

Zhamak Dehghani:

所以能够要求我们的运营团队，不仅仅是…我的意思是，我知道几乎没有，可能非常，非常少的无服务器部署，但这仍然是一个不同的部署模式。所以将它添加到已经建立的基础设施中，这对他们来说似乎有点负担，如果团队不能成功地带来无服务器的功能，将它添加到基础设施中。它们会恢复，它们实际上恢复到只把它写为一个容器。我想知道这个问题是不是…如果这是有意义的，比如你已经在做手术了。将润滑一个自助服务的基础设施，这是不同的。引入一个嵌入式无服务器是有意义的。

宝拉保罗:

是的，我也见过类似的情况，Kubernetes的基础设施并没有建在客户那里。当然，开发人员很容易就能包含新功能、新服务，所有这些都被容器化了。但当然，基础设施团队仍然要做的，维护映像。这是典型的任务。所以我的意思是，在某种程度上，我们可以说，是的，我们不再需要担心为了解决安全问题而修补图像或旋转集群。”但从另一方面来说，如果直接谈到无服务器，也会有摩擦，因为您已经为集群中的服务、日志聚合、仪表板建立了可观察性实践。在我们当时使用的无服务器的情况下，这是不一样的，你不能用同样的方式来测量它。

宝拉保罗:

所以你必须。。。这几乎就像是混合数据中心和云，你现在有了一个混合，容器和无服务器，或者服务器完整和无服务器，无论无服务器的反面是什么，我不太确定。所以我认为，无服务器的好处是存在的，但可能有一些模式比其他模式更容易应用。

迈克·梅森:

我认为这很有趣，因为我经常听说无服务器不是一种全有或全无的架构，你可以选择你的生态系统的一部分，并说，“我们将在这一点上使用无服务器。”但实际上听起来要比这复杂一点，在现实世界中，或者取决于组织。

麦克罗伯茨:

不，我觉得你上了迈克，我觉得这是我觉得…我喜欢无服务器，因为它实际上不是一个固执的架构，你可以把它带到一个非常小的层次。对我来说，关键是，你希望你的操作平台是什么，对吧?有些人想说，“我们想标准化Kubernetes。”如果这足够好，如果Kubernetes作为一个平台满足了开发人员的所有需求，那就太好了。这是美妙的。很多人都说:“嘿，我们要把特定供应商的平台标准化作为我们的平台。”亚马逊提供的所有原语，比如亚马逊安全，亚马逊如何处理网络，诸如此类。可以使用Amazon Lambda，也可以使用容器。或者您可以使用EC2来实现。

麦克罗伯茨:

这两件事都是关于理解你的平台是什么。但你完全可以在这里和那里放一点点无服务器的东西。几周前，我在O'Reilly的一次会议上做了一个主题演讲，我谈到了我如何看到组织引入无服务器。我们一直以来都是这样的。。。我们很多人现在都看到了什么。现在我们进入了更成熟的阶段。就像在无服务器时代的开始，所有的都是初创企业，要么全有，要么全无，每个人都在努力工作。但这是早期的采用者。现在，我们看到的是，有点。。。现在我们进入了早期的大多数，比如，我们通常看到的是，在操作中使用无服务器是非常典型的，这对一些人来说是非常奇怪的。他们想，为什么操作人员会想用这个，就像完全非操作类型的东西一样。

麦克罗伯茨:

实际上，我们已经看到了很多团队，运营团队，他们从使用各种无服务器工具和技术中获得了很多价值。在那之后，它会开始进来，这是非常经典的然后开始考虑使用它，用于cron服务器上通常用于cron作业的小事情。因为它很容易设置一个预定的lambda，来为你做那个工作。然后你不需要管理一个cron服务器来统治所有的服务器，每个人都讨厌它，因为它有100个不同的cron作业在上面运行，这完全是一场噩梦。对吧?然后你就可以从那里慢慢进入完整的应用程序。

迈克·梅森:

所以，我想问一些愚蠢的问题，对吗？因为老实说，我真的需要处理一些事情。所以，有人说，有点开玩笑，但他们说，“无服务器是新的存储过程。对吗？它是一段代码，漂浮在那里，在一些共享数据存储上运行，无法控制它们到底是什么，只是无法看到它。”这是真的吗？我的意思是，你怎么处理这些漂浮的东西。我是说，这甚至不是。。。云，关于云的笑话是，没有云只是你在别人的电脑上运行的东西。我是说，现在情况不同了。过去我喜欢。。。至少我有一个真正存在的应用程序。

迈克·梅森:

现在我只有一个函数。请告诉我，所有这些东西的管理比这更有条理。如何进行测试循环?诸如此类的事情。

麦克罗伯茨:

是的,它是。任何让他们的lambda服务任意访问数据库的人，都要检查他们的头脑，对吧?这里有很多你可以做的事情。还有……我是说，我们可以深入调查。这是我最喜欢的领域之一。人们有很多方法，“构建lambda应用程序将与我们构建传统应用程序的方式非常、非常不同。我该如何安排我的消息来源，我不能用它们回购，等等等等。”我认为很多东西绝对不会改变，比如我们如何做持续交付，我们如何构建源代码，不会因为lambda而改变。我的意思是，它可以做到，你会看到很多教程说，“现在打开Amazon web控制台，上传你的zip文件。”

麦克罗伯茨:

“不，不，不，不，我们不是那样做的。”作为一种学习工具，这是很好的。”这不是您在无服务器系统的生产中所做的，您使用的是完全相同的过程，我们已经通过持续交付和良好的工程实践多年来一直在构建。实际上是一样的。我可以举一个例子，它有点…它没有使用无服务器技术的所有方面，但是您可以非常非常愉快地使用无服务器技术构建一个微型服务。我的意思是你可能有10个不同的lambda函数，一个API网关在这些lambda函数前面，还有一个这些lambda函数使用的嵌入式数据库。你可以设置AWS安全性，这样其他任何东西都无法与数据库对话，你还可以设置那些lambda函数的安全性，这样它们无法与数据库之外的任何东西对话。

麦克罗伯茨:

正当一旦您了解了使用AWS安全性的一些基本原理，就不难了。在这一点上，对于外部观察者来说，您拥有的是一个微服务，他们不知道这是在容器中实现的还是在lambda中实现的，对吗？这种架构模式不会改变，你如何设置你的测试和CD，所有这些都不会改变。碰巧您已经将代码构建到lambda函数中，而不是容器中。这是完全可能的。还有其他的方法，你可以建立lambda和，我会。。。18个月前，关于如何构建和打包这些东西，这还是一个有点狂野的西部。但我肯定认为在亚马逊世界，我们真的开始看到，一些标准出现了，以及我们如何看待这些东西。

宝拉保罗:

是的，我之前想问的，我认为这是一个相关的话题。无服务器真的是一种架构吗?或者它只是一种不同的部署拓扑?因为，正如你所说的，我可以在容器中构建微服务，并在Kubernetes或mezzos中编排它们。或者，我可以将它们部署到lambda中，并为谁应该与谁对话的策略配置网络。所以对我来说，这是相同的架构，只是不同的部署拓扑，或者基础架构，如果你愿意的话。那么，无服务器真的是一种架构吗?

麦克罗伯茨:

所以我们都是顾问。所以我可以说一个关键的短语，这要看情况。我只是举了一个例子，你可以使用无服务器技术而不改变你的架构。这是完全可能的。在很多情况下，这是非常有效的。但是，这是一个很大的但是，我不认为这总是考虑无服务器的最好方式。首先，这是有问题的。还有一些好处是你没有得到的。问题来了，我认为你在Paula之前说的一点是，缩放呢?如果你有一个用lambda实现的微服务，它没有连接到自己的数据库，而是连接到下游服务，那么伸缩会怎样呢?

麦克罗伯茨:

例如，如果你正在构建连接到的下游微服务，它本身不是无服务器的，那么你必须考虑。当你在创建一个无服务器和非无服务器的混合架构时，你必须非常非常清楚所有相关组件的可伸缩性属性。所以，这就是你需要从不同的角度思考的地方因为有一些不同的约束和一些不同的行为。这就是消极的一面，你必须换个角度思考。但从积极的一面来看，我们开始看到的实际上是……当团队真正开始做这些事情时，他们会说:“哦，哇，我们有完全不同的方式来设计东西。”

麦克罗伯茨:

一年多前，一个叫Goico的人做了一个非常棒的演讲，他讲了我们如何通过两次迭代来重新设计无服务器的架构。第一个是把所有的东西都放到函数中但并没有改变任何东西。这很好，它带来了好处。但他没那么感兴趣……这并不是那么有趣。一旦他习惯了一段时间，他就会重新构建它，但在构建的方式上做了巨大的改变。做一些事情，比如，允许前端直接与数据库通信，包括一些你在这些无服务器服务中得到的安全模式。做一些事情，比如接受他通常不会使用的亚马逊服务，以一种有趣的方式扩展了他的用例。

麦克罗伯茨:

其中一件事，他从中得到了两件事，一件是，他现在更容易做出改变，但他也提出了他在亚马逊的账单，为了这个特殊的……这是一个应用，一个思维导图应用每月大约有20万活跃用户。所以你知道，不是小的，但也不是微不足道的。他提到了他在亚马逊的账单，他的亚马逊基础设施每个月的费用不到100美元。其中只有1.5美元是lambda，就像大多数CloudFront和其他服务一样。所以，当你开始真正理解，就像这些东西可以让你做什么，它可以显著地改变你的架构。

麦克罗伯茨:

因为这是关于…这就是，实际上不是那么有趣的地方。Lambda就是把东西粘在一起。真正有趣的是，你开始思考，所有这些可用的其他服务，这意味着我一开始就不需要写代码。从比例的角度来看，它们都能很好地协同工作。很多人已经讨论这个话题有一段时间了。但我认为…这是棘手的部分。因为，我们如何构建应用程序，但真正依赖于很多很多供应商的服务，这是东西真正有价值的地方，但也真的有点。这里有一些警告和一些我们需要思考的事情。

Zhamak Dehghani:

在架构上，Paula问的问题还有Mike，你问的关于可见性的问题，从无服务器的好处中，如果我挑出一个无趣的，lambda和作为服务的功能，我认为那只是，纯粹的事件驱动架构。当我们讨论事件驱动架构时，你会得到一组模式，你可以有，一个中介或一个模式，其中你仍然有一个中介服务，你的流程的不同步骤，然而，它发出事件，然后向下…流程的一些下游部分可以响应，所以你仍然在一个中介中控制工作流，但是工作流的一些部分可以被响应地调用并扩展到代理模式，好的，一切都Kafta主题,每个人都应对它,我想如果我们纯粹拿λ,没有混合架构那么纯粹的事件驱动架构的工作流是如何实现没有在底层的功能你使用从第三方或其他你SAS功能提供。

Zhamak Dehghani:

在纯粹的事件驱动架构中，我们需要解决一系列问题，不管你在做什么类型的事件驱动架构，但这是……你必须认真考虑这些问题，比如你如何实现真正的事务或者不实现事务，你如何处理错误，你如何理解。你如何管理你的工作流，传奇的概念，我认为，架构从工作流实现，有一些真正有趣的模式和一些具有挑战性的模式集，当你进入一个纯粹的反应和事件驱动的架构，使用lambda。

麦克罗伯茨:

是的。首先，抛开我对无服务器架构的抽象想法。我推荐Goico的演讲，讨论事件驱动架构，尤其是数据管道。这对lambda来说很神奇。我是说，很无聊。实际上，我不认为是无聊的。我想我在lambda上花了很多时间。事实上，我对我们今年看到的一些变化感到非常兴奋。但是我是如何进入lambda的是通过数据处理管道，有多少公司发现lambda在这个数据处理和异步系统的世界里非常有效。你可以查阅各种案例研究，像美国金融业监管局和房利美这样的公司，他们一直在用lambda来做这类事情。

麦克罗伯茨:

这是因为扩展的好处，也是因为成本的好处，人们真的很喜欢它。但是，确实有一些挑战，你在和他们交谈，我的意思是，我认为这些挑战在某些方面是存在的。不管你用的是不是lambda。无论您是否使用lambda，这些挑战中有很多都存在。有时候，不使用lambda是合适的。再一次，回到这个混合应用程序的概念，如果你正在构建一个数据处理管道，这意味着你通常有几个阶段在进行，这可能是完全有意义的，而不是在lambda中实现其中的一些阶段，这可能是有意义的，要么是在容器中或EC2上托管的更传统的应用程序中的某些阶段，要么是使用其他类型的无服务器系统。

麦克罗伯茨:

因此，Amazon越来越受欢迎的一个元素是称为step函数的服务，它基本上是作为服务的状态机。这是……我记得已经有一年半的时间了，我不记得有多久了，但它正在变得越来越强大。所以在某些情况下，在你的管道中使用这种组件是有意义的。所以，试着想出合适的组件，合适的技术在合适的位置是非常重要的。但是，是的，你仍然需要考虑什么是交易。有时lambda会带来它自己的挑战。所以我讲过的一个地区,和我讨论这个火沼泽λ,再一次,这是,λ担保,至少执行一次,至少关键,有时一个特定lambda函数调用事件不止一次为同一来源。

麦克罗伯茨:

所以你需要考虑幂等性。但是，我们一直需要考虑幂等性，当我们一直在考虑，有更多的分布式开发，和更多的分布式架构，无论如何。情况，你只是强迫我们思考这些问题而不是引入新的问题。

迈克·梅森:

我的意思是，我们一直在讨论，脱离自己操作的东西，并允许，无服务器的平台提供商为你做它，是无服务器的DevOps的终结。不,不是吗?

麦克罗伯茨:

不。

迈克·梅森:

你还需要DevOps?

麦克罗伯茨:

不。当人们在网上说这样的话时，我很生气。是的，有人说无服务器是DevOps的终结。而我，150%不同意这种观点，对吧?对于很多组织来说，无服务器是某种操作的终结。你不需要考虑操作系统，你不需要考虑我之前提到的一些基础设施。宝拉提到的,操作系统打补丁,这是一个很好的例子从1月初,早在1月或2月,在今年早些时候,幽灵和崩溃,漏洞出来,每个人都需要的东西修补他们的操作系统,因为有一个错误在英特尔芯片,可以利用。所以，Amazon Lambda只是修补了每个人的Lambda，没有讨论，没有工作要做，他们不需要重新部署他们的软件。它只是发生。

麦克罗伯茨:

因此，这种奇妙的操作工作，我们都不喜欢做。这是非常糟糕的事。就像这样消失了。这是毫无疑问的。很多关于配置管理的东西我们在过去10年里一直在讨论，其中一些已经消失了。在lambda中使用puppet或chef或其他东西并没有真正的意义。那种级别的DevOps工具，会消失，这是真的。但这不是DevOps，对吧?如果我们看看DevOps手册，还有人们喜欢的，Jez Humble，和Nicole Forsgren，还有很多人在过去几年里一直在谈论的，DevOps是关于我们如何加速开发?我们如何加速整个过程，并使之尽可能精简? That stuff still exists, we still need to do monitoring. We still need to do deployment, we still need to do testing. We still need to think about so many aspects and so to me, what DevOps is really about.

麦克罗伯茨:

你在四种价值观中谈论这个，我不记得你在科技雷达中是怎么称呼它的了，那东西和以前一样重要。事实上，我认为在很多情况下，一些无服务器平台让我们加速了这些想法。所以在我看来，它是在拥抱DevOps，而不是取代它。

Zhamak Dehghani:

用真正的思考来监控……在资源、操作系统和基础架构协调器方面，可能有一些事情你不会监控，但在你的应用程序方面，已经被分解成小块的事件驱动函数。这是一个更重要的问题，也可能是一个更复杂的问题。我的意思是，即使有了微服务，监控也已经成为一门科学。还有一些公司正在建立，以处理监控数据，无论是来自你的追踪或指标，并试图在其之上添加智能，以真正理解什么时候发生了问题，具体发生在哪里。我想现在你的架构有一个小块,需要相互协作,创造一个有意义的整体服务或工作流程,监控和理解,你要从这些信号,小段代码,甚至更大的挑战和更大的投资。

宝拉保罗:

是的,没错。我是说，你还是得担心安全问题。你还需要担心相关id，这是监控。对于所有这些事情，我通常会和我的交付基础设施或DevOps人员一起工作，确保我们有正确的工具，或者我们在适当的聚合器中消费我的服务产生的任何东西。所以,是的。

Zhamak Dehghani:

但这只是一个连续体，就像驱动架构一样，我们必须处理事务，回滚或错误。同样，作为服务的函数和lambda架构迫使我们处理它。监控和可观察性,如果你有一些服务,是的,也许你可以跟踪,看看日志,写几个,查询,SQL查询,上面的Kibana到底发生了什么事,但当环境变得更细粒度的……如果把它分解成细粒度的函数，那么你就必须投资并把它看作是它自己的一种服务，你需要在理解大量数据的基础上构建智能。

麦克罗伯茨:

是的，我正要说，如果你看看无服务器的工具，空间，它都是关于监视和可观察性的，因为这是目前围绕它的一个关键缺失部分。

迈克·梅森:

所以如果我们…在这里结束播客，如果我们思考一下即将发生什么，或者无服务器的未来。我想我们应该说，我们是在2018年底录制的。无服务器的发展速度相当快。Mike，你对2019年无服务器有什么期待或者未来有什么重要的事情?

麦克罗伯茨:

是的，我要说的是，我把大部分时间都花在了基于AWS的服务上。在过去的几年里，我们几乎所有的客户都在那里，都是AWS，所以，我有一点警告。亚马逊的无服务器平台现在已经相当成熟。正当lambda已经存在四年了。我们在lambda身上看到的事情，在reinvent有很多lambda的声明，大约一个月前。现在是关于调整，而不是关于重大的、重大的变化。这是关于，试图消除一些摩擦，人们有，与这些服务的一些伟大的方式，但它开始变得相当稳定。因此，我认为，对于Zhamak刚才谈到的这件事，我仍然认为在监控方面还有一些工作要做。

麦克罗伯茨:

但对我来说，我们现在开始考虑高层次的东西。我们谈论的是教育。这需要是我们不断努力的东西。当我不与客户打交道的时候，也就是大部分时间，我会试着思考这些东西，但有很多人在研究，如何构建无服务器的应用程序。我认为我开始看到的另一件事，更多的，这是伟大的，这是思考。这是相关的，围绕着移动的应用程序，和无服务器。因此，实际上，Amazon自己现在有一个或几个团队，致力于在无服务器的情况下思考这类领域。亚马逊有一个团队在研究这个叫做无服务器应用模型的东西，它在一定程度上是一个部署工具，但它更重要的是，它是关于。

麦克罗伯茨:

当我们考虑构建一个无服务器的应用程序而不仅仅是一个单独的lambda函数时，软件开发生命周期是什么?与此相关的是，还有另一个团队，他们正在研究一个叫做无服务器应用程序库的东西，这是一种你可以导入其他人已经建立的无服务器应用程序的方法。但更重要的是，这里有一个更大的图景，关于他们在想什么，就是，当你试图构建一个应用程序的应用程序时会发生什么。当我们试图构建一个自己的无服务器应用程序集合时，这意味着什么?所以他们在做…他们已经在这方面做了一些很好的工作。但他们正在做一些非常有趣的工作，以延续到明年。

麦克罗伯茨:

所以对我来说，这些是主要的事情。我的意思是，我们会看到平台继续完善，比如，亚马逊几周前刚刚宣布，实际上昨天刚刚发布了GA，现在有了对亚马逊API网关的web套接字支持。大多数人，不会在意这一点，对一小部分人来说，这将会带来巨大的变化。因此，我们看到这些不断的小改进的洪流，我说，缓解了使用这些平台的摩擦，我们将继续看到这一点。

Zhamak Dehghani:

是的，我同意迈克的观点。就像发生的任何一种范式转变一样，我们经历了这条增长曲线，人们跳入并开始使用它。然后，社区支持开始发挥作用，工具开始演变，就像，可观察性工具和模式演变，哦，我们真的伤害了自己，在这个领域使用lambda，或者，用自动可伸缩的lambda连接充斥我们的数据库。所以这些进化的模式和反模式，被更广泛地分布，我想是均匀地分布在社区中，人们开始谈论它们并写它们。有一个方面我希望我们能看到一些改变，我没有看到在地平线上，也许迈克，你正在地平线上看到一些东西。更多关于标准化的内容。所以Kubernetes所允许的是，它创建了一个开放的标准，所有的供应商都在使用它，它在某种程度上消除了你对AWS或GCP的依赖。对吧?你有某种程度的抽象。我想知道无服务器的时代即将到来。

宝拉保罗:

我也想看看。因为就像Kubernetes一样，现在，如果我能将我的应用程序容器化，我不在乎它是否在中编排，因为你的Google AWS和我还没有看到无服务器的灵活性，我喜欢它，因为如果我们知道一件事，那就是事情会改变，我们应该能够在没有太多摩擦的情况下改变我们在何处托管无服务器功能的想法。如果山姆在听，那就是我圣诞节想要的。

Zhamak Dehghani:

也许这种需求会减少，因为你…也许你写的代码的数量，与平台紧密耦合，也许它更少，你可以用更少的开销移动它。但我仍然觉得有标准化的空间。

麦克罗伯茨:

是的，这是一个有点争议的领域，取决于你和谁交谈。正当一方面，是的。标准好，能够移动好。CNCF内部有一个项目，云本地计算联合会，它是。。。基金会，对不起，这是…他们所做的大部分事情就是把时间花在库伯内特身上。他们确实在帮助库伯内特家族向前发展，但其中有一个团队专注于无服务器。该小组一直在关注的一件事是这个公共事件，lambda函数的接口。所以是的，很好，这将会发生。另一方面，在你看来，Zhamak，就像从编码的角度将lambda函数移动到Azure函数一样，真的是。。。如果你做得对，那是微不足道的。

麦克罗伯茨:

因为这些都是非常非常轻量级的框架。当你构建一个lambda函数时你要做的唯一一件事就是满足函数签名，就是这样，没有库，什么都没有。所以从函数到别的东西是很简单的。但接下来是真正棘手的问题。山姆·纽曼也讨论过这个问题，这整个区域的问题不在于函数的移动，而在于函数使用了什么，对吧?如果你要建立一个高水平的无服务器服务，你会使用15 20，也许是亚马逊的服务，这些都是非常高的价值，你使用这些服务，不是因为亚马逊对你耍了什么花招，但你使用它们是因为它们加速了你如何构建和操作你的应用程序，对吧?

麦克罗伯茨:

你用的是亚马逊的Cognito之类的，这样你就不用管理自己的密码系统了。所以问题是当移动的时候。将lambda函数移动到Azure函数的想法不会改变…不是从语法的角度修改代码。它考虑的是与您交互的所有服务的语义，这些服务需要更改。这是一个大得多的问题，比函数或服务函数的通用接口要大得多。

宝拉保罗:

没错，我总是说代码是最简单的部分。我一直在关注这类事情，但我认为这也是一个漫长的旅程，像开放服务经纪人，把所有这些放在一起。

迈克·梅森:

酷。好吧，我们就到这里吧。我要感谢我的搭档，来自Thoughtworks的Zhamak和Paula Paul，还有Mike。188bet宝金博app下载迈克·罗伯茨，非常感谢你今天来到播客节目。我想给你一分钟，谈谈你是做什么的，人们可以在网上找到你。所以，把这些都告诉我们。

麦克罗伯茨:

谢谢你迈克。再次感谢你邀请我参加这个节目。你可以在交响乐网上找到我。symphony是我和我的商业伙伴John Chapin在几年前创办的一家咨询公司。所以我们真正帮助人们浏览整个云架构和云工程和开发意味着什么是在地面上,我们将愉快地坐着卷起袖子,搭配工程师正在处理这些事情,弄清楚这意味着什么,因为建筑运营和工程,现在是一个大而模糊的世界。所以，我们喜欢帮助人们弄清楚如何在那个世界中导航。你可以在交响乐团找到我们。io，或者你可以在Twitter上找到我@Mikebroberts。但是，如果你想要任何帮助，或者想要讨论这些东西，请给我写信，mike@symphonia.io，我总是喜欢听人们的问题，也喜欢了解人们是如何使用这些东西的。

迈克·梅森:

令人惊叹的谢谢，迈克。因此，对于听众来说，如果你喜欢播客，请在你用来收听我们的播客平台上给我们一个评论或明星评级，因为它确实帮助人们找到节目，增加我们的影响力。所以，非常感谢大家，我们将在下一个节目中与大家见面。