内容简介:DevOps 给我们带来的变化主要包括:人们越来越能够接受 DevOps 了、公有云的优势越发明显同时基础设施也逐渐完善。DevOps 将项目开发、测试、部署和迭代式发布集成在一起,形成一套统一的协作流程。为了能够了解到 DevOps 的现状和未来的发展方向,我们分别采访了 40 位 IT 部门主管,他们共来自于 37 个不同组织。我们分别向他们请教了这样一个问题:“自从公司采用了 DevOps 这套方法,你觉得公司内发生最大的变化是什么呢”? 以下是他们的回答:
DevOps 给我们带来的变化主要包括:人们越来越能够接受 DevOps 了、公有云的优势越发明显同时基础设施也逐渐完善。
DevOps 将项目开发、测试、部署和迭代式发布集成在一起,形成一套统一的协作流程。
为了能够了解到 DevOps 的现状和未来的发展方向,我们分别采访了 40 位 IT 部门主管,他们共来自于 37 个不同组织。我们分别向他们请教了这样一个问题:“自从公司采用了 DevOps 这套方法,你觉得公司内发生最大的变化是什么呢”? 以下是他们的回答:
被接受程度
- 在过去 DevOps 只被硅谷企业采用,那时除了硅谷没有企业愿意尝试这套方法论。但是现在每个企业都在考虑使用 DevOps。那么它是如何帮助到我们的组织呢?对于一家企业来说,DevOps 既是一种文化观念上的概念也是一种方法上的改变。我们需要树立改变的决心,然后从相关框架开始改变。
- 其中最值得关注的就是大家对 DevOps 的意识有所提高。当下人们对 DevOps 的理解程度有了明显的提高,在这种趋势下与其纠结于 Jenkins 和其他持续集成 工具 之间的差异,不如着眼于如何在整个系统中更好地使用类似 Jenkins 这样的工具。在这个过程中,人们也正在认识到数据的重要性。随着人们发现业务需求,编写应用程序代码和开发速度的加快,DevOps 正变得越来越成熟,同时也认识到全栈 DevOps 还有很长的路要走。而为了在交付速度和质量上取得成功,整个 DevOps 流程都需要自动化起来。
- 随着人们逐渐意识到相关工具和知识储备的好处时,越来越多的人接受它们。随着时间的推移,AWS 也相应增加了许多服务。且随着 DevOps 越来越多的被采用,也有很多其他企业和个人在构建相关的工具和产品,这些工具和产品也使得 DevOps 变得更容易被接受和采用了。
- 目前尚处于初级阶段。许多创业中小型公司正在使用 DevOps。由于 ITIL 流程早已深入人心,所以全球 2000 强实施 DevOps 的情况还非常零散。在 DevOps 中,把所有工作都交给开发者而不用任何的运维人员是不可能的,很明显,我们要做的是提高开发团队的敏捷性。总体而言,现在 DevOps 是一个很流行的词汇,所有的客户都在考虑采用 DevOps。
- 随着工具、平台和思维的成熟,在过去的一年内 DevOps 发生了很大的变化,人们现在正在积极的拥抱和实施 DevOps,同时也更多的体会到它的优势所在。与此同时,大型组织也正在接受 DevOps 和最新的思维方式。可能现在还不能适用于遗留系统,但是现在可以看到人们将 DevOps 使用在遗留系统中的强烈愿望。
- 在大约 4-5 年前,DevOps 可以说是一个来自硅谷的神话,当时只有 Netflix、Facebook 和 Google 采用了 DevOps。但在过去的几年里,越来越多的公司走上 DevOps 舞台,人们都在讨论他们是如何从组织内部进行转型的,以及个人如何在这个过程中承担更多的责任,更好的实现自动化。如何才能更公开的与他们分享呢?相关的度量指标和共享知识正变得越来越多。金融和电信机构都有自己的创新实验室来吸引具有不同思维的新人来改变传统员工的方式和行为。同时每个团队也正在研究公司如何进行数字化转型,以及如何构建软件并适应当前的组织和流程,同时他们还要教会组织的其他成员如何为未来做不同的事情。
- DevOps 更广泛的被企业采用。“基础设施即代码 (Infrastructure as code )”正获得越来越多的关注。文化采用是第一波浪潮,但现在已经得到了广泛的接纳。现在,随着代码自动化的深入展开,更多的工具和软件融为一体,虚拟硬件和基础设施融为一体。我们可以在新的环境和红 - 绿部署中使用自动化 CI/CD 工具。
- 人们对 DevOps 的理解越来越到位了。当下通过会议、文章和播客都可以对 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!
其他
- 我们是 DevOps 的早期实践者,通过 DevOps 我们实现了业务的快速拓展。在我们公司,所有的工具、流程和标准的运维程序都能够较好的被大家所理解。我们支持查看开箱即用的运维指标、数据迁移的逻辑处理,并能够保持整个数据中心的弹性。
- 自从我们开始使用 DevOps 以来,最大的变化是行业整个 DevOps 过程的自动化工具和基础设施的激增。而在多年前,DevOps 还仅仅被认为是开发人员和运维人员之间连通沟通和流程的一个桥梁。而在今天,DevOps 更多的被视为是软件从计划到发布阶段过程中一套自动化的流水线。为了优化这条流水线,并能够自动化流水线中的所有步骤,出现了大量的工具。对于开发阶段来说,首先出现的工具是 Puppet/Chef/Ansible,但现在正逐渐被 Docker 所取代,这一切都是在云端完成的。在本地的实验环境(物理机或者虚拟机)已经成为了过去时,Cloud/SaaS 是 DevOps 发展的重要推动原因。
- 从开发到运维,从每月发布三次到每天发布三次,这使 SQL 接入变得更糟。45% 的信息泄露率,相比几年前增加了近 8%。随着越多的人采用了 DevOps,人们也就发现了越多的漏洞,在这些漏洞中,有 60% 从未被修复过。更可怕的是,其中有 40% 到 60% 的企业不使用任何的安全测试来保障流水线的安全。
- 对于部分更加成熟的应用,如何能够使软件进行持续部署,以消除团队间的摩擦,获得更好的协作呢?时代变化越来越快了,但最基本的应用并没有任何改变。我们看到更多非确定性的应用,其中某些应用可能要从各个传感器中获得数据。而如何测试和处理这种变化呢?在 DevOps 中所采用的基础设施主要关注于针对模式的测试和确定应用了人工智能 / 机器学习 (AI / ML) 的持续部署 (CD) 。从确定性的应用程序到非确定性的应用程序使得 DevOps 变得更加错综复杂了。
- 在 DevOps 中,需要更多的自动化。自动化的工具也可以创造出更大的价值。DevOps 其实已经超越了开发的范畴,更多的上升到了文化的层面。在之后实施 DevOps 的过程中,最终也将会慢慢演化为文化问题。这正是 Devops 的作用,可以看到它正在帮助他们优化并适应他们的流程。
- “基础架构即代码”的总体原则,以及减少应用程序开发人员如何配置其应用程序的可变性,这些现在是基本保持不变的。我们已经看到在 SDLC ( SDLC 是软件组织内的软件项目遵循的过程。) 中的开发阶段发生了重大变化,我们现在采用了新技术和工具,如 Jenkins,Docker,Kubernetes 等。
- 我的经历甚至可以追溯到人们称之为 DevOps 之前,所以在发展的过程中我看到了很多的变化。在这其中最重要的是构建了各种框架,如 RightScale、Puppet 等,以及从人工手动运维转换到我们现在看到的更自动化的流程。
- 自从我们开始实施以来,自动化已成为实现大多数 DevOps 的方法。许多手工过程(如测试,配置和部署)已通过各种工具实现自动化。而且,随着云的出现,DevOps 自动化现在已经成为以云为中心了。
以下是分享这些观点的 IT 管理者:
- Tim Curless, AHEAD 公司高级技术架构师
- Will Hurley, Astadia 公司软件生命周期服务副总裁
- Lei Zhang, 彭博开发者体验(DevX)负责人
- Ashok Reddy, 加州技术集团总经理
- Sacha Labourey, CloudBees 公司 CEO
- Logan Daigle, CollabNet 公司 DevOps 战略与交付总监
- Sanjay Challa, Datical 公司资深产品营销经理
- Colin Britton, Devo 公司 CSO
- OJ Ngo, DH2i 公司 CTO
- Andreas Grabner, Dynatrace 公司 DevOps 布道者
- Anders Wallgren, Electric Cloud 公司 CTO
- Armon Dadgar, HashiCorp 创始人和联合 CTO
- Tamar Eilam, 任职于 IBM Research, 专注于研究下一代云和 DevOps 技术
- Mathivanan Venkatachalam, ManageEngine 公司副总裁
- Jim Scott, MapR 公司副总裁和企业架构师
- Mark Levy, Micro Focus 公司战略总监
- Glenn Grant, Mission 公司总监
- Jonathan Lewis, NS1 公司产品营销副总裁
- Zeev Avidan, OpenLegacy 的首席产品官
- Tyler Duzan, Percona 公司产品经理
- Bradbury Hart, Perfecto 公司副总裁兼首席布道家
- Damien Tournoud, Platform.sh 公司创始人和 CTO
- Bob Davis, 首席营销官 and Jeff Keyes, 产品营销总监, 均任职于 Plutora 公司
- Brad Micklea, 技术部门高级主管, Burr Sutter, 开发者体验部分主管,均任职于 Red Hat 公司
- Dave Nielsen, Redis 实验室生态系统项目负责人
- Brad Adelberg, Sauce Labs 工程副总裁
- Adam Casella 和 Glenn Sullivan, SnapRoute 公司联合创始人
- Dave Blakey, Snapt 公司 CEO
- Keith Kuchler, SolarWinds 公司工程副总裁
- Justin Rodenbostel, SPR 公司开源项目副总裁
- Jennifer Kotzen, SUSE 高级产品营销经理
- Oded Moshe, SysAid 公司产品副总裁
- Loris Degioanni, Sysdig 公司 CTO 和创始人
- Jeffrey Froman, DevOps 主管,Aaron Jennings, 工程师, 均任职于 Temboo 公司
- Pan Chhum, Threat Stack 公司基础架构工程师
- John Morello, Twistlock 公司 CTO
- Madhup Mishra, VoltDB 公司产品营销副总裁
- Joseph Feiman, WhiteHat Security 公司首席战略官
- Andreas Prins, XebiaLabs 公司产品研发副总裁
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 主管要做微服务 程序员不干了
- 运维主管离职后倒卖代码,非法获利 800 万被抓
- 苹果挖墙脚,请来 Google 搜索和人工智能部门主管
- 调查了 300 多位技术主管:AWS 和 Azure 经常配对使用
- 资深码农也中招,BitGo工程师主管被盗10万美元比特币
- 凡事都要问主管、东拉西扯没重点:敏捷破坏者实战手册
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
谷歌和亚马逊如何做产品
梅 (Chris Vander Mey) / 刘亦舟 / 人民邮电出版社 / 2014-6-1 / CNY 49.00
软件在交付之前,面临产品、方案、项目和工程管理等诸多挑战,如何做到游刃有余并打造出极致产品?本书作者曾任谷歌和亚马逊高级产品经理、现任Facebook产品经理,他将自己在达特茅斯学院钻研的理论知识和在领先的互联网公司十年的工作经验尽数总结在此,从定义产品开始,一步步指导你完成管理项目、迭代、发布、市场推广等交付流程,让你身临其境地体验到极致产品如何取得成功。 本书主要内容: 如何清晰定......一起来看看 《谷歌和亚马逊如何做产品》 这本书的介绍吧!