編程語言從最初的0101機器碼到彙編語言再到面向對象的編程，不斷的發展，整個發展趨勢呈現高內聚、低耦合、可重用、可理解的特點。最早編程是用機器碼，人的大腦不像電腦，無法處理0101；後來彙編語言還是太費解，又出現了高級語言；然後因為我們需要更加接近人類語言的方式描述問題，開始出現結構化編程或者模塊化 ...
編程語言從最初的0101機器碼到彙編語言再到面向對象的編程，不斷的發展，整個發展趨勢呈現高內聚、低耦合、可重用、可理解的特點。最早編程是用機器碼，人的大腦不像電腦，無法處理0101；後來彙編語言還是太費解，又出現了高級語言；然後因為我們需要更加接近人類語言的方式描述問題，開始出現結構化編程或者模塊化編程的方式；但我們要面對的問題還是太複雜，所以就需要把他切割成小問題，即模塊化；模塊化出現之後，我們又開始追求高內聚低耦合，因人腦仍然沒有辦法思考太多的模塊之間錯綜複雜的關係，所以需要高內聚低耦合，分層次的看待這些問題；但就算把這些功能都充分的去模塊化、高內聚低耦合，發現數據流還是太複雜了，所以需要把數據也給高內聚低耦合，這個時候我們開始去做面向對象的編程，當面向一個對象的時候編程就會比較高效。面向對象就是幫助我們把數據對數據的操作分裝到模塊裡面，同時提供新的思考問題的方式，這樣子我們本來只是比較簡單的大腦，居然一下子就可以駕馭非常複雜的業務邏輯，做很龐大的軟體系統。
目前我們發展出了23種設計模式，發展出CS、BS、MVC、MVP各種各樣神奇的架構模式之後，開始用這些概念“吵架”，或者做成面試題。整個發展的路線很明顯的趨勢是：不斷地追求更好的高內聚低耦合。相信可預見的未來仍然會繼續去尋找更好的一個高內聚低耦合的編程模式，我們總是在追求更好的可重用性，儘量地減少重覆的工作。近幾年大家都在討論的微服務，微服務面對系統的時候，能不能用很多重覆自治的子系統來完成。這些子系統應該可以獨立於大系統獨立存在，每一個子系統應該可以管理好自己、保證自己是健壯的、可處理好異常情況、面對壓力時候擴容負載均衡、沒有壓力時應該縮容。同時子系統無需擔心被用，被越多的使用方使用，越說明該子系統有很好的可重用性，使用量越大越說明可能會產生規模效應，那就可用更低的平均成本來提供更好的服務。
討論微服務時，之前我們僅僅是在討論一個系統怎麼被拆成幾個微服務，然後再用新形式來做新的系統。但這樣做與以前做的模塊化編程毫無區別。在雲時代基於微服務的設計理念開發軟體，首先要考慮的是有沒有一個現成優秀的雲服務可以作為一個系統需要的微服務，直接可用，比如圖片上傳、下載、裁剪、縮放等功能；如果沒有，那系統需要的服務，把它開發出來有沒有可能變成一個通用的服務，然後開放出去，這樣的話除了有可能去交付系統之外，還可能通過售賣我的微服務獲利。
軟體開發歷史上走過了結構化、面向對象，還有各種各樣的開發模式，這些所有的發展模式共同的發展方向是越來越高的高內聚低耦合，越來越好的可重用性，越來越容易被我們的大腦理解。在雲時代，微服務是符合這三個大方向的全新軟體開發模式。
雲時代的雲服務公司，它們的核心業務和麵臨的問題就是今天這些純粹的技術問題，除了要能夠解決並封裝成服務，還需要不斷的降低成本和優化效率，而在雲上的降低成本和優化效率這是真正意義上的技術價值的直接體現。亞瑪遜能夠連續 降價來阻止競爭對手進入，正是技術綜合實力的體現，未來必然只有少數雲服務公司能夠把提供服務的成本控制在自由市場競爭的價格之下。
雲時代我們需要採用新平臺來革新我們的軟體開發模式，作為一個走過16年曆史的.NET, 在2014年順應時代要求自我刷新，推出的開源跨平臺的.NET Core, 就是為雲原生應用的開發而準備的平臺，.NET Core相較於他的哥哥.NET的優勢也正是我們很容易的使用C# 語言去構建高內聚低耦合的系統。藉助於K8S，service fabric, 我們很容易構建一個.NET Core的服務。最近結合.NET Core和k8s 容器服務在騰訊雲上製作了一個教程 《.NET 微服務實戰 — 微信公眾號開發（ https://cloud.tencent.com/developer/edu/major-100017）》，教程里例子-公眾號開發雖然簡單，我只是使用這個簡單例子來闡述一個簡單的問題，雲時代的.NET 是怎麼樣的，我們要怎麼樣使用.NET Core。
