正文
与任何正在经历变革的领域一样，云原生世界中有繁杂的概念。上一个部分列举的概念，不是每人个人都清楚应该如何恰当地利用。同时，很多关键的项目，要么太庞大，要么太重要，不适合重头重写。因此，我们觉得最好把这些新的结构用在新的项目或者老项目的新部件中。在系统老的部件得到了改善后，然后再花时间合理地学习并采用其他新技术。寻找把新的特性或者系统分解成微服务的方式。
没有硬性的规则。每一个机构都是不同的。软件开发的实践必须要根据身边的团队和项目来做出调整。理想不同于现实。有的项目经得起实验折腾，但是很多非常重要的项目应该采取更加谨慎的态度。还有一些场景是介于两者之间的，一些技术即使已经被验证过，但仍需要规范化并且经过大规模的测试，之后才能应用到核心系统上。
云原生的定义中离不开的更好的工具和系统。没有这些工具链，每一个新部署在生产环境的服务都会有很高的运维成本。监控，跟踪，配置等等都增加了一个处理的负担。这个额外的开销是对微服务大小的切分应该合理的主要原因之一。开发团队的速率和在生产环境中运行更多（服务）的成本，这两者的利弊需要权衡。类似的，新的技术和语言引入，尽管可能新鲜刺激，也必须仔细考虑其风险和代价。关于这个话题，Charity Majors有一个非常好的演讲（http://suo.im/2R6fp9）。
要降低构建和运行新服务中的运维成本，自动化是关键。像Kubernetes、容器、CI/CD、监控等等这样的系统，都有一个相同的重要目标 – 让应用开发和运维团队的效率更高行动更快，让打造的产品更可靠。
要达到云原生的愿景，最好使用新一代的工具和系统，而不是传统的配置管理工具，因为它们有助于分解问题然后分工给不同的团队处理。通常来讲，新的工具通常能让独立的开发和运维团队拥有自主权，然后通过自服务（self service IT）提高生产力。
第三部分：DevOps
不妨将DevOps看成一种文化的转型，开发者现在需要关心他们的应用是怎样在生产环境中运行的。而运维也对应用的运作机制有了认识并且授予了知情权，从而可以在帮助打造可靠应用方面发挥重要作用。增进这些团队之间的理解和建立同理心是关键。
但是可以更进一步。如果我们重新思考我们的应用的构建过程和运维团队的结构组成，我们能进一步加深这种关系。
Google没有传统意义的运维团队。相反，Google定义了一种新的叫做SRE（Site Reliability Engineer，网站可靠性工程师）的工程师。他们是技能扎实的工程师（报酬同其他的工程师处同一个水平）他们不但随时保持在线，同时得到授权并被赋予通过自动化来在推动应用变得更加稳固方面扮演至关重要角色的重望。
当在凌晨两点报警触发的时候，任何响应该报警的人都会做同一件事情 – 努力弄清出了什么问题，好早点回去继续睡觉。真正定义一个SRE的地方是第二天早上10点钟发生的事情。运维组的人是否只会抱怨，还是会和开发团队一起协作保证同样的报警不会再次出现？在让应用变得尽可能稳定可靠方面，SRE和开发团队有一样追求。结合不追责的的事后剖析，可以保持项目的健康，不让技术债务堆积。
SRE在Google是最被看重的人群之一。在实际中，很多项目在没有SRE参与启动的时候，开发团队肩负了让他们的产品在生产环境中运行起来的期望。引入SRE团队的流程，通常需要开发团队向SRE团队证明他们的产品已经准备到位。开发团队需要已经做好了所有的准备工作，包括设置好监控和报警，报警的应对策略和发布流程。开发团队要能显示出报警的情况已经达到了最少的程度，并且绝大多数的问题已经被自动化了。
随着运维的角色参与程度更深，与特定的应用相关度更高，让一个运维团队掌控整个运维栈变得不合理。这引出运维规范（Operations Specialization）的问题。从某种意义来说这是一种“反DevOps（anti-devops）”的做法。让我们来自下而上的看：
-
硬件运维
。这一层很显然可以分离出来。实际上，很容易把云IaaS看成是“硬件运营即服务（Hardware Ops as a Service）”。
-
操作系统运维
。必须有人保证机器能够顺利启动，并且有一个好的内核。将这一部分从应用的依赖管理中分离出来也反映出了用来托管容器的操作系统发行版（CoreOS, Red Hat Project Atomic, Ubuntu Snappy, Rancher OS, VMWare Photon, Google Container Optimized OS）的最小化趋势。
