盘点云计算的优势，较低的托管成本、较低的基础架构复杂性、较高的可扩展性……这些都是实实在在的好处。不过对于企业来说，选择云计算最关键的驱动在于产品速度，换句话说，利用适当的云计算产品和技术，我们可以在最短时间内把理念变成用户需要的实际产品。
过去三年里，有大量的企业投入到了容器化架构的怀抱之中，从踩坑到克服未知的难题，再到得心应手，一部分公司逐渐尝到了“产品速度”带来的甜头。
但也有另一部分企业，容器运行测试、扩大测试范围、得到管理层批准、全面迁移上云，并且相信容器编排工具Kubernetes会处理好所有的事情，然后在一切似乎顺利进展的过程中，莫名其妙陷入了与指数级增长的复杂度抗争的漩涡之中——监控、存储、处理不同组件、定义通信、网络安全……进退两难。
问题到底出在哪呢？以下六点，抛砖引玉。
第一：基础设施
企业一般会在IaaS厂商那里买几台机器，希望通过将基础设施迁移到云端来达到马上省钱的目的，却发现成本非但没有降低，反而可能有些上升，于是开始反思是不是哪里出了问题。
出现这种情况其实是正常的，首先通过不断的调优，资源方面的节省才能显现出来；其次云计算的核心更多在于低风险和敏捷性，而不完全是“可见的成本“。
想象我们用过去普遍的方式为数据中心购买硬件，很可能会买到错误的大小或者错误的机器，此时我们应该拿这些机器怎么办呢？另一方面，把应用调整到一个不适合的环境中本身是一个耗时费力的过程，这方面的成本怎么算？
选择云计算的话，以上问题迎刃而解，原本购买基础设施的风险要小得多，配置环境的时间和人力成本同样大大降低，也就是说我们产品速度上的成本降低了。对于开发者，是花两年时间来做对业务有直接价值的工作，还是与错误的环境斗争到底，答案是很明显的。
所以第一个经验是，首先思考如何降低风险，而不是降低硬件成本。
第二：自动化
过去的经验告诉我们，私有云也可以实现非常高的自动化水平，一切取决于企业是否选择了正确的服务和工具，像自动化部署、CI/CD、自动化配置、伸缩等等。
在这一方面需要注意的问题主要集中在落地模式和建设规划两方面。落地模式上，企业需要按照自身情况来做出选择，是使用定制化产品，还是在开源框架的基础上自己进行开发；建设规划上，企业的自动化过程往往不是一蹴而就的，需要一个循序渐进的过程，前期的IT架构梳理极为关键。
第三：文化
在技术向云计算转变的同时，企业文化也应该随之而变。传统的模式下，企业规避风险即不惜一切代价将不确定性最小化，这导致很多企业IT拒绝进行改变，也就逐渐在竞争中落了下风，而这也是部分企业在云计算技术方面实施后，发现并没有解决问题，反而产生了新问题的原因所在。
正确的做法是应用一种“实验“的文化，通过分析、规划、评估和测试来尝试不同的方法，根据结果来进行调整，随时准备好迭代、准备好回滚、准备好再一次尝试。
这也就是为什么DevOps被公认为是一种文化，也是IT转型的重要途径。当然文化本身的转变也不是一朝一夕的事情，需要从早期开始落实，更需要持续不断的影响和强调。
第四：微服务
关于微服务架构的定义、优势等等不必多言，从spring cloud、dubbo到最新的service mesh，这些年大红大紫的微服务架构，真正能够拿出来作为可实践案例的不多。
除了对于技术栈的选择困难，很多企业的误区在于“一步到位”的错觉，导致企业本身将最初的门槛设立极高，而正常的过程是应当以最小代价发布第一个微服务，在跨过这个门槛之后，剩下的工作可以被复制而且速度会越来越快。
另一个教训，其实不止是微服务架构方面，就是尽量不要重复造轮子，参考或者选用成熟的解决方案永远会是最便捷的落地途径。
第五：容器化
Docker是容器化最突出的技术代表。利用Docker构建一个容器，包含一个微服务所需的所有依赖，而后部署在任何想要部署的地方。
而在最近，docker受到了一些批评和质疑，我们认为原因在于很多企业对docker的期望有些不切实际，而忽略了容器化同时需要考虑的调度编排、存储网络、服务注册发现以及宿主机管理等等紧密联系的技术问题。
另一方面，我们要知道Docker其实并不是一项新技术，它的创新更多是在思想层面，在它对于封装、隔离、发布的改进。
第六：编排
真正用于生产的应用往往会跨越多个容器，往往会部署在多台机器上，会涉及到如服务发现、负载均衡、高可用、存储、网络等等。目前容器编排事实上的标准是Kubernetes。
关于Kubernetes，难点在于这一容器编排工具本身包含很多高难度技术概念，学习门槛很高、学习曲线很陡峭，同时缺少管理流程。所以这里容易出现的是“用不起来“的问题，解决办法除了活学活用，还可以考虑使用第三方包装好的Kubernetes面板和解决方案。
好雨，让云落地，提供以应用为中心的云计算产品和服务。访问 https://www.goodrain.com 了解更多