世界各地的開發者正在經歷着迄今爲止最大的軟件變革：從單體、單節點的應用程序遷移到運行在分佈式系統上的基於微服務的雲原生應用程序。
Lightbend最近完成了一項對1000多名者和其他IT決策者的調查，揭示了企業在這一轉變過程中面臨的挑戰以及如何應對這些挑戰。作爲一名開發人員或軟件工程師，你可以從這項研究瞭解到一些有用的東西。
別忘了爲什麼要採用雲原生技術
你很容易陷入這樣一個困境：你想搞明白在使用什麼技術，以至於你忘記了當初爲什麼要使用它們。但請記住，採用雲基礎設施——無論是自己數據中心的Kubernetes集羣，還是公共雲中的無服務器API——不是目標。目標是幫助組織構建更具可伸縮性和靈活性的應用程序，並更快地完成構建。如果你在構建應用程序時沒有真正考慮雲基礎設施的優缺點，那麼很有可能沒有真正實現組織的目標。
設計雲原生應用程序來處理無響應或損壞的組件
節點崩潰。網絡故障。遠程API會產生意外的結果。雲原生開發需要你“優雅”地處理這些問題。應用程序需要給用戶某種響應，即使一個或多個組件損壞或無響應。你還需要考慮一旦損壞或不可用的組件再次工作時如何恢復。
別忘了安全性和法規遵從性
雲原生應用程序面臨獨特的合規性和安全挑戰。接受調查的高管們一再表示，他們希望開發者能在這些問題上多加考慮。早期將安全和合規團隊引入開發過程並願意投入工作以瞭解其行業的安全性和合規性要求的開發人員不僅會在工作場所取得領先，也可以通過避免在開發週期中進一步重構特性或整個應用程序，提高團隊的工作效率。
一定要儘快找到可以轉移到微服務或無服務器的功能
雲原生開發不是一個全有或全無的命題。你不必一次扔掉所有的單體。你可以構建面向微服務的試點應用程序，同時查看所有現有的單體應用程序，並考慮哪些功能可以中斷。跨多個應用程序共享的功能，如支付處理，是一個不錯的選擇。CPU密集型特性也會降低整個應用程序的速度。鏡像轉換是一個典型的例子，它可能最好在功能即服務（FaaS）平臺上單獨運行。FaaS不會強迫用戶等待應用程序調整上傳的一些鏡像的大小，而是可以在應用程序的其餘部分繼續運行時處理該任務。
不要以爲更可配置或更便攜的解決方案是“殺手鐗”
依賴於那些給開發者提供了很多選擇並且在雲端之間完全可移植的框架是很誘人的。但更多的選擇和控制也意味着更復雜和更大的維護責任。這樣做的結果是，你需要做更多的工作，從而將精力集中在構建提供業務價值的功能上的時間更少。當然，依賴雲提供商的特殊功能會降低應用程序的可移植性。但是，如果你沒有利用這些提供商提供的資源，你真的從雲計算中獲得了全部價值嗎？有時候，最好犧牲一點控制權來換取靈活性和更專注於重要事情的能力。
確定組織可以接受哪些權衡
構建雲原生應用程序需要權衡。你需要了解這些權衡，並明確哪些是可以犧牲的，哪些是不能的。這通常意味着要與管理團隊溝通，確保技術目標與管理目標一致。
結論
向雲原生環境的巨大轉變會要求你放棄許多您熟悉的東西，從架構到開發流程再到框架。這也意味着放棄對應用程序部分的控制。但是，這種改變也會讓你解脫，當你專注於更高層次的功能時，你會從開發的苦差事中解脫出來。這種遷移意味着把更多的精力放在感興趣的事情上。
原文鏈接：
6 Cloud Native Do’s and Don’ts for Developers – The New Stack
