云原生集成开发环境——TitanIDE
通过网页在任何地方更安全、更高效地编码2022-07-05
613
原文译自:Elastisys博客
DevOps 是一种文化运动,它为软件开发带来了许多必需的敏捷性。但,DevOps被大多数人误解了—— DevOps 真的意味着开发人员除了开发之外,还应该具备管理、运维复杂底层系统的能力吗?
在本文中,我们将讨论开发人员和平台运营之间技能组合的差异。首先,我觉得DevOps的真正意义应该是:开发人员完全拥有软件开发、发布和生命周期管理的所有权,并去执行应用程序的操作,而不是管理底层IT平台。
左边是不切实际的期望,右边是 DevOps 和平台运维的划分
DevOps 的兴起与误解
DevOps 是软件开发中的一种文化运动,开发人员在其中承担其应用程序的运营责任。这不仅包括像以前那样开发代码。它还包括操作任务,例如发布新版本、管理其代码的生命周期(升级、数据库迁移等),以及通过监视和日志记录随时间观察其行为。
DevOps 极大地提高了应用开发的生产力和敏捷性。开发人员完全掌握应用程序的生命周期意味着他们关闭了代码在现实中的行为方式的反馈循环。性能问题由负责修复它们的人员直接识别。应用程序洞察力直接提供给开发人员和设计人员,以优化应用程序用户体验。等等。
但DevOps经常被误解了。因为开发人员被鼓励“bite off more than they could chew”。
促成 DevOps 运动的技术和管理它的隐藏角色
DevOps 引发了组织演变和文化转变。DevOps 之所以能够以我们所看到的形式进入这个阶段,是因为有支持这种工作方式的技术。技术支持将基础设施作为代码工具使用的能力。无论是虚拟机设置中的管理程序、Kubernetes 设置中的容器,还是功能即服务设置中的语言运行时。如果没有这些技术,我们将无法采用我们所知道的 DevOps。
但是仍然需要有人管理该底层技术。
在本文中,我们称他们为平台运维人员。
平台运营商与开发者有何不同?
开发人员与平台运维员的技能组合
开发人员开发,因此,他们最主要的能力是输出代码。但这不仅仅是代码,因为开发人员主要专注于在高级抽象层面上解决问题,对问题进行建模,并将这些模型和抽象转换为代码。
相比之下,平台运维人员专注于计算机系统的内部运作,并确保其高效、安全、正确地运行,并且随时可用。
软件开发和平台运维任务所需的技能组合差异很大。
在 DevOps 中,开发人员还应负责管理其应用程序的生命周期并在运行时观察它们,这不仅意味着开发人员的责任转移。这也意味着他们需要学习一套工具和支持技术。可观察性堆栈,例如日志记录和监控系统。部署编排,例如用于使用云、Kubernetes 或功能即服务平台的 API 和工具。
开发人员通常会接受这些工具和新的工作方式。因为随着他们工作责任的增加,他们的敏捷性也随之提高,他们的工作效率也更高。好处是立竿见影的,可以在整个组织中感受到。
然而,关键是必须有人专门为这些新工具和平台组件而工作。不仅仅是安装一次,而是维护、升级、排除故障并保护这些工具或组件。
至关重要的是,期望开发人员也能够管理底层系统是不合理的。
但,这些工作,正是平台运维人员所做的!
平台操作员拥有足够资深的技术来处理这些问题,例如,为什么网络失败、操作系统耗尽文件描述符或为什么 I/O 性能突然下降。
正确建模问题域的“人类现实”并将该模型转换为代码已经足够困难了。在足够深的层次上理解操作系统以自信地对“计算机的现实”进行故障排除,本质上是不同的。
有些问题当然可以通过“宠物对牛”的操作方法来解决,其中运行时(VM、容器平台、函数运行时)被替换。但是那些根深蒂固的,那些由错误引起的,会导致错误反复出现的,必须真正得到照顾。
即使是牛生病了也需要兽医帮助。平台运维人员就是那些老手。
这就是鼓励开发人员“bite off more than they could chew”的方式: 他们被告知要同时进行开发和所有操作。不是合理的应用操作,而是底层平台的管理,显然这不合理。
仅仅因为一个人擅长前端和后端的 JavaScript,并不意味着他们在系统管理工作方面也很出色。
这也不意味着他们能有效地完成这些任务。他们的时间可能更适合花在做他们擅长的事情上,而不是疯狂地在谷歌上搜索系统管理问题的答案。花费在这方面的任何时间都意味着他们的精力被从开发新功能中拉出来,而用于对平台进行故障排除。
安全风险角度
在没有经过适当培训的情况下让人员负责平台安全也是一个严重的安全风险问题。开发人员永远不会被分配足够的时间来处理整个事件。这就是为什么在 Datadog 的 2020 年容器报告中,最常见的 Kubernetes 发行版使用了 17 个月,因此不受支持且没有资格进行安全更新。除非专门为处理安全问题腾出时间和资源,否则显然行不通。
企业积压的无数安全任务就是其需要的证明。这些通常与应用程序的安全性有关。如果连这些都没有解决,谁来处理与平台相关的问题?
那么在实践中,真正的 DevOps 是什么样的呢?
实践中的真正 DevOps
让我们再看一下这张图,并把注意力集中在它的右侧
开发人员可以通过承担开发和应用程序操作的职责来实践 DevOps 的工作方式。这允许开发人员快速迭代。他们可以用敏捷的方式监控、分析、计划和执行代码更改。它使他们能够集中精力并通过应用程序开发为组织创造价值。
在技术层面上,使他们能够做到这一点是平台运维人员的工作。该团队在后台工作,并使平台和系统保持良好的运行。他们是支撑,为开发人员以 DevOps 方式履行其新职责奠定了基础。
DevOps 从未打算让开发人员同时进行应用程序和平台运维。
对开发人员提出切合实际的期望可以通过让他们解决平台问题来弥补所有时间损失。这意味着有更多时间为企业的最终用户创造价值,同时提高工作效率并满足开发人员的工作,而无需在开发和平台运维之间进行思维转换。
行云CloudOS致力于让开发者专注于业务创新,与DevOps真正的理念不谋而合。
行云 CloudOS 封装 Docker、K8S 等底层技术,为用户提供可视化操作页面,让传统应用研发团队无缝转型为云原生数字化应用研发团队。
在云原生数字化时代,应用与云原生平台分离,IT 团队中相关人员分别承担应用研发、应用运维、平台运维等角色。Docker、K8S 等云原生技术为底层平台技术,平台运维人员需要学习并掌握,应用研发和应用运维人员将更聚焦于应用本身,不需要过多关注底层云原生平台技术。因而CloudOS 云原生平台对底层技术进行封装,给应用团队提供友好易使用的可视化操作页面,让应用团队不需要学习 Docker、K8S 技术也能高效进行数字化应用创新。
CloudOS 并非是传统的DevOps工具
CloudOS 与典型DevOps工具对比