AWS Service Catalog為DevOps和雲端帶來5大好處

好了,或許您現在對微服務和容器等主題更感興趣,但請耐心聽我說。隨著雲端基礎架構的演進,AWS Service Catalog變得越來越必要,它允許IT人員和開發人員共享經過審批的服務,有助於打破部門壁壘,並鼓勵DevOps相關實踐。

如果您不熟悉Service Catalog,它允許組織在AWS上建立、管理和共享經過批准使用的IT產品和服務目錄。您可以共享簡單的服務,例如Amazon S3儲存桶,或更複雜的服務,例如包含自動調節群組、Amazon RDS和Amazon DynamoDB表的多層應用程式。令人驚嘆的是,最終使用者可以佈建這些服務,而無需了解AWS服務背後的複雜性,如果您願意,甚至無需對AWS擁有寫入權限(稍後將詳細說明)。

此外,Service Catalog建基於AWS CloudFormation之上,這意味著在設計服務並遵循安全最佳實踐時,您可以添加約束,例如控制實例大小(我知道,每個人都喜歡啟動最大的實例)。

在這篇部落格文章中,我將分享五個理由,解釋為什麼您現在應該將Service Catalog納入DevOps和雲端策略。

提升安全性

10年前,我還是系統管理員時,記得我們部門擁有佈建所有新資源的完全控制權。我們很幸運,現在情況已不再如此,開發人員佈建資源已成為典型做法。

在AWS上佈建資源從未如此簡單,但許多能夠佈建資源的開發人員對AWS共用安全模型的了解有限。例如,最近Uber的一次駭客入侵就是由於某人將金鑰上傳到GitHub所導致。更糟的是,AWS持續推出令人印象深刻的新服務,使得了解並遵循各種服務的安全最佳實踐佈建資源變得更加困難。

Service Catalog可以幫助提高安全性,方式如下:

• 讓開發人員在沒有AWS存取權的情況下佈建資源。是的,您沒有看錯:您可以添加約束,規定應使用哪個IAM角色來佈建資源。
• 在CloudFormation之上建立您的服務目錄,這意味著您可以遵循一次安全最佳實踐,例如為S3啟用靜態加密。因此,當您的使用者佈建資源時,所有這些最佳實踐都會被應用。

節省成本

在Service Catalog中,您可以對允許佈建的資源大小添加約束(不再愛用超大型實例)。您的開發人員仍然可以佈建資源,但不會讓公司破產。您的財務長將因此而喜愛您。

透過限制，您可以控制實例類型為t1.micro或m1.small

跨多個帳戶集中管理Service Catalog以達到更好的合規性

雖然Service Catalog建基於CloudFormation之上,但與CloudFormation不同的是,它旨在共享常見部署的應用程式以促進協作。這意味著您可以跨多個帳戶共享服務目錄,並將相同的約束複製過去。這裡有一篇很棒的文章介紹如何做到這一點。

提高生產力

大多數情況下,我與公司合作使用Service Catalog是為了提高生產力。我常聽到的一個反對意見是:”我們還沒有準備好這種程度的標準化,因為我們的基礎架構正在快速變化中——我們處於快速變更模式。”這個說法很公平!然而,即使在這個快速發展階段,您的開發人員也可能正在個別而非集體地致力於標準化以提高生產力。例如,假設我通常會啟動一個測試伺服器,並更新安全群組以存取VPN。很可能還有其他開發人員採取類似行動,編寫自己版本的腳本。這正是Service Catalog的用武之地,它提供了一個平台,可以與其他員工共享這類服務(例如啟動只能存取VPN的伺服器),從而提高團隊生產力。

促進DevOps文化

DevOps的主要目標之一是打破部門壁壘,並使團隊成員圍繞交付客戶價值而團結一致。Service Catalog通過將共享和協作的做法具體化,鼓勵DevOps文化的形成。

接下來呢?

我對Service Catalog的功能及其為DevOps團隊帶來的前景感到興奮。在nClouds,我們正在將對Service Catalog的使用提升到一個新的層次,整合審批流程來管理佈建的服務,並將工作流程自動化為變更管理流程的一部分。自動化和輕量級流程提供了所需的控制,但又不會犧牲DevOps的敏捷性。您可以在這份新的白皮書”AWS的現代變更管理”中閱讀更多相關內容。

此外,如需瞭解有關Service Catalog和DevOps實踐的更多資訊,AWS re:Invent上有一些很棒的演講可供重播:金融服務FSV308、Fannie Mae MSC201和John Wiley & Sons DEV321。