雲原生正規化轉變您準備好了嗎？

雲原生正規化轉變：您準備好了嗎？

the cloud native paradigm shift: are you ready?

雲原生正規化轉變：您準備好了嗎？

2023年4月3日由皮尼列茲尼克 - 4分鐘的讀出時間

在container solutions，當我們說我們要幫助公司將自己轉變為cloud native實體時，我們出於特定原因使用該術語。cloud native是一項重大的正規化轉變，不僅僅是將最新的新技術固定在公司多年來一直在做的事情上。

上一次真正的正規化轉變是敏捷，它發生於20年前，但尚未結束。很少有人真正在做純粹的敏捷，儘管許多組織都這樣認為。大多數人並不真正了解敏捷-並且絕對不練習敏捷。儘管如此，許多人至少已經適應了一些敏捷工具，因此將自己視為敏捷。

更大的擔憂是人們普遍認為cloud native僅是敏捷的增量階段，就像下一步一樣。但這既不真實，也有潛在危險。cn不是敏捷的一些向前迭代。這是真正的正規化轉變。它是敏捷的替代品。

為什麼這麼重要？對於我們來說，這是我們在進行cloud native準備情況評估時發現的。這意味著，實際上，在這樣的組織中進行成熟度評估時，我們需要意識到這一點。

真實示例：一位客戶，具有敏捷傾向的瀑布（衝刺和scrum大師）打**給我們，請教他們的雲遷移。他們接受了我們的分析和反饋，並編寫了乙份長達80頁的報告，花了四個月的時間將其彙總在一起。如果您有80頁的圖表和文件，那麼您就不會敏捷。在cn中，如果您給我們四個月的時間，我們可以交付整個系統。

在決定遷移到cn時，應該在所有方面重新考慮您所做的一切。從文化到技術。假設您做的每件事都是錯誤的，並問自己如何改進。可以想象，這種「您需要改變一切」的資訊，對於客戶來說是非常驚人的。但這是正確的道路。

對於任何希望進行cloud native轉型的公司來說，核心問題是他們根本不知道自己不知道的事情【出自：達克效應】。

可怕但必經之路

對於傳統的瀑布式公司而言，這尤其具有挑戰性。在他們的**方法中，可以理解事情的運作方式。例如，召集一名工程師來估算為其產品製作iphone應用程式需要多長時間。工程師說，三個月，他們的經理加倍或增加三倍，以考慮其他因素並得出切合實際的時間表。但這是線性推論，每個人都理解其中涉及的步驟。

但是，在cloud native轉換的情況下，工程師沒有估算依據。他們沒有技術經驗，因此只能做出最佳猜測-由於分布式系統固有的指數級困難和複雜性，這是完全錯誤的。他們說乙個星期，事實證明是一年。

同樣，他們的經理聽見了三個星期的估計，進行了通常的推斷，並提出了三個月的建議。。。但實際上已經三年了。只有他們無法知道這一點，也無法理解為什麼會這樣。他們不知道他們不知道的東西。

接下來發生的是，經理很快就用光了預算和耐心。典型的企業要耐心一到兩年；我們最好，最支援雲的客戶需要一年的時間進行遷移。大多數公司需要更長的時間。

真實示例：我們曾經有乙個客戶端，該客戶端安裝了openshift（容器應用程式平台），並且在測試中執行了乙個應用程式。基於這一成功經驗，他們決定「確定，現在我們將在接下來的三周內加入10個團隊。我們已經準備好完全使用cloud native！」

這是基於他們以前總是做事的方式，在這種情況下，這是乙個可以理解的決定。但是，他們所做的是在他們一直使用的同一系統之上安裝了一堆昂貴的複雜工具。是的，他們將擁有kubernetes-但它們仍將每六個月部署一次。

我們需要更深入的了解，儘管這是向前邁進的一步，但實際上是相反的。當我們觀察最終為公司帶來的價值時，實際上是負面的。

沒錯，您可以指出擁有容器化微服務，並相信這使您成為cloud native公司。但是，實際上，您剛剛花了很多錢並投入了很多任務作-但您並沒有變得更快或更便宜。

典型的cloud native轉換方案

既然我們能夠識別一些常見的cn轉換情況，那麼我們在container solutions進行cloud native的時間已經足夠長了。這些場景可能在細節上有所不同，但在結構和**上卻極為相似，我們在評估企業時經常會發現這些場景。對於全新的遷移計畫，或者更經常的是，被要求找出導致該計畫出錯的原因。

這篇文章是我們研究各種頻繁發生的轉換方案，它們的外觀，發生的原因以及解決方案的幾種方法之一。這些情況和解決方案也可以在我們即將出版的o'reilly書中找到，「雲原生轉換：實用的創新模式」。

雲原生正規化轉變 您準備好了嗎？