挑戰
在過去幾年中，為全球旅遊業提供 IT 解決方案的 Amadeus 發現，其服務導向型架構支援的 5,000 項服務需要一個新的平臺。這家擁有 30 年曆史的公司在德國運營著自己的資料中心，內部和外部對需要地理分散的解決方案的需求日益增長。更普遍地說，“我們的目標是實現更高的可用性，”Amadeus 分散式系統高階專家 Eric Mountain 表示。該公司的目標包括：提高基礎設施管理的自動化程度，最佳化工作負載分配，更高效地利用資料中心資源，以及更輕鬆地採用新技術。
解決方案
Mountain 一直在監督公司向 Kubernetes 的遷移，使用的是 OpenShift 容器平臺，這是 紅帽 的企業容器平臺。
影響
該團隊在 Kubernetes 中部署的首批專案之一是 Amadeus 航空公司雲可用性解決方案，該解決方案有助於管理不斷增長的航班搜尋量。“它現在每秒處理數千筆生產交易，並部署在全球多個數據中心，”Mountain 說。“這並不是現有工作負載的遷移；這是一個全新的工作負載，我們以前無法實現。這個平臺讓我們獲得了以前沒有的市場機會。”
當年，他負責公司從 Unix 到 Linux 的遷移，現在他正在監督向雲原生的轉變。“技術不斷變化，我們欣然接受，”他說。“我們今年慶祝公司成立 30 週年，我們將繼續發展和創新，以保持成本效益，並提升每個人的旅行體驗，同時不中斷依賴我們技術的客戶的工作流程。”
這就是 Amadeus——為全球旅遊業提供 IT 解決方案，從航班搜尋到酒店預訂再到客戶反饋——在 2014 年面臨的挑戰。技術團隊意識到，其服務導向型架構支援的 5,000 項服務需要一個新的平臺。
轉折點發生在他們開始收到許多內部和外部請求，要求提供需要部署在公司德國主要資料中心之外的地理位置的解決方案。“有些請求是要求在客戶場所執行我們的應用程式，”Mountain 說。“我們還希望提供一些需要數百毫秒響應時間的新服務，這是我們無法透過跨大西洋流量實現的。或者至少，如果不是吞噬我們應用程式處理單個查詢可用時間的很大一部分，就無法實現。”
更普遍地說，公司對提高高可用性、增加基礎設施管理的自動化程度、最佳化工作負載分配和更有效地利用資料中心資源感興趣。“我們有成千上萬臺伺服器，”Mountain 說。“這些伺服器被分配了角色，所以即使設定是高度自動化的，機器仍然有一個給定的角色。這在許多層面上都是浪費的。例如，一個應用程式不一定能非常最佳化地使用機器。虛擬化可以有所幫助，但它不是萬能藥。如果那臺機器壞了，你仍然需要修復它，因為它有那個角色，你不能簡單地說，‘好吧，我再拿一臺機器來，給它那個角色。’它不快。它效率不高。所以我們想要更高層次的自動化。”
雖然 Amadeus 主要使用 C++ 和 Java，但它也希望能夠更容易地採用新技術。Mountain 表示，一些開發人員已經開始使用 Python 等語言和 Couchbase 等資料庫，但他希望有更多的選擇，“以便更好地調整我們的技術解決方案以適應我們提供的產品，併為我們的開發人員開闢全新的可能性。”使用最新的技術和酷炫的新事物也將使吸引新人才變得更容易。
所有這些需求促使 Mountain 和他的團隊尋找一個新平臺。“我們在相當短的時間內進行了一系列研究和概念驗證，我們考慮了許多技術，”他說。“最終，我們剩下三個選擇：在本地構建所有東西，在 Kubernetes 之上構建我們認為缺少的東西，或者選擇 OpenShift 並在其之上構建剩餘的東西。”
團隊決定不自己構建所有東西——儘管他們過去做過類似的事情——因為“人們已經發明瞭一些看起來不錯的東西，”Mountain 說。
最終，他們選擇了紅帽基於 Kubernetes 的企業產品 OpenShift 容器平臺，而不是在 Kubernetes 之上構建，因為“我們想要的東西與紅帽預期的 OpenShift 發展方向之間存在很多協同作用，”Mountain 說。“他們顯然正在開發 Kubernetes，並在 OpenShift 中提前開發了一些對我們很重要的東西，例如更高的安全性。”
希望這些特定的功能最終能內建到 Kubernetes 中，就安全性而言，Mountain 認為這已經實現了。“我們意識到，我們可能總是需要自己開發一定程度的自動化來彌補某些差距，”Mountain 說。“我們做得越少，對我們就越好。我們希望，如果我們在別人已經構建的基礎上進行構建，我們所做的事情實際上可以被上游化。隨著 Kubernetes 和 OpenShift 的發展，我們看到我們確實能夠移除我們為了彌補早期發現的差距而實現的一些額外層。”
團隊著手解決的第一個專案是他們知道必須在德國資料中心之外執行的專案。由於專案的需求，“我們不能僅僅依賴內建的 Kubernetes 服務發現；我們必須在此之上再加一層服務發現，以便在我們的系統內部實現操作層面的負載均衡，”Mountain 說。他們還建立了一個專門用於監控的流，當時 Kubernetes 或 OpenShift 生態系統中沒有提供。現在 Prometheus 和其他產品已經可用，Mountain 表示公司可能會重新評估他們的監控系統：“我們顯然總是喜歡利用 Kubernetes 和 OpenShift 所能提供的一切。”
第二個專案最終率先投入生產：Amadeus 航空公司雲可用性解決方案，該解決方案有助於管理不斷增長的航班搜尋量，並部署在公共雲中。Mountain 說，該解決方案於 2016 年初推出，現在“每秒處理數千筆生產交易，並部署在全球多個數據中心”。“這並不是現有工作負載的遷移；這是一個全新的工作負載，我們以前無法實現。[這個平臺]讓我們獲得了以前沒有的市場機會。”
經歷了不止一次這樣的技術演進，Mountain 對如何處理文化變革提出了建議。“這是一個我們可以逐步解決的方面，”他說。“我們必須繼續為客戶提供現有產品的新功能，並且我們必須保持現有產品正常執行。所以我們不能簡單地在一天之內做所有的事情。我們也不能那樣推銷。”
那麼，首要任務是選擇一兩個應用程式來證明該技術有效。Mountain 的團隊沒有選擇高影響、高風險的專案，而是選擇了一個較小的應用程式，它在複雜性方面代表了公司所有其他應用程式：“我們只是確保我們選擇了一個足夠複雜的應用程式，並證明它可行。”
接下來是說服人們。“在運營方面和研發方面，會有人理所當然地說，‘有系統，而且它能工作，為什麼要改變？’”Mountain 說。“真正能說服人們的唯一方法是向他們展示價值。”對於 Amadeus 來說，人們意識到航空公司雲可用性產品無法在公司現有系統的情況下在公共雲上提供。然後問題變成了，他說，“我們是否要進行全面遷移？這樣做是否合理？”
“底線是，我們想要這些多資料中心能力，而且我們也希望我們的主流系統具備這些能力，”他說。“我們不認為我們能用以前的系統實現它們。我們需要 Kubernetes 和 OpenShift 帶來的新自動化、同質性和規模。”
那麼，如何讓所有人都參與進來呢？“確保你的研發和運營之間有良好的聯絡，”他說。“還要確保你儘早與投資者和利益相關者溝通。弄清楚他們會期望你什麼，這將說服他們，或者不，這是你公司正確的道路。”
他的另一個建議是簡單地讓人們可以嘗試這項技術。“Kubernetes 和 OpenShift Origin 都是開源軟體，所以評估期沒有複雜的許可證金鑰，你也不限於 30 天，”他指出。“只管去執行它吧。”他還補充說，“你必須準備好重新思考你做事的方式。當然，讓你的應用程式儘可能地雲原生是你獲得最大收益的方式：12 要素、CI/CD，也就是持續整合、持續交付，還有持續部署。”
在他們探索技術這方面的時候，Mountain 和他的團隊很可能會身體力行他向其他踏上雲原生之旅的人所宣揚的。他說：“看看當你把它弄壞時會發生什麼，因為了解系統的侷限性很重要。”或者更確切地說，他指出，它的優勢。“弄壞 Kube 的東西實際上是它的一大優點——它會恢復。這是你唯一真正能看到你可能能夠做事情的方式。”