在晓冬过去一年参与的项目中，用户经常会提到“IaaS”“PaaS”这些词。实际工作中，晓冬和同事们也帮助客户落地了一些成功案例，赢得了用户的信赖和好评。这说明“即服务”这个词越发深入IT人心，也体现出不少企业IT已经踏上了向服务转型之路。在介绍中，晓冬一直拿“吃汉堡”举例，来说明基础设施即服务IaaS、平台即服务PaaS和软件即服务SaaS这些概念。
比如晓冬牛年第一天特别想吃牛肉汉堡，为了满足自己的口腹之欲，摆在晓冬面前的有这么些【解决方案】：
-
自己动手丰衣足食：去超市购买牛肉、面粉，在经历了腌渍、加工、发酵、烘烤等一系列复杂的流程之后，最终再拿出从便利店买的快乐水，终于吃上了一份牛肉汉堡套餐。
-
半成品加工：拿出从超市购买的已经腌渍加工处理过的牛肉、面包，开火煎烤牛肉、微波炉“转一转”面包，拿出快乐水，也是一种牛肉汉堡套餐的体验。
-
某团外卖送啥都快：通过外卖平台，点一份牛肉汉堡，等待外卖期间抽空去楼下买了一份快乐水，半小时后外卖送到，享受美食。
-
楼下快餐店：步行5分钟，去楼下快餐店，点上一份牛肉汉堡套餐，不到10分钟就吃上了美食，就是贵了点。
不难看出，从左到右依次是一个【消费者】从【自建】到享受【即服务】的过程。消费者的需求在得到满足的同时，也大大缩短了达成目标的时间，提高了实现成效的速率。而我们常说的IaaS、PaaS、SaaS就是服务提供商(公有云)或者企业IT(私有云)对最终用户(消费者)提供的几种服务模式。最终用户使用这些服务的目的是为了达成自己的业务目的(比如部署一个现代化应用)，实现自己的成效(比如定个小目标，先赚他一个亿)。对企业内部来说，IT提供这些服务来达成自己的成效(向服务转型)，实现自己的价值(标准化定价模型量化工作量)。
正是因为在这种模式下，IT能体现出自己的价值，才会越发深入人心。【一切即服务】将会吸引越来越多的IT注目，相关市场的前景也一定会越来越好。
🐂 无论私有云还是公有云，能实现【业务敏捷交付】的就是好云。
业务放到哪朵云一直是一个争论不休的话题，恐怕在未来很长一段时间都无法准确地给出答案。但实事求是地说，企业无论是选择私有云、公有云还是混合云都能实现它的IT成效：向最终用户提供IaaS、PaaS、SaaS乃至CaaS、XaaS这类服务。
许多人说，公有云比私有云的成本低，晓冬为此也专门查阅了不少研究和报告，发现这类说辞大都来自于厂商的言论，鲜有具有说服力的依据。而早在两年前，451 Research的数字化经济研究总监Owen Rogers就发表过类似的“吐槽”，他言道：“The prevailing mythology that Public Cloud is always cheaper is very powerful.”
在晓冬看来，真正让用户选择公有云服务的原因是公有云能提供标准化的、按需灵活的服务。相对应地，用户选择私有云的原因是因为它的数据安全保护、资产所有权归属以及和企业业务流程集成方面的优越性。从成本角度去决策上公有云或是私有云不太可能会是主要的驱动力，但是如果能在不损害业务敏捷交付的前提下，实现成本最优，是IT决策者所乐意看到的成效。
这里，我们不得不说说一个老生常谈的词汇叫做“业务敏捷交付”。一言以蔽之，就是在不断提高的客户期望和竞争压力环境下，企业以更快速度发布首次即正确的软件，以实现盈利，这就是业务敏捷交付的驱动力。
正是在这种发展趋势下，微服务的概念被提出，与传统单体应用庞大的代码库相比，微服务让开发人员只专注于小型代码库，从而带来许多方面的收益。包括为上文所说的【业务敏捷交付】提供了一种途径，容器正是实现微服务架构最适合的技术，而无论是私有云还是公有云都可以为容器提供一个良好的运行环境。
🐂【容器基础设施与管理即服务CaaS】会成为新的热点。
根据各项数据和报告显示，容器的使用在全球企业中稳中有升，65%的组织表示他们使用Docker容器，58%的组织以某种方式使用Kubernetes编排系统。(来源《Flexera 2020年云计算状态报告》)Gartner也提出，到2022年，全球将有超过75%的企业将在生产环境中使用容器技术。迫切的企业需求加上高速的技术发展，各大厂商也提出了【容器基础设施与管理即服务CaaS】产品和解决方案。
CaaS的理念其实很好理解，就好像是在IaaS上交付虚拟机一样容易的来交付容器。其相关的一切基础设施，包括网络、负载均衡、安全、存储、计算、认证、弹性缩放等等均由CaaS平台提供。就目前来说，开源项目Kubernetes依旧是主流的容器编排引擎，管理员通过K8S能轻松地实现容器的部署与运行。因此CaaS不会受到厂商的绑定，用户可以自由地选择公有云或者私有云来构建CaaS平台，用以推进应用现代化进程。
去年4月，VMware正式发布了vSphere7，用户终于可以【像交付虚拟机一样容易的交付容器】。概括的说，这种变革就是用Kubernetes来重新定义vSphere。我一直认为Project Pacific太平洋计划是VMware下的一盘很大的棋，其看准的就是容器市场未来广阔的发展前景。但就vSphere本身来说，距离CaaS平台还有一段距离，举个生动的例子来说，vSphere就像是几块普通的【乐高积木】，想要筑成一个稳定可靠的CaaS平台，实现企业数字化转型，还需要一些其他的【积木】，而VCF(VMware Cloud Foundation)就是一个包含各类必要组件的【积木套装】。
近半年来，不少朋友都会谈起Tanzu。其实Tanzu是一个很宽泛的概念，在晓冬看来，VCF是Tanzu技术堆栈中的基石，它提供了用户快速构建一个CaaS平台的可能。
晓冬对于VCF的理解是：这是一套面向应用的产品组合拳，注重IT与用户/开发者之间的协同。无论是虚拟机还是容器，VCF都能适应这些工作负载，在满足各类应用高性能运行的同时，提供原生安全的保护，并能最大化全自动编排为IT带来的收益。
在接下来的篇幅中，晓冬就和各位来聊聊这段时间经历了Homelab和项目总结后，对VCF构建CaaS的一些心得。
容器运行在物理机还是虚拟机？这又是一个各抒己见的好话题。就目前晓冬所经历的项目来说，不少企业似乎更倾向于采用【Run Dockers in VM】的方式。原因可归纳为：
- 第一，以VMware为代表的虚拟化架构在中国已经发展了十多年的时间，已经形成了成熟的生态圈(产品功能、IT人员技能、软件定义数据中心等等)，将容器运行在虚拟机上，能享受虚拟化平台的所有功能：比如VMware的vSphere HA提供计划外停机的高可用性、分布式资源调度能更好地提高硬件利用率等等。
- 第二，除互联网企业以外，不少IT还是对将核心应用运行在容器平台这个课题存在一些顾虑，不少企业对于容器依旧抱着“浅尝辄止”的态度，因此测试环境往往是一个“尝尝鲜”的地方。既然如此，置备几台虚拟机进行测试无论是从工作量还是成本考虑都是一个不错的选择。
- 第三，即使在云上，很多企业用户同样是选择使用虚拟机来部署容器应用。
这些都说明相对于裸金属服务器，虚拟机更容易被管理员所接受采纳。
但这些都不妨碍一些企业依旧选择【Run Dockers in BM】的方式。但无论是哪种方式，都是VCF所支持的。
不少朋友所咨询的“在ESXi里面跑容器”，其实就是一种【Run Dockers in BM】的方式。该场景中，激活了【工作负载】功能群集内的每一台ESXi主机都是工作节点，Pod将直接运行在ESXi的用户空间中。如果说用一句话来形容这种场景，那便是“只要管理员会使用vCenter，就可以轻轻松松地部署一个安全、高效、高性能的Kubernetes群集。”具体的操作步骤，在晓冬庚子年开篇中已有说明，详情可以参看【Project Pacific的第一次接触】。
而关注过vSphere7.0U1更新的朋友也会知道，从这个版本开始，管理员通过vCenter部署主管群集Supervisor Cluster的时候，可以选择两种不同的网络堆栈。
这不仅仅是“用不用NSX来组网容器网络”的选择题，更是【Run Dockers in BM】还是【Run Dockers in VM】的选择。两者的对比分析，可以通过晓冬总结的一个表格来简单概括一下。而对【Use NSX-T as CNI】这种场景来说，各位也可以参看晓冬前年的公众号文章。【NSX DC能为容器云原生做些什么(1)】【NSX DC能为容器云原生做些什么(2)】
通过上面的表格，我们可以简单总结出几点：
- 第二，NSX-T虽然不是必须的组件，但是凭借其强大的SDN、安全微分段和网络服务功能，无论是哪种场景，采用NSX-T都能提高CaaS平台的原生安全性、快速交付能力和高性能吞吐；
-
第三，虚拟机方式更加灵活，ESXi(物理机)方式更加便捷，两者可以共存，提供CaaS平台极大的灵活性。
如下图所示：采用vSphere原生Pod场景下，Kubernetes版本是固定的；
而采用TKG场景下，管理员可以按需选择不同的Kubernetes版本。
相信通过上文的对比，各位对于使用VCF部署容器的方式，心中大概已有一个概念。但就像我上文所说的，VCF能助力用户构建出一个CaaS平台，还依赖于它这个【积木套装】中的其他组件。
🐂 商用？开源？容器网络的构建可以简约，但不能简单。
无论管理员最终是否选择NSX-T来构建容器网络，对于容器网络的定义和管理都是简约易行的。首先，我们来看看NSX的容器网络：
管理员使用vCenter构建容器网络阶段，只需要轻松便捷地进行参数定义和鼠标点击就可以完成配置。在NSX Manager界面，可以清晰地看到这些已经生效的实例，包括容器网络的【分段】、容器Egress【源网络地址转换】、容器Ingress【负载均衡器】和容器服务【分布式负载均衡器】。
当开发人员使用YAML定义Network Policy之后，NSX会自动创建出对应的安全微分段实现Pod颗粒度的端到端安全防护。
与虚拟机一样，对于容器工作负载的网络可见性问题，也可以使用NSX的Traceflow功能帮助管理员进行巡检和排障。(VCF中的另一款产品vRealize Network Insight同样可以实现这个需求)
可见，在采用NSX-T作为容器网络技术栈的场景下，管理员对于容器网络的管理和网络安全的控制是简约且行之有效的。
那么，如果对于采用像Calico这样开源CNI的场景，又是怎样的一番天地呢？我们不妨也通过几张演示图例做个通俗的展示吧。回顾上文，管理员采用NSX-T作为容器网络技术栈的时候，容器网络是NSX的Overlay网络、容器服务是NSX的分布式LB、Ingress和Egress都是NSX的网络服务；这些是【商用】的选择。【开源】的情况是，容器网络是Calico或者Antrea，容器服务和Ingress可以采用HAproxy，Egress是借助于NodeIP；包括管理网络在内的需要与外部L3互访的场景都是由物理网络负责的。而看似略显复杂的这些网络配置，同样可以由管理员轻松简约地实现。
细心的朋友一定会有疑问：那么TKG虚拟机中运行的容器网络和服务网络在哪里定义呢？别急，这些是通过YAML文件定义的，其中更包含了其他个性化定制的设置，这也是晓冬在上文说的“通过vCenter和YAML配置文件自动执行”的含义。
那容器网络安全如何来实现呢？当然还是可以通过YAML文件去定义Network Policy，只不过实现的方式不再是通过NSX的安全微分段，而是依赖于开源CNI本身。
由此可见，无论是采用【商用】还是【开源】容器CNI，对于CaaS平台的构建本身来说，都是简约易操作的，但无论是性能、安全和可管理性角度来说，都是不简单随性的。
🐂 vSAN？不仅是一款超融合产品！
聊完了VCF中的计算vSphere、网络NSX对于构建CaaS平台的贡献，我们再来说说vSAN这个Gartner超融合魔力象限中的No.1吧~
关于vSAN本身的产品特性神马的，这些都是不新鲜的东西了(好了好了，再讲就烦了)，还是就晓冬对于vSAN在CaaS平台构建中的作用谈谈心得吧。
现在的vSAN已经可以称之为“存储服务”了。其实VCF不限于使用VMware自家的vSAN。传统的SAN存储、NAS存储甚至本地存储都可以用来作为容器的持久卷来使用。而vSAN除了能提供高性能的云原生存储之外，还能提供强大的自恢复能力。在更新的版本中，vSAN已经可以支持通过NFS和CIFS协议对外提供存储服务了。我们知道，VCF不仅仅可以用来作为构建CaaS的【积木套装】，对于像虚拟桌面、传统应用、数据库这样的工作负载，同样可以很好地按需提供服务，胜任各类业务的存储需求。对于构建CaaS平台来说，除了计算资源和容器网络，存储也是必不可少的，vSAN正是解决这个问题的金钥匙。不仅仅是提供Pod运行的存储空间，像TKG虚拟机模板、容器镜像都可以放置于vSAN之上，提供高性能、高可用、高安全的特性。管理员可以通过定义【虚拟机存储策略】，关联vSAN数据存储来轻松简约地完成配置工作。
🐂 总结一下吧~
说了这么多，简单提炼一下吧。对于帮助用户构建一个CaaS平台来说，VCF是完全可以胜任的，甚至是一款牛气冲天的【套装】(vSphere、vSAN、vRealize、NSX可都是对应Gartner象限里面的领导者或者远见者)。这些产品组合之后，能提供容器运行所必要的全部基础设施和管理平台：
vSphere：工作节点和资源、集中管理的统一平台
vRealize：自动化交付和运维(篇幅有限，后面再说)
这同时满足了传统基础架构管理员对于CaaS平台的稳定性需求，和最终用户对于业务敏捷交付的看重。就VCF的基础架构本身来说，更多地是让管理员通过vCenter、SDDC Manager这些管理工具实现包括容器在内的统一管理。而对于开发者来说，实事求是地说，他们其实并不知道容器是运行在【物理机(ESXi)】还是【虚拟机(TKG)】中，容器网络究竟是【开源】还是【商用】，承载的究竟是私有云【自建VCF】还是公有云【VM on Cloud】,业务究竟运行在【数据中心】还是【边缘站点】。命令行和最终交付的应用，是开发者们所擅长和期待的。相信通过VCF，管理员和最终用户/开发者能做到协同工作，稳中求速，牛气冲天！
新年开篇，多写一点干货。在新的一年里。晓冬会继续不定期更新，希望各位喜欢并持续关注。
