敏捷开发亦需要敏捷工具
在过去，许多依赖信息技术的企业，对于应用程序的开发过程中，整个开发与运维生命周期，需要投入大量人力、时间与资源进行测试与准备工作。 时至今日，全球各个产业大量依赖信息技术所带来的业务增长，也促成多数企业对于软件架构与开发方法、基础设施建设，乃至于组织结构如何调整的探讨，以便应对这样的改变，都是现代企业需要解决的重要课题。
软件开发方法论从过往大家所熟知到的瀑布式开发方式，推展到敏捷开发方式的倡导; 由多位软件工程领域大师，于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云原生