便宜 服务器_无服务器更便宜，而不是更简单

便宜 服务器

by Dmitri Zimine

由Dmitri Zimine

无服务器更便宜，而不是更简单 (Serverless is cheaper, not simpler)

The (Emit) conference last week featured a lineup of excellent talks, an engaging panel discussion, and plenty of time to meet and exchange notes with the awesome fellows of the serverless community.

上周的(Emit)会议举行了一系列精彩的演讲，进行了有趣的小组讨论，并有很多时间与无服务器社区的杰出人士见面并交换笔记。

Cost is unanimously cited as the key driver for serverless adoption. On-demand execution and built-in elasticity optimizes utilization while keeping uptime and reliability even higher. Pay-per-use billing makes cost directly quantifiable. The savings can be insane. Anne Thomas, a Gartner analyst, shared at the panel discussion that her enterprise clients are attracted to serverless by “cost” benefits.

一致认为， 成本是采用无服务器的关键驱动力。 按需执行和内置的弹性可优化利用率，同时保持正常运行时间和更高的可靠性。 按使用付费计费可直接计算成本。 节省下来可能是疯狂的 。 Gartner分析师Anne Thomas在小组讨论中分享了她的企业客户被“成本”收益吸引到无服务器的趋势。

But there is no free lunch in a closed system: to gain a benefit something must be sacrificed. In technology, the most common currency to pay for benefits is “complexity”.

但是在封闭的系统中没有免费的午餐：要获得收益，就必须牺牲一些东西。 在技​​术中，支付利益最常见的货币是“复杂性”。

When microservices replaced monoliths to gain the benefit of scale reliably under massive load, it was not a free lunch. Dealing with eventual consistency, handling asynchronicity, latency and fault tolerance, managing APIs and message schemas, load balancing, running rolling upgrades — we paid with a great deal of extra complexity for the gains.

当微服务代替巨石可靠地在大规模负载下获得规模效益时， 这不是免费的午餐 。 处理最终的一致性，处理异步性，延迟和容错，管理API和消息模式，负载平衡，运行滚动升级-我们为此付出了很多额外的复杂性 。

Where does the complexity reside, and how do we manage it?

复杂性存在于何处，我们如何处理？

Take a look at the picture. The orange blocks represents the code. As we move to micro-services to serverless, the individual blocks of code become smaller and simpler, while the total complexity grows. Much of this extra complexity is “wiring”: configurations, deployment scripts, devops tooling artifacts — templates, recipes, playbooks, dockerfiles… All the stuff used to forklift the solution up to the cloud, and keep it there. The gray stuff between the orange code blocks. This reminds me of an old Russian joke:

看一下图片。 橙色块代表代码。 随着我们将微服务转移到无服务器，各个代码块变得越来越小，越来越简单，而总的复杂性却越来越高。 这种额外的复杂性大多是“接线”：配置，部署脚本，devops工具工件(模板，配方，剧本，dockerfiles…)所有用于将解决方案提升到云端并保存在那里的东西。 橙色代码块之间的灰色东西。 这让我想起了一个古老的俄罗斯玩笑：

- What is air made of?

-空气是什么制成的？

- Well, it’s made from molecules!

-好吧，它是由分子制成的！

- And what is between the molecules?

-分子之间是什么？

This wiring between the code: it better be code! And this is what DevOps was all about with it’s “Infrastructure as code” mantra. Devops — to give yet another definition — is a framework and tooling to tame the extra wiring complexity introduced by micro services.

代码之间的这种连线：最好是代码！ 而这就是DevOps的“基础架构即代码”口号。 Devops –给出另一个定义–是一种框架和工具，可以应对微服务引入的额外布线复杂性。

When Serverless replaces micro-services, it is not going to be free lunch either. We are paying by introducing more complexity, now for the benefit of massive cost savings.

当Serverless取代微服务时，它也不是免费的午餐。 我们现在通过引入更多的复杂性来付费，以节省大量成本。

Some parts of the serverless system do become simpler. Not dealing with virtual machines, networking, storage, and operation systems is a huge relief from the massive operational burden of provisioning, configuring, monitoring and remediating infrastructure. Functions provide a simple programming model and mostly focus on business logic. The execution environment is tight, controlled and under “continuous X-Ray”. Chris Anderson, a PM for @AzureFunctions, highlighted how much easier it became to pinpoint problems with function executions.

无服务器系统的某些部分确实变得更加简单。 不处理虚拟机，网络，存储和操作系统，可以极大地缓解调配，配置，监视和修复基础架构的巨大运营负担。 函数提供了一个简单的编程模型，并且主要集中在业务逻辑上。 执行环境是紧密的，受控的并且在“连续X射线”下。 @AzureFunctions的项目经理 克里斯·安德森 ( Chris Anderson)指出了查明函数执行中的问题变得更加容易。

But the law of conservation still applies, and when function are simplified, the released complexity moves somewhere else. Where does the complexity go, and how do we manage it?

但是，守恒定律仍然适用，并且在简化功能时，释放的复杂性会转移到其他地方。 复杂性到哪里去了，我们该如何处理？

Part of complexity is delegated to cloud PaaS services (may I call it JPaaS? [3]) . AWS API Gateway, S3, Kinesis, SNS, DynamoDB, StepFunctions, or their Azure and GCP siblings — are at play with any serverless solution. They are readily available, fully managed, feature rich, “infinitely” scalable, and pay-per use. To gain their benefits, we happily trade control — another common tech currency — to be liberated from infrastructure and boilerplate concerns. Note the return from micro-services’ “Smart endpoints and dumb pipes” back to “dumb endpoints and smart pipes” and even the workflows; spend a minute to reflect on this pendulum sway.

复杂性的一部分委托给云PaaS服务(我可以称之为JPaaS吗？[3])。 AWS API Gateway，S3，Kinesis，SNS，DynamoDB，StepFunctions或它们的Azure和GCP兄弟姐妹–与任何无服务器解决方案都在起作用。 它们随时可用，完全管理，功能丰富，“无限”可扩展且按使用付费。 为了获得自己的利益，我们高兴地贸易管制-另一种常见的高科技货币-从基础设施和样板的担忧中解放出来。 请注意，从微服务的“智能端点和哑管道”返回到“哑端点和灵管道”甚至工作流； 花一点时间思考一下这个摆摆。

Sometimes, the surrender of control backfires and complexity unexpectedly spikes where things used to be simple. Setting up binary headers in AWS API Gateway via CloudFormation templates makes you miss the clarity of handling it in your microservice’s code. Using feature-rich JPaaS services requires deep expertise, and unlike regular programming and CS this expertise doesn’t translate between platforms: knowing DymanoDB will be little help in learning BigTable.

有时，控制适得其反和复杂性的投降会意外地使事情变得简单。 通过CloudFormation模板在AWS API Gateway中设置二进制标头会使您错过在微服务代码中处理它的清晰性。 使用功能丰富的JPaaS服务需要深厚的专业知识，并且与常规编程和CS不同，该专业知识不会在平台之间转换：了解DymanoDB对学习BigTable几乎没有帮助。

Nevertheless, the delegation to JPaaS is a net positive and covers a good part of complexity. But not all of it. The other part of complexity lies, again, in “wiring”.

尽管如此，派往JPaaS的代表团还是一个积极的人，涵盖了很大一部分复杂性。 但并非全部。 同样，复杂性的另一部分在于“布线”。

Functions are smaller, but there are an order of magnitude more relations to understand and dependencies to manage. Functions are simpler, but they no longer contain the logical flow. The logic and the flow of the end-to-end solution is driven by events. It no longer resides in any coding artifacts, and becomes very difficult to reason about.

功能较小，但是要理解的关系和要管理的依赖关系要多一个数量级。 函数比较简单，但是不再包含逻辑流程。 端到端解决方案的逻辑和流程受事件驱动。 它不再驻留在任何编码工件中，并且变得很难推理。

How is this side of complexity handled today? Not too well. It takes uber-architect(s) to keep it under control. The processes and tools are yet to catch up. Serverless frameworks are growing like mushrooms after the rain but are mostly stuck with FaaS — with slight variations on the same, an already solved problem. Even the most advanced ‘serverless’ framework, and the one that recognizes that Serverless is more than FaaS, and provides plugins and native resource support for other services — even ‘serverless’ doesn’t cover the end-to-end wiring complexity of a serverless solution. Take the canonical HelloRetail serverless project code and inspect how much complexity is left-out. The “project”, the services’ dependencies on JPaaS and each other, the deployment order, event types and schemas and many more are not covered by the framework. They are partially scripted, partially documented, but mainly residing in the heads of the “uber-architects” or as tribal knowledge (which, in software, is also known as “trouble knowledge”).

今天如何处理复杂性的这一方面？ 不太好。 它需要uber-architect进行控制。 流程和工具尚未赶上。 无服务器框架在雨后如雨后春笋般生长，但大部分都被FaaS所卡住-相同的情况下，已经解决的问题略有变化。 即使是最先进的“无服务器”框架，也认识到Serverless不仅是FaaS，而且还为其他服务提供插件和本机资源支持，即使“无服务器”也无法涵盖服务器端到端布线的复杂性。无服务器解决方案。 取得标准的HelloRetail无服务器项目代码，并检查剩下的复杂性。 框架未涵盖“项目”，服务对JPaaS的依赖以及彼此之间的依赖关系，部署顺序，事件类型和模式等。 它们是部分脚本，部分文档，但主要存在于“超级建筑师”的脑袋或部落知识(在软件中也称为“麻烦知识”)。

What about DevOps? Shouldn’t it help? The answer is NO, or, at least, not entirely. For one thing, DevOps folks obviously don’t flock around serverless nearly as much as they do around kubernetes. Why so? Maybe our maker-persona DevOps friends just don’t have enough infrastructure knobs and levers to tinker with? Or maybe the reason is more fundamental: DevOps is a response to another problem space — microservices — and not fully applicable to serverless as many microservice assumptions no longer hold. Taking away “ssh to the box” alone retires half of DevOps tooling. Even Terraform, built to codify cloud infrastructures, is somehow not nearly in as much favor in the Serverless community as it is in microservices DevOps.

那么DevOps呢？ 它不应该帮忙吗？ 答案是否定的，或者至少不是全部。 一方面，DevOps的人们显然没有像围绕kubernetes那样拥挤无服务器。 为什么这样？ 也许我们的制造商角色DevOps朋友只是没有足够的基础设施旋钮和杠杆来进行修补？ 也许原因可能更根本：DevOps是对另一个问题空间(微服务)的回应，并且由于许多微服务假设不再成立，因此不能完全适用于无服务器。 仅消除“ ssh to the box”就可以淘汰一半的DevOps工具。 即使是为统一云基础架构而构建的Terraform，在某种程度上也没有像无服务社区那样受到微服务DevOps的青睐。

As the result, serverless today lacks the established operational frameworks, patterns, and tooling that are required to tame it’s complexity. It requires an uber-architect to invent the end-to-end solution and tame complexity. These uber-architects are blazing the path and show success and helping the patterns emerge. But as Anne from Gartner pointed out at the (Emit) conference panel, there will be no widespread serverless adoption until the frameworks and tooling catch up.

结果，当今的无服务器缺乏缺乏解决复杂性所需的已建立的操作框架，模式和工具。 它需要一个超级架构师来发明端到端解决方案和驯服的复杂性。 这些超级建筑师正在开拓道路，展示成功，并帮助模式浮现。 但是，正如来自Gartner的Anne在(Emit)会议小组上指出的那样，直到框架和工具赶上来之前，才会广泛采用无服务器。

Like many times before, challenge is an opportunity. DevOps came to tame complexity of micro-services and made cloud apps “possible”. Something is coming to tame complexity of serverless and make cloud apps “economical”. Whatever it is, it’s gonna be big. When it comes to $, economical forces work flawlessly. The cost saving benefits of serverless are so clear and so substantial, and the push from all major cloud vendors towards serverless is so strong, that it won’t be long before the complexity is tamed and serverless becomes mainstream in all the areas where it applies.

和以前一样，挑战是机遇。 DevOps应对了微服务的复杂性，并使云应用“成为可能”。 驯服无服务器的复杂性的某些事情正在使云应用“经济”。 不管是什么，它将变得很大。 说到美元，经济力量可以完美地发挥作用。 无服务器的节省成本的好处是如此明显和可观，所有主要云供应商向无服务器的推动是如此强大，以至于不久就可以解决复杂性并使无服务器成为所有应用领域的主流。 。

Thanks for reading. Please share your comments and your thoughts on the future of serverless here and on Twitter. And if you enjoyed reading this and want me to write more articles like it, just tap the “clap” button.

谢谢阅读。 请在此处和Twitter上分享您对无服务器未来的评论和想法。 如果您喜欢阅读本文，并希望我写更多类似的文章，请点击“拍手”按钮。

PS. You may be insterested in Hackernews discussion and comments on this article.

PS。 您可能会对Hackernews的讨论和对本文的评论感到迷惑 。

翻译自: https://www.freecodecamp.org/news/serverless-is-cheaper-not-simpler-a10c4fc30e49/

便宜 服务器