DevOps将被平台工程替代- Umesh


我在工程的运营方面已经有很长一段时间了。从Rails 1.0开始,我就一直用Ruby开发。在那之前,我写过一些世界上最垃圾的PHP。2006年AWS EC2推出时,我有机会从数据中心迁移到AWS EC2。随着我在运营方面的经验增加,我被 "放鸽子 "到 "DevOps "的角色。

到目前为止,我已经在一些公司部署了200多个生产级的Kubernetes集群。

想知道一个秘密吗?

我为每一个集群都复制和粘贴了相同的该死的Terraform模块。我的工作感觉像一个骗局,但公司付给我的是我在Kubernetes方面的专业知识,而不是写Terraform。我建立了一个复制粘贴驱动的单用户平台即服务,只要不出问题,没人在乎。

你已经走到了这一步,所以我就直接说了吧。

建立 "DevOps "团队的公司的方向是正确的,但他们需要从基础设施配置管理转向平台工程和实现开发者自助服务。

知识孤岛是好的。
孤岛是一个特点,而不是一个错误。

专业知识是个好东西。

DevOps是狗屁。

平台工程
如果你打算建立一个平台,有五个核心部件是必须的,但根据我们的经验,还有一些属性可以成为一个伟大的平台。

  • 可通过开源工具进行扩展。团队和工作负载是不同的,会有不同的黄金路径。如果一个IDP有一种意见的方式来运行你的工作负载,那么它并不比PaaS好。对Kubernetes的抽象是不够的。IDP必须适用于所有工作负载类型,无论是容器化、无服务器化还是虚拟化。
  • 反锁定,你应该能够从一个错误的构建或购买决定中走出来,而不需要冒生产的风险或有一个艰巨的迁移过程。
  • 安全性、合规性和护栏必须是内置的。没有它们,你就不能实现自助服务,你就不能实现服务。破坏自助服务的最快方式是CISO担心出现漏洞。一个简单的Web表单或YAML抽象的AWS或GCP API是不够的。必须包括实践和安全方面的专业知识。
  • 强大的构建块,以提高工程速度。我们在云计算领域的专业知识在整个行业中都很缺乏,一个优秀的IDP应该有安全、可靠的构件来快速设计云服务。
  • 通过灵活性和可扩展性实现实验。如果你不得不求助于另一个工具或平台,以了解你的应用程序在无服务器容器中的工作情况,或使用不同的Pub/Sub系统,那么你的IDP就会受到利益相关者的反击。IDP必须能够进行实验,这样才能为我们的应用做出正确的决定。
  • 必须支持应用程序和基础设施的短暂环境。我们的应用正变得如此严重地依赖云服务。如果你不能在打开拉动请求时提供像桶、队列或数据库这样的依赖关系,那么你真的能接近生产吗?
  • 对已配置的基础设施和应用程序进行可配置的警报和监控,并有良好的默认值。如果工程师可以部署他们自己的资源,他们必须被监控,而不需要一个额外的工具来配置。否则,这些资源配置了警报的可能性将大大降低。

平台工程是可能的,而且是未来的趋势。

随着世界上越来越多的地方上网,我们的系统越来越复杂,规模越来越早。我们每天都在从新兵训练营中培养出优秀的新工程师,但作为一个行业,我们在运营成熟度上并不出色。我们有大量的数据需要保护。我们是个人信息的管理人。客户认为我们有信托责任,但我们大多像个业余爱好者。

我们需要确保 "平台工程 "是下一个流行语。