为了避免成熟落后于人的痛苦，企业们纷纷开始实施并不断改进自己的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。
无服务器将大热
无服务器（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
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。