全面标准化
我为会议上的演讲准备了这些材料，并问我们的技术总监，Kubernetes对我们组织的主要特点是什么。 他回答：
开发人员自己不知道他们做了多少额外的工作。
显然，他的灵感来自于最近读过的《事实》 （ Factfulness） -很难注意到微小和持续的变化使情况变得更好，而我们却不断地忽略了自己的进步。
但是转向Kubernetes绝对不是微不足道的。
我们几乎有30个团队在集群上运行全部或部分工作负载。 我们大约70％的HTTP流量是由Kubernetes集群上的应用程序生成的。 这可能是自从我在Forward集团于2010年收购uSwitch之后我加入公司以来最大的技术融合，那时我们从.NET和物理服务器切换到AWS，从单片系统切换到微服务 。
这一切发生得非常快。 2017年底，所有团队都使用了他们的AWS基础架构。 他们设置了负载均衡器，EC2实例，ECS集群更新以及类似的东西。 一年多了，一切都变了。
我们花了最少的时间进行融合，因此，Kubernetes帮助我们解决了紧迫的问题-我们的云正在扩展，组织变得越来越复杂，我们几乎无法招募新人加入团队。 我们没有将组织更改为使用Kubernetes。 相反，我们使用Kubernetes更改了组织。
开发人员可能没有注意到大的变化，但是数据说明了一切。 稍后再详细介绍。
许多年前，我在Clojure会议上听了Michael Nygard的演讲，内容涉及无法达到最终状态的建筑 。 他睁开了我的眼睛。 将电视商店与厨房用品和大规模软件体系结构进行比较时，一个整洁而有序的系统看起来很有趣-现有系统看起来像是一把哑刀，并且出现了某种粥而不是切成薄片。 没有新刀，沙拉就没什么可考虑的了。
这是关于组织如何评价三年项目的方法：第一年是开发和准备，第二年是实施，第三年是回报。 他在一次演讲中说，这样的项目通常是连续进行的，很少到第二年年底（通常是由于被另一家公司收购以及方向和战略的改变），因此通常的架构是
变化的层次看起来有些稳定。
uSwitch是一个很好的例子。
我们切换到AWS的原因有很多-我们的系统无法应对高峰负载，并且组织过于僵化，而且针对特定项目成立并由专业划分的密切相关团队阻碍了组织的发展。
我们不会放弃所有内容，转移所有系统并重新开始。 我们通过现有的负载平衡器通过代理创建了新服务，并逐渐使旧应用程序阻塞 。 我们想立即显示退货，并在第一周内对生产中的新服务的第一版进行了A / B测试。 结果，我们采用了长期产品，并开始从开发人员，设计人员，分析人员等组成团队。然后，我们立即看到了结果。 在2010年，这似乎是一次真正的革命。
年复一年，我们增加了新的团队，服务和应用程序，并逐渐“扼杀”了整体系统。 团队进步很快-现在他们彼此独立工作，由所有必要领域的专家组成。 我们最小化了产品发布的团队互动。 我们仅为负载均衡器的配置分配了几个命令。
团队自己选择了开发方法，工具和语言。 我们为他们设置了任务，他们自己找到了解决方案，因为他们是这方面的精通技术。 使用AWS，这些更改变得更加容易。
我们直观地遵循了编程原则-彼此之间松散连接的团队之间的交流会减少，并且我们不必花费宝贵的资源来协调他们的工作。 所有这些在最近出版的《加速 》 一书中都有很好的描述。
结果，正如迈克尔·尼加德（Michael Nygard）所描述的，我们得到了一个包含许多层变更的系统-有些系统是使用Puppet自动化的，有些是使用Terraform自动化的，有些是我们使用ECS的地方，有些是EC2。
在2012年， 我们为我们的体系结构感到自豪，可以轻松地将其更改为实验 ，找到成功的解决方案并进行开发。
但是在2017年，我们意识到发生了很多变化。
AWS现在比2010年复杂得多。它提供了大量的选项和功能-但并非没有后果。 如今，任何与EC2合作的团队都必须选择VPC，网络配置等等。
我们自己经历了这一过程-团队开始抱怨他们在基础架构维护上花费了越来越多的时间，例如，更新AWS ECS集群 ，EC2计算机中的实例，从ELB平衡器切换到ALB等。
2017年中，在公司活动中，我敦促每个人标准化他们的工作，以提高系统的整体质量。 我用刻薄的冰山比喻来展示我们如何创建和维护软件：
我说过，我们公司中的大多数团队应该创建服务或产品，并专注于解决问题，应用程序代码，平台和库等。 大量工作仍在水下-集成日志，提高可观察性，管理秘密等。
那时，每个应用程序开发人员团队几乎都处理了整个冰山，并自行做出了所有决定-选择语言，开发环境，库和指标工具，操作系统，实例类型，存储。
在金字塔底层，我们拥有Amazon Web Services基础架构。 但是，并非所有的AWS服务都是相同的。 它们具有后端即服务（BaaS） ，例如用于身份验证和数据存储。 还有其他相对较低级别的服务，例如EC2。 我想研究数据并了解团队有理由抱怨，他们确实花更多的时间在底层服务上，并做出许多不是最重要的决定。
我使用CloudTrail将服务分为几类，收集了所有可用的统计信息，然后使用BigQuery ， Athena和ggplot2来查看开发人员的情况最近如何变化。 相反，我们认为RDS，Redshift等服务的增长是可取的（并且是预期的），而EC2，CloudFormation等的增长是可取的。
图表上的每个点都显示了我们的员工在特定时期内每周使用的低级服务数量的90％（红色），80％（绿色）和50％（蓝色）。 我添加了平滑线来显示趋势。
尽管我们在部署软件时（例如，使用容器和Amazon ECS）的目标是更高层次的抽象，但是我们的开发人员经常使用越来越多的AWS服务，并且没有从管理系统的困难中充分抽象出来。 在两年中，服务数量为50％的员工增加了一倍，而为20％的几乎增加了两倍。
这限制了我们公司的成长。 团队寻求自治，但是如何雇用新人呢？ 我们需要强大的应用程序和产品开发人员，以及对日趋完善的AWS系统的了解。
我们想扩大我们的团队，同时保留我们成功的原则：自治，最少的协调和自助服务基础架构。
使用Kubernetes，我们通过以应用程序为中心的抽象以及以最少的团队协作来维护和配置集群的能力来实现了这一目标。
面向应用的抽象
Kubernetes概念很容易与应用程序开发人员使用的语言相匹配。 假设您正在将应用程序版本作为部署进行管理。 您可以在服务后面运行多个副本，然后通过Ingress将它们映射到HTTP。 通过用户资源，您可以根据需要扩展和专用化该语言。
团队使用这些抽象可以更有效地工作。 基本上，此示例提供了部署和运行Web应用程序所需的一切。 剩下的就是Kubernetes。
在带有冰山的图片中，这些概念是在水平面上，将上方的开发人员的任务与下方的平台结合在一起。 集群管理团队可以做出低级且微不足道的决策（关于管理指标，日志记录等），同时与开发人员通俗地说同一语言。
在2010年，uSwitch拥有传统的团队来为整体系统提供服务，最近，我们拥有一个IT部门来部分管理我们的AWS账户。 在我看来，缺乏共同概念严重阻碍了该团队的工作。
如果您的词汇表，负载均衡器和子网中只有EC2实例，请尝试说些有用的话。 描述应用程序的本质非常困难，甚至不可能。 它可以是Debian软件包，可以通过Capistrano进行部署，等等。 我们无法用所有人都通用的语言来描述应用程序。
在2000年代初期，我在伦敦的ThoughtWorks工作。 在采访中，我被建议阅读Eric Evans的“面向问题的设计” 。 我在回家的路上买了一本书，开始在火车上读书。 从那时起，我几乎在每个项目和系统中都记得她。
本书的主要概念之一是不同团队之间使用一种语言进行交流。 Kubernetes只是为开发人员和基础架构维护团队提供了这种统一的语言，这是其主要优势之一。 另外，它可以扩展和补充其他主题领域和业务范围。
使用通用语言进行交流可以提高工作效率，但仍然需要尽可能限制团队之间的互动。
必要的最少互动
Accelerate的作者强调了松散耦合的体系结构的特征，IT团队可以使用这种体系结构更有效地工作：
在2017年，持续交付的成功取决于团队是否可以：
未经管理人员许可，请认真更改系统的结构。
认真更改系统的结构，而不必等待其他团队进行更改，也不必为其他团队创建很多不必要的工作。
在执行任务时，无需与其他团队进行沟通或协调。
随需部署和发布产品或服务，无论与之关联的其他服务如何。
无需集成测试环境即可按需执行大多数测试。
我们需要所有团队都使用集中式软件多租户集群，但同时我们希望保持这些特征。 我们尚未达到理想，但我们正在尽最大努力：
- 我们有几个工作集群，团队自己选择在哪里运行应用程序。 我们尚未使用联合身份验证 （我们正在等待AWS支持），但是我们拥有Envoy来在不同集群中的Ingress平衡器上进行负载平衡。 我们使用持续交付管道（我们拥有Drone ）和其他AWS服务来自动化大多数任务。
- 所有集群都具有相同的名称空间 。 每个团队约一个。
- 我们通过RBAC （基于角色的访问控制）控制对名称空间的访问。 为了进行身份验证和授权，我们在Active Directory中使用公司身份。
- 集群会自动扩展 ，我们会尽力优化节点的启动时间。 它仍然需要花费几分钟，但是，总的来说，即使工作量很大，我们也不会进行协调。
- 应用程序将根据Prometheus的应用程序级别指标自动扩展。 开发团队通过每秒查询指标，每秒操作等来控制其应用程序的自动扩展。由于群集具有自动扩展功能，因此当需求超出当前群集的能力时，系统即可准备节点。
- 我们使用名为u的命令行工具编写了Go语言，该工具可在Kubernetes中标准化命令身份验证，使用Vault ，请求临时AWS凭证等。
我不确定使用Kubernetes可以拥有更多的自主权，但是绝对可以保持较高的自主权，与此同时我们也摆脱了一些问题。
切换到Kubernetes很快。 该图显示了工作集群中的名称空间总数（大约等于命令数）。 第一次出现在2017年2月。
我们有急事的理由-我们希望让专注于其产品的小型团队免于对基础架构的担忧。
一队同意由于logrotate设置不正确而导致其应用服务器空间不足时切换到Kubernetes。 过渡只用了几天，然后他们又开始做生意。
最近，团队已转向Kubetnetes寻求改进的工具。 Kubernetes集群简化了与我们的Hashicorp Vault ， Google Cloud Trace和类似工具的集成。 我们所有的团队都获得了更有效的功能。
我已经显示了一张图表，其中包含从2014年底到2017年我们的员工每周使用的服务数量的百分位数。 这是此图到今天的延续。
我们在管理复杂的AWS框架方面取得了进展。 我很高兴现在有一半的员工正在做与2015年初相同的事情。 我们在云计算团队中拥有4-6名员工，大约占总数的10％-90％的百分位数几乎没有动摇也就不足为奇了。 但我也希望在这里取得进展。
最后，我将讨论我们的开发周期如何变化，并再次回顾一下最近阅读的《加速》一书。
该书提到了两个精益开发指标：交货时间和包装尺寸。 从请求到完成解决方案的交付都考虑了交货时间。 包装尺寸是工作量。 包装尺寸越小，工作效率越高：
包装越小，生产周期越短，工艺变异性就越小，风险，成本和费用就越少，我们将更快地获得反馈，更有效地工作，我们有更多的动力，我们试图更快地完成并减少交货时间。
该书建议按部署频率衡量数据包的大小，部署频率越高，数据包越小。
我们有一些部署的数据。 数据并不完全准确-有些团队将版本直接发送到存储库的主分支，有些使用其他机制。 这并不包括所有申请，但是12个月的数据可以认为是指示性的。
第三十周的失败是圣诞节。 对于其他情况，我们看到部署频率增加，这意味着数据包大小减小。 从2018年3月到2018年5月，发布的频率几乎翻了一番，最近我们有时每天发布100多个。
切换到Kubernetes只是我们标准化，自动化和改进工具策略的一部分。 所有这些因素最有可能影响释放的频率。
Accelerate还讨论了部署频率与员工人数之间的关系，以及如果增加员工数量公司的运作速度。 作者强调了相关架构和团队的局限性：
传统上认为，扩大团队可以提高整体生产率，但会降低单个开发人员的生产率。
如果我们在部署频率上采用相同的数据，并绘制出对用户数量的依赖关系图，则可以看到，即使我们有更多的人，我们也可以提高发布频率。
在本文的开头，我提到了《 事实 》一书（这启发了我们的CTO）。 对于我们的开发人员而言，向Kubernetes的过渡已成为最重要，最快速的技术融合。 我们一步步走，很容易不注意到一切都变了好转。 拥有数据是件好事，它们表明我们已经达到了想要的目标–我们的员工致力于他们的产品并在自己的领域中做出重要的决定。
过去对我们有好处。 我们拥有微服务，AWS，完善的产品团队，负责产品生产的开发人员，松散耦合的团队和架构。 我在2012年的一次会议的报告“我们的启蒙时代” （“我们的启蒙时代”）中谈到了这一点。 但是，完美无极限。
最后，我想引用另一本书-Scale 。 我是最近开始的，关于复杂系统的能耗有一个有趣的片段：
为了维持显影系统中的秩序和结构，需要不断地涌入能量，这会造成混乱。 因此，为了维持生命，我们必须一直吃饭，以克服不可避免的熵。
我们通过为增长，创新，维护和修复提供更多的能量来对抗熵，随着系统的老化，这变得越来越困难，而这场斗争是关于任何系统的衰老，死亡率，可持续性和自给自足的认真讨论的基础，公司或社会。
我认为您可以在此处添加IT系统。 我希望我们的最后努力将使熵保持一段时间。