DevOps 已死，AppOps 长存
本文最初发布于 Medium 网站，经原作者授权由 InfoQ 中文站翻译并分享。
没错，我玩了一把标题党。很抱歉，但这样做也是有理由的。我希望大家都来关注 DevOps 中一个被人低估的新趋势，即 AppOps。
在 IT 世界中，时不时学习新的流行语是家常便饭。大多数流行术语就像流星一样，在你完全理解应该学习的内容之前就消失在了天际。还有一些概念会成为接下来几年中的趋势，比如 DevOps 和 Frontend 就是两个例子。
新的术语层出不穷，所以我们必须专注于其中真正有意义的那些。我并不相信什么流行语或者趋势，我相信的是概念。即便技术和趋势纷纷过时，概念依旧长青。
所以我会在这篇文章中讨论 AppOps 这个概念。读完本文后，当你开始听别人谈到新的 AppOps 趋势时，你就知道该怎样跟他们讨论和争论了。
NoOps 趋势
顾名思义，NoOps 趋势旨在消除开发和运维之间的所有摩擦，做法就是直接把运维去掉了。
看起来这是一个颇为激进的解决方案，但我们也用不着从字面上去理解它。正确的解释——也是可行的解释——是在部署和交付阶段尽可能移除人为因素。
这种方法自然是由云来提供支持的，云可以帮助各种事物实现自动运作。如果你有兴趣了解更多关于 NoOps 的信息，可以参考我几年前写的一篇文章。
顺便说一下，要继续阅读本文，你只需知道：
NoOps 做的就是减少部署管道中的人为因素，并将感知带入开发团队。
因此，NoOps 与 DevOps 并不冲突。相反，它说的只是在情况允许时以巧妙的方式使用 DevOps。
专注于应用
不管你正在编写的是一个小型应用程序还是一个非常大的项目，你都需要合适的 DevOps 设置才能继续下去。
我简直无法想象在 2021 年会有人通过 FTP 上传文件来更新应用程序——如果你正在这样做，请赶快停止吧。
所有人都需要 DevOps 和基础设施，但是我们真的要在上面花费时间和金钱吗？
当然，我们必须这样做，因为好处太明显了！但如果我们从投资者的角度来看这个问题，我们就会明白这不是团队的最终目标。
如果说技术是让事物由概念走向实践的推动因素，那么 DevOps 就是提高事物效率的方法。但是我们不能忘记我们的应用程序应该做的那些“事情”。
这就是 AppOps 的目的：将注意力集中在应用层面，包括源代码和基础设施。
为什么是 AppOps？
AppOps 优势体现得最明显的场景之一就是基于 Kubernetes 的应用程序。如果你打开一个个集群，你会发现很多 pod/service/deployment 设置大体都是一样的。
事实上，每个 PHP 应用程序都有相同的配置，只有参数不一样。Java、.Net 或其他应用程序也是如此。问题是 Kubernetes 对主机应用程序的内容是不可知的，因此它需要将所有细节都告知应用。
即便用的技术都是一样的，我们也必须从头开始处理所有新的应用程序，为什么？
我本应只解释一次 PHP 应用程序的组成方式。而且我不该浪费时间来定义 PHP 应用程序的部署方式，因为世界上所有的 PHP 应用程序基本上都是相同的，我希望有人（可能是供应商）向社区提供一次正确的配置来重用。假设有一个可重用的配置。你就只需要简单地开发应用程序就够了，无需再费力做那些重复性任务，不再重新发明轮子。此外，你还可以专注于真正重要的事情，不用操心什么细节。
前面我说的关于 Kubernetes 的内容还可以扩展到虚拟机、云服务等等。这就是 AppOps 的有趣之处。
AppOps 是怎样做到的？
可以想象，Kubernetes 没有什么水晶球插件可以让集群预测你正在部署的内容。Kubernetes 是一个容器编排器，将自身确立为抽象基础设施的标准，你不能强求它做更多事情。所以我们基本上有两种选择：
-
准备可以重用的配方或工件（例如一组 YAML 配置），按以前的方法做事。
-
采用一种允许你专注于应用程序、不再操心基础架构的解决方案，以云方式实现它。
我们来具体看看两种方法的细节。
老方法
老方法是最简单但最不时髦的解决方案，不过你用不着重新发明轮子了。
如果你正在使用 Kubernetes，你可以使用 Helm 或 ArgoCD 等工具自动设置应用并创建可重用的应用定义。
如果你使用的是虚拟机，一个好的解决方案是准备 Ansible 脚本。
此外，你可能有兴趣探索 Terraform 这种简单的基于云的解决方案，用它将基础设施作为代码来管理。
除了上面这些解决方案之外，你还需要制作第一个解决方案的原型，并部署这个部分。因此我更喜欢下面这种方式！
云方法
在云时代，使用现成即用的服务是加快事物实现的巨大推动力。
所以我们应该首先评估易于使用的解决方案。在 Kubernetes 领域有一些云工具，它们可以让你在应用程序级别部署，无需操心背后的事物。
第一个工具是Shipa，这是一个非常有趣的新兴解决方案，用来在没有任何 DevOps 流程的情况下部署应用程序。这个解决方案确实可以让我们只专注于应用程序开发而忘掉服务器。
第二个选项是Devtron，它提供了一个交付工作流实现，可以简化 Kubernetes 管理并让部署过程非常顺滑。这款工具与一些预定义的配方相结合，可以让我们忘掉基础设施。
我相信很快就会有越来越多的解决方案以 AppOps 的方式实现 DevOps 的目标，就像技术世界每次都会看到的那样，工具永远不会成为问题。
结语
应用程序开发和交付领域在过去几年中取得了令人难以置信的创新和发展。
Kubernetes 是加快开发速度和减少开发与运维之间摩擦的革命性工具中的一员。我们可以在网络上找到大量资源，并且云也提供了巨大的推动力。
虽然这些解决方案都推动了全球的数字化转型，但我们并没有就此止步。我们现在希望不要再为管理这些工具和复杂性付出那么多精力，这样才能更多地关注应用程序的开发，并为最终用户带来更多价值。
AppOps 是实现这一目标的一种方法。有了那些从更高视角管理基础设施的工具后，我们就能隐藏复杂性，专注于那些对业务真正重要的事情。并且这样做是可行的，我们已经有许多工具可以很好地实现这一目标。
本文由 InfoQ 翻译自 Daniele Fontani 的文章：https://betterprogramming.pub/devops-appops-f096cdbb02ac
本文文字及图片出自 InfoQ
共有 8 条讨论