DevOps成为“新的遗产”，更高阶的技能是SRE

在这个领域，我常与工具制造者、创新者以及那些那些引领“无服务器”云应用的开发人员一起沟通。本次，我与Kelsey Hightower进行了交谈，他是谷歌云平台的开发引领者以及“Kubernetes Up and Running”的联合作者。为保证质量，以下访谈内容已被精编过。（译者注：黄色对话框为“我”，蓝色对话框为Kelsey Hightower）

Q: Kelsey ，你是 Google 开源容器编排系统 Kubernetes 的领导专家。 你是如何参与 Kubernetes 的，最初让你兴奋的是什么？

A: 我先说一点背景帮助大家理解，我以前做过财务、初创公司以及网络托管的系统管理员；曾经在一些数据中心工作过，我深知基础设施管理的痛点。我知道在容器出现之前，所有的维护类型 “一次写入，随处运行” 、虚拟化、配置管理等。

从一个系统管理员转变为开发人员，我知道怎么维护代码，也知道如何处理开发人员和运维人员之间的摩擦。

几年前，我在一家叫 “CoreOS” 做容器的公司工作，我在那得知了谷歌在2014在 DockerCon 发布了 Kubernetes 。他们发了新闻稿和一个 GitHub 仓库，但由于没有文档，你无法真正使用该项目。

所以，我撸起袖子，深挖代码，并发表了第一篇文章“如何在你的电脑上安装 Kubernetes 以及如何玩转它”。这篇文章在《HackerNews》排名第一，谷歌的新闻稿排名第二，这也就意味着刚才说的 CoreOS 在 Kubernetes 社区找到了自己的位置。

但当时的 CoreOS 并没有致力于 Kubernetes 的探究，所以我就在家努力。晚上，我就投入 bug 得修复和重构测试，组织代码。在我在台上讲述 Kubernetes 之前，我是 Kubernetes 的贡献者。

我对 Kubernetes 感到兴奋，因为我知道它能解决我过去遇到的问题。如果十年前我有这个，生活就会更好。所以我清楚地知道它可以改善人们工作的潜力，不是未来，而是现在！

Q: 那么 Kubernetes 究竟是如何改善人们的生活的呢?

A: 如果你把 Kubernetes 拟人化，它正在做最优秀的系统管理员做的事情。如果我给你一段代码，它可以很容易的被部署到对应的环境中。

特别是三、四年前，在我们拥有卷和所有这些网络技术之前，Kubernetes 的核心价值非常明显: 部署和管理容器。

你有一些容器和一些机器。使用 Kubernetes ，你可以使用非常小的配置片段运行这个容器，然后只观察它的运行。如果你毁坏了一台机器， Kubernetes 会将容器“移动”到不同的机器上。仅这一点就比大多数人正在做的事情更先进，即使是在今天。

Q: 三四年后的今天，Kubernetes 正在蚕食着容器的世界。但是同时也出现了“无服务器”技术，即服务功能，它解决了你刚才提到的一些基础设施管理问题。你对 FaaS 这个概念有什么看法?

A: 我第一次看到 FaaS 的想法是在 CGI 时代。编写一些 PHP 代码，把它放在 Apache 后面，然后 Apache 在收到 HTTP 请求时调用它。当时的限制是:没有可伸缩性，没有云的概念，也没有针对每种语言的整洁API 。

现在我们看到 Amazon 在 Lambda 上又做了一次尝试。他们说:“现在我们有了云，并且对这个弹性计算环境可以做什么有了一些了解，我们可以使用你的源代码并将其与云上其余部分——身份验证、数据库和 API 网关——一起运行了。“

Q: Lambda 和 CGI 脚本之间的另一个差异是成本模型。你认为功能性计费会改变游戏规则吗?

A: 我可以理解“每次调用付费”的成本模型。我几乎把它看作是进入云的更大部分的入口。

我个人认为 FaaS 是云的编程环境。作为云提供商，我有事件、消息队列和所有这些服务——这就是我提供的价值。我不会向你收取 SDK 的费用来利用这些服务。这就是为什么我不想在函数的成本上设置一个巨大的障碍。

Q: 实际上，你可以在 Kubernetes 集群上运行函数 Kubeless 。这对你来说是两全其美吗?

A: 如果你有一个基于 vm 的环境，那么在运行应用程序之前，你需要做大量的工作。

Kubernetes 用更好的抽象提高了标准——你只需给它一个容器，声明它应该如何运行，就可以了。但是 Kubernetes 仍然缺少一些关键的工作，比如由无服务器平台提供的工作。如果你想要这些工作，你可以通过安装类似于 Kubeless 的东西，在 Kubernetes 上对它们进行分层。

现在你可以上传代码片段(也称为函数)并运行它了。记住，所有这些 FaaS 产品会在盖子下建造一个容器。但是对于 Kubernetes ，它是开源的，你有充分的可见性和控制力。

FaaS 为某些用例提供了一个很好的抽象，但它并不适合所有人。Kubernetes 代表了当今大多数人能够理解和利用的最高抽象级别，特别是来自VMs的抽象级别。然后无服务器是上面的一个步骤。

如果你有一个 Kubernetes 集群，多年来我们已经看到它得到了广泛的采用，那么在其上运行 Lambda 这样的工作难道不是很好吗?所有必要的抽象都在那里，这使 Kubernetes 成为人们用来在其上创建新工作的基础。甚至 Serverless 。

Q: 长期来看，Kubernetes 会继续成为人们所熟悉的抽象，还是会有更多的人向上移动技术栈并在 FaaS 级别上构建?

A: 人们应该为他们正在做的事情使用正确的抽象。例如，当我编写谷歌 Assistant 集成时，我只想运行响应用户查询的代码片段。我可以在谷歌云函数上运行。我不需要容器，不需要数据量或存储，我只想作为一个函数运行它。它是该用例的完美抽象。

现在，如果我想做一些机器学习，使用 TensorFlow ，然后我想给我的代码一个完整的容器，它可以装载一个数据量，使用一个 GPU ，这并不是当今无服务器平台的最佳位置。所以我认为人们应该做的是使用最高层次的抽象。

Q: 我们也正在远离传统上与 DevOps 相关的技能。当我为这个系列采访 Simon Wardley 时，他说 DevOps 是“新的遗产”。这和你的经验相符吗?

A: 我同意 Simon 的观点。我认为在科技领域，每当我们学习一门学科，我们就给它起一个名字。“我是一名系统管理员。我做 DevOps 、我做 SRE ”。我们真正想说的是:在这一点上，我们要检查我们的纪律（discipline），给它起个名字。

应该发生的是，在我们给一个纪律命名之后，它应该融入到技术中去。你没有理由要做 40 年的 DevOps 。一旦我们得到正确的实践，它应该变成技术。

Kubernetes 出生在 DevOps 。即使它起源于谷歌，它也不一定是谷歌内部的克隆，它实际上很好地配合了 Docker 社区中正在发生的事情以及来自 Puppet 和 Chef 的人们试图实现的内容。

我们的意思是，如果你使用配置管理来部署应用程序， Kubernetes 将我们所学的知识作为一个集体社区，并将其设置为默认值，从而简化了部署。我们不再需要“编写”最佳实践。

如果一个节点失败了，戴上“ DevOps 帽子”，你会怎么做?你将自动将服务故障转移到另一台机器。这是 Kubernetes 所固有的。我们还通过 DevOps 实践了解到，你应该拥有集中的日志和监视等功能。

你知道吗，Kubernetes 已经打开了盒子。所以我们已经将许多 DevOps 实践应用到技术中。当我说到“我们”的时候，我指的是所有对 Kubernetes 项目做出贡献的人。

Q: 如果现在许多这些经典的 DevOps 规程都已经自动化了，那么人们应该掌握的下一个更高阶的技能是什么呢?

A: 站点可靠性工程（SRE）。现在你有了一个像 Kubernetes 这样的系统，甚至 Lambda 这样的系统——谁来监视监视者?即使云提供商正在做所有的事情，我也需要再次检查我的延迟是否在客户需要的地方?供应商会尽最大努力为我提供优质服务，但如果我的客户不同意，那么我就有问题了。

也许我使用了错误的库，或是无用的数据库。这就是你的 SRE 团队增加了很多价值的地方。谁在乎部署?一言为定。但是一旦部署完毕，我该如何调整客户的体验呢?

在这里，我们可以解放自己，处理待办事项。每个 DevOps 人员都有一个 backlog 。“总有一天我们会得到集中监控。总有一天我们会得到 CI/CD 。“好吧，现在你就可以开始反击。

Q: 你认为谷歌云平台使用 无服务器 和/或 Kubernetes 做了什么真正让你兴奋的事情?

A: 我们相信我们已经做了无服务器很长时间了。App Engine无疑代表了 AWS 自上次 re:Invent大会以来一直在说的:无服务器不只是 FaaS 。我们希望给人们带来无痛使用的体验，我们相信 App Engine 已经这样做了近8年。或者 BigQuery ——它是完全管理的，你只需运行查询并决定希望它运行得多快。

在计算方面，我们有云功能，通过添加对更多编程语言和特性的支持，我们将 FaaS 产品扩展到更广泛的开发人员社区，这些编程语言和特性让人们关注代码，而不是基础设施。

我们也有人们不一定知道的端到端解决方案:我们已经将云功能集成到对话流中。如果你想为谷歌助手构建自己的 Alexa 技能或谷歌操作，你可以使用对话流。在构建这些技能或操作时，所有 ML 培训都在浏览器中完成，在后台利用 GCP 。

这就是无服务器的思想和价值所在。你没有提供基础设施，但仍然在进行计算。因此，我们已经采用了无服务器的思想并将其真正接近于价值线。

Q: 读这篇文章的一些人现在会感到有点沮丧。他们可能会想:“ Kubernetes 和 serverless 太酷了，但我不会在日常工作中使用它们。”现在让我和我的组织参与进来是不是太晚了?“你能给这些人一些鼓励或建议吗?”

A: 我想说:“你已经具备了开始采用这些新技术的必要技能。”这些技能来自于管理 Kubernetes 之前的平台所付出的鲜血、汗水和眼泪。

他们比任何人都更了解自己的组织，所以无论技术环境如何变化，他们都是有价值的。

所以我们为“没有人能从你那里夺走它，没有服务器，没有云提供商”而自豪。

但你必须采取行动，展示你的价值。这就是我认为人们会犯错误的地方。他们走进来，想要进行一次 Kubernetes 式的对话，或者一次没有服务器的对话。他们应该做的是说“我的团队或组织想要做什么?”

也许你的开发人员抱怨说，在他们能够完成某些工作之前，必须先启动基础设施。告诉他们:“试试这个。上线你的代码并观察它的部署。“如果他们看到其中的价值，他们会支持你，支持你的经历。”然后有一天你可以告诉他们这是 Kubernetes ，或者 Lambda ，或者别的什么。

我们必须变得更有商业头脑，谈谈为什么我们想做一件不同的事情，而不是穿着 Kubernetes 的衬衫到处走，比如:“嘿，我去参加了一个会议，我认为我们现在应该做 Kubernetes。”

慢下来!你确切地知道业务问题在哪里。解决问题，然后再讨论 Kubernetes 。