DevOps 已死,AppOps 长存

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介:   本文最初发布于 Medium 网站,经原作者授权由 InfoQ 中文站翻译并分享。  没错,我玩了一把标题党。很抱歉,但这样做也是有理由的。我希望大家都来关注 DevOps 中一个被人低估的新趋势,即 AppOps。  在 IT 世界中,时不时学习新的流行语是家常便饭。大多数流行术语就像流星一样,在你完全理解应该学习的内容之前就消失在了天际。还有一些概念会成为接下来几年中的趋势,比如 DevOps 和 Frontend 就是两个例子。  新的术语层出不穷,所以我们必须专注于其中真正有意义的那些。我并不相信什么流行语或者趋势,我相信的是概念。即便技术和趋势纷纷过时,概念依旧长青。

  本文最初发布于 Medium 网站,经原作者授权由 InfoQ 中文站翻译并分享。

  没错,我玩了一把标题党。很抱歉,但这样做也是有理由的。我希望大家都来关注 DevOps 中一个被人低估的新趋势,即 AppOps。

  在 IT 世界中,时不时学习新的流行语是家常便饭。大多数流行术语就像流星一样,在你完全理解应该学习的内容之前就消失在了天际。还有一些概念会成为接下来几年中的趋势,比如 DevOps 和 Frontend 就是两个例子。

  新的术语层出不穷,所以我们必须专注于其中真正有意义的那些。我并不相信什么流行语或者趋势,我相信的是概念。即便技术和趋势纷纷过时,概念依旧长青。

  所以我会在这篇文章中讨论 AppOps 这个概念。读完本文后,当你开始听别人谈到新的 AppOps 趋势时,你就知道该怎样跟他们讨论和争论了。

  顾名思义,NoOps 趋势旨在消除开发和运维之间的所有摩擦,做法就是直接把运维去掉了。

  看起来这是一个颇为激进的解决方案,但我们也用不着从字面上去理解它。正确的解释——也是可行的解释——是在部署和交付阶段尽可能移除人为因素。

  这种方法自然是由云来提供支持的,云可以帮助各种事物实现自动运作。如果你有兴趣了解更多关于 NoOps 的信息,可以参考我几年前写的一篇文章。

  顺便说一下,要继续阅读本文,你只需知道:

  NoOps 做的就是减少部署管道中的人为因素,并将感知带入开发团队。

  因此,NoOps 与 DevOps 并不冲突。相反,它说的只是在情况允许时以巧妙的方式使用 DevOps。

  不管你正在编写的是一个小型应用程序还是一个非常大的项目,你都需要合适的 DevOps 设置才能继续下去。

  我简直无法想象在 2021 年会有人通过 FTP 上传文件来更新应用程序——如果你正在这样做,请赶快停止吧。

  所有人都需要 DevOps 和基础设施,但是我们真的要在上面花费时间和金钱吗?

  当然,我们必须这样做,因为好处太明显了!但如果我们从投资者的角度来看这个问题,我们就会明白这不是团队的最终目标。

  如果说技术是让事物由概念走向实践的推动因素,那么 DevOps 就是提高事物效率的方法。但是我们不能忘记我们的应用程序应该做的那些“事情”。

  这就是 AppOps 的目的:将注意力集中在应用层面,包括源代码和基础设施。

  AppOps 优势体现得最明显的场景之一就是基于 Kubernetes 的应用程序。如果你打开一个个集群,你会发现很多 pod/service/deployment 设置大体都是一样的。

  事实上,每个 PHP 应用程序都有相同的配置,只有参数不一样。Java、.Net 或其他应用程序也是如此。问题是 Kubernetes 对主机应用程序的内容是不可知的,因此它需要将所有细节都告知应用。

  即便用的技术都是一样的,我们也必须从头开始处理所有新的应用程序,为什么?

  我本应只解释一次 PHP 应用程序的组成方式。而且我不该浪费时间来定义 PHP 应用程序的部署方式,因为世界上所有的 PHP 应用程序基本上都是相同的,我希望有人(可能是供应商)向全日制社区提供一次正确的配置来重用。假设有一个可重用的配置。你就只需要简单地开发应用程序就够了,无需再费力做那些重复性任务,不再重新发明轮子。此外,你还可以专注于真正重要的事情,不用操心什么细节。

  前面我说的关于 Kubernetes 的内容还可以扩展到虚拟机、云服务等等。这就是 AppOps 的有趣之处。

  可以想象,Kubernetes 没有什么水晶球插件可以让集群预测你正在部署的购物内容。Kubernetes 是一个容器编排器,将自身确立为抽象基础设施的标准,你不能强求它做更多事情。所以我们基本上有两种选择:

  准备可以重用的配方或工件(例如一组 YAML 配置),按以前的方法做事。采用一种允许你专注于应用程序、不再操心基础架构的解决方案,以云方式实现它。

  我们来具体看看两种方法的细节。

  老方法是最简单但最不时髦的解决方案,不过你用不着重新发明轮子了。

  如果你正在使用 Kubernetes,你可以使用 Helm 或 ArgoCD 等工具自动设置应用并创建可重用的应用定义。

  如果你使用的是虚拟机,一个好的解决方案是准备 Ansible 脚本。

  此外,你可能有兴趣探索 Terraform 这种简单的基于云的解决方案,用它将基础设施作为代码来管理。

  除了上面这些解决方案之外,你还需要制作第一个解决方案的原型,并部署这个部分。因此我更喜欢下面这种方式!

  在云时代,使用现成即用的服务是加快事物实现的巨大推动力。

  所以我们应该首先评估易于使用的解决方案。在 Kubernetes 领域有一些云工具,它们可以让你在应用程序级别部署,无需操心背后的事物。

  第一个工具是Shipa,这是一个非常有趣的新兴解决方案,用来在没有任何 DevOps 流程的情况下部署应用程序。这个解决方案确实可以让我们只专注于应用程序开发而忘掉服务器。

  第二个选项是Devtron,它提供了一个交付工作流实现,可以简化 Kubernetes 管理并让部署过程非常顺滑。这款工具与一些预定义的配方相结合,可以让我们忘掉基础设施。

  我相信很快就会有越来越多的解决方案以 AppOps 的方式实现 DevOps 的目标,就像技术世界每次都会看到的那样,工具永远不会成为问题。

  应用程序开发和交付领域在过去几年中取得了令人难以置信的创新和发展。

  Kubernetes 是加快开发速度和减少开发与运维之间摩擦的革命性工具中的一员。我们可以在网络上找到大量资源,并且云也提供了巨大的推动力。

  虽然这些解决方案都推动了全球的数字化转型,但我们并没有就此止步。我们现在希望不要再为管理这些工具和复杂性付出那么多精力,这样才能更多地关注应用程序的开发,并为最终用户带来更多价值。

  AppOps 是实现这一目标的一种方法。有了那些从更高视角管理基础设施的工具后,我们就能隐藏复杂性,专注于那些对业务真正重要的事情。并且这样做是可行的,我们已经有许多工具可以很好地实现这一目标。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
3月前
|
运维 Devops jenkins
十六年所思所感,聊聊这些年我所经历的 DevOps 系统
从 2008 年开始,我陆陆续续参与了多个 DevOps 系统的建设,如今,审视这些系统的建设初衷和它们的设计思路或遇到的问题,依然有不少借鉴意义。我会按照时间顺序,把每个 DevOps 系统的特点,诞生的背景,以及在当时所主要解决的问题做一个概要的介绍,同时,我们也会以今天的视角再次审视这些问题,来看下同样的问题,经过十几年的发展,解决方案上有哪些不同。
|
3月前
|
运维 监控 Devops
DevOps 的反模式
【8月更文挑战第27天】
42 1
|
3月前
|
敏捷开发 运维 监控
DevOps 与 Agile:探寻根本区别
【8月更文挑战第27天】
93 1
|
运维 监控 安全
DevOps 反模式
DevOps 反模式
200 1
DevOps 反模式
|
敏捷开发 弹性计算 监控
阿里云项目敏捷实践之DevOps
敏捷开发少不了一个方便的持续交付环境。今天我使用阿里云简单搭了一套开发环境,这里简单记录一下搭建过程。
400 0
阿里云项目敏捷实践之DevOps
|
运维 监控 Devops
我眼中的DevOps
DevOps 是由开发(developments)和运维(operations)两个单词组成,可以看做是开发、测试和运维之间的一个交集,通过一些列固化的流程来使得整个项目的开发周期变得更便捷和可靠。
我眼中的DevOps
|
安全 Devops 数据库
开发人员眼中的 DevOps
在我看来,Devops 最大的核心就是持续集成,代码通过发布之后,经过Jenkins 等的持续集成,经过检出、质量检查、编译、打包、测试、通知、确认发布之后,软件开发部署部分就完成了最核心的一部分。这部分就实现了开发人员与运维人员的交汇、开发人员可以只需要开发代码、并通过Devops 发布部署到指定的节点上,同时,开发人员只需要提交代码就可以了,而运维人员也可以通过Devops 和开发人员进行良好的沟通与协作,更快更可靠的创建高质量软件,给用户更直观、高效的体验。
1617 0
|
Devops
关于实现DevOps的这四个关键因素,一起来听听他们怎么说…
8月9人日晚7点,将由Ghostcloud资深DevOps专家为大家讲解《针对企业的DevOps改进和实践》等课程。全新的“精灵学院”正式开课,我们只做这个夏天最具实践价值的课程,欢迎大家报名参加~
2349 0