Stephen Orban現任AWS企業市場戰略總監。在加入AWS之前，他是道瓊斯全球CIO，負責領導道瓊斯集團的信息技術戰略和實施。Stephen在道瓊斯內部率先倡導了“云優先”的戰略，幫助道瓊斯集團全面采用云服務，“All-in-AWS”。基于自身的經驗和AWS豐富的服務，Stephen開設了專門面向企業客戶的專欄，探討企業客戶在采用云服務過程中最重要的議題，并分享AWS客戶的成功經驗。
”合抱之木，生于毫末; 九層之臺，起于累土; 千里之行，始于足下。” –老子
今年的AWS舊金山技術大會令我頗有驚艷之感。我有幸在大會前的企業云專場做了題為《企業的云旅程》的主題演講，并在眾多企業客戶及其它業方的關注之下分享了自己的心路歷程。除了豐富的新內容、新服務以及來自各個行業且規模不一的客戶的精彩介紹，AWS合作伙伴生態系統亦呈現出不斷發展之勢。三年之前，瀏覽合作伙伴的展示內容只需15分鐘，但今年琳瑯滿目的布展內容給我帶來了長達數小時的美好回憶。
云已經成為新常態
實現云技術是一場漫長的旅程，我們無法在一夜之間走完這段道路。企業在完成這段旅程中會面臨種種挑戰與機遇。企業踏上的這段云旅程可以也應該以流程化姿態享受其過程。在此期間，大家有機會成功降低成本、提高執行速度并發展新型技能，同時為客戶帶來更加可靠且全局可用性更高的服務內容。
目前尚未踏上這段旅程的企業則正在考慮如何才能將云技術引入自己的現有環境。這將幫助他們在向所關注領域投入資源時，充分享受由云技術所帶來的種種優勢。
在我曾任CIO的道瓊斯公司，我們自上世紀七十年代開始、每十年專注對企業架構進行一次調整。在這種情況下，坦白地講，大部分基礎設施與流程并沒能帶來預期效果。我們在新項目的推進速度方面也較為遲緩，因此失敗的嘗試往往會導致高昂的成本支出。而近年在新項目的推進過程中，我們通過與AWS協作而積累到大量專業知識與經驗，技術更新速度也得到長足進步。我們從單一新型應用程序起步，隨后構建起VPC將該應用與位于防火墻后的服務項目加以對接，遷移部分災難恢復應用系統，并在具備一定經驗儲備后僅用時六周就完成了一座數據中心向AWS的整體遷移。其后，我們下決心在三年內將75%的整體基礎設施轉移至云環境當中。我們在實施過程中學到了很多，這使我們赫然發現在云環境下竟然能夠如此快捷、如此出色的成功構建新架構，而云部署的實際效果遠遠優于原有內部基礎設施方案。我們開始考慮將基礎設施事務分別交由AWS與自有數據中心承擔，并利用AWS作為各個項目的主要實現手段。
通過總結自身經驗以及與客戶進行交流，我發現一旦這段云旅程步入正軌、企業積累到一定經驗，其它事務將以加速方式結出喜人的碩果。云技術帶來的收益非常明顯，而且在我們了解到如何打理云服務這一新型技術之后，原本幾乎不可能實現的目標將成為云遷移名單中的優先選項。在各個階段，大家都能夠從多種方案中做出選擇，包括是否重新設計開發運維、是否使用AWS Marketplace、是否接受開源機制或者與之相關的技術方案組合。隨著對云體會的不斷深入，正確的IT道路將自行出現在我們面前。也就是說，目前規模龐大的可用AWS服務選項及其不斷改進的良好態勢已經極具吸引力，大多數正在考慮將云計算引入自身體系的大型技術企業都很難抗拒這種誘惑。大家可以了解如何才能將AWS融合到自身建立起的現有網絡拓撲結構、服務器與存儲模型、內部虛擬化、桌面管理以及企業IT管理模式當中。
下面一起來看好消息……
AWS并不是一個非此即彼的命題
目前已經存在大量執行策略，用于指導大家保證AWS能夠與現有投資資產并行不悖。整個遷移過程的實施速度盡在控制，并可根據業務需求及壓力作出調整。
作為初期目標，我們不太可能剛一起步就打算將所有業務全部遷移至云環境當中。而且從合理性角度來看，中止一切現有活動、直接進行現有基礎設施遷移也毫無明智性可言，特別是在現有基礎設施仍有其專長所在的情況下。
很多客戶告訴我們，他們發現其能夠在不對現有基礎設施進行任何修改的情況下輕松體驗AWS的實際使用感受。在此之后，客戶也能夠非常便捷地在現有基礎設施與AWS之間建立起業務對接關系。一旦連接建立起來，我們將迎來充滿可能性的新起點。從這里開始，大家的云之旅程已經悄然開啟。
一段典型的企業云旅程
在過去幾個月中，我有機會與來自不同行業且足跡遍布世界各地的幾十位企業客戶進行交流。將這部分信息與我個人在道瓊斯及News Corp在轉化為云優先企業過程中積累到的經驗相結合，我為大家總結出了以下這段常見的云技術實現流程：
1. AWS試點項目。試點對象可以是經過明確定義的實施項目也可以是采取模糊成功指標的研發工作。企業中的常見起步實例包括簡單網站、移動應用程序后端、災難恢復站點、開發及測試環境下的額外容量、非關鍵性任務應用程序遷移或者創建面向未來需求的新型執行標準。
2. VPC集成。在此階段大家的任務是建立連接，從而保證AWS能夠作為現有企業網絡之外的延伸機制發揮功效。網絡工程師應當以審慎的態度推進這項工作，從而避免帶來任何可能給企業帶來不便的負面狀況。不過除此之外，這其實是一項非常簡單的實踐活動，所需時間僅為數小時、而非數天或者數周。
3. 混合架構承擔工作負載。企業中的大多數工作負載都屬于這一類別。通常情況下，現有基礎設施中的一部分關鍵性資產需要耗費較長時間才能順利被遷移至云環境當中。但除此之外，那些較為靈活的系統——具體情況取決于資產實際情況——能夠立即成為遷移備選項。首先將注意力集中在這些非關鍵性系統中能夠幫助企業客戶快速獲得收益，而在此期間積累下的經驗與信心也有助于企業日后更順利地完成共享資產遷移。在經歷過數次系統遷移之后，大家會發現整個流程要比預想中更為輕松。我就曾親眼見證過多家客戶的實際執行過程，在運行混合應用程序方面積累到一定經驗之后，這些企業開始全面奉行云優先指導方針。這種作法還能夠鼓勵企業以逆向思維看待云遷移工作。相較于論證某個項目能否在云環境中實現，企業更應當去證明其為什么無法在云環境中實現。在這種情況下，企業往往傾向于利用托管SaaS解決方案打理各種常見的企業后臺功能，例如HRIS、電子郵件以及協作系統。
4. 使用DirectConnect. 在內部數據中心與AWS之間直接起用專用連接通道DirectConnect往往成為網絡敏感型應用程序在混合模式下正常運作的前提條件。根據我的個人經驗，大家在實際實施過程中也需要采取此類方式。當然，直接連接并非嘗試混合架構時的先決條件。
5. 全面使用AWS。隨著更多資產遷移到AWS當中并享受由該平臺帶來的功能優勢，企業可能迎來了發展臨界點，即其整體系統中利用云平臺實現的功能開始多于由混合架構所實現的功能。部分企業已經就此給出自己的解決思路，即“全面”貫徹云戰略——其中Infor、Sun Corp以及凱賓斯基酒店都是這方面的典型代表。
您何時準備開始您的云旅程? 以上情況與您旅途的經歷是否相符?歡迎各位在評論中分享您的體會。
京公網安備 11010502049343號