内容简介：但我已经清楚的是，对于使用Serverless作为术语的个人，以及正在构建服务并称之为Serverless的供应商，仍然有一些基本方面需要澄清。所以，让我带你去了解一下为什么我认为Serverless是Cloud 2.0的开始。
最近几个月，我已经停止写关于Serverless的博客了。 这有很多原因，但很多原因都是因为我感觉已经没有太多的东西来增加讨论了。 不是因为我没有什么新鲜事要说，而是因为我已经在以前的博客帖子、Twitter帖子或录音谈话中说了很多。 过了一阵子，这些谈话和要点对我来 说并不新鲜了，一遍又一遍地说同样的话，对我来说真的很难，也有点毫无意义。
但我已经清楚的是，对于使用Serverless作为术语的个人，以及正在构建服务并称之为Serverless的供应商，仍然有一些基本方面需要澄清。
所以，让我带你去了解一下为什么我认为Serverless是Cloud 2.0的开始。
一、代码为王的时代
在技术发展的很长一段时间里，构建网络化应用程序依赖于软件。要知道发生了什么事情，你必须非常了解的软件，或者了解从某个地方下载并部署的软件。
开源运动在一定程度上是对试图控制互联网软件供应的主要软件公司的反应，这导致了一些难以置信的 工具 和服务的惊人爆炸式增长。
在20世纪90年代末和21世纪初，我们看到了一些开源技术的出现，尤其是LAMP技术栈，为围绕着互联网的令人难以置信的一系列创新奠定了基础。
随着虚拟化技术的出现，“代码为王”似乎是不可避免的，这导致了云服务和能够改变技术方向的巨无霸云供应商。
云服务成为了规范，尽管许多公司仍然停留在内部私有云时代，但它肯定正在成为企业的事实标准。
所有这些都是以能够 将 自己的代码上传到云端 为前提的。
代码为王，程序员正在制造新的国王。 https://thenewkingmakers.com/ —正如Redmonk的Stephen O’Grady所说，这句话由来已久。
这就 是很久以来的情况。 开发人员开发软件，运维团队管理基础设施，虽然DevOps运动为这些团队提供了更好的合作方式——CI/CD、流程自动化、理解的改进——但这种分离仍然存在。
二、Serverless模糊了开发和运维边界
很快Serverless来了。而很多人会争论什么时候Serverless出现（以及它是什么！）我绝对会把Serverless的诞生与2014年在Re：invent推出的AWS lambda联系起来（我不会解释为什么我要在这里这样做，这并不完全相关）。Serverless!=FaaS，FaaS是Serverless的主要推动者，这是一个突破，意味着它成为主流。
对我来说，关键是，Serverless依赖的开发人员，需要比以往任何时候都更高的层次去理解运维。也就是说，开发人员需要了解软件如何实现容量伸缩的行为，包括：怎么扩容到100和缩容到零，以及数据访问行为等，诸如：使用峰值如何影响数据访问或类似的情况。
我对Serverless的定义也是经济层面的：
“一个Serverless应用程序是指在无人使用的情况下运行它不需要花费任何成本，但不包括数据存储成本。”
因此，这依赖于开发人员至少在一定程度上理解他们是业务的一部分，而不是孤立于业务决策。当涉及到云计算时，这通常更像是运营团队职责的一部分。
当您使用所有这些元素时，与以前的范例相比，开发人员在新的Serverless世界中承担更多的责任。
对于开发人员来说，不了解Serverless解决方案中更改的影响以及发生的意外后果（具有财务影响）要容易得多。
Serverless的转变依赖于他们对基础设施如何工作的理解，实际上更少地依赖于他们的代码质量多好或多差。
这给我们带来了一个有趣的观点。
三、“代码就是王者”时代已过时，“基础设施”是新王者
当您以Serverless的方式构建时，您通常更依赖于云提供商提供的服务。正如人们经常提到的，Serverless不是一个好名字，“服务型的”可能是一个更好的名字。
这是有道理的。 了解要使用的服务以及什么时候是构建一个好的Serverless应用程序的关键元素。
但这只是Serverless模式转变的一部分。第二部分并不总是那么明显。
您实际上需要尽可能少的代码。
因为代码是一种责任。
我不是唯一一个从上面的tweet看出结论的人。其他人，如：Joe Emison，谈到在Serverless的范例时，认为LOC（代码行数）需要保持尽可能的少。
因为如果代码更少，那么复杂性就更少。
这包括 您的基础结构 ，它应该是某种定义语言的形式，允许您部署应用程序。因为当您构建一个Serverless应用程序时，您正在创建连接服务的基础结构和业务逻辑，以及一些“代码”，其中“代码”只是您编写的代码，以实现服务无法实现的功能。
事实上，您的代码远不如您如何设计应用程序重要。这仍然很重要，但比以前要少得多。如何利用云服务成为您的应用程序。
我建议这样做：
最终的Serverless应用程序中根本没有代码
四、Cloud2.0： 基础架构为王
为什么我把这个叫做“C loud 2.0 ”，并把它变成一个“新事物”，好像它在某种程度上有所不同？
这真的很简单。
到目前为止，云计算的概念一直是关于构建应用程序和部署到服务器、实例容器上。
Serverless，“Cloud 2.0”不再是那么回事了。
Serverless的目标是将代码减少到零，并使用云供应商服务尽可能多地完成工作。这就是为什么当有人跟我说“在K8S上运行FaaS”是Serverless的时候，我觉得这很令人困惑。对我来说，这严重地增加了代码的数量，减少了正在使用的服务的数量，与Serverless的想法完全相反。是的，它使用“函数”，如果这是使某个东西变得Serverless的唯一定义，那么很好，但是如果您看一下上面的内容，这种方法就变得荒谬了。
上世纪90年代末，我在一所大学的数据中心开始了我的技术生涯，并且是一名系统管理员。我知道运行实际的机器和处理所有问题意味着什么。我整个职业生涯都在努力避免那些问题。
云供应商花了十多年的时间来构建服务，以便用户不必构建复杂的系统。
如果您可以简单地从云提供商处购买服务，那么为什么您要在K8S之上运行自己的服务功能，或者在云提供商上运行类似的服务功能？从LOC/维护/时间/努力的角度来看，这真的没有意义，除非你必须使用on-prem或类似产品，否则我不理解。
如果你还想，那就去吧。
但几乎可以肯定的是，你不再需要了。
五、Cloud 2.0： 谁创造了新国王？
以Stephen O’Grady和他书中的词组为例，我想知道新的国王会是谁？
我有一些想法。
我认为会是那些掌握了这种新的“基础设施就是王者”模式的人。
我认为会是那些明白了完美的代码不再是成功的必要条件的人。
我认为会是那些明白了无论你今天写的代码，都是明天的技术债务的人。
我认为会是那些明白了工作背后的商业规则比技术成就更重要的人。
我认为会是Serverless的架构师……
......以及那些理解高伸缩性和可用性云服务，并知道如何编写高度优化和最小化的代码来将它们连接在一起，并对技术债务持非常务实的观点的人。
六、但是，我们仍未到达......
这个新世界缺少工具、故事和英雄。
目前，我们正在使用Cloud 1.0工具来尝试提供Serverless解决方案。
目前，科技界还没有为这些新工具做好准备。
不过我们离得不远。
Cloud 2.0是Serverless
这就是我们将要结束的地方。我敢肯定！
原文链接：
https://medium.com/@PaulDJohnston/cloud-2-0-code-is-no-longer-king-serverless-has-dethroned-it-c6dc955db9d5
译者介绍：
ArthurGuo 职场老司机。21世纪初开始拥抱开源，后转型项目管理。现在某云计算公司担任技术总监。掌握多门计算机语言，但更擅长人类语言。爱玩文字，不喜毒舌。
↓↓ 点击"阅读原文" 【加入云技术社区】
相关阅读：
RightScale 2019年云状况调查报告：35% 的云支出被浪费「附50页PDF下载」
2018年云计算九大趋势热词：Serverless、混合云、多云、中台、边缘计算等「附下载」
更多文章 请关注
文章好看点这里[在看]:point_down:
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- 算法当道！为什么人类和人工智能越来越像？
- 30万人黑客组织紧盯区块链 熊市当道攻击事件或将加剧
- 马克·库班论战史蒂夫·凯斯：AI当道，20年后程序员或将失业
- 低代码、无代码、零代码
- 代码分析驱动代码质量
- 代码结构及一些代码规范建议
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
