要想通过容器来运行应用必须要对应用进行划小处理。这要比应用迁移至X86上，数据库能不能在虚机上跑之类的云化改造来的更动筋骨一些。传统的企业级应用是单体应用（monolithic application），比如运营商的系统，业务非常复杂，这种巨型系统，首先要关注的是如何根据业务划分子系统。这种划分是一种垂直切分，十几年前开始风行的SOA（Service Oriented Architecture）就是基于这种垂直划分后的子系统的。在SOA体系里，每个子系统都是独立的服务（Service），通过服务接口与外部协作。既然有垂直切分就得有水平切分。传统的企业级应用一般是分层结构，如表现层、应用层和数据层。如果将垂直切分后的子系统按三层架构来设计，我们会得到更细一步的“服务”。这种横竖切割的过程也叫做服务化过程。SOA还同时提供了调用服务的接口协议，XML和WS（Web Service），提供服务之间的通信与整合枢纽：企业服务总线（ESB），服务编排所需要的业务规则流程引擎（BPM）等。

 

　　按照 SOA 这种思想和架构原则来改造应用无疑相当于推翻重新开发一遍，在成本上很难接受而且工作过于复杂。 因此大部分企业实践SOA的思路不是划小应用，而是做不同应用系统间的松耦合集成，让系统与系统之间通过服务接口（Service API）和企业服务总线（ESB）进行交互。

 

　　应用没有被划小，传统的复杂应用只是通过API将其功能和数据进行了开放，但还装不进轻量级的容器Docker中。实际上应用服务化的目的不是为了使用容器，而是想解决三大问题：一是应用的维护问题，二是应用的开发问题，三是应用的部署问题。

 

　　一个简单的应用会随着时间推移逐渐变大。几年后，一个小而简单的应用因为改来改去会变成一个庞然大物。一旦你的应用变成一个庞大而又复杂的怪物，维护开发团队肯定会很痛苦。敏捷开发和快速部署举步维艰，其中最主要的问题就是这个应用太复杂，以至于任何一个程序员都不可能搞懂它。因此，修正bug和添加新功能会变得非常困难，并且很耗时。