漫谈多云Multi-Cloud系列(二): 驾驭多云

进入正题前先分享一个故事，Palo Alto Networks是一家总部在硅谷以防火墙为主业的公司，作为防火墙届的后起之秀，成立7年就做到上市，把前辈们打得满地找牙，公司也搬进了Yahoo当年的总部。这家公司确实有好的产品，但是防火墙这个市场早已经很成熟了，所以核心的问题是怎么把产品卖到那些已经有其它防火墙设备的公司，而他们的销售想到了一个聪明的办法，销售们对客户说，你们不需要改动原来的防火墙设备，只需要把Palo Alto Networks的防火墙设备放在原有的防火墙设备后面先试试看。这个部署对于客户就简单了很多，而且上线之后，客户看到新的防火墙居然真能逮到很多的攻击，而且每天都是如此，慢慢的，企业也就接受了让两套防火墙设备一前一后同时存在，久而久之，看到前面的防火墙居然一直会放过那么多的攻击，有些甚至干脆把老的防火墙设备下线了。

如果多云的架构也能像防火墙那样一前一后的部署，确实是可以很好地共存。但是公有云服务远比防火墙复杂，云服务分三大块，计算，网络，存储，而防火墙只是网络中的一小块而已。每朵云其实都是一套完整的体系，企业即使只用了其中的一个服务，也需要顺带着用上其它的一系列配套服务，举个例子，企业想做一个图片访问的服务，打算把图片放在AWS的S3上，但是连带着需要使用CDN，监控，日志，告警，计费，权限这些相关产品。假设为了灾备，企业又想把图片放到Google Cloud的GCS上面，那又是一套Google全家桶。几朵公有云的产品虽然类似，但是许多设计是完全不一样的。比如AWS的资源是基于帐号的，Google Cloud则是基于项目的；AWS和Google Cloud的权限系统虽然都叫IAM (Identity and Access Management)，但是设计理念不尽相同。一旦上了多朵云，就意味着团队要在工作中不停得做上下文切换，就更容易出错。管理多云复杂到孵化了一个新的商业品类，在2019年Gartner魔力象限(Magic Quadrant)里叫做Cloud Management Platforms。

采用多云，团队需要具备足够的工程素养，同时也要有研发流程保障。

团队需要对容灾，稳定性有强烈的认同感，才能抵消在部署多云的各种抵触感。多云部署是为了容灾，容灾就意味着小概率发生事件。和防火墙部署能时时刻刻获得正向反馈不同，多云的建设在绝大多数时间是看不到回报的，所以其引入的复杂度会影响团队的士气。而且既然设计了容灾，就需要做定期的容灾演练，多云的容灾因为环境复杂，风险更大，更加大了落实的难度，到了应急时刻，谁也不敢按下切换的核按钮。

另一方面，虽然CTO的初衷是想通过多云来做容灾，架构师也能设计出合理的基于多云的容灾架构。但是到了执行层往往会出问题，没有严格的研发流程保障，一次代码提交的疏忽就能导致两朵云的产品互相依赖，将之前单元化/隔离的所有努力付之一炬。出现这种情况，系统的整体可用率反而比一朵云还要低。

选择哪朵云，以及要不要上多云往往是CTO层面的决策，所以选择的因素也不是只在技术层面。有可能需要选择多家厂商，来获得更好的议价权；有可能是要建立战略合作关系；也有可能是因为私人关系，谈业务靠CXO之间刷脸这点在企业销售里很常见。如果有这方面的因素，可以考虑在旁路应用（比如离线分析，冷备）引入多云，但是核心链路还是尽量使用单一云厂。