随着IT技术的不断发展,从传统的IT建设模型逐步向新型IT建设模型过渡,建设模式的改变,必然影响应用系统的全生命周期。应用系统的建设经过单体应用、SOA应用、逐步走向微服务应用，至于何为单体应用、SOA应用以及微服务应用，本文不做重点介绍，本文主要用于论述微服务与DevOps的关系。
为了避免枯燥的讨论抽象概念关系，接下来我将从一个日常生活场景开始讲起。对于一个正常人来说，每日的生活离不开吃住行，那么吃住行中吃排在首位，对于土生土长的北方人来说，提到吃就必须提到小麦，小麦从种子开始，经过播种、收割、碾压、风干、磨面、做成面包，每个过程阶段都需要不同的投入，播种前需要犁地、施肥、育种，播种后需要除草、施肥、光照、收割，收割后需要碾压、风干、磨面、做成面包，每个阶段都涉及不同的工作。
如果把小麦到馒头比喻成应用系统的开发，这期间有手工工作、自动工作、半自动工作。其实我们应用系统的开发，也是经过了一些列的手工工作、自动工作、半自动化工作。假如不考虑季节因素，日复一日，年复一年，小麦到面包的过程，就是一个持续交付的过程，在交付过程中，逐渐的完善犁地的深度、施肥的成份、碾压的强度、风干的时长等等。这就类似于我们做微服务化实施的过程，逐步的拆分微服务，逐步的实施交付，不断的完善，这个过程中，手工工作、自动工作、半自动化工作，就类似于我们在微服务开发过程中使用的工具，工具有高效低效之分。
在小麦到面包的过程中，为了提高投入产出率，我们不仅优化种子，而且优化过程工具，最典型的莫过于上世纪主要靠人工完成的过程，现在已基本有自动化机器完成，那在自动化机器完成的基础上，如何进一步提升回报率呢？就是我们的DevOps理念，“打破部门鸿沟，实现工具流水线”，DevOps的诞生从狭义上说，就是实现各个阶段工具链的自动化，从广义上讲就是实现跨部门之间高效协作。
虽说小麦到面包的案例比较普通，但是也已基本引出了本文的重点，即“微服务与DevOps的关系”，采用理工类经典的论证模式“如果某企业向微服务转型，且微服务实施已取得成效，那么企业DevOps平台也已基本落地”。听起来比较绝对，但话糙理不糙，具体原因如下：
- 微服务的实施，必然将原先一个应用拆分成数十个，那么对于每个拆分后的微服务进行编译、打包、部署必将是原来工作量的数倍，如果不采用自动化工具。
- 微服务的实施，必然会涉及多个微服务之间的协作，那么对微服务功能进行单元测试、回归测试、性能测试将变得更加复杂，如果不采用自动化工具，工作量之大，复杂度之高，难以估量。
- 微服务的实施，必然会升级多个微服务采用框架各异，那么微服务部署所依赖的基础环境，必将异常复杂繁琐，如果不采用自动化工具。
- 微服务的实施，必然会涉及多个团队协作开发，那么微服务需求的管理，则项目的管控将异常艰巨，如果不采用先进的项目管理工具。
- 微服务的实施，必然会频繁的进行应用的更新，那么代码编译、版本控制、代码质量将无法保障，如果不采用成熟的工具。
鉴于以上种种问题，微服务的实施必然要具备需求管理、代码版本管理、质量管理、构建管理、测试管理、部署管理、环境管理等工具链，除此之外，还需要开发部门与运维部门的协作，因此，DevOps是微服务实施的充分必要条件。
离开微服务，DevOps是否有意义，就如同农作物的流水线离开了小麦是否有意义一样，农作物的流水线离开小麦，还有玉米、大豆、高粱等，因此，微服务是DevOps实施的充分但不必要条件。