HashiCorp Terraform 金融案例｜AXA (安盛集團) 雲端遷移自動化
內容目錄
對於安盛集團來說，將 6,000 到 8,000 個應用程式遷移到公有雲意味著自助平台和自動化流程是必要的，看看他們如何使用 Terraform Enterprise 實踐。
註：本文由以下影片轉錄文字
我叫 Kelly Monteith，在安盛集團工作。我有點不好意思，因為我在一家法國公司工作，但現在要用英語演講。我很抱歉，但老實說，你也不想聽我用法語講的。
AXA 安盛集團
AXA (安盛集團) 是一家非常大的金融公司。我得從簡報上念這段話，這是我唯一會照著念的部分。我們在全世界 51 個國家/地區營運，我們有 145,000 名員工和經銷商，為 9,300 萬客戶提供服務。和任何人一樣，這些資料都是我昨天才查的 (笑)。
我們在金融業工作，這是高度監管的產業，面臨著和 Samya 之前提到的很多相同的挑戰。我理解她說的，我們面臨著同樣的挑戰，也知道我們在應對這些挑戰時採用了一些相同的方法。
安盛集團的營運
我們在 16 個國家/地區都有業務。例如歐洲、亞洲、美國和墨西哥。我們有超過 6,000 名員工，是一家很大的組織。我們負責安盛集團的基礎設施和核心 IT 應用程式。我們有一群非常多元化的人員，從傳統的基礎架構管理人員到營運人員，我們正努力朝著以產品為導向的組織發展。
我們試圖把現在所做的一切都打造成產品，並把這些產品提供給我們的客戶。我們的客戶是安全團隊和 DevOps 團隊，他們負責開發 AXA 用於營運其業務的 IT 應用程式。
我們支持安盛集團的幾乎所有實體，最近我們已成為安盛集團的內部雲端提供者。我們提供一些產品 —從我們想合作的主要雲服務提供商那裡獲取一些雲服務，像是 AWS、 Azure 和 GCP。我們在這些雲服務提供商平台上構建一些產品，我們也充當雲端代理。我們在 16 個國家/地區都有團隊，與業務部門在同個地方，協助把這些雲產品整合到 AXA IT 團隊中，並啟用這些雲服務。
我在 AXA 領導多雲團隊，我的職責是讓我們的應用程式團隊以安全的方式（即安全和合規）盡可能輕鬆地使用這些雲服務，而要讓他們更容易使用這些服務 — 就要將這些應用程式移到雲端。
雲端優先策略，服務全部要上雲
我們現在有一項巨大的計劃，名為 Atlas 計劃。但在談到 Atlas 計劃之前，我想談談我們的雲端策略。我們的雲端策略已經改變了。大約五年前，我們定義了一個雲端優先策略。所有新的業務應用程式都應針對公有雲服務，我們有敏捷開發團隊、功能團隊、敏捷小組等，我們正在努力改造所有的業務應用程式。
我們希望營運公司能夠改造他們的業務應用程式 — 重新架構它們，在可能的情況下重新平台化，並將它們移至託管平台類型服務。我們希望遠離以往在伺服器 VM、基礎設施服務等上提供應用程式的方式，畢竟我們覺得將這些基礎設施服務原封不動地移到公有雲沒有任何好處。
我們希望專注於功能即服務、資料庫即服務以及可以從這些雲服務提供商獲得的所有無伺服器應用程式。我們構建了自己的容器平台，因此我們可以將我們的應用程式容器化並在公有雲中運行。這已經是五年前的事了。
然後，我們在核心數據中心構建了私有雲基礎設施。緊接著，我們到了下一個更新週期，面臨一個重大的決定：我們是否要更新我們開發的私有雲服務？我們是否要更新我們所有核心 IT 服務？我們是否要繼續使用相同的數據中心？還是應該大躍進並將所有內容移至公有雲？ Atlas 計劃就是在做這件事。雲端策略已經改變了，我們正在尋求將所有內容移至公有雲。
這給了我們比依賴雲服務提供商的現代託管雲服務帶來更多的挑戰。我們必須在公有雲中複製許多基礎設施管理服務，為了進行那種“ lift-and-shift” 遷移，我們必須將許多這些管理服務 —這些營運能力 — 帶入公有雲，而這就是 Atlas 計劃正在做的事情。
Atlas 計劃 – 構建自動化工具的全球雲端遷移
Atlas 計劃是全球雲端遷移計劃，目標是退出我們的私有 IaaS 並在雲端環境中更新我們的核心 IT。
好消息是，它仍然是多雲策略，我們將繼續採用多雲策略。我們再次討論了是否要與一家戰略雲端提供商合作，還是要繼續使用 AWS、Azure 或 GCP。
歸根結底，我們是一家保險公司。我們比較保守，我們想分散風險。我們也受到嚴格監管，所以分散風險非常重要。
儘管我們仍然維持多雲策略，但我們不會開發任何雲端入口 (cloud portals)。我們不會開發允許使用者登錄控制台並在公有雲中構建基礎設施的東西，我們不想複製雲端服務供應商已經做過的事情。
關鍵原則是「全部是代碼，全部自動化」。因此，Atlas 計劃要遷移這些應用程式，所有內容都必須完全自動化，它必須完全是基於基礎設施的代碼 (infrastructure as code)。
我相信你能想像到，對於在金融公司工作的人來說，我們有很多老舊的既有應用程式。我們沒有它們完整的源代碼，它們都是多年來被設置出來的。我看到很多人在這裡點頭表示同意 (指現場聽眾)，我們沒有基於基礎設施的代碼部署，所以我們必須開發它。我們必須構建那些自動化工具來實現向公有雲的遷移。
Atlas 計劃持續進行，它不是簡單的 lift and shift
Atlas 計劃不僅僅是遷移。它不是簡單的 lift and shift。我們需要審視整個 IT 環境，還需要審視所有管理服務。
我們不能一次把所有東西帶上雲端，也不能一次做全部的事情，所以我們需要決定優先事項。
我們希望在本年底/明年中期退出我們的私有 IaaS。這意味著我們不能浪費任何時間，我們不能把所有東西都搬到公有雲上，然後再用它來進行遷移。我們必須務實一點。
以下是 Atlas 計劃的一些數據：全球有 40 個實體參與其中， 600 人致力於雲解決方案和自動化遷移作業。
我們不得不採取自動遷移的方法，因為就只有這麼多高級技術人員可以協助遷移業務應用程式。
如果我們想遷移 6,000 個業務應用程式，有些人說可能有 6,000 到 8,000 個，我保守估計為 6,000 個，但是有 13,000 個虛擬機和 5,000 個技術服務器。當我看到這個數字時，我非常驚訝 — 我們運行業務應用程式所需的技術服務數量有夠多！
我們不能簡單地 lift and shift 來完成這項工作，我們必須採取自動化的方法並構建自動化工具來實現這一點。
自動化的開端及開發路徑 – HashiCorp Terraform
大約 5-6 年前，我們開始使用 AWS、Microsoft Azure，然後稍晚之後使用 GCP。GCP 是用於一些非常特定的用例，例如大數據和商業智能。
我們啟用了 AWS 和 Azure，並專注於構建這些基礎。我們做了大量工作來構建這些基礎。我們有大約 1,200 個 AWS 帳戶和 500 個 Azure 訂閱，基本架構 (foundations)、雲端部署區 (landing zones) — 我想 Sammy 指的是它們 — 都必須完全自動化。我們在 4-5 年前就做了這件事，我們用 Terraform 來做，但是是 Terraform 社群版。
我們使用了 HashiCorp Terraform — 不是全部都用到它 — 但在某些情況下，我們使用了 Terraform，並構建了這些雲端部署區，即可以支持我們新業務應用程式的基礎。我們構建了基於 IBM 或 RedHat OpenShift 的容器平台。該容器平台在 Azure 上運行 — AWS 上也有 — 我們用它來現代化和重新平台化我們的許多業務應用程式。
然後，在 2020 年，我們相對成熟的營運公司之一 AXA Germany 開始了基礎架構自動化專案。他們的 DevOps 團隊剛成立時，每個人都使用不同的工具，像是 Azure DevOps、CodePipeline、CloudFormation — 等不同的 CI/CD 工具。
德國有工業化歷史，真正地將營運工業化，並構建那些標準基礎架構。因此，AXA Germany 的 CIO 來找我們說，我們想看看是否可以構建一個標準的基礎架構即代碼。他們使用 AWS 和 Azure，所以他們想要一些在兩個雲中都適用的東西。他們選擇了 Terraform，但他們希望我們構建那種工業化部署，這也是我們第一次交付 HashiCorp Terraform Enterprise。
Terraform Enterprise 自動化遷移的起點
我們的德國團隊，Group Operations Germany 構建了這個 Terraform Enterprise 平台。大約 9 個月內，我們就已經將所有 DevOps 管道遷移到了 Terraform Enterprise，要麼直接使用 Terraform Enterprise 和 VCS 驅動的流程，要麼整合他們現有的管道工具。然後在 9 個月內，德國就要求之後全部的東西都必須使用 Terraform Enterprise。
這最初只是一個專門針對德國的專案。然後，我們的策略改變—我們決定要將所有東西都轉移到公有雲—我們必須建立一些東西來實踐。
正如我所說，我們想以自動化的方式完成它，一切都是代碼，所以我被要求研究如何實現這種遷移。我們如何支援實體團隊將他們的應用程式移到公有雲？我不想重新發明任何東西，所以我抓住了 AXA 德國的那些人並說，「讓我們把它做成一個全球產品！」
目前的成就 – 完全整合監控工具/資料庫到 Terraform Enterprise
幾年前，我們是這樣做的：我們研究了德國做了什麼，以及他們如何在私有網路中實施 Terraform Enterprise — 它實際上是託管在 AWS 上。然後我們把它做成了一個全球產品。它是 Terraform Enterprise 的多租戶部署。我們已經部署了 35 個實體，現在我們正在使用它們來進行所有遷移，和新的業務應用程式部署到該雲環境中。
我們已經啟用了該基礎架構自動化，我們今天構建的每個應用程式都使用 Terraform Enterprise 平台。所有從本地部署的私有雲 IaaS 基礎架構的遷移—所有正在遷移的服務器—都使用該 Terraform Enterprise 平台進行遷移。
我們已嘗試將它完全整合到所有其他 AXA 環境中—監控工具、配置管理資料庫、所有其他東西、網路等。我們已嘗試構建全部的功能，其中一些我之前有看到已經完成了，正在複製到 Terraform Cloud 或 Terraform Enterprise 的下一個版本中。這對我們來說是個好消息，我們已經完成了一部份工作。
展望未來 – 讓開發人員輕鬆使用 Terraform 構建安全合規的雲端環境
我們發現開發人員是一群有趣的人。如果你只給他們雲端服務的工具，如果工具有用，他們就會用；如果不給他們工具，他們是工程師，他們會直接發明一些東西，他們會自己寫，他們會自己打造出來。他們可能不會考慮我們全部的安全或合規需求，所以我們的做法不是強制他們使用某些東西，而是試圖提供開發人員要求的服務。
我們舉辦了許多社群活動。兩週前，我們在科隆舉行了軟體工程峰會，我們的合作夥伴 HashiCorp 也參加了該活動。我們努力傾聽那些開發人員，因為如果開發人員要求某些東西，而我們沒有提供—如果他們無法輕鬆使用它—我知道他們肯定會自己動手打造，因為他們是工程師。
因此，我們嘗試構建他們要求的服務—以及他們根本沒有要求的—嘗試預測他們的需求並構建這些服務，使他們能夠輕鬆使用合規、安全的服務。
我們希望提高自動化水準。我們正在研究 GitHub 操作和 Terraform 運行任務，有很多東西還要改善，我們會不斷改進這個平台。
我們已經建立了這些基礎，所以我們今天有一個雲代理團隊，他們將創建雲端部署區。他們啟用了一個實體，並完成整合，我們希望讓開發人員可以輕鬆地啟動新的環境來構建開發人員雲端部署區。因此，他們不需要知道如何創建 AWS 帳戶或請求 Azure 訂閱或資源組。
我們希望讓他們可以輕鬆地使用一個模塊，該模塊可以為他們的應用程式引導整個 DevOps 環境。這將包括所有網路、監控工具和與身份管理系統的整合等。真正地讓開發人員可以輕鬆地啟動新的環境、開發他們的應用程式並納入他們的 Terraform 工作區。
無代碼配置 (No-code provisioning )
無代碼配置（No-code provisioning）也許是個行話，我不確定，但如果一個開發人員只想儲存一些數據，那麼他們會很高興使用一個模塊來創建一個資料庫。如果他們只輸入一些屬性，例如數據的保密級別，那麼我們就可以使用正確的加密、曝光等來構建儲存桶。我認為，如果我們讓他們很容易使用這些服務，開發人員就會欣然使用。
無代碼配置在我們這裡現在是可行的，它適用於遷移和服務器基礎架構。我們對他們說這是運行 SQL server 的 Windows 2019 版本的標準模式，然後他們就很高興地接受它，用於構建他們的應用程式。
我們想這樣做，我們想擴展它。所以，很高興看到 HashiCorp 也朝著同樣的方向前進。
SaaS 模式
接著我想談談 SaaS 模型，因為我現在在運行一個平台團隊，而我不想做營運，我也不一定想營運我們的 Terraform 基礎架構平台。我們現在在 AWS 上運行一些虛擬機，我們必須維護它們。我們每個月都必須升級，因為 HashiCorp 每個月都會發布一個包含一些不錯的新功能的新版本，但我並不想這樣做。因此，我很想知道 SaaS 模型將走向何方，以及它是否適合 AXA，我希望它會。
在整個安盛集團中啟用雲端和自動化遷移
我有基礎架構背景，所以我不得不把框架放在這裡 (指簡報)。但你們可以看到，Terraform 位於雲端部署中。讓我先把下面的這小部分放到第一個來講。
你們有那些基礎架構，我們使用雲端服務 AWS、Azure、GCP。我們已經建立了這個基礎層。現在它不是一個很大的層，它只是你每次創建新帳戶或訂閱時需要做的事情。它是必須配置的 IAM、網路和安全服務的整合。所以我們以完全相同的方式配置，構建了我們稱為 MPI 的產品。MPI 是託管的公共 IaaS，它只是一組允許你部署安全且合規的虛擬機的模式。
我們有這個開源 PaaS。它是基於 OpenShift 的容器平台。我們在全球運行大約 20 個 OpenShift 集群，在該平台運行 27,000 個容器—我們構建讓開發人員很容易使用的容器平台。然後是位於其上的原生雲端服務，這是我們傳統上一直在構建的雲端平台和產品。
我沒有把所有工具都放在這裡 (指簡報)，我注意到在先前的簡報中有 Artifactory 和 Checkmarx 等工具。我們試圖提供託管的 Terraform Enterprise 雲端部署服務。並且為所有原生服務或我們自己開發的產品提供標準模塊，以便可以被使用。
這些模塊附帶一組規範，這些規範會告訴你它們是否合規。與剛剛提到的略有不同，我們目前沒有強制執行其中許多規範，我們與安全團隊密切合作，但目前大部分是諮詢性的。
Terraform – 事件驅動的標準化模塊
每當我們構建新的服務或產品，我們都會創建標準模塊和規範，讓開發人員使用它們來構建自己的業務應用程式。如我之前所說，並非我們所有的核心系統都已遷移到雲原生服務。它們不全都具有 Terraform 提供程式。我們尚未為它們編寫 Terraform 提供程式，因此我們仍然需要進行一定程度的自動化來將這些產品整合到這些後端系統中。
一個簡單的例子是，如果將 EC2 VM 部署到 AWS，我們需要將其註冊到多個後端系統。例如 Puppet、身份系統、特權用戶訪問管理系統和我們的配置管理資料庫，並非全部都具有 Terraform 提供程式。我們尚未開發完成，如果使用這些模塊，我們會在這些雲平台上運行這些基礎設施。我們有一個配置事件，我們可以使用該配置事件來進行一些後端系統整合。最終，我們希望將所有這些作為配置過程的一部分進行移動，但目前還沒有實現。我們沒辦法一次解決所有問題，正如我之前所說，我們有很多應用程式需要遷移。
我們開發了這個調度平台功能，它是事件驅動的，它具有各種工作流程的 API 服務，用於將服務註冊到這些後端系統。因此，開發人員和遷移團隊將使用這些模塊，使用我們的產品將這些服務部署到戰略提供商平台。這會產生一個事件，事件會觸發某些操作，這些操作將進行一些後端服務整合。
分析資料湖數據，提升洞察力和可觀察性
因為這些東西，我們對已部署的內容和我們在雲端服務中的運作有了很深的洞察力。我們使用資料湖技術收集我們部署到公共雲端的所有資源的盡可能多的數據。
實際上，它不僅是公共雲端。有一個叫做 POD 的東西，它是個分發點，這只是一個基於 VMware 的本地部署。我們知道有些東西會在我們的核心數據中心保留。我們想遷移所有東西，但我們知道我們不會這樣做，我們也不會立即這樣做。
但是，所有部署的東西，我們都會收集關於它的所有數據到資料湖中。然後我們會有一些洞察力，並可以使用 Power BI 或其他商務智能工具來分析這些數據，然後進行報告。這種可觀察性可以傳遞給治理團隊、架構團隊、財務團隊，也可以是操作團隊，主要是安全團隊，他們想知道這些業務應用程式是否在安全環境中運行，例如，我們是否將客戶數據暴露在公共互聯網上。
這是我們團隊的責任：我們提供配置、調度和可觀察性功能。基礎設施—我的舊角色，現在由我們的 Azure 核心功能中心運行—我們有基於不同技術的能力中心，例如 Azure、AWS、GCP、OpenShift 等。
完全整合到 AXA 環境 – AWS、Terraform、Power BI、Dynatrac、CI/CD 工具
首先，我們自己運行 Terraform Enterprise。我們目前只在 AWS 上運行它。正如我之前提到的，我們希望在未來將其轉移到 SaaS 服務。
我們也為瑞士的營運公司運行一個小型實例，他們在 Azure 上有一個部署，雖然我們是用 AWS 為我們的大多數客戶提供服務，但是，如果你曾在瑞士公司工作過，你會知道他們想將所有資料保留在瑞士—非常嚴格地監管—因此這個實例在 Azure 上運行，因為 Azure 在蘇黎世有資料中心。
但重點是，我們的 Terraform Enterprise 部署在 AWS 上。它在一個私有網路上，我們已將它與所有其他 AXA 服務整合—Power BI 用於報告、Dynatrace 用於監控。我們與所有 CI/CD 工具整合，用它們來部署 Terraform，我們還備份了所有狀態，這些我們事情我們全都搞定了。
Terraform Enterprise 使用數據報告
左邊的這張圖是舊的圖表，不是最新的數據 (指簡報)。但我們在報告 Terraform Enterprise 使用情況方面做了大量工作。我們自己建立了工作區探索器。我今天早上剛看到了這個公告，也許我們在這裡做的工作中的很多部分將被 HashiCorp 提供的開箱即用解決方案取代。
但是我們在收集所有數據、報告組織數量方面做了大量工作。我們有報告告訴我們是否有合規的工作區。合規工作區意味著它們具有所有正確的策略，使用了所有正確的命名約定。
我們有報告告訴我們低利用率的工作區，這些工作區是 7 個月前被使用的，此後未被使用。因此，這些資源可能只是在那邊而從未被更動，或者這些資源根本用不到—在這種情況下，會有其他資訊會告訴我們它們的成本，我們可以根據需要考慮刪除這些工作區。
總結 – 我們選擇 Terraform Enterprise
我們在公有雲中啟用新的託管服務，從此開始了我們的雲端之旅。
我們最初並沒有發現將所有工作負載遷移到雲端的優點。但我們現在改觀了，我們現在有一項大型計劃，預計 AXA 在未來四年內將所有工作負載遷移到公有雲的超大計劃。
我們做了大量工作來整合 Terraform Enterprise，以確保現在部署的內容都是以基礎架構為代碼，並且完全自動化，因此可以說沒有手動配置操作。實際上仍然會有一些手動操作，但我們要確保現在部署到雲端的所有內容，未來都可以讓我們維護和支持它。
可逆性 (reversibility) 也正在到來。所以，未來我們是否能將在 AWS 上運行的應用程式移到 Azure？我不確定，但這可能是我們的長期目標，我們只能透過選擇一個通用工具來實現—我們選擇 Terraform Enterprise。
就這樣，我 (的分享時間) 只剩下一分鐘了 。
本文翻譯自原廠文章：Building a migration factory with Terraform Enterprise at AXA Group
