隨着IT技術的不斷發展,從傳統的IT建設模型逐步向新型IT建設模型過渡,建設模式的改變,必然影響應用系統的全生命周期。應用系統的建設經過單體應用、SOA應用、逐步走向微服務應用，至於何為單體應用、SOA應用以及微服務應用，本文不做重點介紹，本文主要用於論述微服務與DevOps的關系。
為了避免枯燥的討論抽象概念關系，接下來我將從一個日常生活場景開始講起。對於一個正常人來說，每日的生活離不開吃住行，那么吃住行中吃排在首位，對於土生土長的北方人來說，提到吃就必須提到小麥，小麥從種子開始，經過播種、收割、碾壓、風干、磨面、做成面包，每個過程階段都需要不同的投入，播種前需要犁地、施肥、育種，播種后需要除草、施肥、光照、收割，收割后需要碾壓、風干、磨面、做成面包，每個階段都涉及不同的工作。
如果把小麥到饅頭比喻成應用系統的開發，這期間有手工工作、自動工作、半自動工作。其實我們應用系統的開發，也是經過了一些列的手工工作、自動工作、半自動化工作。假如不考慮季節因素，日復一日，年復一年，小麥到面包的過程，就是一個持續交付的過程，在交付過程中，逐漸的完善犁地的深度、施肥的成份、碾壓的強度、風干的時長等等。這就類似於我們做微服務化實施的過程，逐步的拆分微服務，逐步的實施交付，不斷的完善，這個過程中，手工工作、自動工作、半自動化工作，就類似於我們在微服務開發過程中使用的工具，工具有高效低效之分。
在小麥到面包的過程中，為了提高投入產出率，我們不僅優化種子，而且優化過程工具，最典型的莫過於上世紀主要靠人工完成的過程，現在已基本有自動化機器完成，那在自動化機器完成的基礎上，如何進一步提升回報率呢？就是我們的DevOps理念，“打破部門鴻溝，實現工具流水線”，DevOps的誕生從狹義上說，就是實現各個階段工具鏈的自動化，從廣義上講就是實現跨部門之間高效協作。
雖說小麥到面包的案例比較普通，但是也已基本引出了本文的重點，即“微服務與DevOps的關系”，采用理工類經典的論證模式“如果某企業向微服務轉型，且微服務實施已取得成效，那么企業DevOps平台也已基本落地”。聽起來比較絕對，但話糙理不糙，具體原因如下：
- 微服務的實施，必然將原先一個應用拆分成數十個，那么對於每個拆分后的微服務進行編譯、打包、部署必將是原來工作量的數倍，如果不采用自動化工具。
- 微服務的實施，必然會涉及多個微服務之間的協作，那么對微服務功能進行單元測試、回歸測試、性能測試將變得更加復雜，如果不采用自動化工具，工作量之大，復雜度之高，難以估量。
- 微服務的實施，必然會升級多個微服務采用框架各異，那么微服務部署所依賴的基礎環境，必將異常復雜繁瑣，如果不采用自動化工具。
- 微服務的實施，必然會涉及多個團隊協作開發，那么微服務需求的管理，則項目的管控將異常艱巨，如果不采用先進的項目管理工具。
- 微服務的實施，必然會頻繁的進行應用的更新，那么代碼編譯、版本控制、代碼質量將無法保障，如果不采用成熟的工具。
鑒於以上種種問題，微服務的實施必然要具備需求管理、代碼版本管理、質量管理、構建管理、測試管理、部署管理、環境管理等工具鏈，除此之外，還需要開發部門與運維部門的協作，因此，DevOps是微服務實施的充分必要條件。
離開微服務，DevOps是否有意義，就如同農作物的流水線離開了小麥是否有意義一樣，農作物的流水線離開小麥，還有玉米、大豆、高粱等，因此，微服務是DevOps實施的充分但不必要條件。