一般在架構的描述上， 層(layer)跟階(tier)常常是可互換，但分層/分階的架構中，其實可能用來描述架構中的不同面向。由於本文山姆鍋需要以兩個面向來描述分層/分階的架構，因此本文為了方便起見，將分層跟分階視為架構中不同的面向，但這只是山姆鍋個人習慣，並非業界標準作法。
在撰寫其它 DevOps 相關文章時，其實都是依照這樣的架構作為組織模型，為了避免在那些文章中出現太多重複的描述，山姆鍋特別寫了這篇文章。單看本文可以建立一些架構概念，但還需要配合其它文章才會有較具體的實作想法。底下分別說明在雲端系統架構中，分層與分階到底關注哪些概念。
分層架構(Layered Architecture)
在常見雲端分層架構面向中，系統從下到上是由：「基礎設施層(infrastructure layer)」、「平台層(platform layer)」以及「應用層(application layer)」組成。 分層的架構中，上層的元件只能依賴於下層或同層的元件。
基礎設施層(Infrastructure Layer)
此層關注系統中的機器(machine)層面，機器提供系統運行所需的計算(computing)、通訊(communication)以及存儲(storage)等最基本的資源。雲端基礎設施供應商提供API、命令列工具讓運維人員可以程式化的方式建立應用以及平台所需系統資源。
平台層(Platform Layer)
平台層負責提供應用層更高的抽象化，進而將應用架構從系統運維中抽離出來，開發人員只需描述應用元件運行的意向(intent)，平台層則將該意向轉化成較低階的服務以及資源物件(resource object)，這裡的服務以及資源對應到本文中的「分階架構」。平台層雖可以協助讓應用盡可能專注在商務問題領域，而不是架構關注點以及運維細節，但仍舊需要應用元件按照既定的模式(pattern)來實作。例如：平台可以自動按照負載來水平擴展應用元件的副本(replica)，應用元件則需要為無狀態(stateless)模式。
下面是幾個平台層可以提供支援的架構關注點：
- 擴展性(Scalability)
- 可用性(Availability)
- 安全性(Security)
- 可靠性(Reliability)
每個應用元件/系統對於架構關注點的優先順序跟需求不同，如果試圖使用統一的應用平台來部署不同應用，有可能導致應用平台部署應用不需要的平台元件。例如：在一個單體應用系統中，部署服務網格(service mesh)可能無法提供足夠價值來抵消運維服務網格的複雜性。架構設計都是一種權衡取捨，所以，平台最好可以讓開發團隊根據應用需要來訂製平台服務，而不是採取一體適用(one-for-all)的方式來供應。
應用層(Application Layer)
應用層的元件都是為了特定應用系統而存在，包括為了該應用系統而部署的支援服務(backing service)都屬於該應用系統。以微服務(microservice)為例，除了微服務本身外，其相依的資料庫、訊息仲介(message broker)、甚至 API 閘道都屬於應用層。應用層的元件可以依照本文所謂的「分階架構」來組織，架構師也可以選擇其它更適合應用的系統架構方案。
分階架構(Tiered Architecture)
分階架構是從客戶端(client-side)到服務端(server-side)這樣的網路架構衍生而來，關注的是用戶的請求(request)如何以端到端(end-to-end)的方式被實現。雲端分階架構可以被分為「客戶層(Client Tier)」、「Web 層(Web Tier)」、「服務層(Service Tier)」以及「資源層(Resource Tier)」，習慣上還是將 tier 翻成「層」，由於跟分層架構中的名稱不同，希望不至於造成太大混淆。
山姆鍋在 一個通用 Web 應用架構 這篇文章中採用的就是這種分階架構。
客戶層(Client Tier)
使用者實際互動的軟體元件，例如：iOS 或者 Android app，都屬於這一層。頁面應用(web app)的程式碼(e.g. JavaScript)雖然是執行時才動態從後端(客戶層之外其它層的總稱)載入使用者的瀏覽器(通稱是「用戶代理」) 中，在架構上仍舊屬於這一層。
Web 層(Web Tier)
Web 層關注的是使用者的請求如何路由(route)到正確、適當的應用服務元件。在現代的架構也會將應用服務共通的服務由此層負責提供。
應用服務層(Service Tier)
服務層是應用系統商務邏輯所在。商務邏輯應該由簡單的程式碼所表示，不相依於其他層。反而是其他階層依賴此層來完成應用特有的邏輯。
資源層(Resource Tier)
資源層負責提供應用所需的支援服務。有些支援服務是由其它雲端服務供應商提供，並非都是內部負責部署與管理。
小結
應用平台是最近山姆鍋文章的主要重點，相關的文章主要都圍繞在如何運用平台來組建(build)、部署(deploy)以及運維(operate)應用系統這個主軸上。理想上，由平台團隊負責提供機制(mechanisms)來自動達到開發團隊提出的意圖(intentions)或者策略(policies)要求。對於現有機制無法滿足的需求，平台團隊提供可接受的機制後由開發團隊自行負責操作。而為了避免口語描述的模擬兩可，平台定義可以清楚表達應用抽象化語意的文件格式(e.g. yaml)，開發團隊只要管理對應的描述文件來反映期望的結果而由平台的自動元件(controllers, operators)來持續調整狀態以符合結果。
