输出既服务

1. 正在急剧变革的 IT 设施

传统的企业，正在基于互联网技术，构建更加高效的商业模式，以加强自身在行业的竞争力。更低的研发成本、更快的产品迭代、更近的客户距离、更好的服务质量… 这一系列的变化，将推动整个社会的生产效率、生活水平迈上新的台阶。

在 ToC 的互联网红利消耗殆尽之时，ToB 的产业互联网无疑拥有巨大机会。但国内商业公司为效率付费的意愿不强，对公有服务不信任，目前 ToB 也不是一门容易的生意。

除了互联网对整个产业的冲击，作为从业人员，我更关注到的是，互联网基础设施正在发生急剧变革。随着云服务的市场份额不断向巨头聚集，IT 蓝领时代可能真的不远了。互联网技术门槛会进一步降低，标准化的生产方式出现，催生大量体力劳动岗位。

传统的 IT 基础设施主要是硬件、网络设备、OS 等。工程师使用这些软硬件，需要一定的学习成本。通常，大公司会有一个运维团队，专职做服务保障。但，运维能力不是天生的，只有踩过坑，才会获得足够的成长。这是除薪资外，又一部分的成本和风险。

运维团队是一个吃力不讨好的部门，没有功劳，只有苦劳。

这时，云服务来了。需要服务器，就买一台云服务器；需要数据库，就买一个云数据库实例，这比自己搭建一套方便、便宜多了。同时，云服务还能提供更好的容灾容错、弹性伸缩，更好的运维服务。

云服务已经被工业界广泛认可，并且产生了巨大价值。云服务的发展，很大程度上得益于虚拟化技术的发展。但虚拟化技术，没有解决分布式调度的问题。

传统软件架构的基础是，一个操作系统运行在一台主机上。受限于这样的理解，需要大量工程师做优化，以适应业务流量的增长。请求的分发，资源的分配，网络的隔离… 如果在单台机器上，这些工作都是由操作系统来完成。那么，为什么不将一个系统直接安装到一个集群上呢？

Kubernetes 正是这样一个系统。它可以接管很多个主机，分布式地调度资源，对于使用者却只看得见一个。我们只需要定义进程，Kubernetes 就会自动在 Pod 中运行起来。

Kubernetes 解决了资源管理和调度的问题，再结合 buildpack 等构建工具，可以很好地满足部署需求。

事实上，我们在部署一个应用时，还会依赖一些组件，比如 Nginx、Redis、其他服务等。它们作为应用的一部分，需要被配置和管理。

服务编排提供组装、配置服务的能力。但是，让开发人员去写冗长的 YAML 配置，这很难接受。最近，看到一些云服务商，已经开始支持通过图形拖拽的方式实现 SDN、服务编排等功能，无疑大大降低了使用门槛。

云编排给部署提供了极大的便利，让架构方案商品化，易于流通。头部云服务商，有能力输出架构方案给中小型公司，中小型公司需要做的是选择方案和一键部署，而不是设计新的架构方案。

我之前写过一篇博客，如何使用 Jenkins、Docker、GitLab 搭建 Django 自动化部署流程
。搭建这样一套简单的自动化流程，我花了一天时间。

如果用云服务，只需要半个小时：

第一步，创建 DevOps 流水线

首先准备一个 GitHub 仓库，仓库中包含构建镜像的全部内容。在 Daocloud 中创建一个 DevOps 项目，选择准备好的仓库，编译镜像。（在创建应用之后，可以增加一个 stage ，用于将应用发布到自有主机）

第二步，编排应用

在应用平台中，创建 stack。编辑 docker-compose.yml ，使用上一步编译生成的镜像。通过环境变量的方式，将数据库配置注入应用。

第三步，提交代码，自动编译镜像，部署应用

接下来的事情，就非常简单了。只需要提交代码，DevOps 流水线就会被自动触发，自动部署发布。

至此，应用就上线了。如果需要进行多实例、异地部署，只需要在 DevOps 流水线中，增加相应的原子即可。

云服务实际上就是领域能力的输出。每一种服务都对应着一种解决方案，对应着一种能力的输出。

IaaS 层输出的是虚拟化主机的能力；PaaS 层输出的是管理应用生命周期的能力；SaaS 层输出的是应用开发的能力。

这样思考，云服务就很容易理解了。这和擅长烙饼的大爷，在路边卖大饼是一个道理，路人总不会因为肚子饿去买一整套烙饼工具。我们只需要瞄准擅长的领域，兜售经过验证的解决方案即可。

整个软件研发周期，都是云服务成长的沃土。有管理需求、缺陷的 Tapd，云数据库，数据运营的 GrowingIO，异常监控 Sentry，日志 Datadog…