1 - 参考资料概述

Cloud Native参考资料概述

Cloud Native 参考资料

2 - 2019

云原生参考资料之文章(2019)

3 - 2018

云原生参考资料之文章(2018)

4 - 2017

云原生参考资料之文章(2017)

4.1 - 迁移到云原生应用架构

迁移到云原生应用架构的学习笔记

文章说明:

1.1 为何使用云原生应用架构

速度

在传统企业中,为应用提供环境和部署新版本花费的时间通常以天、周或月来计算。

互联网公司经常提到它们每天几百次发布的实践。为什么频繁发布如此重要?

  • 如果你可以每天实现几百次发布,你们就可以几乎立即从错误的版本恢复过来。
  • 如果你可以立即从错误中恢复过来,你就能够承受更多的风险
  • 如果你可以承受更多的风险,你就可以做更疯狂的试验
  • 这些试验结果可能会成为你接下来的竞争优势

所以,速度快很重要。这个快速发布-》试错 -》改进 实现快速创新的说法不错。

TODO:考虑画一个示意图,用来说明为什么要快。

精益大师Mary Poppendick提出的问题了——“如果只是改变了应用的一行代码,您的组织需要多长时间才能把应用部署到线上?“

这个说法非常适合用来直观的体现快。

安全

云原生应用架构在快速变动的需求、稳定性、可用性和耐久性之间寻求平衡。这是可能的而且非常有必要同时实现的。

安全的实现方式:

  • 可观测性:指标、监控、警报、数据可视化框架和工具是所有云原生应用程序体系结构的核心
  • 故障隔离:将系统拆解为微服务;结合容错
  • 容错:防止级联故障
  • 自动恢复:有可观测性、故障隔离、容错字后,就有机会做自动恢复。在可替换性的支持下,可以简单的重新或者重新部署

弹性扩展

如何扩大服务能力:

  • 水平扩展应用实例
  • 改善资源利用率:虚拟化/容器化 + 部署多个工作负载 (需要隔离性支持),然后通过编排来调度以调高效率

公有云基础设施的出现有助于实现这个目标。

付出的代码:

  • 架构:支持水平扩展的应用程序的架构必须不同
  • 状态:应用无状态 + 状态外部化

移动应用和客户端多样性

  • 移动平台的巨大差异也对应用架构提出了要求
  • 移动应用程序通常必须与多个传统系统以及云原生应用程序架构中的多个微服务进行交互
  • 云原生应用程序架构还通过诸如API网关之类的设计模式来支持移动优先开发的概念:指的是BFF模式吧?

1.2 云原生架构定义

12因素应用

12因素应用是一系列云原生应用架构的模式集合,最初由Heroku提出。如Cloud Foundry、Heroku和Amazon ElasticBeanstalk都对部署12因素应用进行了专门的优化。

微服务

微服务将单体业务系统分解为多个“仅做好一件事”的可独立部署的服务。

自服务敏捷架构

使用云原生应用架构的团队通常负责其应用的部署和持续运营。(开始 + 测试 + 部署 + 运营)

基于API的协作

在云原生应用程序架构中,服务之间的唯一互动模式是通过已发布和版本化的API。 实现体现为微服务

抗脆弱性

稳健性或弹性,

Nassim Taleb在他的Antifragile(Random House)一书中介绍了抗脆弱性的概念

“混沌猴” 将随机故障注入到生产组件中,目的是识别和消除架构中的缺陷。

感觉这个说法有点不太合适,还是用回 弹性 比较好。

2.1 文化变革

企业IT采用云原生架构所需的变革根本不是技术性的,而是企业文化和组织的变革,围绕消除造成浪费的结构、流程和活动。

这个说到点了!

从信息孤岛到DevOps

企业IT通常被组织成以下许多孤岛:

  • 软件开发:开发
  • 质量保证:测试
  • 数据库管理:DBA
  • 系统管理:运维
  • IT运营
  • 发布管理
  • 项目管理

DevOps代表着这样一种思想,即将这些信息孤岛构建成共享的工具集、词汇表和沟通结构,以服务于专注于单一目标的文化:快速、安全得交付价值。

从间断均衡到持续交付

从集中治理到分散自治

TBD:后面写云原生文化时再整理。

5 - 2016

云原生参考资料之文章(2016)

6 - 2015及更早

云原生参考资料之文章(2015)

7 - 2018

Cloud Native 书籍介绍

7.1 - 书籍

Cloud Native 书籍介绍

Cloud Native 书籍介绍

2015

时间未知

8 - 演讲(2017)

Cloud Native 演讲介绍

Cloud Native 演讲介绍(2017年)

国内的演讲:

8.1 - CNCF: What is Cloud Native

What is Cloud Native and why should I care

笔记说明

“What is Cloud Native and why should I care” 这个Slides来自 Alexis Richardson ,他是 CNCF TOC Chair & CEO Weaveworks,时间是 23 Feb 2017。

Weave的解决方案

Netflix率先将云原生作为一种实用工具,这里有一个重要的slides Netflix Development Patterns for Scale, Performance & Availability ,来自Netflix,2013年,应该是第一次提出 Cloud Native 的概念吧?

Weave Cloud 业务需求:

  • 24-7-365, 全球,多租户,安全等
  • 团队100%专注于快速应用开发,而不是VM管理和维护
  • 我们可以根据使用/成本来增加/减少组件
  • 不在接线上花钱(Prometheus只适用于Docker,Kubernetes ..)
  • 我们可以在任何地方运行Weave Cloud应用程序(开源而不仅仅是亚马逊)

我们的解决方案经验:对我们最重要的是什么?

  1. 自动化:很多自动化。端到端。自动化所有事情。

    如:CI / CD!编排!可观测性!

  2. 需要关注应用而不是基础设施,例如使用随时随地都能正常工作的标准包装,如容器!

  3. 需要了解并应用新的云原生模式和工具,以用于监控,日志,正常运行时间管理等,如微服务及其他!

这里有一个非常有意思的自动化实践,ABCDE:

  • App is developed & tested locally:本地开发和测试应用,这个对开发效率有非常大的帮助,的确很重要。
  • Built automatically using CI of our choice:使用我们选择的CI进行自动构建
  • Container image pushed automatically:自动推送容器镜像
  • Deployed automatically using Weave Cloud deploy service…:使用Weave云部署服务自动部署
  • …to an Execution Environment of your choice:部署到选择的执行环境

经验教训

Cloud Native需要很好的工具:

  • 开源
  • 随处运行
  • 可信赖的软件,由可靠的团队和流程管理
  • 易于监控和控制
  • 与其他工具互操作,以通用惯例的方式

基础设施必然是枯燥乏味的:

  • 要专注于您的应用,基础设施必须是枯燥乏味的
  • 使用容器
  • 使用PaaS/CaaS或您喜欢的任何容器平台
  • 注意1%的故障问题

我们需要良好的模式:

  • 微服务(和Microliths)

  • Cattle not Pets:是奶牛不是宠物

  • 可观察性和控制性

  • 通信模式 - 蓝/绿,金丝雀,智能路由和负载均衡……

Cattle not Pets 算是行业术语,或者典故了,具体解释见 https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets

Cloud Native是模式

模式用来干嘛:通过向他人学习来避免痛苦

  • Availability/可用性:Microservices & Netflix for everyone

  • Automation/自动化: Deployment & Management

  • 促进 CI/CD & 自动化的“ABCDE”

  • 任何地方! Containers 是可移动的

通用开源软件

  • Software is eating the world
  • Open Source is eating Software
  • Cloud is eating Open Source

如果没有通用开源软件,我们将冒着Cloud锁定的风险。

Appendix 中的 cloud native 层次关系分析非常有意思。

8.2 - CNCF: Cloud Native Strategy

Cloud Native Strategy

笔记说明

“Cloud Native Strategy” 这个Slides来自 Jamie Dobson,时间是 2017-02。

Strategy

何时使用策略:

  • 超越组织边界。
  • 组织缺乏关键能力。
  • 创造赢家和输家。 (还有抵抗)

元素:

  • 目标建立在更大的故事中
  • Situational Awareness:情境意识
  • Now and the future: 现在和将来
  • Coalitions: 联盟
  • Self-Supporting Actions: 自我支持行动
  • Risk: 风险
  • Courage: 勇气

A strategy is a way through a difficulty, an approach to overcoming an obstacle, a response to a challenge.

Strategy可是是克服困难的一种方式,也可是是克服障碍的一个方法,是一个对挑战的回应。

鹅和金蛋

  • Microservices.
  • Highly available.
  • Two pizza teams.
  • Auto-Scaling.
  • Load Balancing.

备注:这一段没太看懂要说啥。

经验教训

  • Lesson #1 - Don’t Steal Ideas But Rather:不要窃取想法,而是
  • Lesson #2 - Steal The Processes That Created Those Ideas:而是窃取创造这些想法的流程

这个说法非常有道理。

  • Lesson #3 - Define the Problem You Are Trying to Solve :定义要解决的问题

这张图倒是很有借鉴意义,cloud native 的能力,分组方式。

  • Infrastructure is Programmable:基础设施是可编程的
  • System Shape== Organisational Shape:系统形状==组织形状

摸着石头过河:

  • Risk and Uncertainty: 风险和不确定性

  • Current Advantage: 目前的优势

  • Potential Actions: 潜在行动

  • Lesson #4 - In Great Uncertainty Take Smaller Steps: 在有巨大的不确定性的情况下,小步前进

Triple D 的概念:

  1. 发现问题
  2. 定义材料
  3. 发布解决方案

Lesson #5 - The Quicker The Cycle Time The Quicker You Learn:循环时间越快学的越快

反模式:

Anti-Pattern #1 - Goal Heavy, Action Light: 目标重,动作轻 Anti-Pattern #2 - Doing Two Things At Once:同时做两件事情 Anti-Pattern #3 - Not Finishing What You Start:开始但不结束

这个三个反模式讲的很好。后面还有一个反模式:

Anti-Pattern - Stealing People’s Ideas. AKA Being Extremely Stupid. And Unoriginal. 窃取其他人的想法,十分愚蠢,不是原创

继续lesson:

Lesson #6 - In Times of Great Uncertainty Buy Knowledge:在有巨大的不确定性的情况下,购买知识

●Lesson #7 - Knowing When To Use Strategy:知道该何时使用策略

这里出来一个daniel pink的关于dive 驱动力的图:

Appendix - Other Useful Models 这里的附录有一些模型。

Autonomy, Mastery 和 Purpose 框架

查了一下,Pink的 Autonomy, Mastery 和 Purpose 框架,参考 https://www.mindtools.com/pages/article/autonomy-mastery-purpose.htm

根据Pink的说法,内在动机基于三个关键因素:自主,征服和目的

autonomy/自主

是知道自己生活和工作的需要。要充分激励,您必须能够控制自己的工作,做什么以及做谁。

据Pink说,自主性激励我们创造性地思考,无需遵守严格的工作场所规则。通过重新思考传统的控制理念 - 正常的办公时间,着装规范,数字目标等 - 组织可以增加员工的自主权,建立信任,并改善创新和创造力。

软件公司经常使用自主激励,其中许多公司让他们的工程师有时间在他们自己的开发项目上工作。这使他们可以自由地尝试和测试新想法,这可以为组织带来好处,例如改进的流程或创新的解决方案。

mastery/征服

征服是改善的愿望。如果你受到征服的激励,你可能会发现自己的潜力是无限的,并且你会不断寻求通过学习和练习来提高你的技能。寻求征服的人需要为了自己的利益而获得它。

例如,以征服为动力的运动员可能希望尽可能快地跑步。她收到的任何奖章都不如持续改进的重要性。

purpose/目的

如果人们不了解或不能投身于“bigger picture”,他们可能会在工作中脱离接触并失去动力。

但那些相信自己正在努力做出比自己更大更重要的事情的人往往是最勤奋,最富有成效和最积极的人。所以,鼓励他们找到他们工作的目的 - 例如,通过使用OKR或OGSM将他们的个人目标与组织目标联系起来 - 不仅可以赢得他们的思想,也可以赢得他们的心灵。

例如,为员工提供利用他们的技能使当地非营利组织受益的机会可以培养强烈的目标感。正如开发以价值观或道德为导向的公司愿景一样,鼓励人们“购买”其关键的组织目标。

9 - 演讲(2018)

Cloud Native 演讲介绍

Cloud Native 2018年演讲介绍

9.1 - CNCF: Evolving Cloud Native Landscape

Evolving Cloud Native Landscape

说明

Evolving Cloud Native Landscape ,来自 Chris Aniszczyk ,CTO of CNCF。

笔记

Chris Aniszczyk 介绍:

  • CTO/COO, Cloud Native Computing Foundation (CNCF)
  • Executive Director, Open Container Initiative (OCI)
  • VP, Developer Relations, Linux Foundation (LF)

备注:好像之前来杭州和蚂蚁谈合作的是这位,待查证。

What is Cloud Native? Definition v1.0

https://github.com/cncf/toc/blob/master/DEFINITION.md

现在这个定义有中文版本了。

为何采用云原生:

  1. 更好的资源效率,可以用较少的服务器上运行相同数量的服务
  2. 云原生基础架构可实现更高的开发速度 - 更快地改善您的服务 - 降低风险
  3. 云原生允许多云(在公共云之间切换或在多个云上运行)和混合云(在数据中心和公共云之间移动工作负载)

Cloud Native Trail Map

Cloud Native Trail Map为企业开始云原生之旅提供了概述。

图片来自这里:Introducing The Cloud Native Landscape 2.0 – Interactive Edition, 清晰原图请见 https://github.com/cncf/landscape#trail-map (大概4M)

What Have We Learned?

  • 核心构建块: Servers ➡ Virtual Machines ➡ Buildpacks ➡ Containers
  • 隔离单元: 从重量级到轻量级
  • 不可变性: From pets to cattle
  • 供应商: 从闭源单供应商到开源跨供应商

IoT + Edge + Kubernetes

物联网 + 边缘计算 + Kubernetes,应该是一个好大的市场。

简单描述了这些场景,有需要时再来看吧,暂时用不上:

  • Kubernetes: IoT+Edge Working Group
  • KubeEdge: Kubernetes + Edge Nodes
  • Serverless + Nodeless

10 - 演讲(2016)

Cloud Native 演讲介绍

Cloud Native 演讲介绍(2016年)

11 - 演讲(2015)

Cloud Native 演讲介绍

Cloud Native 演讲介绍(2015年及更早)

2015

2014

2013

11.1 - Netflix: Netflix Development Patterns

Netflix Development Patterns for Rapid Iteration, Scale, Performance, & Availability

说明

Netflix Development Patterns for Scale, Performance & Availability ,来自Netflix,2013年,应该是第一次提出 Cloud Native 的概念吧?

笔记

这页好像很有历史意义,猜测是第一次出现 Cloud native :

Cloud Native:

  • Service oriented architecture:2013年还是SOA,当时还没有微服务的概念
  • Redundancy
  • Statelessness:无状态对扩展实在是太重要也太方便了
  • NoSQL:2013年nosql是大热
  • Eventual consistency:最终一致性的实践倒是挺早

按照规模和变更频率划分为四种类型:

  1. enterprise IT:规模小,变化慢,所以容易处理
  2. 电信:规模大,变化慢,主要应对硬件失败
  3. 初创公司:规模小,变化快,主要应对软件失败
  4. 网络规模:规模大,变化快,软硬件或者说所有东西都会出问题

Netflix Cloud Goals:

  • Availability:可用性优先考虑,4个99(99.99%)
  • Scale:然后是可扩展性
  • Performance:再是性能

可用性的复合,当服务依赖增加时,可用性下降。

为了在有1000个组件的请求下达到4个九:

  • 如果组件失败会导致系统失败,则要求每个组件达到6个9
  • 或者,如果组件失败可以降解而不是导致系统失败,则可以隔离非依赖

但是,Availability, Scale, Performance 是不够的!

快速迭代,提高变更率,而变更会导致bug,变更频率会影响可用性。

可用性和变更率之间的妥协: 当变更率增加时,可用性下降。

如果要提高可用性,就要降低变更率。

而要改变曲线,同时实现提高可用性和增加变更频率。

这就必须打破导致级联系统失败的级联依赖,实现子系统隔离: 让失败只发生在一个组件中,而绝不导致级联系统失败。

而子系统隔离需要实现:

  • 具备超时和故障转移能力的冗余系统:当超时时可以有默认相应作为fallback
  • 金丝雀推出 (Canary Push)
  • Red/Black 部署:应该就是现在常说的蓝绿部署
  • Standby Blue system:待机蓝色系统,应该指冷备、热备之类
  • Zone isolation:区域隔离,以应对基础设施失败,如电力故障
  • Region isolation:地域隔离,通过DNS切换region,然后一个region下再有两个zone

子系统隔离的总结,不得不说netflix厉害,2013年就做的这么成熟。