-
Azure Labs: Mixed-OS Docker Swarm
接下來就玩大一點，前一篇都講到，既然將來 container 會是 software 統一的發行途徑了, 那麼只有 windows 怎麼夠用? 延續前面的 labs environment, 我們就接著把 linux 加進來吧~
其實，去年在寫這篇 架構師觀點: .NET 開發人員該如何看待 Open Source Solutions? 的文章時，我就有這個想法了。文內提到 stackoverflow.com 的架構, 採用個別 domain 最好的 solution, 而不是先被某個 os 或是 framework 限制住選擇。因此 stackoverflow.com 選擇了一個混搭 windows + linux 的架構。
這類架構，在過去的開發環境內，真的是來折磨開發人員的。開發不外乎要建立測試環境，想想看你有辦法很容易地在你的 PC 建立一個同樣的 架構嗎? Sure.. 弄個 VM 當然沒問題，只是要讓每個人都能很快地架起來，他的門檻實在不低啊，再加上裡面的服務都要 update to date, 就更 吃團隊的開發流程與 CI/CD 是否確實了。如果你的環境都已經容器化, 那剩下的就是找個能同時丟 linux 及 windows container 進去執行的環境了。
這願景已經可以實現一半了 :D，較正式的部署 (例如開發團隊共用的 DEV environment, 或是 Production environment), 可以建立一個 Mixed-OS docker swarm, 也就是本篇 labs 要介紹的。另一個就是等 Microsoft 在今年 dockercon 2017 宣布的下一個年度更新 Microsoft to allow Linux containers to run on Windows Server 釋出之後，你就 可以在自己的開發機，用 docker-compose 一次就把整個開發環境建立起來，不論背後是跑 windows or linux。
不論如何，這一切都是以 container 為核心架構的，現在投資這技術永遠不嫌晚，看下去就對了!
-
Azure Labs: Windows Container Swarm
Azure 上面的 container 相關服務越來越完整了, 完整到我都快找不到理由自己架設了 @@, 從 registry 有 Azure Container Registry 可以，Orchestration 有 Azure Container Service 可用之外 (支援 swarm, dc/os, kubernetes), WebAPP 也開始支援直接部署 container,加上前兩天 preview 的 Azure Container Instance (把 container 當作超高效率的 vm 看待會比較好懂, 你自己準備 image 就可以丟上去跑)…
不過 windows container 的支援總是慢半拍啊.. (敲碗), 加上我有些 Scenario 不得不再 intranet 架設這些環境, 因此還是硬著頭皮花了點時間研究 windows container + swarm mode.. 大部分的文章都是跟你講 linux container, 針對 windows container 的沒幾篇，中文的就更不用講了，我只好野人獻曝的貢獻這篇..
這篇交代兩個部分: 一是 windows container + swarm mode 的部署經驗。為了強調重點在於 swarm mode 的運用, 我選擇在 Azure 上面建置， 可以省去很多 OS 安裝設定的問題。另一部分就是 windows container 總是慢半拍, 先期導入的人 (對，就是我) 總是有些地雷要踩，後半部就是 分享一些目前還有陷阱的地方，讓現在就需要使用 windows container 的朋友們可以少走一點冤枉路。
其實這些服務，花個兩分鐘填一下資料，ACS (Azure Container Services) 就通通幫你搞定了啊，不過 ACS 對 windows container 的支援還在 preview, 我只好自己來土炮了。不過得力於 Azure 實在太方便，其實自己土炮一個 Windows Container Swarm Mode 的 Cluster 也只是五分鐘的事情啊! 要等下一篇文章出來再寫，大概又是一個月過去了，於是我就順手先把這篇紀錄一下，想在 Azure 上面體驗 Windows Container Cluster 的可以先參考這篇~
-
架構師觀點 - 轉移到微服務架構的經驗分享 (Part 3)
前面兩篇，分別介紹了微服務架構的規劃方向，還有實際切割的案例探討。這篇 (Part 3) 的重點就要擺在微服務到底該在甚麼樣的基礎建設上面 運行? 維運過去單體式架構的 application, 所需要的基礎建設，會跟微服務架構下可能會有數十個 service instances 同時執行，甚至上百個 service instances 一樣嗎?
我只能說，考量完全不一樣!! 微服務架構簡化了服務本身的複雜度 (每個服務變小了，責任也變單一)，但是整體的 application 並沒有變簡單啊， 因此複雜度都轉移到服務與服務之間。因此要能妥善管理及維護好眾多的服務 instances 能彼此順利的合作，是個不小的挑戰。這邊最主要的關鍵， 就在於底層的基礎建設了! 這篇就花點篇幅來聊聊這個部分: 微服務架構的基礎建設與部署。
-
容器化的微服務開發 #1, IP查詢架構與開發範例
總算把包含架構與觀念的實際案例篇寫完了，前面也寫完了微服務化一定會面臨的 API 開發設計問題，那接下來可以開始 進入有趣一點的部分了。微服務架構是由很多獨立的小型服務組合而成的，這次我們直接來看看每一個服務本身應該怎麼開發。
- 這張圖真是百搭啊…
這篇既然要講到實作，那就不能不提讓微服務可以實現的容器技術。我一直覺得很可惜的是，不管國內或國外的文章，以開發者的 角度來介紹容器技術的案例實在不多啊 (還是我關鍵字下的不對? @@) 過去的觀念裡面，都是強調 container 有多好用，但是 看來看去都是把現有的 apps 重新用 container 打包及部署。DockerCon 2017 正式介紹了 LinuxKit, Microsoft 也宣布了 Windows Container 要開始支援 Linux container 等等…，我想不用多久就是 container 滿天飛了。到時你還 只是 在考慮 containerize (容器化) 而已嗎? 如果你的服務將來註定要在 container 環境下執行，在開發的當下，你會如何設計你的軟體架構?
介紹 docker 的文章，很少是以 pure developer 角度在寫得，如果領域換到 windows container + .net developer 就更少了。我從小就是靠 Microsoft Solution 吃飯長大的，C# 我也從當年還是 Visual J# 的年代，一路到 .NET framework 1.0 就 開始用到現在，既然 Windows Container 也都問世了，那這篇文章的示範內容，我就用 Windows Container + .NET Framework + Azure 來做吧!
Container Driven Development (我自己亂掰的名詞，不過竟然還 google 的到東西 @@) 就是我這篇想寫的概念，從 container 的 角度來思考你的 application 該怎麼設計。其實方針前面這幾篇微服務的文章都講過了。這篇就直接看我如何用這樣的思維來規劃 開發架構吧。我這次挑選的主題，是前陣子我實際上碰到的 case: 用 IP 查詢來源國家的服務。
這功能很符合微服務的定義: “小巧，專心做好某一件事”，剛好前陣子 Darkthread 也寫了一篇 “用 100 行 C# 打造 IP 所屬國家快速查詢功能“，我就沿用 Darkthread 貢獻的 Source Code, 把它包裝成微服務，用容器化的方式部署到 Azure !
-
架構師觀點 - 轉移到微服務架構的經驗分享 (Part 2)
前情提要: (Part 1)
補上欠很久的第二篇~
上一篇聊了進入微服務架構前，架構師本身的心理建設、為何要用微服務的原因，以及導入這些美好的架構背後的代價。 這篇開始拿我過去負責過的實際案例，來聊聊我如何把典型的商用大型軟體 (單體式架構)，逐步調整為微服務架構的過程跟決策。
先寫在前面，如果你想看的是現在大型的雲端服務，如何用微服務架構落實的 (例如 Netflex 等等)，那這篇可能不是你有興趣的。 這篇講的案例，比較是台灣大部分軟體公司會面臨的狀況，過去發展很久的傳統企業應用程式 (通常是 ASP.NET + MS-SQL)，架構 較講究的會有三層式架構，有的甚至只有兩層 (WEB + DB) 而已。隨著時間的發展，功能不斷的增加，軟體越來越複雜，但是架構上 卻沒有太大的變化。
這樣發展了幾年下來，大概都已經面臨到維護的成本跟難度已經到達瓶頸的階段了吧! 這時會採用微服務架構的動機，就跟大型雲端 服務採用微服務架構的理由不同了。主要動機都會再改善既有問題為主。這篇講的就是我過去處理過的這類案例。所以也請各位先有 心理準備，這篇的內容並非完全按照典型的微服務的路線發展，我自己為這套系統的狀況做了些調整與取捨，寫這篇單純分享經驗而已~
看到這邊，準備好了就請繼續往下捲，本文開始~ :D
