本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 盡可能且實際地採用雲端原生受管服務
<a name="managed-services"></a>

當您一開始考慮如何利用雲端服務時，使用您的團隊熟悉的基礎設施服務和開發工具，似乎是最佳的前進途徑。不過，選取雲端原生受管服務，特別是無伺服器選項，可以大幅降低成本、工作量和複雜性。

雲端原生的受管服務可消除許多未區分的 IT 任務，這些任務需要員工的時間和精力，而這些任務可能會更好地花費在以任務為中心的活動上。此外，隨著提供者改善其服務的功能，您的解決方案自然會繼承效率、安全性、彈性、效能和其他特性的增量改善。例如，全受管資料庫服務是功能豐富的關聯式資料庫管理系統，但您不需要佈建和管理資料庫執行所在的基礎伺服器和作業系統。這可消除當您在自己的資料中心或雲端佈建的自我管理虛擬伺服器上維護關聯式資料庫時，通常需要的管理任務。下圖說明此差異。

![比較自我管理和全受管資料庫服務的責任](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-education-hybrid-multicloud/images/db-services.png)


當您比較任何雲端原生受管服務與類似的自我管理方法時，消除基礎設施管理的好處很明顯。因此，每當您需要部署購買或自訂開發的應用程式將在其上執行的元件時，您應該使用雲端原生的受管服務來減少時間和精力。

當您的團隊負責在雲端中建置、部署或管理解決方案時，請使用雲端原生的受管服務，充分利用您雲端供應商的差異化功能和創新。此策略可讓您選擇、整合和部署雲端服務，以減少這些專案所需的時間和精力，同時提高其彈性和安全性。為了實現成功的雲端策略，請考慮在將自訂解決方案遷移至雲端、在雲端開發新解決方案，或在雲端部署授權軟體時採用這些雲端原生*建置區塊*。當您評估雲端原生受管服務的選項時，請考慮下列重要問題。
+ **您是否需要將更多員工的時間和精力集中在教育任務的核心功能上？**

  管理伺服器，即使是虛擬伺服器，都需要時間和注意，以確保它們與系統軟體升級和修補程式保持最新狀態。使用為您處理這些任務的 受管服務，可讓您將 IT 人員的時間導向更直接符合機構任務的活動。例如，如果您需要部署容器，請考慮無伺服器受管服務，例如，[AWS Fargate](https://aws.amazon.com/fargate/)這樣您就不必設定和維護伺服器。透過消除採購、佈建和管理基礎基礎設施的需求，您可以專注於提供新功能、最佳化效能並改善使用者體驗。當您針對自我管理選項評估受管服務時，請考慮此優點。
+ **您的團隊需要哪些努力才能採用雲端原生受管服務？**

  使用雲端原生的受管服務設計和實作解決方案可能有一種學習曲線，但這些工作將在解決方案生命週期內透過降低成本、時間和複雜性來償還。由於雲端運算的隨需pay-as-you-go特性，雲端原生服務可讓您以更靈活的方式快速迭代和實驗，同時避免前期投資。這會導致創新增加和專案時間表縮短。不過，為了有效地實現這些好處，請考慮採用和使用服務可能需要什麼，例如員工訓練最佳使用模式和程式碼重構，以適應服務特定的 APIs。即使服務使用業界標準或開放原始碼 APIs，您可能需要重構或設定應用程式來處理功能差異或版本不符。
+ **您目前如何部署和管理基礎設施？ 您需要維持該層級的控制嗎？**

  有多種方式可以託管和管理雲端中的基礎設施，包括使用裸機主機、虛擬機器、受管容器服務和無伺服器產品。即使您目前在內部部署環境中使用類似的基礎設施，例如虛擬機器或容器，請考慮替代方法是否適合某些工作負載。例如，不要在虛擬機器上執行所有應用程式，請考慮容器化您的應用程式，並利用 [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/) 等受管容器服務。這可能需要重構，但您可以使用 等工具[AWS App2Container](https://aws.amazon.com/app2container/)來簡化和協助容器化。進一步執行此操作，而不是為所有元件部署伺服器或容器，請考慮完全無伺服器選項。無伺服器技術具有自動擴展、內建高可用性和pay-for-use模式，可提高敏捷性和最佳化成本。同時，他們不需要管理伺服器和規劃容量。等無伺服器運算服務[AWS Lambda](https://aws.amazon.com/lambda/)是無伺服器架構的核心。Lambda 支援常見的程式設計語言，並允許開發人員專注於應用程式程式碼，而不是管理基礎設施。探索每個工作負載的這些選項，並考慮學習曲線、管理開銷、成本和授權等因素。
+ **您是否必須部署和管理任何授權軟體的基礎設施？**

  當您從獨立軟體廠商 (ISVs) 部署和管理授權軟體時，使用雲端基礎設施模擬內部部署似乎很合理。例如，您可能會考慮將內部部署虛擬機器取代為雲端託管的虛擬機器。雖然這是可行的選項，但請考慮您是否可以使用雲端原生受管服務取代架構的任何元件。例如，您可以使用全受管資料庫服務取代自我管理的資料庫伺服器，在執行相同的資料庫引擎時減輕管理負擔。許多 ISVs已經使用利用 受管服務的雲端架構，甚至可能提供預先建置的範本來簡化部署。如果可能，您應該偏好提供方案指引和支援雲端部署的 ISVs。將授權軟體部署至雲端之前，請務必諮詢 ISV，以了解雲端環境授權與內部部署授權有何不同。
+ **您是否擔心使用受管服務可能會導致廠商鎖定？**

  許多雲端原生的受管服務都是為了支援常見的產業標準和 APIs而建置。例如， [AWS Glue](https://aws.amazon.com/glue/)和 [Amazon EMR](https://aws.amazon.com/emr/) 等分析服務是以產業標準處理和儲存架構為基礎，例如 Apache Spark 和 Apache Parquet。 [AWS Lambda](https://aws.amazon.com/lambda/) 原生支援 Java、Go、Microsoft PowerShell、Node.js、C\#、Python 和 Ruby 程式碼。[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) 支援多個版本的常見資料庫引擎，包括 SQL Server、Oracle、PostgreSQL 和 MySQL。當 服務具有專屬 APIs 時，原生或合作夥伴解決方案可能可以使用通用、不區分雲端的通訊協定與 APIs 互動。例如，[Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) 具有用於直接整合的服務特定 API，但您也可以在使用 時，使用網路檔案系統 (NFS)、伺服器訊息區塊 (SMB) 和網際網路小型電腦系統界面 (iSCSI) 等標準儲存通訊協定與其互動[AWS Storage Gateway](https://aws.amazon.com/storagegateway/)。您仍應專注於選擇最符合您需求的雲端原生受管服務，同時盡可能降低營運開銷，但您可能偏好使用或提供常見業界標準和通訊協定的服務。