平台工程当道 提升开发体验呼声高涨
发布时间：2024-01-07 07:47:24 所属栏目：云计算 来源：DaWei
导读： 在云原生开发领域，“DevOps死了吗？”、“云上DevOps太难了！”类似的问题网上有很多种提法。但答案很明确：并不是。随着平台工程的兴起，这类问题的答案也发生了
|
在云原生开发领域，“DevOps死了吗？”、“云上DevOps太难了！”类似的问题网上有很多种提法。但答案很明确：并不是。随着平台工程的兴起，这类问题的答案也发生了变化——DevOps正在改变，但不会很快消失。DevOps角色发生了变化，它将成为提高开发者体验的助燃器，帮助每个人用更少的成本，做更多的事（Doing More with Less）。 而诸如Ambassador Labs等开发者平台的悄然出现，也许正在为开发者铺设了一条清晰的道路。开发者平台旨在帮助开发人员实现更高的生产力，减少认知负荷（“要学习的东西多而杂”的负担），同时安全地快速维护软件。 平台工程作为一门学科，虽然还没有定义，也很模糊，但随着更多的包装和商业选择的出现。 1、一场云原生挫败感导致的的演变 有两件事情可以佐证平台工程和开发者平台的兴起、未来的主导地位和商业化。 首先，开发人员的挫败感是公认的。Kubernetes开发者有理由对引入微服务和云原生开发所带来的一些新挑战感到沮丧。开发模式的完全改变，加上突然期望开发人员应该能够“左移”，对他们的代码承担端到端的代码运行责任，造成了额外的、抱怨四起的认知负担。 其次，还有一系列常规的、重复性的任务突然落到了开发人员身上——在许多情况下，他们没有任何类型的路线图或一套抽象概念来弄清使用什么工具。包括缺少可视化的服务，来加快他们所需的反馈回路。这些都相当于放慢了产品和功能的实现。Garden的一项开发者生产力调查发现，开发者平均每周需要花费15个小时在非开发任务上。 这不仅是一个糟糕的开发者经验的难言之隐，而且还拖累了生产力，严重拉低下限。第二，虽然有些开发者喜欢自由地试验和尝试新的工具（1%），但绝大多数的开发者（99%）希望，甚至可能需要，有明确的“护栏”和“黄金通道”来维护和运行他们的代码。大多数开发者希望把他们的时间集中在写代码上——而不是运行基础设施和试图弄清楚那些为了生产力而应该工作的事情，比如维护工具、建立开发环境、自动化测试等等。 平台工程建立在传统的DevOps实践的基础上，并利用这些知识和经验来识别和实现新的效率，并以更少的资源做更多的事情。或者，正如就像之前所提提到的，“你可以说平台工程采用了敏捷和DevOps的精神，并在云原生世界的背景下进行了扩展”。 2、开发者平台是个中间地带 给开发者更多的控制权和洞察力，以提高速度和建设效率，这样能鼓励开发者对自己的软件进行全生命周期管理的驱动力，出发点是好的。但是，基础设施并不是，而且可能永远不会是开发者的主要关注点——或者说是开发者引导其精力的最有效的地方。 然而，在云原生空间中，开发人员需要更多地了解基础设施，以及在发布代码后会发生什么。如果出了问题，开发人员仍然需要对代码负责，并了解它的依赖关系，以帮助解决和识别（并修复）下游问题。 但对于服务、环境和云本身来进行组织和决策，则不然。这就是要求一个学科的专家尝试在某个完全不同的学科中快速专业化，这既有悖于提高速度和开发人员经验的最初想法，也否定了用更少的资源做更多事情的想法。有时，让非专业人员承担专业责任的想法，认为这会缩小资源足迹——用更少的资源获得更多的资源——会产生更多的问题。 为所需的工具和可见性提供开发人员自助服务，铺平道路，但足够灵活，可以容纳不同类型的开发人员。它既适用于新的开发人员，也适用于希望实现可靠、高效生产的经验丰富的开发人员。 使DevOps/PlatformOps能够支持和增强自助行动，增加他们在战略改进和项目上花费的时间和精力，减少救火时间。 允许更好地衡量性能、法规合规性和安全性，因为运营和资源数据集中在平台内。 （编辑：大同站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
推荐文章
站长推荐