從上個月AWS服務器宕機事件中，我們應該可以看出，只有一個云是不夠的。所以筆者現在希望討論一個稍遠一點兒的話題，關于如何更好地完成云轉型，而避免孤注一擲。
除了防止宕機事件對你造成過大的影響之外，你也應該知道，任何擁有你的數據的供應商，都會想方設法榨取這段合作關系中的最大利益，他們絕對不希望你從他們的云中撤離。“戰略撤退”有時候也是一段業務關系中最重要的部分，以下是筆者的一些建議。(已經根據云的類型進行了分類)
適用于IaaS
1、使用Docker或一個類似的解決方案。你應該擁有可浮動的容器，讓你能夠在突發情況下進行重建和部署。這是一個非常關鍵的應急辦法，讓你能夠避免被供應商“捆綁”。
2、避免直接進行數據庫集成。是的，你的App需要一個存儲空間，但是兩個App不應該訪問同一個操作存儲區。這種類型的連接和協議更像是建了一棟紙牌搭的屋子，很不牢靠。在你移動數據庫之前，無法移動任何其中的任何東西——當然，如果你按照正常流程處理，不會有什么大問題。與之相反的，你就會在一個非常讓人頭疼情況中結尾。
適用于IaaS/PaaS
3、實施API/REST集成。Rest架構能讓你更容易通過HTTPS進行連接、制定標準和更容易重新定位的網絡電話。
4、外部化配置。不要將方案、服務器或域名硬式編碼到你的URL中，其他與環境有關的都應被外部化。
5、使用常見的API。如果你正在使用NodeJS、Express或其他類似的著名API，那么你就是安全的，不必擔心供應商“捆綁”的問題。而如果你開始使用平臺提供的服務，那么你就有大麻煩了。
適用于SaaS
6、確保有一個標準的數據導出步驟。這里的意思是，你能輕松地將數據導入另一個系統。
7、測試數據導出步驟。理論上他們不太有可能會讓你抓取數據的轉儲，筆者曾經見過提供這種功能的供應商，但實際上轉儲功能并沒有按照合理的時間表進行工作，而且那時的數據已經成為了垃圾。
8、傾向于著名的解決方案，穩固Rest API。事實上，你無法一次性完成轉儲、導入和移動的工作。你可能需要一些定制的中間代碼，在你抓取和傳輸的位置。
適用于關于云的任何方面
9、傾向于開源技術。如果你的核心技術、API和功能是由一個健康的開源項目提供的，那么在你需要脫離供應商時，你就會有很多更好的機會。這里說的是架構的選擇，舉個例子，你可以考慮用Kafka代替Kinesis。
10、避免依賴于看起來獨一無二的云供應商技術。有時候你的架構連結更多的是處理而不是編碼，這些傾向于漏入API調用或其他操作管理程序。例如，也許你不使用AWS的Elastic Map Reduce，不過坦白來說它不是最好的財務分析產品，而且多少有點兒古怪。它與你曾使用過的任何云平臺都不相同，從這方面來說，你或許不該選擇它。
11、使用固定的IP和DNS名稱，并綁定到你的公司，而不是供應商。使用一個IP和DNS名稱一定程度上是互聯網101。虛擬主機失靈重啟并產生一個新的IP，這樣不是很有彈性，更不用說重定位了。
12、盡可能地使用信息傳遞。如果你能夠在信息基礎上做得更多，那么服務的宕機就能在一定程度上接受了。這意味著，當你選擇移動云服務時，仍可以在其他的地方繼續運行你的業務。
13、選擇兩個云。正如筆者之前所說，如果你一開始就選擇了至少兩個云供應商，那么在移出時就會更簡單。在SaaS中可能會有點困難，但是在IaaS/PaaS中可操作性很強。
總的來說，你至少應該傾向于開源、開放標準和開放API的特定供應商解決方案。使用微服務架構或至少符合其原則。始終保持你的撤退戰略，你就會與你的云供應商擁有一個非常有利于自己的關系。記住，你的云供應商永遠會想著如何讓你離不開他們。
京公網安備 11010502049343號