认识达内从这里开始

随着互联网的不断发展，越来越多的互联网软件开发团队都要求程序员实现效率开发，而今天我们就一起来了解一下，DevOps对软件编程开发都造成了哪些改变。

公有云

随着云原生应用的推动，我们总是需要采用 DevOps。当我们开始为正在运行的服务交付代码时，我们就需要改进我们现有的流程了，以确保整个团队能够在一个被充分理解的流程中工作。为什么我们要采用基于云的架构并且要在 Jenkins 上进行自动化的构建，为什么采用云的方式?我们不想冒险，需要用代码来验证我们是否走在了正确的道路上。以前在一个项目步入生成环境前要经过八个不同的环境，但现在 DevOps 简化了整个流程，只用更少的环境就可以做到了。

Kubernetes(K8s) 在公共云中逐渐崛起。当你在云上运行 K8s 时，游戏规则都将改变。基于他人的成果使难度大大降低，我们可以在这样的平台上部署大量的已经装好的软件。由于有很多任务都是自动化执行的，所以需要我们做的事情就变少了。也许将来会导致一部分人的失业问题，但至少在目前为止，DevOps 所产生的变化不仅没有导致人们的失业还简化了部分工作。对于那些正在迁移到 K8s 的人来说，工具的使用正发生着重大的变化。大型云厂商 Intuit 公司已经不遗余力地投身于 K8s，雇佣了很多人来做这件事情。

工具和云环境正变得越来越复杂。过去只是运行在本地环境而已。 而现在，云和混合云可以轻松实现快速的扩容和缩容。终，成本下降了，但是收益却明显上升了。

一部分技术先行者们正在推动公共云、更多的 API 访问以及自动化的发展。相关的技术带头人也正在为我们开辟道路。大多数人还在远处紧紧追赶，但是他们已经认识到，需要这样做才能跟上面向客户的应用程序。大家都唯恐落伍，倍感紧迫。

DevOps 这一术语起始于 2007 年，直到现在才开始为大型网站之外的大多数组织投入应用。只是现在，战略才从早期应用转向大规模部署。

在过去几年中大的变化不一定是 DevOps 的概念，而是人们在实行过程中的不断尝试，以及终由哪些缔约方带头采用。

容器和 Kubernetes(K8s)

这其实是一种哲学的思维过程，同时也是 DevOps 和容器的组合。对代码和自动化容器进行虚拟化要容易得多，这也使得开发人员能更容易在类似于生产的环境中工作。人们对容器技术始终保持乐观的态度，K8s 社区也始终维持活跃状态，它现在已经成了事实上的自动化标准。K8s 变成标准，可以使开发者在平台之间更自如的切换，同时保持高度的敏捷性。

采用者越来越多。人们都普遍采用 K8s 进行容器的编排和管理。如我们亲眼所见，容器化是一种变革，它创建了一种思想，这种思想主张，我们既可以将配置应用于测试环境，也可以应用于生产环境。现在通常在非生产环境中构建容器，然后在推向生产。因此现在是虚拟机“和”容器，而不是虚拟机”或”容器。

DevOps 也变得越来越成熟了。DevOps 已经被更多的垂直行业所采用，甚至有一些相对保守的企业也开始采用 DevOps 了。而这些改变也是由容器技术带来的。对于不同规模公司中的人来说，Docker 和容器编排更容易理解些，这样能够较容易的打包软件，并在在 CI/CD 流水线中移动。Docker 其实挺容易理解的，为了采用 DevOps 或者自动化相关流程，只要采用标准的镜像格式，将镜像放在哪里都可以。K8s 相当于一个 mini 版的云，在一定程度上也提升了我们的速度。

DevOps 近大的变化就是逐渐转向了容器。似乎每个人都正在云环境中推出容器。他们虽然是新出现的概念，但是很多组织并没有正确的使用它们。容器可以做很多事情，包括充当经济高效的工件，以使开发变得更快速。然而，许多企业也发现，如果一次推出过多的容器，其收益将呈递减趋势。

起初，DevOps 主要被用作一种运维的哲学。这种哲学主要与敏捷开发方法相关，并将开发和运维集成到相同的团队中。将在这过程中产生的代码视为基础设施。且随着云架构 (现在是容器) 的出现，它已经成为现代组织处理基础设施的默认方式。现在 DevOps 不太关注作为代码的基础架构的基本需求，而更关注如何使用这些概念来提供持续集成和交付流水线，并确保可审计的自动化是产品交付中每个功能的一个组件。这允许 DevOps 团队协助组织进行成本优化和制定合规性目标。

容器化已经发生了巨大的变化。我们也已经从 Puppet(开源软件配置管理工具) 转向了 Kubernetes!

节选：infoq

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!