创业公司使用容器的四个原因
前两篇文章（一个创业公司的容器化之路（一） - 容器化之前、一个创业公司的容器化之路（二） - 容器化）我们介绍了杏仁架构的发展历程。我们再回顾一下第一篇开头提出的三个初创公司的技术挑战：
- 如何快速、低成本的搭建系统，同时确保安全稳定？
- 如何快速的构建和发布应用，满足业务需求？
- 如何提高团队开发效率，确保开发质量？
杏仁通过容器化来应对这几个挑战，也取得了一些成就，但也说不上完美的解决。毕竟我们规模还小，很多方案也只是在我们这个规范刚好够用。不过在这个过程里，我们还是深刻体会到了容器化的价值。正如我介绍容器的时候说的，容器会和集装箱一样，成为一个标准化的基础设施，对上层应用产品革命性的影响。
很多大厂其实一、两年前就开始做容器方面的尝试。但现在，我们认为其实初创公司也应该考虑应用容器了，原因有以下几点。
容器生态已经成熟，容器服务和容器云可以大幅降低容器使用成本。
去年容器编排还不能说很成熟，例如 Kubernetes 还存在不少缺陷。但经过一年时间狂飙猛进，Kubernetes 今年已经很成熟了，有不少企业已经在生产环境使用了 Kubernetes。部署和运维也比之前简单多了。
另一方面，各大公有云也都推出了容器服务，还有不少独立的容器云公司。如果你是用公有云的话，推荐直接使用相应的容器服务，可以快速的搭建系统，大幅降低运维成本，提高效率。
并且这会带来一个额外的好处，因为这些容器服务都是基于 Kubernetes 的，而容器本身就是一个标准化的东西，使用容器服务反而可以降低对公有云服务的依赖。在公有云的容器服务之间迁移，或者后期打算自建然后迁移，都不是很难的事情，
容器使创业公司可以轻松的应用行业最佳实践，创建优质应用。
几年前有人提出了一个十二要素应用的最佳实践，我认为是一个很好的标准。
下面列表对这十二条实践进行了分析，我分成了三种情况，分别用三颗星、两颗星和一颗星表示。
- ★★★：没有容器实践起来很困难，容器环境下可以很容易实现。
- ★★：没有容器也可以实践，但在容器环境下可以做得更好或更轻松。
- ★：没有容器也可以实践，容器环境里也能支持。
| 最佳实践 | 支持程度 | 说明 |
|---|---|---|
| 基准代码：一份基准代码，多份部署。 | ★★ | 不仅一份代码多份部署，容器能做到一份镜像，多分部署。 |
| 依赖：显式声明依赖关系。 | ★★★ | 容器通过 Dockerfile 管理内部依赖，实现自包含；容器编排管理服务依赖。 |
| 配置：在环境中存储配置。 | ★★ | 容器通过环境变量传递配置；容器编排能提供标准的配置工具。 |
| 后端服务：把后端服务当作附加资源。 | ★ | |
| 构建，发布，运行：严格分离构建和运行。 | ★★ | 通过 docker build 构建，通过 docker run 运行，严格分离。 |
| 进程：以一个或多个无状态进程运行应用。 | ★ | 容器对无状态应该可以完美支持，有状态应用现在也能很好支持。 |
| 端口绑定：通过端口绑定提供服务。 | ★★ | 容器编排可以处理服务依赖和绑定，应用不再需要关心。 |
| 并发：通过进程模型进行扩展。 | ★★★ | 容器编排可以很轻松的扩容。 |
| 易处理：快速启动和优雅终止可最大化健壮性。 | ★★★ | 容器编排可以支持快速启动、优雅终止，具有自愈能力。 |
| 开发环境与线上环境等价：尽可能的保持开发，预发布，线上环境相同。 | ★★★ | 容器的可移植性和自包含，能做到随处运行，但应用的环境依然保持一致。 |
| 日志：把日志当作事件流。 | ★★ | 容器和容器编排可以很好的支持日志。 |
| 管理进程：后台管理任务当作一次性进程运行。 | ★ | 容器编排提供了多种方式可以运行一次性任务。 |
所以可以看到，在容器环境下，可以很轻松的实践这十二要素，从而使得应用更容易开发、维护和部署。
容器使创业公司一开始就可以以极低的成本应用微服务架构。
这张图很多人应该看到过，是 Martin Fowler 提出的关于微服务和单体应用的生产率趋势的比较。
这张图要表达的意思是，如果团队使用微服务，开始可能需要花费更多的精力来搭建基础设施和架构，但是生产率可以一直维持在比较高的水平。而在创业公司，我们一般会为了速度，采用 Quick & Dirty 的方案，也就是创建一个单体应用。一开始这样会很快，但问题是，单体应用会越来越庞杂、越来越难以维护，此时就会严重影响团队生产率。
当生产率下降到一定程度时，团队会开始考虑服务化（包括我们杏仁也是这么做的）。但在服务化的过程中，会消耗更多的人力和资源，严重影响生产率。服务化完成之后，生产率会有一定提升，但也很难一下子达到微服务的状态，需要不断的重构并拆分服务。所以在互联网，其实大部分稍微有点规模的公司的生产率曲线是这样的：
但是在容器环境下，一开始就使用微服务的话，其实生产率并不会比单体应用低多少。
这是因为容器已经提供了微服务所需要的很多基础设施，包括服务注册和发现、服务依赖和生命周期管理、负载平衡等，而且健壮性和资源利用率也会更高。如果是直接使用容器云，则运维的成本也很低。并且 SpringBoot、Service Mesh 等的工具和理念的兴起，也给微服务开发提供了一种规范，降低了开发难度。
当然，微服务的业务架构也是很重要的一方面，需要仔细考虑。但业务架构的设计，更多考验的架构师的能力和经验，本身并不会花太多时间。
所以在容器环境下，我们没有理由再去创建一个单体应用，一切都是微服务，只要业务架构设计合理，研发团队可以更专注于业务开发，生产率可以一直保持在较高水平。
容器使创业公司降低运维成本，提升运维效率，轻松实践 Devops。
容器环境下，很多以前的日常操作都自动化或至少半自动化了，比如比如部署、发布新应用、扩容等等，都可以很快速的响应。容器编排的自愈能力，即使除了问题，也可减少人工干预。
所以容器环境下的运维是幸福的，不用在苦逼的响应各种需求，可以吃着火锅唱着歌把事儿做了。大大加强了运维的幸福感，终于运维同学也可以开开心心的去谈恋爱了。
而开发也可以对自己的应用有更多的掌控。除了能快速频繁的部署，也可以从日志、监控中得到数据和反馈，出现问题也可以通过工具一定程度上去进行调试。
容器即未来
所以，只有在容器环境下，最近几年炒的火热的微服务、Devops 才可以更好的发挥作用。正如上一篇说的，基于容器，会逐步建议一套完整应用架构体系，而这套体系会带来革命性的改变。
容器即未来，而未来已来到眼前。
