多集群策略可以有效地分解企业级架构上的复杂性 ， 是应对复杂数据生态的强力措施 。
“无服务器”架构
Serverless服务是指那些在基础设施之上进一步将程序运行环境也虚拟化的云产品 ， 使用Serverless服务 ， 用户既不需要搭建服务器 ， 也不需要构建运行应用所需的系统环境 ， 他们只需要做一件事：编写代码 。
Serverless是一件美好的事吗？不同的用户态度可能会大相径庭 ， 这取决于团队自身的背景和对云计算的拥抱程度 。 Serverless的哲学在于“把精力用到最核心的问题上” ， 喜欢Serverless的用户会对其赞不绝口 ， 因为它确实将团队从基础设施和运行环境的维护上彻底解放了出来 ， 使得团队可以集中精力交付更多的开发任务 。 但是也有技术人员会对Serverless持一种轻蔑态度 ， 认为这种服务只适合开发简单的应用 ， 或者只有技术实力不强的团队才会选择 。
对于后者我们不予置评 ， 但是对“Serverless服务只适用于中小规模开发”的言论 ， 需要谨慎看待 ， 从我过去接触到的大量企业用户来看 ， 得出该结论的原因很有可能是对所使用的Serverless服务了解不深造成的 。 大部分初级用户是通过Serverless服务的控制台页面编写和调试程序的 ， 这种图形化界面使用起来非常简单 ， 在很短时间内就可以有所产出 ， 这也是很多团队喜欢Serverless的原因之一 ， 但是基于图形化界面进行开发有着无法克服的弊端 ， 包括：代码缺乏版本控制 ， 无法多人协作开发 ， 程序规模变大后难以维护等等 ， 这些并不是Serverless本身的问题 ， 而是基于Serverless的开发没有进行“工程化”导致的 。 人们会将这些问题错误地归结到了Serverless上 ， 进而得出了“Serverless服务不适合大规模开发”的结论 。
关于Serverless项目的工程化 ， 我们有过很好的实践经验 ， 通常Serverless服务都会提供CLI与API用于部署和运行程序 ， 这些CLI与API与用户界面上的操作是等价的 。 一个非常好的做法是基于这些接口将部署和运行等操作编写成自动化脚本 ， 脱离对用户界面的依赖 ， 然后将这些脚本和程序代码一起组织成一个工程项目 ， 放到Git Repository上 ， 这样就可以对程序代码进行版本控制了 ， 然后再利用构建工具打包 ， 并通过DevOps工具自动化部署 ， 这样一个Serverless项目就转换成了一个常规项目 ， 可以复用所有常规项目的开发流程与规范 ， 构建大规模Serverless项目将不是问题 。
云计算 VS 开源生态
我们已经说了很多云计算的“好” ， 最后回应一下对云计算与开源生态相左的“担忧” ， 从目前的行业态势来看 ， 主流云厂商其实早已认识到这个问题 ， 并在产品设计上努力向开源标准靠拢 。 只有使用行业广泛认可的技术 ， 云计算才有活力 ， 也才能缓解用户对云平台绑定的担忧 ， 进而吸引更多的用户向云上迁移 。
在数据领域 ， 各主流云厂商都有基于Hadoop、Spark等主流开源大数据产品封装的“云化”版本 ， 与Cloudera的CDH类似 。 同时 ， 很多Serverless服务也大多基于主流开源产品封装 ， 或者保持一致的编程接口 ， 例如AWS的Glue就是基于Spark的Serverless服务 ， 编程接口与开源Spark一致 。
总的来说 ， 云计算与开源生态不是也不应该是对立的 ， 一方面 ， 云厂商有向开源生态靠拢的商业驱动力 ， 另一方面 ， 有能力的云厂商也应该积极回馈开源社区 ， 一起营造更好的双赢局面 。
一点展望
由于过往的独特经历 ， 我先后经历过“半云” ， “全云”以及“非云”等多种环境 ， 真切地体会到了云计算对数据平台的深刻影响 ， 当今的数据平台建设 ， “云上”和“云下”已经几乎是两个赛道了 ， 如果以个人的一点浅见展望一下的话 ， 我认为上云是不可逆转的趋势 ， 在云上构筑数据平台是未来绝大多数企业的首选 。