一、云原生定义
云原生定义随着Craig和我开始构建Heptio的旅程，我们一直在思考我们看到的行业。我们花了相当多的时间在Google(我们两个人之间的16年)，并且很好地了解Google如何构建和管理系统的。 但是，你不能在Google工作。 那么，所有这些不断发展的新概念如何能应用到传统的公司/开发商/运营商?
这是一个‘云原生系列文章’的***部分，阐述如思考和应用“云原生”思想的多个角度。
1.云原生的定义
对于 Cloud Native 意味着什么，还不能生硬和快速地对其下定义 。 事实上，还有其他重叠的术语和意识形态。 Cloud Native作为正在构建团队，文化和技术的根本，以利用自动化和架构来管理复杂性和加快步伐。 在这种模式下运维需要尽可能多的扩展人的方面，同时尽可能多的扩展技术方面。
“Cloud Native作为正在构建团队、文化和技术的根本，以利用自动化和架构来管理复杂性和加快步伐。”
一个重要的注意事项： 你不一定只能在云中运用“云原生” 。 这些技术可以适当地逐步应用，来帮助您顺利地转型到云。
2.云原生的价值
Cloud Native的真正价值远远超出了与其密切相关的一揽子技术。 为了真正了解我们行业的发展方向，我们需要审视我们在哪里和如何使公司、团队和员工更加成功。
有些技术在这一点上已经在以技术为中心的前瞻性公司中得到证明，这些公司已经投入了大量的资源。 想想Google或Netflix或Facebook。 更小，更灵活的公司也在这里实现价值。 然而，这一理念在技术早期采用者之外应用的例子很少。 当放眼更广阔的IT世界，我们仍然在这个旅程的开始阶段。
“我们才刚刚开始云原生的旅程。”
随着一些早期的经验被证明和共享，那些主题正在出现?
1-更高效和更快乐的团队
云原生工具允许将大问题分解为更小的部分，用于更专注和灵活的团队。
2-苦逼程度的降低
通过自动化大量的手动的导致痛苦和停机时间的工作。 这采取自我修复和自我管理基础设施的形式。 期望系统做更多。
3-更可靠的基础设施和应用
构建自动化来应对那些可以预期的通常会导致意外事件和故障，更好的故障处理模式。 示例：如果是单个命令或按钮单击以部署用于开发，测试或生产的应用程序，则可以更容易地在灾难恢复方案(自动或手动)中自动部署。
4-可审计，可见和可辩
复杂的应用可能非常不透明。 用于Cloud Native应用程序的工具根据需要通常可以更好地了解应用程序中发生的情况。
5-深度安全
现在许多IT系统都是外强中干的。 现代系统应该是默认的安全和最小的信任。 Cloud Native使应用程序开发人员能够在创建安全的应用程序中发挥积极作用。
6-更有效地利用资源
自动化的“类云”部署和管理应用程序和服务的方式开辟了应用算法自动化的机会。 例如，集群调度器/编排器可以自动化在机器上的调度工作，而由运维团队在电子表格中管理类似的分配。
我们在Heptio非常高兴能够帮助将Cloud Native的优势带给更广泛的IT行业。 在本系列的其余部分，我们将讨论与现有系统，DevOps，容器和编排，微服务和安全性的集成。 请留意，让我们知道您最感兴趣的是什么。
二、云原生实践
1.因地制宜，循序渐进
像其它创新活跃的领域一样，云原生世界有相当多的流派。 如何能够把上一章里的优秀的想法，都***的实现出来并不是能轻易地说清楚。 为此把任何重大的项目重写都显得动作太大太夸张了。相反，我鼓励您对较新的项目或现有项目的新部件尝试这些新结构。 随着系统的老组件的改进，花时间适当地引入新技术和学习。 寻找方法来把新功能或系统实施为微服务。
“如何能够把上一章里的优秀的想法，都***的实现出来并不是能轻易地说清楚。”
2.没有固定和速成套路
每个组织都是不同的，新软件开发实践必须推广到现有的团队和项目。 破除团队的割据。 一些项目可以进行实验，而其他关键核心业务项目应该更加地谨慎地靠拢和学习。 在这个过程中，也有新技术需要在被应用于到关键系统之前进行规模化和测试的必要性的情况。
3.云原生由优秀工具和系统定义
云原生由更好的工具和系统来定义的。 没有这些工具，生产中的每个新服务的运维成本将会居高不下 。必须把监控、跟踪、配置等当做一个独立的重要的事情。这种开销是为什么微服务的规模应该以适当的方式落地的主要原因之一。 开发团队速度的优势必须与在生产中运行更多服务的成本进行权衡 。同样，引入新技术和语言令人兴奋的同时，也具有成本和风险，必须认真加以权衡。 Charity Majors对此有一个伟大的谈话，网址：
https://www.oreilly.com/ideas/a-young-ladys-illustrated-primer-to-technical-decision-making 。
4.自动化是关键
自动化是降低与构建和运行新服务相关运维成本的关键 。 像Kubernetes、容器、CI/CD、监控等系统都具有相同目标，即使应用程序开发和运维团队更高效，以便他们能够更快地推进并构建更可靠的产品。
5.自服务引爆效率
把***一代的工具和系统更好地搭配，以实现本地私有云对旧的传统配置管理工具的需求，因为它们有助于破解传统的问题，以便它可以很容易地在团队里推广。 较新的工具通常赋予个人开发者和运维团队以自助服务的方式获得更高的生产力
接下来的第3部分 ，我们将看看Cloud Native如何与DevOps相关。 我们还要了解一下Google如何通过SRE角色实现这一点。
三、云原生DevOps
1.文化转型
将DevOps视为文化转型可能是最有用的，开发人员必须关心他们的应用程序如何在生产环境中运行。 此外，运维人员知道并有权知道应用程序如何工作，以便他们可以主动发挥作用，使应用程序更可靠。 在这些团队之间建立理解和同情是关键。
但这可以进一步。如果我们重新审视应用程序的构建方式和运维团队的结构，我们可以改进和深化这种关系。
2.网站可靠性工程师
Google不使用传统运维团队。 Google反而定义了一种称为“网站可靠性工程师”的新型工程师 。 这些是受过高度训练的工程师(在与其他工程师相同的水平得到补偿)，不仅携带寻呼机，而且希望和有能力在通过自动化推动应用程序更可靠的过程中发挥关键作用。
“第二天早上10点所发生的定义了SRE。”
3.激励SRE和开发团队的协作
当寻呼机在凌晨2点钟关闭时，任何人对寻呼机都做着同样的事情 - 试图找出发生了什么，以便他/她可以回去睡觉。 第二天早上10点所发生的定义了SRE。 做运维的人只是抱怨或者和开发团队一起合作保证寻呼机上出现的事情不在发生了就够了么? SRE和开发团队有使产品尽可能可靠的激励。 这与无指责的事故分析结合，可以促成没有技术债务的健康项目。
4.SRE受人尊敬
SRE是Google里最受尊敬的人之一。 事实上，通常产品的发布并不需要SRE，而是期望开发团队在生产环境中运行他们的产品 。引入SRE的过程通常涉及开发团队向SRE团队证明该产品已准备就绪。 预计开发团队将完成所有的基础的工作，包括设置监控和警报，警报触发的工作流和发布流程。 开发团队应该能够使寻呼机收到最少的报警，大多数问题已经被自动化。
5.运维专业化
由于运维的角色变得更加复杂和特定于应用程序，因此对于单个团队拥有整个运维堆栈没有什么意义。 这导致了运维专业化的想法。在某些方面，这是一种“反奴役”。 让我们从下到上。
运维专业化 硬件运维
这已经是明显可分离的。 事实上，很容易将IaaS云看作“硬件运维即服务”。
运维专业化 操作系统运维
有人必须确保机器启动，并有一个好的内核。 从应用程序依赖性管理中突破这一点反映了集中在托管容器( CoreOS ， Red Hat Project Atomic ， Ubuntu Snappy ， Rancher OS ， VMWare Photon ， Google Container Optimized OS )上的最小操作系统发布趋势。
运维专业化 集群运维
在容器化的世界中，计算集群成为一个逻辑基础架构平台。 集群系统(Kubernetes)提供了一组原子操作，使许多传统运维任务能够自我服务。
运维专业化 应用运维
每个应用程序现在可以有适当的专门的应用程序团队。 如上所述，开发团队可以并且应该在必要时发挥这一作用。 这个运维团队希望在应用程序上更深入，因为他们不必是其他层面的专家。 例如，在Google，AdWords Frontend SRE小组将与AdWords Frontend开发小组讨论，而不是与集群SRE(小组)小组交谈。 这种激励的一致性可以导致更好的结果。
根据组织的需要，可能还有其他专门的SRE团队的存在空间。 例如，存储服务可以被分解为具有专业技能的SRE的单独服务。 或者可能有一个团队负责构建和验证所有团队应根据政策使用的基本容器映像。
原文链接:https://blog.heptio.com/cloud-native-part-3-6f9d888c5f07#.seyinvei7
作者:Joe Beda
【本文为51CTO专栏作者“刘征”的原创稿件，转载请通过作者微信公众号“DevOps教练”（MyDevOps）获取授权】
