數字化轉型浪潮滾滾而來，越來越多的企業開始擁抱雲原生。根據雲原生計算基金會（CNCF）最新調查顯示，雲原生技術如今已無處不在。
與此同時，容器也已成為常态，在2019年，有高達84%公司應用容器技術，而在2016年初次調查時僅為23%，增長可謂神速。其中有78%的受訪者使用K8s來管理容器。
源于一個樸素的想法
早在2016年起，K8s便開始嶄露頭角，并逐漸在行業中獲得重視。K8s确實解決了計算平台上一些現實問題，但在Developer層面還不夠友好，即在K8s上開發，不僅要了解K8s的概念和它的API，還要對其各種工作方式了解。
微軟首席程式員白海石
這引起了一位有着長達33年程式設計經驗的資深程式員的重視，他就是微軟的首席程式員白海石。
據白海石介紹，當時的想法非常樸素，即能不能建立一個和平台無關的應用程式的設計語言，讓開發者在設計應用程式時，不必過多關注底層基礎架構，轉而專注于應用程式的拓撲結構。OAM「Open Application Model」由此誕生。
在後來讨論OAM的過程中，白海石的一位以色列同僚Yaron Schneider希望更進一步，設計一個新的程式設計模式，将分布式系統常見的功能封裝成一個邊車「sidecar」，通過http或gRPC暴露給開發者。就這樣，DAPR「Distributed Application Runtime」也誕生了。
與過去分布式系統的思路相比，DAPR有很多不同：
首先，該設計沒有侵入性，因為應用程式本身不需要引用任何DAPR的程式庫，也不需要與DAPR相關的任何東西，所有都是基于标準的http邊車的端口進行調用；
其次，其設計理念可以讓開發者選擇性的使用DAPR的全部或部分功能，并不強制使用者從頭到尾必須采用DAPR提供的全部功能，嚴格按照其程式設計模式來設計程式；
最後，DAPR支援各種程式設計語言，隻要通過http或gRPC進行交流，所有現代語言均可使用DAPR。
OAM和DAPR都是針對開發者設計的，他們位于一個分布式系統中的兩個不同層面。OAM在更高層，用來描述應用程式整體的拓撲結構，而DAPR更進一步，用于解釋每一個部件内部是如何實施的。
OAM應用模型
OAM與DAPR的宗旨是要為開發者，特别是企業級的開發者，在設計和實施分布式系統時提供一些幫助。随着企業數字化轉型程序的發展，很多傳統企業也開始将應用程式向雲中遷移，而這過程實際上還是非常複雜，而通過OAM和DAPR這種比較簡單的應用程式模式和程式設計模式，為開發者提供一些便利，助其在雲上高效開發。
開源是一個很自然的選擇
OAM和DAPR已經開源。白海石認為，這兩個項目的開源是一個很自然的選擇，因為要做一款通用的應用模型和分布式系統的程式設計模式，離不開社群的支援。其設計理念、具體實施，都需要經過社群來驗證，在社群的共同努力下，讓項目朝着開發者更友好的方向發展。
而過去傳統的産品管道，在半封閉的情況下，從開始到相對完整的版本，再推到社群，基于使用者的回報，再進行下一次疊代。這樣的話，更新速度太慢，同時也不能同步考慮社群的不同需求和意見，多少有些後知後覺。
而通過開源的方式，一開始便與社群一起工作，能夠讓系統在架構上、功能上，更貼近最終産品想要達到的廣泛應用，是以這兩個項目的開源，是一個極度自然的選擇。
目前，這兩個項目的進展都很順利，DAPR如今是每三周有一個新的小版本釋出，預計到今年的9月份，會推出1.0版本；OAM稍微慢一些，因為它要設計應用程式模式，其中還存在很多的不同意見，需要不斷進行讨論。目前已經釋出了Alpha 1版本，Alpha 2近幾周也會釋出，下一個目标是Alpha 3，更長遠的一些目标還在讨論中。
在OAM層面，阿裡巴巴是非常重要的合作夥伴，不僅在規範制定本身，包括背景的實施，都提供了非常多的力量來支援。此外，還有其他合作夥伴，在OAM合作中是非常融洽的，整個過程都是非常平等、融洽的進行，有問題大家共同修補。當然，也有很多激烈的争論，但這對項目發展都是健康的，旨在将項目做得更好。
另據白海石介紹，OAM和DAPR這兩個開源項目在社群中接受程度都很好，特别是DAPR，在很短的時間内就達到了5K Star，其内部還做了一個圖譜來跟蹤DAPR Star增長情況，其增長是直線上升的，開發者的反響超出了預期。
簡化K8s開發，支援在雲與邊緣中自由切換
DAPR的設計理念就是為了給開發者提供便利。在寫分布式系統時，通常将開發者需要完成的任務封裝成DAPR的功能，暴露給開發者。例如DAPR提供狀态管理、服務發展、消息收發、釋出與訂閱、安全資訊管理等，目前提供的功能是分布式開發者需要做的事情，其目的就是希望通過簡單的API，将這些功能暴露給開發者，進而高效開發。
此外，開發者并不需要局限于DAPR中，以狀态管理為例，是以鍵值對的方式存儲或讀取狀态，僅需一個鍵值和要存儲的資料，即能完成資料的存取。該功能看似簡單，實際封裝了一些典型的資料行為，進行實作一些比較安全的分布式代碼。
同時，在後面的資料源中加入了自動重試，比如連接配接失敗會重試，在内部加入了自動的版本管理和并發控制。在預設的情況下，即便開發者不太了解分布式程式設計，也能書寫出比較可靠的分布式代碼。如果，開發者對分布式狀态管理有一定了解，想要采用更進階的線程處理方式或并發形式，DAPR也是允許的。
由于K8s的流行性，很多情況下需要将應用程式運作在邊緣K8s的Class上，這是因為K8s提供高可用、濃縮轉移、水準縮放，這在雲上和邊緣上都是需要的。DAPR雖不依賴K8s運作，但能夠完美支援K8s，使得應用能夠在雲計算和邊緣計算兩種不同的平台中運作。
對于一些低能力的裝置，無法運作K8s或Container。由于DAPR本身支援松散程序的運作方式，即DAPR能夠單獨做一個程序，不需要依賴K8s或Docker，使得DAPR能在更低能力的裝置商，運作同樣的程式設計能力。
值得注意的是，很多邊緣計算的方案都有邊緣和雲的部分，如何将邊緣和雲協同起來非常關鍵。而DAPR提供了從邊緣到雲比較統一的程式設計模式，即使未來需要在邊緣和雲之間部署方式和位置進行調整，也能靈活的在邊緣與雲之間自由切換。
未來的一些思考
OAM和DAPR這兩個開源項目，目前還處于早期的快速發展階段，雖然已經在部分企業中得到運用，但未來還有很長的路要走，在這裡，白海石也提出了一些思考。
OAM從Alpha 1到Alpha 2過程中将進行一次重構。因為在Alpha 1中，其資源的排程與管理是合在一起的，在Alpha 2版本中将會分開，通過一個比較抽象的資源排程，連接配接不同的平台，對平台資源進行管理。
例如，可以将同一套OAM應用程式，既能連接配接阿裡雲也能連接配接Azure。對OAM而言，這是兩個不同平台的選擇，但對OAM本身工作調動邏輯或工作描述的方式是不變的，使得OAM支援多雲平台。
此外，OAM團隊也在考慮，如何實施一個專門為邊緣計算開發的平台，即一個應用程式可以釋出在雲上，也可以釋出在邊緣計算上。
DAPR也有幾個方向：首先，希望它更輕量化，目前DAPR本身很輕量，隻有50多M，運作時僅需4M記憶體，在當下的計算環境中非常輕量。但DAPR團隊希望做的更輕量，以便能在更小的裝置中運作。
另外一點，希望開放DAPR的自定制功能。實際上，DAPR是将分布式系統常用的功能封裝成邊車的方式暴露給開發者，但這些常用功能都是DAPR團隊想到自定義的，如狀态管理、消息收發等。未來，這部分是不是可以開放出來，特别是機器學習的模式，例如開發者訓練了一個機器學習的模型，他可以通過DAPR将它封裝成一個功能型邊車，釋出給其他開發者，這個應用場景将來會很多，非常值得期待。
One more thing
至此，此次的采訪已經接近尾聲。但近年來微軟有了一個非常明顯的變化，即擁抱開源。在此，白海石也解讀了微軟為什麼要擁抱開源。
白海石認為，主要有三個方面：第一，從雲計算發展的現實角度看，無論雲中運作的是微軟還是第三方的産品，最終消耗的還是雲平台的計算資源。是以，擁抱開源，就是擁抱各種工作方式、各種工作流、各種系統，都能遷移上雲，這對Azure的發展大有裨益。
第二，從Satya Nadella上司層文化的轉變，自上任伊始，便喊出Microsoft愛Linux，進而帶動微軟在開源領域不斷開拓創新，在開源領域不斷貢獻力量。
第三，在軟體行業，所有企業、機構、組織都在擁抱開源，可以說這是一種發展趨勢，這也将融入微軟年輕一代的文化之中。
作為一位有着33年程式設計經驗的資深程式員，對于開發者們普遍面臨的焦慮問題，白海石有着自己的體會。他表示，作為一名程式員，最重要的還是喜歡這個行業，這份工作很多情況下是枯燥和寂寞的，但如果喜歡的話，一旦從中鑽研出對世界有幫助的東西，這是非常鼓舞人心的。隻有對事業本身的熱愛，才能吃的下苦，做出有意思的事。
值得所有人學習的是，白海石常年堅持技術内容輸出，至今已經出版了8本雲計算方面的書籍。另外還有兩本已經進入寫作程序，一本是關于DAPR的，另外一本是講邊緣計算的。白海石認為，分享知識是一個很自然的事情，這或許和他的家庭環境有關，他出生在一個教師世家，從小便耳濡目染，希望不斷學習，并将學習成果分享給更多人。同時，白海石在美國的偏遠地區支教，如今已是第四年。他也呼籲，所有人都應該盡量學習，盡量分享。