作者：Tracy Ragan，CDF理事會成員
最初于medium.com釋出
https://medium.com/@tracy_35812/its-more-than-just-containers-2fce4ad5832
向微服務架構發展是組織迎接未來的關鍵。
采用容器政策是開始現代架構之旅的好方法。但不要止步于此。當你接受了容器和Kubernetes，下一個也是最重要的一步就是轉向微服務架構。微服務是種獨立部署的小型功能，它将定義你的完全數字化轉型。微服務使你能夠編寫全新一代的軟體。他們使AI和ML成為可能，同時也為高度可伸縮的軟體創造了一個平台，與單體解決方案相比，成本隻是一個很小的部分。
如果已經将應用程式容器化，那麼就可以進行下一步了。遷移到微服務架構有很多好處，并且大多數公司将在未來5年内轉移到這個開發平台。這些好處并非沒有挑戰。任何轉變都有破壞。這種破壞是受歡迎的，如果我們能夠了解微服務架構與單體架構的差別和相似之處，就可以克服這種破壞。
事實上，微服務是很複雜的。它們的建立和傳遞與單體的實作非常不同。但是你可以這樣做。作為一個集體社群，我們在過去經曆了類似的大轉變，例如從大型機到分布式，我們不僅生存了下來，而且茁壯成長。就像從大型機到分布式系統的轉變一樣，微服務擾亂了我們編寫和傳遞代碼的方式。是以，是時候進行軟體開發的下一個發展了。
三個基本事實
當轉向微服務時，考慮以下3個基本事實：
- 微服務不需要傳統的“建構”步驟。連結不是在CI建構步驟中完成的，而是通過API在運作時完成的。
- 為了獲得微服務的全部好處，應該在團隊之間共享它們。
- 微服務是獨立部署的，可以影響多個“邏輯上的”應用程式。
CI建構
“十分鐘建構”多年來一直是持續內建的戰鬥口号。目标是在10分鐘或更少的時間内修複建構。好消息是，每個人的建構時間都将少于10分鐘。壞消息是，進入CI建構步驟的配置管理和決策制定将不複存在。相反，你的建構将專注于為你的服務建立一個容器并注冊它。建構完成。我們在這個過程中失去的是“邏輯上的”應用。它仍然存在，但我們不再建立一個構成完整解決方案的“完整”建構。我們隻是在建造一個可重複使用的小部件。
微服務共享和領域
應該重用大多數微服務。微服務擴充表明你的總體架構沒有利用微服務重用的優勢。為了避免這種錯誤，你的微服務政策應該圍繞領域驅動設計的概念進行定義。這種方法要求你後退一步，從“解決方案”的角度來看待你的組織。這些解決方案将定義需要在組織豎井之間建立和共享哪些微服務。當确定了這些解決方案，你很可能會發現，将近80%的微服務将被重用，隻有20%的自定義微服務将用于任何單獨的解決方案。在下面的例子中，你将看到網站A和B如何在共享的基礎上自定義。
微服務分享
這種級别的代碼重用對于我們滿足21世紀數字轉型的要求是必不可少的。我們有很多軟體需要設計，而微服務重用是實作這一目标最劃算的方法。
“邏輯上的”應用程式沒了
微服務的好處也是其複雜性。當你丢棄應用程式建構過程時，你也丢棄了應用程式版本控制過程。對于微服務，需要一種新的方式來考慮軟體配置管理和應用程式版本。雖然我們不再将應用程式作為一個整體來釋出，但我們仍然在建立應用程式。銀行将繼續建立抵押貸款、汽車貸款和結算應用。它們隻是建構方式不同而已。當我們開始轉向微服務架構時，對完整的“邏輯上的”應用程式進行跟蹤、版本控制和可視化的方法對于簡化微服務實作是必不可少的。
總結
遷移到Kubernetes和微服務架構讓你的組織面向未來。要做到這一點，你将需要重新設想你的軟體開發實踐來支援微服務實作。當你開始這個旅程時，請考慮丢失一個完整的應用程式建構的影響，該建構決定了一個獨立的應用程式版本将如何基于作為一個整體編譯和連結的代碼和庫進行操作。其次，檢查并辨別你的微服務模式，将它們定義為邏輯解決方案空間或領域。領域驅動設計是成功實作微服務的關鍵。沒有這個，你可能會建立微型服務蔓延。最後，軟體配置管理和應用程式版本控制仍然很重要。考慮跟蹤微服務版本到應用程式版本的方法。你需要了解邏輯上的應用程式使用什麼、影響應用程式的微服務以及跟蹤所有叢集中的應用程式版本差異的能力，以實作微服務所需的大規模DevOps。
關于作者
Tracy是DeployHub的首席執行官和聯合創始人。DeployHub是第一個微服務管理平台，旨在促進微服務的共享、關系映射和部署。Tracy是配置管理和流水線生命周期實踐方面的專家，特别關注微服務和雲原生架構。她目前擔任持續傳遞基金會（CDF）的董事會成員，并被選為總會員代表。她也是Ortelius開源項目的執行董事，該項目是DeployHub的開源核心。
http://www.deployhub.com/
http://www.ortelius.io/