首先祝大家：新年快樂，牛年大吉，牛轉乾坤，一往無前！
2020年的春節，新冠疫情使得全球業務停滯不前，那時候，沒有人知道會發生什麼，因此會議被取消，合同被擱置，專案被推遲，一切似乎都停止了。但是我們卻見證了IT社群所煥發的活力。儘管其他行業還不能恢復正常，各行各業通過IT技術來進行經濟和社會活動，2020年讓我們把數字化轉型向前推進了一大步，很多傳統的企業通過這次數字化的洗禮，雲的技術被更多人所接受，在IT行業中，基於雲原生技術的開發仍在繼續，該領域也出現了一些有趣的技術趨勢，我們一起來看下未來幾年內dotnet 技術在雲原生領域的發展。
在過去幾年裡，一直在被吹捧的新興的微服務風格的應用程式構建，應用程式將大型應用程式分解為較小、相互連線的元件，從而使團隊可以在應用程式的不同部分上獨立工作，而不會互相干擾，但是微服務也會帶來自身的一系列挑戰。更有甚者是有些團隊為了微服務，認定spring cloud就是構建微服務的利器，選擇將dotnet轉向spring cloud搞微服務，結果是微服務也沒搞好，落了個天天996，團隊成員怨聲載道。隨著2020年kubernetes 的進一步普及，dotnet 在容器化方面的優勢的不斷提升，dotnet在kubernetes 這個新時代的安卓系統裡面的優勢越發明顯， 微服務構建也轉向了以Sidecar 模式，這種Sidecar 模式正在以更加迅猛的勢頭將中介軟體領域的能力下沉至 Kubernetes 這個新一代的應用基礎設施當中，除了已經如火如荼的 Istio 對流量治理領域的顛覆，微軟已經不甘示弱的開源了 Open Service Mesh 作為回應。而與此同時， OAM 在微軟的姊妹專案 Dapr 則直接拉齊了 Kubernetes 與中介軟體在“服務發現與繫結”側的距離，老牌專案 Dubbo 亦宣佈了下一代雲原生中介軟體的技術藍圖。當然， 所有這一切背後的使用者動機是非常清晰的：雲原生時代的中介軟體，既要語言無關，也要平臺無關。
在所有問題上，對於任何給定的專案而言，正確的方法都可能介於兩個極端之間（要麼微服務架構，要麼單體架構），微服務的構建在企業軟體設計中正在取得平衡，不會再走向極端，而是接受了微服務的真正內涵，既與語言無關，又與平臺無關，選擇適合自己團隊背景的技術構建雲原生應用，對於dotnet 技術背景的團隊在構建雲原生應用，.NET 5為你提供了很好的技術底座。
儘管Kubernetes主要面向系統運維人員，但它也在如何輕鬆擴充套件和管理分散式應用程式方面引發了一場革命，對於開發人員而言，它仍然是需要跟進學習的一個新時代的分散式作業系統，我們的企業基於kubernetes 構建自己的服務平臺，kubernetes 位於底層， 基於kubernetes開發雲原生應用程式的工作，微軟又一次走到了前面，作為最懂開發者的微軟 偕同阿里雲 推出了開放應用模型 OAM ，OAM 正迅速成為Kubernetes 社群中的事實標準， OAM 在微軟的姊妹專案Dapr 再一次將我們開發雲原生應用的模型呈現在所有社群面前，目前已經發布了1.0-RC3，也許春節後就可以正式釋出1.0.特別對於.NET開發者來說，Dapr 裡面的程式設計模型是很熟悉的，Dapr 所帶來的有狀態的Actor服務，就是來自於.NET開源專案Orleans 的Virtual Actor，還有微軟的開源專案Service Fabric 的Virtual Actor。
雲原生的微服務在任何現代應用程式框架中都越來越重要，因此選擇正確的開發環境和工具至關重要。隨著Dapr接近其1.0版本，它為我們提供了一組構建塊和支援工具，可幫助我們以易於部署和可重複的方式實現關鍵的微服務設計模式。對通用語言的支援和與框架無關的方法確保了花幾天時間評估Dapr是非常值得，大家學起來吧。推薦大家從這幾篇由朱永光 寫的文章開始瞭解：