應用程式現代化和分離 (decoupling) 基礎架構服務及雲端團隊
在公有雲上將應用程式現代化能夠優化產品的成本面和生產面，但這些優勢通常只有「全有」或「全無」兩種選項，若要有這些好處，你必須搬遷到雲端。企業希望透過搬資料到雲端進行現代化，且能夠依照需求提供本機和雲端遷移路徑的解決方案。這項現代化對於企業的創新十分重要，可以結合機器學習和資料分析。
此外，不同的公有雲提供不同的平台，讓工作負載的遷移在技術上和開發人員操作上變得十分困難。有許多企業會選擇使用多種雲端平台，不同時間能夠和不同的供應商合作，希望能夠保有一些作業的獨立性。
這是兩種截然不同的型態需求：內部現代化、多雲解決方案。這兩種需求都需要一種可在各雲端平台上運作，並提供方便開發的新平台。Kubernetes 在容器的編排和工作負載轉移上都是業界先驅，它迅速成為能夠跨平台執行應用程式的標準，是眾多平台的基礎。為了能夠同時滿足敏捷式開發和企業團隊營運的需求，這個產業現在可以專注於最初的目標：建立一個全自動化的雲端平台服務：一個能夠自然發展的動態分散式系統，用途種類繁多的機器學習，同時也提供一致性的開發者體驗和單一管控機制。
Google 建立 Cloud Services Platform (CSP) 來加速 SaaS 供給商、開發人員、IT 營運商和終端使用者的應用服務現代化。為了平衡開發速度、營運效率和管理平台，CSP 框架支援關鍵元件分離法：
- 基礎設施和應用程式分離 (decoupling) 應用：透過容器和 Kubernetes
- 團隊分離 (decoupling) 運作：透過 Kubernetes pods 和服務
- 開發和營運分離 (decoupling)：透過服務和政策管理
- 安全性、開發及營運分離：透過結構化政策管理
成功的分離 (decoupling) 基礎架構、服務和團隊，減少人工調整、成本和複雜性，並大幅提升開發人員的速度、營運效率和企業生產力。它提供一個框架、執行方法和運作模式，確保迎接開放、混合和多雲的未來。
圖一：現代化的方式
透過分離 (decoupling) 加速應用程式現代化
分離 (decoupling) 基礎設施和應用程式：容器和Kubernetes
原生雲端的轉移比起虛擬主機 VM 需要考慮更多。VM 可以解決許多問題，但僅介於基礎設施的表現而不是應用程式上。特別的點為，VM 映像檔和應用程式的關聯十分緊密，作業系統(OS)、應用程式、引用的程式庫。
因此，由 Docker 驅動的容器第一個角色為將應用程式打包與基礎架構區隔開來，包括模擬機、程式庫和 OS 操作系統。事實上，Docker 其中一個最成功的例子是在使用者筆電上能夠建立、測試應用程式，並且將之部署到雲端上。例如：容器中定義正確的程式庫及附屬元件並部署到基礎架構，可以忽略原本部署在基礎架構上的其他資料，並讓可能發生衝突的程式庫同時並存在同一台機器上。
容器的第二種角色 (有時稱為「Linux 容器」)，能夠在同一台機器上分別獨立不同應用程式。Google 在十多年前開創這一系列的工作，以至於我們能夠在同一台機器上打包許多不同應用程式，並不用擔心彼此互相干擾的問題。這讓我們能夠檢視叢集的排程，像是跨平台特定應用程式的 bin-packing 裝箱問題。
基於「程式撰寫一次，隨處執行」的成功，可攜式和效能獨立在共享的基礎架構上，容器已被證明是分離應用程式與基礎架構的第一個關鍵步驟，也是應用程式現代化的基本要素。
分離 (decoupling) 雲端團隊：Pods 和服務
對一個簡單的應用程式來說，容器提供足夠的功能：一個開發團隊可以用容器開發應用程式，並且將之部署到雲端上。但是對於開發應用程式較複雜的團隊，我們希望能夠將團隊的分工運作各自切割。對於負責共享基礎架構的團隊而言，能夠清楚分離更是攸關重要 (例如監控軟體或日誌紀錄)。一個日誌團隊必須要根據應用程式的更新去發展自有的日誌功能。如果客戶每一個app都使用一個容器，他們必須要針對容器建立一個記錄檔的版本並部署該版本。客戶若要升級日誌紀錄，須部署一個新的容器 – 分離應用程式和日誌團隊，也需要做整合，並適時的調降他們的速度。
什麼是 Pods?
Kubernetes推出Pods的功能解決了分離 (decoupling) 的問題。一個 pod 中有一組容器 (container)，這些容器可以共同排程 (在同一台機器上運作)。它可以共享機器資源例如：本地磁區 (local Volume) 及預定單一個 IP 位址。在日誌範例中，每個 pod 都有應用容器和日誌容器，透過兩個管道做溝通：共用磁區 和/或 localhost 本機網路。這種鬆耦合能夠在 pod 中各自獨立更新：應用容器能夠只更新客戶 API 紀錄，但不包括執行紀錄更新。擁有這種功能的容器在 pod 中通常被稱作「邊車模式 (sidecar)」。
每一個 pod 中都有自己的 IP 位置可以實現分離 (decoupling) 的功能 – 每一個 pod 可以使用所有的 port。這十分的重要，因為大多數的應用程式有假設的固定 port (例如 HTTP 的 port 80)。DNS 所使用的 port 並沒有按照慣例 (在正常狀態下)，所以 port 會被假設 2。傳統來說，port 結合了應用端和機器端的概念，每台機器上有多種不同的應用程式，因此在每台機器上有多個 IP 位置。Pod 解決了這個問題，實際上一台機器有 100 個 pod 就會有至少 100 個 IP 位置。
基礎服務
現在基礎架構主要為「服務導向」，但是在我們回答「什麼是服務？」之前，必須先從 Kubernetes 這個抽象的服務開始說起。在文章的後面，我們會討論到一些建立在這個服務上好用的功能。
Kubernetes 的基本服務為一組機制為背景動態建立 pod 集合，並執行不同的政策和維護服務 IP。這種服務機制叫做「微服務」，但是服務的內容或範疇不須特別小，它更能做到建構區塊和團隊用來提供服務。Google 總共運行超過 10,000 多項服務。
目前為止這個服務最重要的部分為高可用永久性名稱。主要的名稱是個 IP 位址：Kubernetes 使用「服務IP」，每個 pod 都會分配到一個 IP，並且可以獨立運作。上述所提到的「一組機制」為一個 proxy，但它也可以是各種形式的路由或 NAT，動態地將服務 IP 對映到 pod IP。雖然 non-proxy 形式的彈性較少，但是通常具有較好的性能。
將執行和服務名稱分離 (decoupling)，對客戶來說有幾個重要的好處：
- 隨著服務和 pods 組成的生命週期分離，可以執行線上升級的運作
- 由於 pod 可以 (手動或自動) 通透地適應客戶端的負載，因此擴展更容易
- 政策定義和一致性可以透過 proxy 執行，簡化複雜的管理流程 (例如安全相關操作)
服務可以整合不同部門的語言和應用套件。
每一個服務可以依據不同語言或風格來建置自己的 pods。服務代表 API，可以使用 IDL 和結構描述來定義，通常使用 JSON HTTP。同樣的，客戶可以使用自己所熟悉的語言。需要高性能的服務可以使用 protobufs 和 gRPC4，透過十幾種語言來實現。
對於「邊車」來說語言獨立是很大的優勢，例如日誌代理程式。由於需和本機端溝通，因此邊車用不同語言撰寫應用程式是很常見的。只有客戶端日誌 API 需用應用程式語言編寫，且通常可以被自動產生。
服務可以讓大部分的應用程式獨立部署並向下相容升級。版本號碼有助於跟開發團隊分離，讓客戶知道是否安全使用新版本。實際上，按照常規開發團隊通常使用圍繞版本號碼來表示語義變化。
Kubernetes 的基本服務是無邊界的。定義上，服務內的所有 pod 都來自相同的規範，且可以隨時這個規範中重新啟動。這樣抽象定義對於大多數的服務和 12-factor apps 來說已經很足夠。一些需要永久儲存資料的假設性情況，被歸類在其他管理服務當中。
此服務的最終目標為分解團隊。如果一個團隊可以清楚的分割各自的工作範圍稱為「解離」，這在傳統上說起來容易，做起來卻不容易。服務是程式部署的最小單位 – 它們被獨立封裝並構成 API 的基礎單位，是更好的「物件」工具，因為它們更大、壽命長、可用性高。對於目前大部分的物件導向程序來說，微型化服務可以加以應用並走得長久。
下一篇：運用容器化架構及微服務架構，升級企業 IT 環境(2)，將提到 Proxy 的用處、Istio 的微型服務和生命週期管理、安全性。
(原文翻譯自 Google Cloud。)
