麻利开发亦须要麻利工具
在过来，许多依赖信息技术的企业，对于应用程序的开发过程中，整个开发与运维生命周期，须要投入大量人力、工夫与资源进行测试与筹备工作。时至今日，寰球各个产业大量依赖信息技术所带来的业务增长，也促成少数企业对于软件架构与开发方法、基础设施建设，乃至于组织构造如何调整的探讨，以便应答这样的扭转，都是古代企业须要解决的重要课题。
软件开发方法论从过往大家所熟知到的瀑布式开发方式，推展到麻利开发方式的提倡; 由多位软件工程畛域巨匠，于 2001 年发表了麻利宣言，麻利开发方法论亦提到软件工程实际的重要性; 其中，蕴含测试驱动开发、继续集成、继续交付等作法。
在 2009 年，Flickr 公司在 Velocity2009 年大会所分享的“Flickr 每天部署 10 次以上：开发与维运的高效率单干”造成轰动，也让各个产业开始思考，自家利用与服务高频公布的可能。
2013 年 Pivotal 的 Matt Stine，在承受华尔街日报专访的时候，在业界率先提除云原生的概念，随后 Pivotal 汇整成微服务、容器技术、DevOps 与继续集成 / 继续交付等四大因素。如何集成与交付再度成为要害因素，而各行业的 IT 需要对于高频交付，甚至是没有服务中断的高频交付需要，一劳永逸。
在传统软硬件所搭建的基础设施，要做到继续集成与继续交付实属不易，更遑论一路从单体演进到微服务架构的应用程序，更是让服务不停机、问题追踪、日志收集与监控等要求的难度晋升不少; 所幸虚拟化与容器技术，让前述繁冗的工作能够更容易做到自动化，而云原生与开源社区的蓬勃发展，让开发与维运人员有更多的抉择。
但云原生基金会的成员，来自不同的公司或是组织，所提出来的我的项目形形色色，尽管解决了许多问题，但各项目标经营策略与继续倒退等议题，让这些软件有着不同的停顿与命运，使得企业用户更须要具备相当规模的软件公司，帮助筛选与提供更欠缺的服务。
在利用现代化的浪潮下，云原生的概念与麻利可说是一体两面，测试与平安左移，加上高频率的公布，可解脱过来在上生产环境的最初阶段，才发现问题，大幅升高上线之后业务中断等的可能; 让利用疾速进入生产环境，对企业产生价值。但目前，相干流水线的搭建，多半由 DevOps 或 SRE 团队自行抉择与搭建，没有特定框架或是标准; 在大量或是简单的流水线搭建需要，紧接而来的会是治理的议题。
OOTB Supply Chain 简介
VMware Tanzu 是由一系列利用现代化所需的产品与工具所组成，其中 Tanzu Application Platform（简称 TAP）是依据 VMware 在世界各地，帮助企业用户进行数字化转型过程中，针对开发人员所需的生产力工具所推出的一系列工具。
TAP 将整个利用开发与维运生命周期分为 Inner Loop 与 Outer Loop 两个大区块。其中每一个环节皆须以不同的技术栈实现相干工作，满足企业对于开发生产力、维运自动化与信息安全等要求。
若以云原生基金会所涵盖的工具，自行筛选搭建，虽非不可能达成此指标，但除了技术与产品选型之外，搭建工作与后续的保护工作量将会十分可观。
而 TAP 曾经考量到企业用户需要与将来倒退，并整合了开源与 VMware 自家技术与产品，打造出残缺的工具链。
而其中的开箱即用（Out of The Box 简称 OOTB）的 Supply Chain 则是源自于开源我的项目 Choreographer Supply Chain。
Choreographer Supply Chain 可由 Path to Production 的构想谈起，也响应了后面所提“让利用疾速进入生产环境，对企业产生价值”的概念，以此为指标而提供开发者高生产力的工具，为维运人员强化流程的自动化，升高人为染指的需要。
从 Supply Chain 的性能角度来看，并以下图高维度的视角为例：以开发人员的角度，仅须要通过由 TAP 所提供的 Workload 形象层，抉择对应的流水线、配置所需的数据库或信息排队列服务，不须要分心解决 K8s 与其余基础设施的相干配置，把更多的工夫放在用户需要与利用开发工作，实现企业所交付工作，让企业服务晋升 Time To Market 以应答市场的疾速变动，也满足市场多样的需要。
运维人员则以 Choreographer Supply Chain 的框架与标准，布局与配置适宜该企业所需的继续集成与继续交付（或可称为平台拆卸阶段）流水线; 在这样的框架与标准之下，运维人员不须要破费心理去买通流水线上的各项工具与产品，更毋庸放心将来这些不同工具与产品的个别降级与保护工作; 仅需遵循 Supply Chain 的配置模板，进行配置工作，即可满足相干需要。
再从另外一个 TAP 产品设计理念来察看，TAP 是能够依据不同工作并配合 Tanzu Kubernetes Grid 的多集群设计，去布局不同性能、不同大小的 K8s 集群，满足整体利用开发生命周期所需涵盖的步骤与性能; 架构图如下所示：
对照更细节的维度来看，以 Web 利用领域建模为例，TAP 的弹性设计适宜工作单纯的繁多集群与简单工作所需的多集群架构需要。
在上述的架构里，有几个组件特地值得阐明：
1.Workload 形象层：通过此形象层，为开发者屏蔽了基础设施相干的配置，让开发者能够用本人相熟与关注的需要，配置如代码起源、指定 Spring Profile、利用所需 CPU 与内存等资源，亦可选用数据库与音讯队列，并配合 Open Service Broker 技术实现设定。此外，可透过形象层 Workload 的 Label 配置，决定该应用程序后续所需进行的流水线，实现 CI/CD 相干工作。
2.Tanzu Build Service：此组件源自于出名 PaaS 平台 Heroku 与 Pivotal 的 Buildpacks 技术; 过来，此项技术被 Heroku 与 Cloud Foundry 所采纳，提供自动化利用打包为容器镜像性能，它除了提供可制订的容器模板，更反对多种不同程式语言，如：Java、. net core、Python、Ruby、Go 与 PHP 多种常见的程序语言。因为 Buildpacks 技术所带来的便利性与安全性，始终以来深受企业用户青睐。因应 Kubernetes 的倒退，Heroku 与 VMware 联手将此技术开源并捐献给云原生基金会，后续 Google 也投入研发资源，让此项技术更加蓬勃发展。基于 Buildpacks 开源技术，VMware 将其倒退成具备商用反对的 Tanzu Build Service，提供 VMware 所验证的根底容器镜像，更将 Spring runtime、OpenJDK 与 Tomcat 等反对融入其中，提供企业客户一个更平安、最佳化且欠缺的高度平安镜像建制工具。
3.Convention Service：此组件位于整个 Supply Chain 的重要地位，透过平台对于应用程序的侦测与感知性能，主动配置容器自愈性能、监控与平安等。经由 TAP 自动化的机制，将其相干的配置注入 Kubernetes 部署文件之中，让开发团队专一于应用程序自身，也升高运维团队的工作量，藉此晋升工作效率与应用程序安全性。
总结与瞻望
在企业谋求业务增长的此刻，信息技术扮演着极其重要的角色，除了满足当初的需要，甚至于要以一直地迭代的手法，验证新的构想与摸索新的业务机会。
因而，高频公布与服务不中断的要求更甚以往。加上微服务架构的倒退，尽管提供更多利用开发的劣势，绝对的也带来部署与维运上的难度，再加上上述的高频公布与服务不中断的要求，对于 IT 相干团队的压力不言可喻。解决上述要求的计划如雨后春笋，也让信息相干从业人员眼花撩乱、抉择艰难。
VMware 在帮助企业实现数字转型，除了提供基础设施相干软件与服务，更关注利用开发者的需要，并一直推出晋升生产力的相干框架与技术。Tanzu Application Platform 就是集利用程序开发生命周期中所需之大成，让开发团队与维运团队能够各司其职，亦可严密单干，朝向开发运维合一的高效团队迈进。
在本文中所介绍的 Choreographer Supply Chain，即为 TAP 的外围组件之一。将来整个 Supply Chain 将可反对更多不同的技术栈，让利用部署过程中的查验与检核更加欠缺，亦提供客户更多适宜企业所需的选项。
作者：王钧平
王钧平是 VMware 大中华区利用现代化部门的架构师，具备 20 余年的利用程序开发教训，已经帮助电信、金融、制作等产业客户，进行利用现代化与数字转型等工作。近年来更专一于畛域驱动设计、测试驱动开发、设计模式等软件工程技术，并辅导客户采纳微服务架构与引进容器技术等，对于云原生相干技术具备丰盛教训。
起源|公众号：VMwareTanzu 云原生