云原生 DevOps
技术雷达是ThoughtWorks每年出品两期的技术趋势报告，新一期即将在5月15日正式发布。本人有幸第三次参与技术雷达的汉化发布工作，并借此机会一览技术前沿的动态和变化。
DevOps 将迎来自己的十岁生日。对于整个行业，DevOps所带来的冲击并没有因为时间的增长而减缓，反而越发的剧烈和深远。
CloudNative 带来的新挑战
随着大规模的互联网应用不断在云计算平台上遇到挑战，新的应用架构模式呼之欲出，在众多的实践和方法论中，CloudNative 应用是其中的佼佼者。
目前 CloudNative 的定义则是来自于2017年成立的 Cloud Native Computing Foundation (“云原生计算技术基金会”，以下简称 CNCF)，CNCF：容器化，容器的动态编排和微服务。
然而，仅仅有了构建 CloudNative 应用的方法论是不够的。一方面，仅仅采用部分 DevOps 技术而没有没有采用 DevOps 的组织流程优化，仍然会出现 “DevOps 之痛”，并阻碍着互联网转型。另一方面，“经典的”企业级 DevOps 经验如何在云计算环境下有效的发挥其作用，也是一个新的挑战。于是我们可以看到，即便是具有 DevOps 基因的互联网企业开始刻意的进行敏捷和 DevOps 转型。而率先完成 DevOps 转型 的企业在进行 云原生 应用改造和技术革新过程中也面临着同样的问题。
这就对 DevOps 在云原生环境下的应用提出了新的课题和实践诉求，我们如何在云原生的环境下实践 DevOps 以达到更有生产力的表现？
本文将结合最新一期的技术雷达，试图勾画出 DevOps 在云原生的环境下的特性、未来的趋势以及相应的实践。
背景：不断蔓延的云环境复杂性
随着更多云计算厂商的出现，差异性质的服务将会越来越少。而在马太效应下，云计算平台之间也将迎来大规模的整合和重组。云计算平台之间竞争不断加剧，使得我们对云计算有了更多的选择，同时带来的是云平台之间在兼容性上的问题。我们虽然可以看到 Docker 这样的封装式解决方案，但对于整体云计算平台的编排和利用。例如网络，安全设施，服务资源间调度，却缺乏统一规范和标准。从平台的角度来看，这确实是避免客户流失的有效手段，但留给用户的选择空间不大。
因此，跨云平台的基础设施编排工具不断出现，使得用户可以在不同的云平台之间无缝切换。呼之欲出的将是一个云计算的标准或者事实标准，进而加强这个市场上的马太效应，淘汰掉小的云服务厂商，或者因为技术独特而被大的厂商收购。
如果你害怕自己的数据中心被平台所绑定，则需要花费更多的成本来维护一个云平台之间兼容性的应用系统。
SecDevOps
相对于企业级的可控网络和访问结点来说，在云原生的环境下，企业所面临的挑战则更为艰巨。这就好比你之前在自己小区的花丛里种花，所面对的无非家猫家狗和小孩子的破坏。现在，要在野生山林里种花，就势必要面对更加未知和复杂的环境。
然而，适应了企业级的应用开发和维护的开发团队并不如天生的互联网企业那般能快速适应互联网的大丛林。
在 DevOps 运动刚开始的时候，安全并不是一个主要的 Topic，只是一系列需要注意的事项，于是在做 DevOps 实践的时候，把安全放在最后考虑，即 DevOpsSec。随着 DevOps 的实践越来越激进，新的工具不断从社区涌现。安全作为 DevOps 的阻力则越来越大。但安全始终是绕不开的重要事情。因此，DevOps 社区尝试用同样的办法炮制和安全部门的合作以及安全实践，随后有了 DevSecOps，Sec 逐渐成为了 DevOps 实践中重要的一环。
就像我们之前讲的，面对复杂多变的云环境，安全要作为第一考量，而不是事后弥补。这一点就和我们在持续交付中探讨的“质量內建”一样。在云平台上实践 DevOps 要做到“安全內建”（Build Security In），这不单单是说我们增加几个自动化安全扫描的工具就足够的。要从系统的角度来重新思考安全在整个应用生命周期和团队的实践。ThoughtWorks 的安全社区在"安全內建"总结出了自己的实践，详细内容可以参考 https://www.buildsecurityin.net/zh 网站。
在上一期的技术雷达上，我们提到了"混沌工程"（http://principlesofchaos.org/），混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。在此基础上，本期技术雷达即将提到“安全混沌工程”，安全混沌工程扩展了安全技术的范畴：将误报引入到生产环境网络和其他基础设施——例如，构建时的依赖关系中，以检查是否有能力在受控条件下识别安全故障。但在初期阶段，应谨慎使用此技术, 避免团队遇到安全问题。
另一方面，云平台服务商自己也推出了安全审计工具。Scout2 就是在 AWS 上的一款安全审计工具，可以自动收集 AWS 上的配置数据以用于审计，它甚至可以生成攻击面报告。
服务优于工具
在企业级的 DevOps 实践中，技术实践的很大一部分内容都是引入先进的管理工具的理念。例如引入持续交付服务器、代码管理服务器、自动化测试套件等等…… 引入的工具在提高团队生产力和敏捷性的同时，也给团队带来了新的挑战：由于每家企业的组织结构和流程不同，加之团队的工程实践能力参差不齐。就导致了很多实践并没有很好的落地执行，企业自身都需要对 DevOps 引入的技术实践进一步消化。
但在云原生的场景下，我们无需去构造工具链，因为工具链本身是为最佳实践服务的。我们只需要根据自己的实践选择对应的服务就可以了，不光包含云平台自身的，也包括外部的。
例如，你的应用可能会用到 MySQL 数据库 或者 ElasticSearch 搜索引擎。在云上环境，你无需初始化虚拟机，安装对应的软件包，进行配置。而是直接采用云平台上提供的服务，例如 AWS 上的 RDS 服务和 ElasticSearch 服务。云平台本身已经将高可用、高稳定性和最佳实践整合在其内部，只需要很少的人力和费用就可以完成过去很麻烦的事情。
又例如，日志收集和监控，我们也不再需要搭建 Nagios 和 Zabbix 这样的工具。只需要 NewRelic 这样的在线服务就可以完成很方便的监控集成。
当我们开始向云上迁移的时候，首先可能把云平台当做一个远程的机房，让应用能够在云平台上运行起来，并在迁移过程中偿还一部分技术债。然后再考虑如何利用云平台的服务替换原有的业务。这往往是一件劳师动众的浩大工程。好在各云平台也提供了相应的简化方式。例如即将出现在最新一期的技术雷达的 Azure Service Fabric 和 Google 推出的 GKE。前者提供了一个 PaaS 平台，而后者则把 Kubernetes 服务化，变成其所在平台的一等公民，大大降低了搭建和维护成本。而随着 Kubernetes 的普及，越来越多的云厂商会将纳入自己产品服务目录的一部分，但 Kubernetes 的迁移仍然是有门槛的，你不得不面对复杂的应用依赖关系情况。而即将出现在最新一期技术雷达中的 Helm 就是这方面的工具， Helm 是 Kubernetes的包管理器，它的依赖管理，模板和钩子机制极大地简化了Kubernetes中的应用程序生命周期管理。让你更容易将应用部署到云计算平台上。
类似的工具还有很多很多。所以，当我们开始在云上构建起自己的数据中心的时候，我们首先需要考虑的是有没有合适的应用服务，而不是自己费精力去构建一套工具。
即便如此，这也不是在所有的场景下都适用，我们还是要权衡众多因素做出判断。不过就我个人的经验来说，经过实践考验的第三方服务永远是首选。
还有一点不得不说的就是安全性的问题，除了上文提到的基础设施安全，我们还要注意应用的安全。Hosted identity management as a service （托管的身份验证服务）也是即将发布的技术雷达中的一个条目。身份验证是很多应用程序的“公用组件”，几乎每个企业级应用程序都会开发一套自己的身份验证服务。在云原生的环境下，未经考验和测试的身份认证反倒是成为了一个重大的安全隐患。因此，我推荐你采用注入 Auth0 这样的统一认证方案来增强你的应用的安全性。我们相信，像Auth0和Okta这样的顶级托管商可以在“正常运行时间”和“安全”两方面提供更好的SLA。也就是说，虽然有时候自行搭建和维护身份管理解决方案是一个现实的选择，特别是对于那些有操作规范和资源的企业来说，这个选择更为安全。
在云原生的场景下，全球的竞争加速了技术实践的淘汰，有生命力的工具和服务在市场上生存了下来。并和它们所服务的客户一起创造了更加有生命力的技术实践。未来会出现更多的公司，将开源工具的最佳实践包装为一个 SaaS 化服务，并更好的和云平台集成。在国内，我们可以看到越来越多的创业企业从这个角度出发，推出了相关方面的产品。这也是未来小规模高增长的技术型互联网企业的创业方向。
无论要采用什么样的托管服务，我们仍然要记得安全，这就是本期技术雷达的另一个主题之一是：信任但要验证。
Serverless 应用优先
在 DevOps 实践中，基础设施即代码技术无疑是最令人着迷的实践之一。最早出现的 Puppet 和 Chef 这样的配置管理工具，在很大程度上降低了管理大量基础设施设备的成本。但随着 PaaS 服务逐渐在云计算平台上占据主流，IaaS 服务高昂的管理成本也让相应的工具日渐式微。基础设施的服务化以及应用的轻量化，使得基础设施即代码更多情况下变成了一个配置管理的工作。
而 Serverless 应用的横空出现，则是让基础设施的管理工作进入了一个新的阶段：基础设施的管理只剩下对基础设施行为的描述，而所有的描述则由配置和代码来实现。
这里的 Serverless 应用不光指的是 FaaS （函数即服务），也讲的是 BaaS（后台应用即服务）。Serverless 技术让我们进一步降低了应用程序执行的门槛。一方面通过标准化的 API 提供基础设施服务，另一方面通过低差异的运行时环境构建出简单的应用程序。两方面的结合构造除了稳定且简单的应用。不光降低了 DevOps 的门槛，也降低了开发人员和维护人员的门槛。
对于即将到来的 CloudNative Developer（云原生开发者），他们不再自己的电脑上的 IDE 中开发应用。而是在线通过浏览器提供的 IDE 开发应用，并遵从云平台提供的各种优秀技术实现。开发者之间的差异性和个性化被进一步降低，带来的是更加可控并且一致的应用行为，高品质的应用和高度提升的开发效率。
当我们考虑向云上迁移应用的时候，某些小组件和工具是否可以写成 Serverless 的应用以降低迁移带来的复杂度和基础设施稳定性挑战。
Ops as infrastructure developers
运维工程师成为基础设施开发者这并不是一个新的趋势，当 Puppet 开启了基础设施即代码的大门之后。我们发现越来越多的运维工程师成为了 Ruby 开发者。随着 Python 在众多运维工具和平台上扮演者越来越重要的角色，更多的运维工程师也成为了 Python 开发者。而和很多的 Python 开发者不同，运维工程师所面向的领域不是 Web 也不是 人工智能，而是基础设施。于是，就有了 “基础设施开发者”这一说法。
而在云原生的背景下，这个趋势得到了显著的加强。随着各种可编程基础设施和 PaaS 平台对编程语言的支持。基础设施和第三方服务的界限越来越模糊，这给了开发者更加友好的体验。在即将发布的技术雷达中简要介绍了troposphere 这个 Python 库，它用于取代 Terraform 来对 AWS 基础设施进行编程。这样我们可以利用语言本身的机制处理基础设施开发中的问题。
CloudNative DevOps 会不会导致 DevOps 的分离？
相对于基础设施的开发者而言，应用的开发者则被称作为 Application Developer。对于以往的 DevOps 痛点，主要是时间上水平的 Dev 和 Ops 的分离，以及职责的分离。它的问题来自于人为讲应用生命周期的各个部分划给了职责不同的各个部门。
这对于应用的完整迭代生命周期来说是有害的，特别是在线产品。
而随着基础设施的标准化和规范化，则会带来新的 DevOps 和分离。但这不是在应用程序生命周期上的分离，而是在应用程序不同职责间的分离。
这是否意味着在一定程度上，Dev 和 Ops 从合作走向了分离？恰恰相反，由于新的技术和实践的引入，原有的 DevOps 团队重新因为实践的需要而重新划分成彼此职责清晰，相互独立而又配合默契的两个团队。应用开发团队完全承接了应用维护团队的全部职责成为一个完整的端到端产品团队。而运维团队也通过新的云计算技术和工具成为了基础设施端到端的产品团队。
然而，缺乏有效的沟通机制和度量机制仍然是企业向“后 DevOps”时代过度的一大陷阱。这么做并不是要消灭沟通，而是在提升沟通的效率。
所以，作为 CloudNative DevOps 的合作，更多的是强调团队面对不同人群的端到端全生命周期服务理念：运维团队服务开发团队，提供更加便捷稳定的基础设施。而开发团队服务于最终用户，提供更加具有价值的应用程序。
而新的 DevOps 分离并不是 Dev 和 Ops 的沟通，是 Application Developer 和 Infrastructure Developer 的沟通，同样使开发人员之间的沟通。他们各自维护各自服务的生命周期，通过专业性提高效率并且通过统一的技术语言进行沟通。
从另一个角度说，传统的 Ops 的定义将逐渐消失，新的 Ops 定义则会结出新的果实。在这个意义上，说 CloudNative DevOps 是对传统 Ops 的一记补刀也不为过。