在過去幾年中，我多次幫助多家企業實現云服務的完善，安全且可靠。雖然這些公司的問題都不一樣，但問題類型本質上還是可以歸類的。這也是本文將會介紹的十誡。

我將這些多年實踐總結出來的十誡分為兩種類型：一種是針對商業決策者（高管），另一種針對技術決策者（技術團隊中的工程師和管理者）

 類型一 面向商業決策者

1.不要把云僅當著一個技術問題

敏捷或DevOps轉型被廣泛認為是涉及某種程度的自上而下的組織變革。這包括新的職責、新的工作方式以及團隊之間新的溝通方式。您不能僅僅是指望通過買一個“DevOps Box”就能達到成功。

你的云計算采用與此無異。不要認為云計算僅僅是通過另一種方式交付同樣的舊技術和工作方式?！斑w移與轉移”的思維方式最終會導致昂貴且臃腫的云計算采用失敗。

在成功采用云計算作為優先選擇的企業中，開發、運維、安全甚至財務等各個方面都會采取新的架構。請花時間理解并包容必需的深層次變化。

圖片

2.從一開始就進行培訓

你不能只是下達一個自上而下的組織強制采用云計算的命令，然后就離開，并期望會發生好的事情。

云計算是一場大規模的技術技能和團隊職責的轉變。擁有對云計算技術的深刻理解的人才并不常見，在市場上也并不易于獲得。合作伙伴可以提供幫助，但最終你還是需要有一個計劃，從內部培養這種專業知識。

在較大的企業中，建立云計算卓越中心是一個不錯的開始，但我也看到過這些努力最終被劃分為又一個信息孤島。你不能只是創建一個“云團隊”；你必須更廣泛地推動一種文化，這意味著要在幾個月甚至幾年的時間里，細心設計云計算技能在整個組織中的普及。

是的，培訓確實花費是很多，但云計算的本質是讓你能夠用相同數量的人工實現更高的價值。因此，將招聘預算的一部分轉移到培訓團隊：當你的團隊掌握使用由云服務提供商維護的服務時，你會對他們的成就感到驚訝。

設定正確的重點，提供適當的激勵措施，你的員工將會逐漸實現轉變。

圖片

3.將云計算視為價值中心

我們仍然看到一些企業主要是出于節約成本的考慮選擇云計算，盡管這樣的企業比以往減少了——并且出于不錯的理由。你選擇云計算不是為了花更少的錢，而是為了創造更大的價值。

這就是為什么我喜歡把云計算描述為“IT的殺手級應用”的想法：就像電子表格讓早期的個人電腦成為可取之處，云計算獨自就能超越您IT投資的成本。

如果你的組織能夠充分利用，云計算能夠提升上市時間、創新速度和敏捷度。

一些公司會在云計費單上陷入困境，因為它是他們能看到和理解的與云計算采用相關的唯一指標——盡管它是一個令人痛苦的指標。成功指標，如價值產生的速度，并不是不可能衡量，但是需要有意識地努力建立和評估。

優先考慮實驗，知道成功的標準，您就會發現云計算所產生的價值遠遠超過了成本。

4.從小開始，但不要無準備

很容易陷入幾個月或甚至幾年的云計算等待期。在Andy Jassy最近的re:Invent主題演講中，他指出了一家組織，盡管該組織自吹自擂地宣稱他們采用了云計算，但實際上他們只是部署了一些小的實驗項目。雖然這種方法可能有利于您技術團隊的簡歷打造，但對于業務而言卻沒有價值。

你在剛開始采用云計算時不會一下子就搞對，但不要讓這種擔憂阻止你開始行動。選擇一個適中的工作負載，認真嘗試將其運行在云上，找出短板，進行改進，重復，并不斷擴大對云計算的了解。

認真對待云計算，就會得到認真的結果。

圖片

5.信任你的合作伙伴

企業在云計算的門檻處陷入數月甚至數年的困境的一個原因是什么？他們意識到變革可能是復雜的，他們不想出錯。

出于這個原因，在云計算的過程中介紹可信的合作伙伴是有道理的——那些在這條道路上走過，既知道陷阱，也知道捷徑的人。

（順便說一句，這也是支持公共云的一個很好論點。你真的認為你能比AWS更好地管理數據中心，或者比微軟更好地構建開發者工具嗎？對鎖定的擔憂在歷史上是合理的，并且有其存在的價值，但最終你必須與能夠適當利用風險的供應商合作。）

尋找你可以信任的云計算和咨詢合作伙伴，然后給予他們足夠的自由度，讓他們幫助你實現持久的積極變化。

圖片

 類型二 面向技術決策者

6.不要因個人喜好選擇技術棧

在技術決策中，存在這樣一條普遍的建議：對于大多數問題，都應該采用經得起時間考驗的長期使用的解決方案。沒人因為寫了另一個Rails應用程序或者任何類似的東西而被解雇。

這條建議在不發生重大破壞性前進躍進的世界中是合理的。然而，云計算改變了情況，因為一些新技術很大程度上減少了你需要管理的內容，同時增加了你提供的基礎規模和功能。

例如，AWS的Amplify服務在移動端和后端開發的實時性方面進步很大?；诘痛a、專注于模式的API開發方法絕對是優秀的；與云本地數據存儲的緊密集成是更好的。并且因為AppSync后端是一個云服務，它會隨著時間的推移不斷改進，而你不必做任何事情。可能需要你花幾周時間才能完全熟悉。但是，在這種情況下，投入一些時間學習的回報是持久的。

關鍵是，你的感覺可能會出賣你。你需要冷靜地評估哪些工具和服務能為你提供最大的收益。

圖片

7.時間是最珍貴的資源；全力優化

你每天都接觸到的最昂貴的資源不是你的生產數據庫集群、應用服務器群或日志框架。而是你的日程安排。

你和你的團隊擁有有限的周期來構建和維護技術。不要浪費時間重復造輪子。

舉個不幸的個人例子，我之前的工作中花費了大量時間從零開始構建一個全棧式的部署框架和管道工具。雖然最終這個部署管道確實為業務提供了一定的價值，但代價是數千小時的工程時間。

如果我和團隊更多地依賴現有的云服務，我們可以在更短的時間內完成同樣的功能，用來從事更有價值的項目，而不用總是解釋給管理層我們在干什么。

鑒于云原生開發高度重視使用現成的服務，它使你在日程表上有更多寶貴的時間可用。

圖片

8.更早地開始在云上構建。不，比那還早一點。

我已經一直在鼓勵“本地測試代碼，云上測試服務”的理念。隨著無服務器開發在技術棧中的位置越來越高，維護獨立于云之外的本地開發環境的價值也越來越小。

如果必須這么做，可以在本地迭代代碼；在遠程棧（顯然不是生產棧）部署的角色和資源上進行測試。你在開發生命周期中越早這么做，發現權限和配置問題的速度就越快，在生產環境中出現意外情況的可能性也就越小。

我認為對此有最好理解的供應商是Stackery。我非常喜歡他們的“cloudlocal”開發概念，盡管我覺得這個名字不太可能流行。他們的命令行工具是我知道的唯一一個目前支持在本地執行AWS Lambda函數，并使用與云部署版本相關聯的角色的工具。（當你調用本地函數時，他們會將信任關系注入到該角色中。）我預測，其他主要的無服務器部署框架，如AWS SAM和Serverless Framework，也將很快為此提供更好的支持。這是未來的發展趨勢。

圖片

9.忽略虛假的問題

你可能認為工作中本來就有足夠多的真實問題，無需捏造虛假問題。不幸的是，軟件工程師非常擅長找到那些真正不重要的問題的解決方案。

例如，你的應用程序真的需要跨區域嗎？如果整個AWS us-east區域都宕機了，你的應用程序需要保持可用性嗎？你會花多長時間維護多區域的事務一致性，你會花多少錢來復制數據，而不是每隔特別長一段時間就優雅地短暫停機？

移植性是一個巨大的虛假問題。就像有人說過，如果你正在使用Kubernetes，你必須是很聰明：這是必須的，而不是一種恭維。協調服務網絡、服務代理、入口路由等是一項非常復雜的任務。

我甚至看到人們在無服務器應用中設計復雜的抽象層，以便他們在需要選擇不同的云服務商時可以隨時更換技術。

一個真正明智的技術決策者明白，你可以擅長的事情范圍是很小的。利用云服務，從箱子里獲得經過生產硬化的體系結構，然后在其上構建你獨特的功能。

如果你必須使用Kubernetes，可以考慮使用一些像EKS on Fargate或SpotInst Ocean這樣的管理服務，它們可以隱藏許多冗長的細節（并且可以在超低價的點實例上調度容器）。

更不用說，你可以通過與云服務提供商更緊密地集成獲得很多優勢。直到云服務提供商表明他們將鎖定掠奪性的價格（這迄今沒有發生），你的時間可能更值得用來交付功能。

我的決策流程很簡單：不要只注重代碼，忽視云服務。

圖片

10.通過展示價值來創造動力

作為一名技術決策者，一個可以直接參與代碼開發的人，你特別適合找出在你的領域中可以產生最大影響力的技術。

如果你無法獲得關于一個設計決策的贊同，而你覺得該決策有明顯的好處，你可以試著在云端為它制作一個原型——這通?？梢匝杆俣伊畠r。

作為技術決策者，你可以給企業提供一個強有力的理由：你已經構建了業務所需要的東西。它運行得快，并且易于維護。

圖片

不管你是商務決策者還是技術決策者，云遷移的成功最終取決于你是否愿意接受不舒服感：去挑戰自己能夠構建產品的界限，摒棄舒適圈，并信任那些為你指明前進道路的供應商和合作伙伴。

如有相關問題，請在文章后面給小編留言，小編安排作者第一時間和您聯系，為您答疑解惑。

原文地址：https://www.trek10.com/blog/ten-commandments-for-cloud-decision-makers