瞭解微設計基礎架構（MDI）的概念，它們如何幫助開發，以及它們與DevOps和微服務等技術的關係。
技術決策既困難又嚴肅，可以決定專案的成敗。如何找到合適的技術棧？“微設計基礎架構”（MDI）是一種新方法，它使用“設計思維”中的回憶來開發最佳，易於理解且是公司範圍內公認的基礎架構或技術堆疊。
技術和基礎設施決策具有挑戰性，因為必須結合不同的要求（公司，應用，未來的安全等），找到合適的解決方案。在某些情況下，專案的複雜性如此之高，以至於應用了類似專案的最佳實踐方法，但這些方法具有不同的背景。這可能導致做出最終不適合應用程式或公司的決策。管理層對成本和速度的期望未得到滿足，部署或移交IT運營成為絆腳石。如何防止這種情況？
1.原則
解決複雜問題的方法有兩種：解決問題的結構化流程，將大問題分解成更小的部分，每個部分都更容易，更清晰地解決。
1.1 解決方案的結構化發展：設計思維
設計思維是基於這樣的假設：當來自不同學科的人在鼓勵創造力的環境中一起工作時，問題會得到更好的解決。他們共同瞭解人們的需求和動機，以便得出經過多次測試的概念和解決方案。
這個過程的一部分是共鳴，定義，構思，原型設計和測試。例如，設計思維用於開發應用程式或業務單元的數字化。
1.2 分解問題：微塊
IT服務和應用程式的問題在於需求的複雜性，從開發，整合和部署流程開始，到資料備份，IT安全和資料保護結束。如果將IT服務劃分為單個部分，則特定要求變得更易於管理。
在軟體開發中使用類似的方法與微服務一起使用。所謂的垂直將應用程式劃分為鬆散耦合的功能塊。這簡化了軟體開發並提高了解決方案的彈性。但是，不考慮企業，IT操作和資料上下文。
Microblock（參考微服務命名）是與其他塊分離的IT服務的一部分，它實現了特殊功能。該塊必須滿足以下要求：
- 明確功能的定義。
- 不依賴於其他塊的技術和基礎設施。
- 標準化介面REST，HTML，SQL，DNS等
- 可以獨立於其他塊進行更改/安裝
1.3 設計思維+微塊=微設計基礎設施
“微設計基礎設施（MDI）將設計思維應用於IT服務的基礎設施設計。任何形式的模組化應用程式或IT功能都被視為IT服務。這種IT服務被分解為微塊。這些構成了技術決策的基礎（在設計思維中稱為：Persona）。
具體的基礎設施和技術要求源自微塊的背景。由於需求較少但必不可少，因此更容易做出合適的技術決策。重要的是要考慮IT服務的每個功能部分，不僅是應用程式模組（微服務）等顯而易見的部分，還包括訪問或PKI管理，DNS，服務發現，監視，日誌記錄和資料備份。
MDI流程使用基於設計思維的流程步驟：理解，定義，構思，原型設計和測試。在自由展開的意義上，步驟不必按此順序完全處理，建立一個涵蓋儘可能多的解決方案的框架更為重要。
2.過程
2.1.建立：選擇團隊和環境
MDI團隊的組成基於不同的IT學科。目的是能夠理解和評估服務和單個微塊的所有上下文和要求。這包括IT管理，架構，開發和運營，資訊保安和資料保護。該團隊應由多種的人才組成，他們在各自的學科和廣泛的跨學科方面具有出色的專業知識。
2.2.理解問題
此階段的目的是瞭解流程和資料流，並將IT服務分為微塊。此階段應與軟體架構團隊並行執行。 MDI團隊成員共享，討論和記錄他們看到微塊的上下文。
2.3.定義：分析要求
介面（型別，協議），資料（輸入，靈敏度，數量，輸出），處理（並行化，程式語言），監視（監視，KPI，日誌資料）是定義需求的微塊的一部分。此外，還有開發和運營流程（部署和整合）。最後，新增了公司特定的要求（資料保護，資訊保安，成本規範）。
2.4.構思：開發可能的解決方案
對於每個單獨的微塊，開發了幾種技術解決方案的想法，唯一的要求是必須滿足規範。通過不斷詢問，檢查技術的選擇是否客觀和明智。例如，5-Why方法是一種很好的方法。
2.5.原型設計：建立原型
在開發原型時，應從一開始就使用自動化，因為它簡化了微塊原型的可重用性和配置。對於每個原型，必須實施執行狀況檢查和自動安全檢查。
2.6.測試：服務的功能檢查
在最後一步中，服務由微塊組裝而成。功能測試和效能測試顯示每個單獨的微塊是否正確結合。如果此處發生錯誤，則必須對其進行詳細分析以找出原點（例如，忽略的要求，不合適的技術，原型結構中的錯誤等）。它會跳回到相應的流程步驟並進行更正。如果一切都符合要求，那麼沒有什麼能阻礙上線。
3.摘要
“微設計基礎架構”的目標是通過一組創意專家為IT服務開發最佳基礎架構。由於模組化結構，專注於單個塊的分離和高度自動化，所需軟體環境的數量可以減少到最小，並且可以降低服務成本。
如果在公司中始終如一地應用此方法，則會建立基於相同技術的微塊叢集，因為上下文只會稍微改變（通常只是應用程式上下文），因此決策很可能會導致相同的技術。這也是高效的核心技術的基礎設施。
4.差異
4.1.軟體架構
軟體架構是指軟體系統的基本結構和建立這種結構和系統的學科。
每個結構包括軟體元素，它們之間的關係，以及元素和關係的屬性。軟體系統的體系結構是一種隱喻，類似於建築物的體系結構。它作為系統和開發專案的藍圖，規劃了由設計團隊執行的必要任務。
軟體架構設計了軟體元件的大致輪廓，不考慮技術方面。 MDI將這方面新增到軟體架構中。這意味著Micro Design Infrastructures不是一種替代方案，而是一種應該並行執行的補充流程。
4.2.微服務
微服務是一種軟體開發技術，它將應用程式構建為鬆散耦合服務的集合。在微服務架構中，服務是細粒度的，協議是輕量級的。將應用程式分解為不同的較小服務的好處是它可以提高模組性。這使得應用程式更易於理解，開發，測試，並且對架構入侵更具彈性。
微服務主要涉及應用程式開發。在垂直和水平可伸縮性方面，基於應用程式上下文分解應用程式。微設計基礎架構（MDI）考慮了一個更全面的上下文，用於定義和分割槽應用程式，並定義了一個可理解和企業範圍內可接受決策的過程。
4.3.獨立系統架構（ISA）
ISA是基於經驗的最佳實踐的集合，特別是微服務和自包含系統以及這些專案所面臨的挑戰。
ISA中定義的原則與MDI中的MicroBlocks概念非常相似。此外，Micro Designed Infrastructures定義了一個在上下文中根據這些原則開發IT服務基礎架構的過程。
4.4.DevOps
DevOps是兩個主要相關趨勢碰撞中出現的新術語。第一個也被稱為“敏捷基礎設施”或“敏捷運營”;它源於將敏捷和精益方法應用於運營工作。第二是對發展和運營人員之間合作價值的更廣泛理解[...]。
DevOps描述了一種更好合作的文化。這種文化是IT領域任何建設性合作的基礎，包括微設計基礎設施。然而，MDI提供了有關如何通過此協作解決特定問題的具體流程和原則。
4.5.領域驅動設計（DDD）
DDD是一種通過將實現連線到不斷髮展的模型來滿足複雜需求的軟體開發方法。域驅動設計的前提如下：
將專案的主要重點放在核心域和域邏輯上;
在域的模型上進行復雜的設計;
啟動技術專家和領域專家之間的創造性協作，以迭代方式完善解決特定領域問題的概念模型。
DDD在解決問題方面也有類似的方法，特別是通過關注功能和背景。主要地，DDD中的元素是基於域的，與MDI使用的基於功能的微塊相反。這意味著Micro Design Infrastructure不是替代方案，而是DDD的補充流程。
4.6.自包含系統（SCS）
SCS方法是一種架構，專注於將功能分離到許多獨立系統中，使完整的邏輯系統成為許多小型軟體系統的協作。這避免了大型單塊體不斷增長並最終變得不可維護的問題。在過去幾年中，我們已經看到它在許多中型和大型專案中的優勢。
SCS將各個模組視為包含資料邏輯和應用程式邏輯的自治Web應用程式。每個Web應用程式都有自己的使用者介面，由不同的團隊處理。 Micro Designed Infrastructures純粹從功能角度來看待技術決策。沒有理由組合幾個功能。此外，MDI定義了一個為IT服務開發無偏見和創造性基礎架構的流程。
原文：https://dzone.com/articles/take-the-lead-on-technology-decisions-sustainable-1
譯者：Emma------
送福利啦~ 近期將之前已翻譯文章，整理成了PDF。
在公眾號後臺回覆：002即可領取哦~
後續也會不斷更新PDF的內容，敬請期待！
