观点：有关DevOps的7个趋势

为了不成熟落后于人的痛苦，企业们纷纷开始实施并不断改进本身的DevOps实践。在这样的环境下，运维和开发团队必需要搞清楚技术的发展方向，以便在大潮到来的那一天作好万全准备，或是在各方的大肆宣传中保持冷静的头脑。

关于可能到来的挑战和机会，咱们不妨来看看DevOps、云计算、微服务架构、容器、无服务器等领域的专家观点。

DevOps的明肯定义将终于成形

回顾过去，不少技术公司已经在DevOps转型中挣扎多年了。J. Paul Reed，Release Engineering Approaches公司的任事股东认为，DevOps的明肯定义将在2017年底终于成形。

“（DevOps）已再也不是新兴现象，做为一种原则和实践的集合，它已经积累了大量的定义和代码方面的工做。”

Reed认为，DevOps的分歧窘境在于“众说纷纭”。或许分歧在将来一段时间内仍将继续，但你们广泛接受的DevOps定义将逐渐造成，而其余定义将随之逐渐被淡化，“DevOps的最终定义是什么？咱们如今已经开始关注了，但到了2018年给你一个准确回答。”

Jeremy Likness，是一位博客达人，同时仍是iVision的应用开发总监。他认为DevOps的最终定义能够总结为：应用生命周期管理（ALM）新方法。

”企业会愈来愈看重敏捷性，并会意识到DevOps实际上是超越敏捷的ALM，而非扩展。做为改变的一部分，Infrastructure as Code（Ioc）在持续交付pipelines中的地位将会愈来愈稳固“。

不会写代码的测试将被淘汰

TJ Maher，是一名自动化开发程序员。在过去两年时间中，他花费了大量时间学习，以便让本身从传统的手动测试升级为自动化开发。也就在过去两年，他的不少测试岗位上的同事丢掉了工做，缘由正在于未能跟上测试行业现下正在发生的变革。

“持续集成和持续交付像是台风同样席卷了整个软件测试行业，不少手动测试员都未能幸免。”

对于不少测试工程师来讲，2016年留给你们的教训即是：learn to code or perish。如今的测试工做几乎全都集中在网络服务层面，对于RESTFUL API需求极大，固然还有对于各类测试工具的使用要求。

C2 IT Solutions Consulting的全球QA测试实践负责人Andy Tinkham相信，还有一个重要缘由能够解释QA专家为何会在找工做时碰壁——测试的商品化。

Andy认为，测试这一职业创建在，一家家企业中的高水平测试员施展他们在测试系统方面的知识和技能。

“咱们一直致力于让测试变得可重复，每一个人均可以按图索骥。咱们将测试工做与自动化方法结合起来，试图把人类活动“翻译”成脚本和一种开发文化，弱化了角色之间的界限，最终将测试行业商品化。

而结果是，愈来愈多的测试工做被自动化完成（固然，自动化不是万能的），其余岗位替代了本来测试工程师的任务。在一些案例中，测试工做被转给了外包团队。

Tinkham和Maher都说，2017年是测试工程师极为关键的一年，大部分工做都比以往要求更高的专业度。

敏捷化运动“回归基本”

敏捷概念提出15年以后，敏捷和scrum被不少人认为是最佳实践，但也有不少人被教条的敏捷方法的负面影响整得精疲力竭。“咱们其实已经偏离的敏捷概念的核心，今年（2017年）也许会是属于敏捷化运动‘回归基本’的一年。

Tinkham相信有两件事会在行业内得到主流注意。一是Joshua Kerievsky's Modern Agile，二是Heart of Agile（Agile Manifesto signatory，Alisrair Cockburn）

不少敏捷大会都在谈论这两个理论，也为精疲力竭的企业从新注入了活力。Tinkham表示，“估计这两个理论会在将来12到18个月内开始影响主流的敏捷观念”。

更多企业上云

Cloud Technology Partner高级副总裁David Linthicum表示，“2017年会是大多数企业会大规模上云的一年“。

”若是他们2016年把20个应用放在了云端，那么在2017年这一数字极可能会是500。“

企业使用云的方式也会在今年逐渐开始改变。”传统PaaS会逐渐失去竞争力，企业们会更倾向于容器化的解决方案，选择可让他们灵活、可自由移植的混合云／多云环境，同时使用一个或多个供应商的云计算服务”，Likness说。

他补充说，但愿看到更多的Linux商品服务器和组织利用.NET Core远离对基于Windows的机器的依赖。 “更多的供应商不只将提供软件即服务（SaaS），并且还将提供容器即服务，所以运行内部部署的客户能够轻松访问一个正在运行的开箱即用的解决方案“。

对于微服务架构的追捧将趋于理性

“企业对于微服务架构的热情从2016年起便不曾消减。对于不少应用来讲，微服务架构的确是伟大的进步，但微服务架构并非‘magic bullet’”，Bluefin Payment Systems高级软件工程师Marco Troisi表示。他和Netflix软件架构师Paul Bakker都认为对于微服务架构的追捧将在今年趋于理性。

Marco Troisi表示，“可能会有更多的人开始谈论，某些应用并不适合微服务架构。同时，帮助咱们管理分布式架构的工具将达到更高的成熟度，让微服务相关的工做变得更简单起来。”

Bakker表示微服务当然很棒，但不少人对于微服务的理解有误差，也不明白架构和工具之间的区别，这也就致使了不少微服务架构被作成了SOA，也所以花了不少冤枉钱。

Red Hat架构师Christian Posta也表示，不少开发者看待微服务架构的方式有问题，“企业会开始认识到，Java并非微服务开发的最佳语言，但依然会在该方向上花费不少精力。”

Posta同时认为像Netflix、Twitter这样的著名公司也许会从新考虑他们的开源策略，这些公司不少时候更像是“隔着墙扔代码”。

“这些改变是很关键的”，Posta认为这些主流公司开源的工具和libraries可能会取代传统供应商的中间件，而一些新兴的创业公司会加速整个生态的造成。

容器和编排工具会变得更易用

Likness表示，云计算巨头在容器方面投入了大量的投资，容器集群管理是供应商开发解决方案的关键部分。

Troisi指望toolmakers专一于如何把docker等容器变得更易用，他对docker-compose很期待，而docker-compose在2017年会变得更成熟、更适合生产环境。

“把docker命令存储在Compose易读的YAML文件中，会是开发者们更倾向的运行Docker应用的方式，而不是记住大量的、很差读的命令行命令“，Troisi说。

Linthicum预测container的热度会继续增加，但也只集中在新建的应用上，“将旧应用容器化难度和花费都不小。“

Likness表示容器在去年逐渐成了许多开发流程的一部分，而今年则会成为最重要的部分之一。

Kubernetes将成为标准

Troisi预计，Kubernetes将成为容器编排的行业标准，相关的研究彷佛也证明的这一说法。可是，Kubernetes的设置和使用相对来讲还比较困难，所以基于容器的PaaS系统，如RedHat OpenShift、CoreOS Tectonic，将帮助企业进入Kubernetes和容器的世界。

Bakker赞成Likness对PaaS的“缓慢死亡”预测，但只适用于较旧的严格锁定产品，例如Google AppEngine。他预计基于Kubernetes的PaaS产品，如Google Container Engine和OpenShift，将在2017年蓬勃发展。Posta预期也是如此：“Kubernetes正在统一容器，基于Kubernetes的PaaS提供商将得到比其余公司更多的牵引力。“

好雨云帮，深度整合Docker和Kubernetes，提供以应用为中心的无服务器PaaS。

连接：https://www.goodrain.com

无服务器将大热

无服务器（serverless）是IT界的最新热点，有很大的潜力。Navica CEO Bernard Golden预计，无服务器技术的影响力将快速扩大并被企业所接受。

“无服务器拥有IT组织彻底摆脱基础架构管理业务的潜力，并专一于应用程序开发和部署，虽然IT一直是不断变化的领域，但明年将为IT组织提供比以往任什么时候候更多的机会和挑战。“

软件咨询公司Cloudbox Systems的首席技术官兼首席数据系统顾问Dean Hallman一直在研究无服务器框架，他看到无服务器框架提供了更多的向导式体验，并填补了主要FaaS提供商（如AWS Lambda，Azure功能和IBM OpenWisk）之间的功能差距，以便无服务器应用程序能够从单个代码库中定位任何这些供应商的服务。

Hallman也指望无服务器对DevOps的演进产生重大影响。在之前由Ops和DevOps管理的域中，开发人员将比以往任什么时候候都更加参与。 “大多数无服务器框架已经提出了一个无服务器友好的DevOps工做流程，”Hallman说，“2017是无服务器奠基基础的一年”。

“将会知足无服务器框架，AWS SAM和AWS子账户的整合趋势，以知足开发人员的访问需求和DevOps的安全性要求。“

哈尔曼预计，微服务架构和容器化基础架构将在2017年与无服务器融合。

总结

• DevOps中，Infrastructure as code是核心组件
• 测试人员不只须要懂测试，还须要了解编程，有能力构建应用
• 敏捷化运动‘回归基本’
• 企业应考虑灵活可移植的PaaS服务提供商，探索基于kubernetes的PaaS产品
• 不是必定要微服务架构，在实施前应准确评估
• 应该在生产环境中尝试容器技术
• 开发和运维应该开始尝试无服务器架构

Author Mitch Pronschinske

原文：https://techbeacon.com/7-devo...