我们真的做到云原生了么？

作者 | Bert Ertman

译者 | 姚佳灵

根据 Bert Ertman 的演讲原文翻译，略有删改。Bert Ertman 没有过分宣传云原生，而是把重点放在云原生对 Java 开发人员的技能和经验的实际需求，以及其对传统系统设计的影响和冲击上。

今天会议的主题是“我们真的做到云原生了么（Are we really cloud-native）？”很显然，我要谈的是云原生计算。现在有很多大型供应商营销部门的公关人员（spin doctor）开始使用这个术语，并把它应用到他们的产品和服务上，但我认为，在此之前我们最好给出一个定义，搞清楚云原生计算到底是什么。

云计算

我们先来谈谈云计算。如果我们想知道这个叫云的神秘家伙最近发生了什么？我可以告诉大家，在过去的几年中，发生了很多事。云显然不是新的东西，但是，最近几年，我们看到出现了大量分析报告，Gartner 等公司预测并证实了云计算的崛起，而不是更传统的非云的内部开发风格。

基本上，他们是说，云服务市场在飞速增长，并且，它的增长是以传统产品为代价的，按 Gartner 的说法，Java EE 已经死了，云会长久存在。我是个热爱 Java 的人，因此，我没有抛弃 Java EE，和现在整个 Jakarta Java EE 的情况没有任何关系，但是，这样做只会让事情变得更糟。不过，如果用像 Spring 或者.net 的东西来代替 Java EE，那么，这样做或许也是可行的。云事物的到来是以其他东西为代价的。我认为，我们无法替换的可能只有 JavaScript，因为我们都知道，JavaScript 不会死，它是不死鸟，所以，它可能永远不会消失。

云计算对一般人来说意味着什么? 云计算对企业意味着什么? 我向一个朋友求助，我认为他是典型的荷兰企业家。他这样回答我，“像是在互联网上的计算机”，我们甚至为此设计了保险杠贴纸。不存在云，它只是在互联网另一端的其他人的计算机。如果 5 年前这么说，可能是正确的。这曾是云计算的状态，它只是虚拟化的，随后被放到其他地方。

不过现在，这不是真正准确地评价云的描述了。如果我们现在必须给企业解释什么是云，那么，我就会这么做。我会从微软的演示文稿中拿出一些来。告诉他们“总有一些内部开发。”是的，在云中总有一些内部组件，无论我们称为边缘计算或简单的内部组件都无关紧要。

如果非要解释下什么是云的话，我们可以认为云基本上由三个主要部件构成。当然，我们现在知道有一些传统的东西，比如基础设施即服务，它们是计算、网络、存储等的主要构件。然后我们有 PaaS，它更多的是附着在 API 上的东西，所以我们可以把它连接到我们的应用程序开发中。还有 web 服务器、数据库、消息队列系统之类的东西。

然后是第三个组件，现在还比较新，也打破了作为服务的传统，如今被称为无服务器。在我看来，这是个非常有趣的名字，在我看来，它是目前云计算中最有趣的事情之一。

计算机的进化

当我们用这种方式解释时，有兴趣的企业用户就会问：“这种无服务器的方案原理到底是什么？您能再详细说说吗？”我会做如下解释：“如果我们愿意，我们可以将无服务器看作是计算机的进化，或者把它看作是虚拟化的进化。”想象一下，不久前，当我们开发完一个软件，我们基本上是在一台真实的物理机器上安装它的。这大概是 15 年前的事情。当然，现在有些人仍然在这么做。

然后，虚拟化产生了，这意味着我们可以购买更大的物理机箱，然后，我们可以在这基础上模拟多个虚拟计算机。接着，在某个时间点，有人决定：“让我们把这些计算机移到互联网的另一端吧，”云计算就这么开始了。改进了一段时间后，我们在 Linux 内核发现了一些东西，于是有了容器。对某些人来说，容器是虚拟化或计算的顶峰。现在，这样的新闻少了，因为产生了无服务器的概念，这意味着，我们只需要运行一个较小的软件，然后，在我们需要运行它的时候，把它运行到某种云计算上。

乍一看似乎很有趣，但是，有一件事多年来一直在阻碍着我们。这就是，经过 50 年甚至 60 年的计算和软件产业发展，我们仍然坚持使用计算机的概念。每当我们创建了一个软件，为了使用它，我们就需要一台计算机。这是件很奇怪的事情，因为在某些方面，计算机可以和宠物相类比。如果我们得到一台新的计算机或一只新的宠物，我们真的很喜欢，就会给它取个名字，好好地照顾它。但是，然后，在某个时间，它变得有点迟钝了。像我们的宠物狗，即使外面在下雨，我们还是得去遛。维护变得越来越麻烦了。如果宠物死了，那么就更糟了。同样的道理也适用于计算机。我们会变得很沮丧。

与其把计算机看作是宠物，我们不如把它看作是牛。比如，我有一群牛。因为有了一群动物，我对单个的动物就不是那么感兴趣了，我感兴趣的是，这群动物生产出来的东西。在这种情况下，如果是奶牛，它们产出牛奶；如果是一堆计算机，它们产出的是计算。对我来说，无服务器，就像一把锯子，把单词“computer”的最后一个字母“r”锯掉了。这把我从在传统计算机上部署软件的做法中解脱出来了。如果我们可以摆脱这样的想法，那么，一个全新的世界就会出现，下面我将进一步解释。

中间件即托管服务？

我可爱的荷兰企业家朋友这时有点迷糊了，但是，我实际上在谈论的是，重新构想没有计算机的计算。实际上，在无服务器的世界中，仍然有计算机。最终运行我们软件的服务器仍然存在，但是，我们不再关心它们了。这一切都始于像一个函数一样在某种计算上运行，但这会朝着更有趣的方向发展，因为，如果我们勇于越过计算再前进一步，展开想象的翅膀：假如我们可以重新构想我们的中间件呢？或者甚至更高级别的服务，作为我们可以像 API 一样消费的完全托管服务呢？这将解放我们常用于硬件和基础设施安装和运行的大量时间和投资。

如果我们不再需要关心安装、运行、补丁和管理我们的数据库、web 服务器、存储解决方案等等，那么，这将节省我们大量的时间和精力，我们可以把它们用于开发软件。在某种程度上，我们可以把无服务器的整个趋势与当时引入电力对蒸汽机的影响进行比较。如果我们用这种方式来看待无服务器，那么，在某种程度上，只要在我们需要它们的时候，就可以把计算、网络、存储，还有中间件服务，甚至更高级的服务抽取出来 。

它就像一个公用程序，我们只在实际使用它的时候才付费，这可能是经济学上的模型，所以即便云计算思想早已传播开来，但也从未成为现实过，因为每次我们在云中启动一个虚拟机，我们就会让它一直运行，所以我们也一直在付钱。现在，如果我们只是按需使用计算，或数据库，或网络，或任何其他东西，只是那么一会儿，那么，我们只为那么一会儿的需求付钱。这确实是个有趣的经济模型。对我来说，这整个无服务器想法是目前云实际发展方向上非常重要的方面。最重要的云只是在互联网另一端的虚拟计算机；当然，它做不到公正，实际上也没有跟上事态发展的实际状况。

无服务器确实很重要。**不过 我们还没 真正 ** 实现 。昨天，这里有场精彩的演讲，谈到无服务器为什么在一个方向上得到了改进，但是，在其他方向上又出现了倒退。我当然不会说它是完美的，但是，我认为，我们的前进方向真的很值得肯定，不过它仍然是个很不成熟的技术。我非常渴望看到它在今后几年的发展。

这世界上正在发生什么事情？

现在，我们先把云的话题放一边。我们来看看在世界的其他地方发生了什么事情。我要说的是，除了科技之外，我们要去哪里？我们的前进方向在哪里？几年前，Marc Andreessen 写了一篇著名的论文，谈到软件正在如何吞噬这个世界，就已经为我们确定了方向。我认为，他的说法仍然正确，甚至现在发展的速度更快了一些。有很多新公司的出现证明了他们已经推翻了现有的商业模式。很多老公司的消失也证明了这确实在发生。

为了应对这个即将到来的新世界秩序，传统商业模式需要更快地发展和适应，我们需要思考如何在不破坏我们已有的一切的前提下更快地发展。如果我们看一下大多数企业，他们不像硅谷的独角兽公司只对新东西、更多新东西，甚至更新的东西感兴趣。他们要考虑自己现有的业务。他们要照顾很多已经存在的事物。我们无法做到飞速发展而不破坏已有的事物。

与此同时，在过去的 5 到 10 年里，我们想出了一些解决方案，以便尝试快速发展而不破坏事物。为了更轻松地适应变化，我们发明了微服务的整个思想，我们试图采用这个想法。然后，为了不破坏事物，我们提出了 CI/CD 等流程，我们引入了容器，使事物可以跨环境移植。后来，我们在此基础上进行了改进，于是，我们尝试转型为敏捷组织，其中不仅包含我们的开发团队，还有我们的业务团队。我们只构建真正需要的东西，并且及时地构建它们。

接着，我们在此基础上加了点 DevOps，以便能够把 CI/CD 及容器的整个思想和想法更快地集成到在生产环境中进行部署的解决方案中。在这样做的并且我们应用了所有这些东西之后，最终产生了像这样更加有趣的东西。这很好，这是来自 Netflix 架构文件的一个截屏。如果这是 Netflix 做的东西，它一定是有价值的，因为 Netflix 是微服务的典范。这是他们的架构全景，如果我们的架构全景开始看起来也像这样的话，那么结果一定也会很棒。

微服务无处不在，这很好，但是，在这个过程中，我们可能会遇到一些麻烦。转型不仅是把新的和更多的技术应用到组合中。通常以过程中组织的转型来看，还涉及很重要的组成部分。我们实际上了解到的第一件事是，开始转型时，实际企业预算的 80%-90% 用于维持现有系统。这只是维持现状。问题是，我们只剩预算的 10%-15% 用在新东西上，而且在这个 10%、15% 的范围中，我们还要用来进行实验。如果我们想要用新东西、新技术、新流程或者任何其他新东西实验的话，我们就还得去找时间和资金来做。事实证明，这确实很难。

即使我们把我们现有的工作负荷，比如说我们的 Java EE 应用程序、整个系统，用直接迁移的方式放到云上去，我们把工作负载从真实的硬件或虚拟化的内部硬件直接转到云上，然后在互联网另一端的某个虚拟机上运行，是否真的有助于我们获得更多的可用资金和时间，节省在基础设施上的投资，从而可以把资金用于其他方面？答案很简单，不能。

如果我们认为只要把应用程序移到云上，就开始省钱，那么，得到结果就是失败。在大多数情况下，情况并非如此。如果我们只看总体花费成本，那么，我们在云上运行现有的应用程序可能比在本地运行要花更多的钱。有些公司可能会说：“这应该是应用程序服务器中的框架很糟糕导致的。”接着，一些云原生 Java 书就会这样建议：用 Spring Boot 来做。

他们会做些什么？他们从小的地方开始，重写逻辑。然后，他们选中 Spring Boot 配置中的所有复选框。结果，他们得到我称为胖罐子的东西，甚至更胖的罐子，最终，就是个反向应用程序服务器。对我来说，在应用程序服务器中运行企业 Java 应用程序，或在选中所有复选框的 Spring Boot 服务器中运行它，两者没什么不同。你有你的老 Netflix 合规，但是，这并不意味着，我们在云中运行我们的程序有任何优势。对我来说，这只是应用程序服务器颠倒了一下。

有些人可能会说：“你忘了一些重要的东西，”因为我们没有把 Docker 放进去。把它放入 Docker 容器，可能会更好。好了，现在，我把它变得更便携了，而且我可以在我的笔记本上的某个测试环境中运行它，然后，再把它移到云中。我仍然没有享受到云带来的任何好处。这就是微服务的概念被引入的情况。我们说，“好，现在我们必须打破这个整体，然后创建很多更小的服务。”我们还是要把它们放入 Docker 容器，然后，放到云中的虚拟机上。

虽然这可能是做微服务的一个很好的尝试，但是，我们可能浪费了更多的资源，因为现在在云中，我们甚至需要更多的虚拟机，并且，我们必须找到大规模管理大量容器的方法。可能有人会问，“你们是在说微服务是个糟糕的想法吗？”不，这不是我在这里要传达的意思，因为，对于我来说，微服务也像一个模块化。模块化总是好的，因为它把更大的结构分解成更小的东西，这样就更容易解决问题。它隐藏了实现的细节，然后利用某种合约把这些东西连接在一起。

这是你在开始进行软件设计、内聚和耦合时首先要学习的内容。引入模块化有很多方法。有些是在代码层进行的。如果我们有个大型代码库，那么，我们可以在编程语言级别就引入模块化。借助像 Java 模块系统这样的东西，或者 OSGI，如果我们愿意，我们可以把更大的代码库分解成更小的模块，然后，把它们粘合在一起。当创新的步伐或改变的步伐加快时，我们修改东西时会更自信，因为那些东西不会崩溃。模块化始终是一个好工具。对我来说，微服务只是进行模块化的另一个层次。如果我们将整体拆分，如果把大型代码库分解成更小的部分，那么，那么我们就需要增加那个层次来实现模块化。对我来说，微服务本质上是个模块化的工具。

然后，如果我们开始把整体分解成更小的块，并在其中加入网络，那么，我们会突然意识到，这么做代价很大，因为把整体分解成更小的服务是有成本的。如果我们开始把这些东西移到云上，特别是移到公共云供应商那里，我们可能不是网络上唯一用户。那么，服务之间的依赖关系会发生怎样的变化呢？如果网络出现问题，又会发生什么呢？从 1995 年开始的分布式计算论文的谬误可能从未像今天这样真实。

因为有一大堆事情要做，所以整个设计分布式解决方案、分解后的解决方案是非常难的。我们尝试解决一件事，而得到的是一大堆新问题或挑战。Kubernetes 可能解决问题，因为这是大家的共识，但是，这是真的吗？我们把 Kubernetes 加入进来。这只是另一个抽象层。

是的，我们可能找到我在前面的幻灯片上列出的问题的解决方案。可能现在我们有更好的资源利用率，因此，我们可以用更少的虚拟计算机来解决问题，从而只需要一点点优化。但是，如何把 Kubernetes 作为平台来运行，那是个很复杂的问题，我知道有很多公司正为之苦苦挣扎。

如今，无论我们走到哪里，即使是这样的会议，都至少有一堆关于 Kubernetes 的讨论。每个人都在说，“要做这个。这是一切的未来。要做 Kubernetes。”不要误会我的意思，我并不反对 Kubernetes。我认为，它能相当好地解决问题， 但是，我想说的是，不是所有人都适合在生产环境中运行和管理 Kubernetes。我已经看到很多团队为了正确设置并投入生产运行而苦苦挣扎。这真的很难，并且，因为它是如此复杂，会阻碍很多的进步。

DevOps

另一个大问题是 DevOps。DevOps 不是什么新东西，它怎么会成为麻烦呢？DevOps 带来的问题是 DevOps 和敏捷之间有相似之处。如果我们回过头想想，当我们开始做敏捷的时候，敏捷的整个想法真的很受欢迎。我认为，我们没花多少时间就把它搞明白了。我们也没花多少时间就明白它带来的好处了，然后，我们就开始引入敏捷。

为了达到一定程度的成熟，我们花了好几年的时间来采用敏捷。这不是因为我们作为开发人员太笨了，而是因为我们被组织转型拖了后腿。只要我们从业务中获得一些支持，那么，敏捷就会变得更加成熟。如果我们认为，“产品所有者，谁需要他们？我们可以让架构师做，”那么，这么做可能是非常愚蠢的，而这就是我们这些年所得到的教训。DevOps 基本上一样。它不是关于学习一些新工具或者混合和匹配，像一些软件工程师和失业的 DBA 一样，这可能不是实现 DevOps 的方法。

DevOps 存在的问题很像恐龙，有些过时（顺便说一下，我不打算在这里讨论 DBA），可以肯定的是，它被称作 DINO，DINO 只是 DevOps 的名字。问题是，恐龙已经灭绝了。如果我们不希望我们的组织灭绝，那么，我们必须要注意如何实现 DevOps。

我们来看看传统组织是如何运行其基础设施及运维的吧。在大多数传统操作中，我们尝试标准化一切，并且有很好的理由。我们尝试标准化管理程序、所有基础设施组件，甚至编程语言。一切东西。这都是有很好的理由的，因为从另一方面来看，这是管理复杂性。我们对此进行标准化，那么，我们就不必那样做。它还应用了某种工作的标准方式，因为在非常复杂的环境中，如果有一组选择项，而不是选择我们想要的东西，那就太好了。

还有，在某种意义上来说，标准化是一种奇怪的生产力工具。通常当有人在演示中给我们展示一张冰山的图片时，如果我们这样描述它，那往往是片面的。但是，在这种情况下，这还不那么坏，因为我们通过标准化实际在做的是，我们创建了一条水线，在水线以下的都是标准化的，所以，我们的基础设施、编程语言等等一切都是标准化的。然后，我们的开发团队只专注于交付，通常是某些可以移植的东西，像容器或一年的文件或一个 Fed 罐子。我们唯一要做的是，将其放置在标准化的基础设施上。从这个意义上说，它是个生产力工具，因为在水线以下的东西都是我们所期望的。我不认为我们知道会发生什么。然后，我们只是开发软件，然后把软件和基础设施放在一起，这就是大多数组织的工作方式。

从某种角度来看，这解决了问题。从另一些角度来看，如果我们希望快速行动并且不破坏事物，那么，这可能不是我们想要的方式。如果我们尝试并把这个转换到我们现在生活的时代和空间来看，并且，我们尝试获得云计算的好处，那么，这个冰山将会看上去有点不同，它可能看起来是这样的。现在，应用程序所处的位置和基础设施所处的位置已经完全分离了。我们在这里要创建的是，把功能性组件、基础设施组件、甚至更多基础设施组件混合和匹配在一起以运行我们的基础设施组件，以及介于两者之间的一切。我们在混合，不断地混合到一种已有的解决方案中。

无论我们是否在做微服务，如果我们在想什么是应用程序，如果我们考虑一下，我们可以尝试并会得到一个答案，比如说，10 年前，2009 年我们会怎样回答。那可能是，“应用程序像我必须一起构建并测试的一堆代码。我把它扔给运维团队，希望他们能让它在他们管理的服务器上运行。我希望用户尝试使用这些应用程序，那么，我们就不会在投资和基础设施及一切其他事情上浪费太多钱。”

这是相当明显的方式，但是，现在，2019 年的回答可能是这样的：“应用程序可能是在公共云上的一些托管服务的组合，它们和我们自己高度差异化的业务逻辑连接并定制。然后，我们把一切都粘在一起，只在需要的时候才运行并被收费。当没人运行它时，我们就不用付费，如果有很多用户，那么我们就多付一些钱，但是，我们对此没有异议，因为这看起来是个非常好的经济规模。”

云原生对我来说是一场 DevOps 之旅。如果我们希望是云原生的，那么，就不是挑选一到两个框架的问题了。这是一场转型之旅，并使 DevOps 到位。我不确定，我是否可以这么说，但是，实际上是将东西连接在一起，我们可以这么称呼它。因为如果我们希望获得云的好处，那么，我们确实必须知道云供应商提供的所有服务。如果我们希望用 Docker 容器打包某种软件组件，并将 Docker 容器带到云供应商那里，比如 AWS，那么，至少有 4 种或 5 种方式可以在 AWS 上运行 Docker 容器。云原生实际上是指，找到哪种方式真正适合特定的应用程序或特定的组件。这是关于跟上我们的云供应商实际取得的所有进步，然后把它应用到我们的软件组件上。

把软件和基础设施粘合在一起还不是最后的状态。这是一个持续的过程。我们用不断出现的新服务和新组件来改善它。因为我们用微服务，这些服务也可能是暂时的。如果服务更改或被另一个服务替换，那么，因为有新的服务可用，所以部署它的新方法和部署它的旧方法可能不一样。这不是考虑服务器和大规模地管理服务，这是考虑管理一个软件和基础设施的大规模混合体。它跟服务有关，把一切作为 API 消费，并粘合在一起部署。

正如我所说的，这是一场 DevOps 之旅，因为这是关于基础设施的现代化及实际上更快前进而不破坏事物的过程。组织文化在其中发挥了重要的作用。稍后，我会回过头来讲讲。如果我们考虑一下我刚才展示的图片，这里有我们可以从云计算中挑选的三个组件。

我希望大家把这些看作是一个装满乐高组件的盒子。我们有由乐高零件组成的盒子，具有用于基础设施即服务的主要构件块，然后，我们有用于 PaaS 的组件，还有无服务器的组件。我的建议是，如果我们开始组合我们的逻辑和基础设施，那么，我们从字母开始。在这种情况下，我们从无服务器盒子开始。如果无服务器盒子提供了可以运行该逻辑任何不错的选项，那么，我一定就选它。

然而，这主要取决于我们的工作负载，是否满足非功能性需求，甚至是否满足经济上的要求。当我们实施无服务器时，它是即用即付的，仍然可能比我们用更传统的方式来解决问题更昂贵。它主要取决于工作负载，因此，通过组合来自无服务器盒子的应用程序开始，如果缺什么或不适合，那么就去 PaaS 的盒子里找找，然后开始把一些 PaaS 组件应用于解决方案。如果这还不能解决问题，那么我们就要加入一些旧的基础设施作为服务器使用。

我们仍然可以加入一些虚拟实例，一些旧的云世界的存储类型。最终，我们得到一个像这样的解决方案。同样，这是一个 AWS 示例，只是为了演示，但是，如果我们看看这个示例，我可以把一些部分突出显示出来。比如，我们看到这是无服务器技术，如 Lambda，还有 S3 存储和 API 网关等的混合体。我加入一些 PaaS 的东西，可能有一些旧服务器的东西。然后，我还有一些基础设施即服务的东西，因为我需要在一些虚拟机上运行其他东西。

最终把一切都绑在一起就是我的应用程序，或者我的应用程序环境的一部分，稍后我部署到我的云供应商。要了解我们的云供应商提供的服务，并真正把软件调试到底层基础设施，这基本上就是云原生的本质所在。技术或框架不会让我们变成云原生。有人说，“这是云原生框架。”那可能是个大谎话。它是我们使用它们的方式，我们把它嵌入给业务交付价值的流程中，因为那样，我们才最终进入获得云的真正价值的阶段。

充分利用云

如果云不再只是虚拟计算机，那么是什么呢？对我来说，它可能扰乱经济。与其在购买硬件、让专门的工作人员处理数据中心和运行所有的基础设施及管理它们上进行巨额的前期投资，现在，我可以只在需要的时候才用。我可以只集成它作为一个 API，从而可以开始实验。即使我处于传统的企业环境，只有很少的钱来用新东西启动实验，这确实是非常合适的模型。我可以从云供应商那里获得一些很酷或更高级的服务，用来开始实验，并且，如果没有按我的预期方向进行的话，我可以切断它，关掉一切，不用继续付费，因此，我的投资很小。我仍然可以节约一些钱用于其他实验。

如果按我的预期方向进行，那么，我可以尝试把它放入新的开发项目中。这就是我们开始采用来自实验的新技术的方式。这就是扰乱经济（the economic disruption）的所在。它并不意味着会更便宜，因此，如果我们使用云的主要动机是节约成本，那么，这主要取决于我们的选择。成本优化也是 DevOps 团队的责任。我们的工程师团队必须看着点儿账单。

在一些组织，这确实很古怪，因为，如果我们说，“开发人员或 DevOps 人员，他们必须查看账单，以算出这个或那个是否是运行这些东西的更好方法，”那么，可能会有一些部门会说，“不，你们不能查看我们的云账单。那是机密信息。”这只是一个例子，告诉我们需要组织转型了，因此，我们需要透明性，以便做出优化选择。

我已经提到多次了，云确实具有实验的优势。我认为，问题的关键是，作为一个企业决定我们真正的战略价值在哪里？在运营我们自己的 Kubernetes 集群中，并尝试做个云供应商？还是从更实用的角度来看，由于我们可以提供出色的服务，而不只是作为云供应商，因此而拥有的竞争优势？对于一些公司来说，这个是关于作为云供应商的问题，而对于另外一些公司来说，他们的兴趣不在这里。在这种情况下，我强烈推荐尝试从云供应商在该领域所提供的服务中受益。

我想补充一点，有些朋友可能不会让你建立自己的 Kubernetes 平台。如果我们想一想，如果要从云中获得最好的东西（我并不反对 Kubernetes），如果我们对此没有意见，如果我们认为这样做会给我们带来一些战略价值，那好，就去做吧。但是，我们可能不全是网络专家，并且，当我们开始分配技能时，会遇到这方面的专家。如果我自己可以做的话，或者，我可以利用云供应商提供的一些更高级的托管服务，并且还不错，那么，我肯定会选择其中一项。

Java 是最佳的选择吗？

我们经常被问到的另一个有趣的问题是，在这个云计算的新世界，Java 仍然是最佳的选择吗？如果我们看看网上的示例，全部都是 JavaScript 和 Python。是时候扔掉 Java 去学另一种编程语言了吗？今天早上，Brian Getson 在演讲中谈到：“如果 Java 每次被宣告死亡，我都能得到 1 美元，那么，我会是个非常有钱的人了。”我认为，他的话很正确。在这种情况下，我要说，由于 Java 语言及其生态系统都有优势，使得 Java 非常适合云计算，如果它还没出现的话。有一些非常酷的东西，如 GraaIVM，以及编译成原生代码。一些云供应商允许我们自带运行时。如果我们想这么做的话，比如说，在 AWS 上使用 Lambda，我们可以同时自带 GraaIVM 运行时。这可能会解决一些冷堆栈问题，如果我们只是在 Lambda 上运行常规 Java 功能的话，我们会遇到这些问题。

我认为，Java 会找到自己在云中的位置。一个更有趣的问题是，“Java 程序员是否适合这个云时代？”答案是，可能，假如 Java 是我们现在唯一拥有的技能，那么，我们将会面临一个艰难的时期。因为有了 DevOps，所以我们需要了解一套全新的职责和问题领域。我在网上找到这个非常棒的路径图。从程序员变成云工程师，要做些什么？除了所有的细节问题外，从选择一种编程语言或学习一种编程语言开始。然后，要理解操作系统概念。学习使用终端、管理服务器、编写脚本、低级网络的内容、中间件服务、基础设施即代码。这里还有很多东西。

所有这些我们都需要 DevOps 团队掌握，以便创建软件组件，并在这个云原生新世界中运行它们。顺便提一下，我们得选择一个云供应商，因此，我们来看看一个云供应商。这是过去几年中，AWS 的发布速度。在 2013 年，他们每天发布一个新功能。去年，他们打破了一年发布 2000 个新功能的记录，算下来，一天要发布 7 项新功能。我们如何能跟得上这些新事物的步伐？

在我们选择这个职业的时候，当我们希望从事 IT 工作时，我们就知道，我们进入了终身学习的职业。坦白地说，在过去的 15 年中，我们对此已经习以为常了，但是，现在，这么多东西在飞快地改变，而我们必须掌握这一切，不是靠我们自己，而是至少我们的团队得掌握。为了做到这一点，就需要进行组织变革。组织必须意识到这点，我们的日常工作中需要一些时间去学习掌握这一切。组织文化是非常重要的。

云原生文化

我碰到过一些非常好的云原生文化杀手。大多数都认为企业没有真正地信任 IT 部门。无论我们怎样看待开发人员或是运维人员，可能都没有用，因为永远都不会有真正的 BizDevSecOps，无论现在是用什么缩写，因为整个组织必须投入才能使之工作。另一件非常危险的事是，削减成本的心态。再说一次，如果我们是获得大量风险投资的独角兽公司，那么，我们可能不担心这件事，因为我们只考虑新的机会。但是，如果我们是传统企业，那么有大量的成本考虑。成本中心是我们很不喜欢的地方，我们一直在尝试优化它们。我们进行重组，我们试着优化成本中心。

如果我们认为 IT 是进行成本优化的方式，那么，我们可能永远不会受益于云原生，因为我们要支付极大的代价才能实现云原生。为了最终受益，我们需要极大的前期投资。如果我们只是考虑云会省钱，那么，现在有足够多的企业，他们有过一样的想法，会立即证明给我们看，我们的想法是错误的。通过使用云，现在我们要支付更多的钱来运行我们的基础设施。这样的故事无所不在。

这是非常危险的心态，不仅因为我们可能永远不会在组织中实现 DevOps，而且也因为文化似乎是人们离职的头号杀手。如果我们希望好职员离职，那么，只要我们有个真正糟糕的文化，然后，他们会都离开。这跟薪水无关，跟管理人员无关，跟文化有关。如果人们不喜欢这个组织文化，那么他们就会离开。文化是我们应该考虑的东西。

让我们试着改变这一切。要实现这个 DevOps 之旅、这个云原生之旅，真正有益的文化方面是哪些？我认为，这始于如今我们所谓的数字转型。我认为，对大多数企业来讲，是时候意识到他们不再是个银行或金融机构了，但是，他们应该意识到，他们是家 IT 公司，只是刚好处于金融服务行业。

这是非常重要的观念。我们可以从很多故事中得知， 开始接受这种观念的公司取得了巨大的飞跃。因为那样，IT 将不再是成本中心了，他们需要采用他们交付软件的流程。这比采用敏捷和 DevOps 是更自然的匹配。如果我们回想当时敏捷和 DevOps 的相似之处，我们花了大约 5 到 10 年的时间才真正做好敏捷。如果我们把这个指标用到 DevOps 上，那么要花我们 5 到 10 年的时间去做好 DevOps，我们的竞争对手将受益于所有云提供的能力，那么，我们可能没有 5 到 10 年的时间了，因为那时我们可能已经倒闭了。这是个非常令人不安的想法。

云计算实际上应该被视为一种潜在的经济干扰，目的是为了节省成本。它也是加快实验进程的完美方法。这并不意味着，如果我们开始在云中进行实验，那么，我们最终也要在云中的生产环境中运行它们。如果结果是我们想要看到的，那么，我们也可以把它放回本地运行，但是云可以帮助我们更轻松地访问所有类型的资源及更高级别的服务，我们可以利用这些服务进行一些真正低成本的实验。最终，这有望缩短上市时间。这基本上就是我们所说的软件吞噬世界。

最后，可能也是关键的一点是，我们必须考虑到我们的工程师需要拥有广泛的技能。如果只会 Java 编程，那就没什么用了。我曾经共事过的一些客户说，“我们只提供 20% 的时间，每周给你一天时间，让你体验我们的云供应商所提供的服务。”这不是构建游戏或玩游戏的一天，仍然是工作的一天，我们开始实验，探索云供应商提供的世界。我们开始探索现有的工具和框架，以便可以利用这些服务和技能。

有时候，出于某些原因还需要做认证，我们希望获得认证。或许我们可能不希望做认证，但我们的雇主希望我们得到认证。那么，我们也会花点时间来进行认证。用这段时间去实验，去学习，去相互学习，这是实现这一转变的一个非常重要的方面。

原文链接：

https://www.infoq.com/presentations/cloud-native-intro/