IBM 认为云计算有三大优势：
- 更灵活。用户可以根据需要，“弹性地”获得 IT 服务。
- 更高效。减少 IT 团队管理和维护底层基础设施的工作量，IT 服务可以更快推向市场。
- 战略价值。通过灵活组合现有 IT 资产与新兴数字渠道，支撑企业业务创新。
云计算与虚拟化的区别
有很多企业已经采用了虚拟化技术：将企业的计算资源（服务器、存储等）集中管理，以虚拟机的形式分配给使用者。虚拟化与云计算的区别在于：虚拟化是指“用软件管理硬件资源”，而云计算是指以虚拟化方式管理硬件资源之后能够对外提供的服务。
除去这个概念上的差异，我们注意到一些企业在谈论“虚拟化”的时候，背后隐含着一个自动化程度不高的、需要人工参与的虚拟机申请和开通的流程。在这样的流程下，获得一台虚拟主机需要的时间通常以天计。因此，虚拟机的使用者倾向于预先申请虚拟主机并长期占用。在这种情况下，“虚拟化”往往意味着缺乏弹性（elasticity）的计算资源分配——尽管虚拟化技术本身并不妨碍弹性。
为了兑现云计算的三大优势，企业 IT 系统必须云化：软件的形态由从前需要在本地安装的软件包，转变为透过网络在线使用的服务，让使用者随时能够获得；原来体型巨大的单体（monolithic）应用，需要转变为细粒度的服务，从而支持灵活的组合与复用。
云时代的研发环境
原来习惯了开发本地安装的软件包和/或巨大的单体应用的研发团队，现在要转为开发云化的软件服务，这个转变并非总是无痛的。首先，研发交付物的形态应该是对云环境友好的。从前研发交付物通常是以软件包的形式提供给用户或是运维团队，例如平台特定的 JAR、WAR、EGG 等软件包，或是 RPM、DEB、MSI 等操作系统特定的软件包。软件包是一种对云环境不友好的交付形式，因为它没有包含软件运行的环境。例如一个软件需要用到 PostgreSQL 数据库和 monit 作为监控工具，平台特定的软件包无法确保这些软件依赖的存在；某些操作系统特定的软件包可以描述软件依赖，但也无法确保依赖软件被正确地配置。过去一段时间里，自动化的配置工具（例如 Chef/Puppet/Ansible）被用于解决运行时环境的问题。而在今天的技术背景下，理想的研发交付物应该是容器镜像（很可能是一组彼此连接的容器镜像），可以在云上直接运行。
对研发交付物的要求随即会影响到研发过程。为了在研发流程的出口得到服务化友好的交付物，最好是在整个开发过程中一直使用与生产环境近似的环境。例如开发人员应该使用全套环境随时验证，自动化测试和手工测试都基于全套环境开展。在这种情况下，环境的设置、管理、更新不可能由每个开发人员和测试人员自己进行，所以环境的管理更新必定是集中进行的，环境的设置必定是自动化的。而且，如果环境固定分配、长期使用，对计算资源的占用可能很大，所以环境应该是云化的、弹性的、按需获得的。
云计算的大背景还会影响研发实践。为了降低搭建研发环境的技术难度，云化的研发环境应该内建研发工具链（包含开发工具、质量保障工具、持续集成/持续交付工具、DevOps 工具、项目管理工具等）。为了规范团队研发质量水平，良好的研发实践（例如代码静态检查、自动化测试等）和流程要求应该固化在工具的日常操作中。理想的情况下，研发团队应该只聚焦关注业务功能开发。开发工具的组合、生产环境的配置、持续集成和持续交付流水线的搭建等工作都应该被标准化和自动化。
综上所述，在云计算的大背景下，IT 组织需要将更多的软件应用部署在云上。云化的 IT 系统对软件研发的交付物、研发过程、研发实践都提出了新的要求。我们认为：现代 IT 组织应该从研发环节开始，以原生支持云计算的方式提供、管理和维护研发环境，从而在研发过程中利用云环境的弹性，确保研发交付物对云环境友好，并把优秀的研发实践和流程要求内嵌到研发环境之中。
IT 组织可以通过以下方式管理其研发环境：
- 将标准的研发环境封装为虚拟化、云化的技术栈，由技术专家管理维护；
- 核心业务价值与技术支撑解耦，工程师专注于业务系统的开发；
- 自动化研发流程，降低研发管理成本。
假设你有 100 台物理机，其实规模不是太大，用 Excel 人工管理是没问题的，但是一台上面开 10 台虚拟机，虚拟机的个数就是 1000 台，人工管理已经很困难了，但是一台虚拟机里面开 10 个容器，就是 10000 个容器，你是不是已经彻底放弃人工运维的想法了。所以容器层面的管理平台是一个新的挑战，关键字就是自动化
自发现：容器与容器之间的相互配置还能像虚拟机一样，记住 IP 地址然后互相配置吗？这么多容器，一旦一台虚拟机挂了重启，IP 改变，你怎么记得住应该改哪些配置，列表长度至少万行级别的啊。所以容器之间的配置通过名称来的，无论容器跑到哪台机器上，名称不变，就能访问到。
自修复：容器挂了，或是进程宕机了，能像虚拟机那样登陆上去查看一下进程状态，如果不正常可以重启一下么？那你要登陆万台 docker 了。所以容器的进程挂了，容器就自动挂掉了，然后自动重启。
弹性自伸缩 Auto Scaling：当容器的性能不足的时候，需要手动伸缩、手动部署么？当然也要自动来。
一个是 Kubernetes，我们称为段誉型。
段誉(Kubernetes)的父亲 (Borg)武功高强，出身皇族 (Google)，管理过偌大的一个大理国 (Borg 是 Google 数据中心的容器管理平台)。作为大理段式后裔，段誉的武功基因良好 (Kubernetes 的理念设计比较完善)，周围的高手云集，习武环境也好 (Kubernetes 生态活跃，热度高)，虽然刚刚出道的段誉武功不及其父亲，但是只要跟着周围的高手不断切磋，武功即可飞速提升。
一个是 Mesos，我们称为乔峰型。乔峰 (Mesos)的主要功夫降龙十八掌 (Mesos 的调度功能)独步武林，为其他帮派所无。而且乔峰也管理过人数众多的丐帮 (Mesos 管理过 Tweeter 的容器集群)。后来乔峰从丐帮出来，在江湖中特例独行 (Mesos 的创始人成立了公司 Mesosphere)。乔峰的优势在于，乔峰的降龙十八掌 (Mesos)就是在丐帮中使用的降龙十八掌，相比于段誉初学其父的武功来说，要成熟很多。但是缺点是，降龙十八掌只掌握在少数的几个丐帮帮主手中 (Mesos 社区还是以 Mesosphere 为主导)，其他丐帮兄弟只能远远崇拜乔峰，而无法相互切磋(社区热度不足)。
一个是 Swarm，我们称为慕容型。慕容家族(Swarm 是 Docker 家族的集群管理软件)的个人功夫是非常棒的 (Docker 可以说称为容器的事实标准)，但是看到段誉和乔峰能够管理的组织规模越来越大，有一统江湖的趋势，着实眼红了，于是开始想创建自己的慕容鲜卑帝国(推出 Swarm 容器集群管理软件)。但是个人功夫好，并不代表着组织能力强 (Swarm 的集群管理能力)，好在慕容家族可以借鉴段誉和乔峰的组织管理经验，学习各家公司，以彼之道，还施彼身，使得慕容公子的组织能力 (Swarm 借鉴了很多前面的集群管理思想)也在逐渐的成熟中。
容器能够把服务打包成基本单元，你可以把它部署到任何地方：本地机器、测试环境或者生产系统。但是在生产环境中，你却不能把所有容器都运行在一台机器上，因为会用光系统的资源。你需要多个机器（或者节点）以集群（不同机器通过网络通信）的方式运行，然后把容器部署到集群中。现在问题变成，如果我有多个机器/节点组成的集群，我该如何决定容器运行在哪台机器上呢？有了编排软件，你只需要告诉它我要部署容器，剩下的事情交给编排软件即可。
编排软件负责以下几点：
- 选择最适合部署容器的机器。最适合指的是拥有最多空闲资源，或者说如果容器能获得更多的运行内存，比如 Redis。
- 发生机器故障，能自动把故障机器上的容器部署到其它节点。
- 如果集群添加了新的机器，重新平衡容器的分配情况。
- 如果容器故障了，重启它。
- ……
现在你已经理解为什么需要容器编排了，下面我们一起看下当下最流行的两个选择以及它们间的对比。
Docker Swarm
Swarm 是为 Docker 开发原生的集群管理引擎。任何适配 Docker container 的工具、服务或软件都可以很好地兼容 Swarm。下面是一些 Docker Swarm 的优缺点：
优点
- 容易上手，“开箱即用”的用户体验。
- 零“单点故障”（single-point-of-failure）架构。
- 自动生成证书，默认提供安全机制。
- 向后兼容组件。
- 开源
缺点
- 处于项目启动/早期开发阶段。我们不推荐商业应用上使用。随着时间推移，它会更加成熟。
- 功能简单有限。
Kubernetes
Kubernetes 是一个 Google 主导的生产就绪、企业级、成熟的编排平台。它的利弊有
优点
- 生产就绪、企业级。它被很多公司用于规模生产环境。
- 相比 Docker Swarm，它更成熟。
- 可用于公有云、私有云、混合云等多种云环境。
模块化。
- 自愈能力：自动布局、自动重启、自动备份、自动伸缩。
- 开源。
- 因为模块化设计，可被用于部署任何架构。
缺点
- 难于部署。如果不使用云服务商 Azure、Google 或者 Amazon，在你的集群中搭建 Kubernetes 环境非常困难。大部分云服务商都提供了一键安装功能。
- 比 Docker Swarm 更陡峭的学习曲线。它不使用 Docker CLI。
