
繼 Meetup #3 之後，很快的兩個月多的時間過去，DevOps Taiwan 在 2017/02/22 晚上舉辦了第四次的 Meetup。
感謝極客窩 (Geek Cave) 贊助場地，感謝安德魯前輩為本次 Meetup 準備的豐富內容，感謝志工群的幫忙。最後同樣也感謝社群朋友不畏風雨的熱情參與！
就以此文簡短紀錄一下本次活動的林林總總。 （封面背景圖片來源 https://unsplash.com/photos/-K6JMRMj4x4）
籌備
打從 Meetup #3 結束之後，時間約在 2016 年 12 月左右，志工們就默默在籌備 Meetup #4，首先苦惱的當然是「主題為何」。在與 DevOps 相關的眾多關鍵字中，這一次要選哪一個來當作主題呢？
很巧的就在此時，剛好注意到安德魯前輩已經撰寫了數篇關於「Microservies 微服務」的中文文章。於是抱持著一股既期待又怕受傷害的心情，直接的就向前輩發出邀約。結果意外的立即就獲得了前輩的正面回應，願意替社群分享主題。
有鑒於前幾次的 Meetup，志工們一直在思考與嘗試希望在活動舉辦上能有所變化，例如上次 Meetup #3 的 CM 大亂鬥，一次湊齊四種工具的講者，並且來了一場綜合座談，就是一個不錯的嘗試，那麼這一次我們又能試試什麼不一樣的做法呢？
不過很可惜的是，雖然有這樣的熱情，但在實務上這次籌備過程並沒激發出特別的想法，最後決定先維持一般做法，以講題分享為主。同時因為安德魯前輩表示可能無法準時到場，所以原訂希望能再湊一位講者，安排在主持人開場之後，先來一場約 15 ~ 20 分鐘與微服務有關的 Lightning Talk，但最終沒能找到合適的講者，故這個計畫也只能因此作罷。
最後活動前面的 20 分鐘到底該做什麼好呢？個人提議不如就設計一個簡單的暖場活動吧？有鑒於這一兩年參加社群活動的經驗，以及參與了不少次 Agile 社群的活動，深深覺得「社群」真正的價值是建立在「人與人的互動」之上，如果社群沒有了交流與互動，那實在是非常可惜的事情。於是前 20 分鐘就定調為「強迫互動的秘密暖場活動」，剩下就等活動日子來到了。
現在回想其實有許多需要檢討的地方，不過這些檢討與反省，就全部留在最後一個段落一起記錄了。
講題分享
這次很榮幸能邀請到 Andrew Wu 一宇數位技術長 & 技術發展顧問為我們分享「Microservies 微服務」 的經驗分享，從講者的個人經歷與部落格文章中可以很清楚地知道是一位在這個產業有著扎實經驗的前輩，同時也是一位對於社群與後輩抱有熱切的教育之心的前輩。
為什麼會特別提到「教育之心」這件事情呢？就以這次 Meetup 分享的內容來說，安德魯前輩特別將「一窩蜂驅動開發」的局部內容放在簡報之中，當然一方面是因為文章內有提到 Microservices，另一方面則是他深深認同文章的觀點，所以除了借用文章當梗呼應簡報內容，也更是為了推廣正確的「開發觀念」，不要成為「一窩蜂開發者」。
講者的簡報「大型 Web Application 轉移到 微服務的經驗分享」已經釋出，可以前往 SlideShare 上觀看。
在這場分享中，講者首先為我們說明「什麼是微服務」。定義的部分沒有細談太多，一方面因為「微服務」也沒有標準定義，只有一些普遍接受的原則與特性，而且談到「微服務」，大家真正再談的全名應該是 Microservices Architecture，關鍵在於這是一種 Architecture。既然是 Architecture 在實際應用時，就不太可能會每個人應用起來都完全相同，多少會有因地制宜之處。與其太過於在定義上糾結，不如多瞭解一下那些被普遍接受的原則與特性，瞭解別人是基於什麼背景、環境與情境而選擇採用 Microservices Architecture。
若是想要深入了解 Microservices，目前已經有一本重量級的著作來自 ThoughtWorks 的 Sam Newman 所撰寫的《Building Microservices》。目前也已經有中文版《建構微服務》，不過安德魯前輩似乎比較建議大家讀英文版，吸收新知有時還是要回到第一手資料比較好。
談到「微服務」避不了要談怎麼「切分」服務，以及服務應該要切分為「多大多小」。而在思考切分與應用 Microservices Architecture 時，其中重要的一環是軟體開發與架構的重要觀念「解耦合」及「單一責任原則」。
整場分享聽下來，我覺得安德魯前輩一直在強調不要「為了微服務而微服務」，而是根據你實際的需要作出適當的重構，這個重構可以是基礎架構層面也可以是軟體架構層面。這也是為何簡報內容會提到「一窩蜂驅動開發」，「微服務」這個關鍵字很炫很潮，但是它不一定對你有幫助，在被關鍵字沖昏頭打算全力投入之前，不如先做一點小實驗、小嘗試。
同時也不要想要一步到位，而是先把一些基礎功夫做足，例如要知道微服務架構先天就是一種分散式系統，那麼你的軟體架構夠彈性嗎？你的開發流程夠彈性嗎？CI、CD、DevOps 這些基礎功做得如何啦？或者你對於 Service Discovery 或其他相關技術的掌握度如何？要知道微服務用得好不好與你有沒有能力管理又多又小又複雜的「東西」有關。
又或者在真正將功能解構成 services 放進一個又一個 Docker Container 之前，要不要先不這麼衝動，先在軟體層面試試？先解構成一個又一個 Share Codes (concepts)、Share Library (binaries) 或是 Component。倘若這樣施行也沒問題，再進一步考慮切分成 Service？搞不好再切成 Component 的時候，你就覺得做到這個程度已經足夠了，也不一定。
在整場的分享中，安德魯前輩還補充了許多他們自己的經驗談，以及為何他覺得 Docker（Container）是最佳的微服務部署技術，諸多細節就不一一紀錄了。
意見回饋及活動檢討
這次一般票開放 60 張，同樣開放搶票之後立即被社群朋友搶光。原本有三位社群朋友獲得「優先搶票權」，但實際使用只有一位，剩下兩個名額也再次釋出為一般票。最後活動當日有三位臨時取消。所以最終一般票共有 59 位。
待用講者票開放 5 張，無人報名，殘念還是殘念，希望下次有講者願意來索取此種票卷。
微服務經驗分享票 5 張，在被我稍稍煽動之下，感謝葉秉哲前輩的響應，索取了一張。同時也邀請了其他的前輩參與本次活動，像是 Docker Taipei 的 Philipz，不過可惜他當晚有其他演講，故無法參與，實在可惜。
總之將上述的票卷加總，不含志工報名人數為 60 名，但實際到場人數為 35 名，本次的報到率約為 58％。
看來未來 Meetup 在無故缺席上，可能需要作出一些調整，不然這麼棒的內容，對於那些真正想聽，卻因為名額被佔據而無法參與的社群朋友實在是感到不好意思。
暖場活動。老實說沒有掌控得很好，一方面沒有事先與志工們建立好默契，因此場面沒能控制得好。另一方面則是受到場地限制的關係，無法按想像中的方式進行。
理想中的環境應該是就地分成四組，然後各組之間有點距離，同時同組人員是可以容易形成面對面交談的狀態，然後各組內自己玩一遍「三句話自我介紹」。自我介紹之後，各組再接著針對「微服務」的相關內容，各組內自行分享與討論，或是單純各組內彼此互相認識新朋友。
但實際場地比想像的壅擠，因此無法讓各組有明顯的間距，同時也無法形成小組面對面的狀態，這造成參與者實際上難形成小組討論，只能與自己左右的人交談。再加上場地的回音很大，因此整個空間都隆隆作響，就更難有效的組成小組。
另外就是其實大家都不是很懂「微服務」，在有經驗者有限（這也是為何會推出「經驗分享票」，因為想要增加有經驗者的人數。）、各組又沒有安插好引導人員的狀況下，也就更難形成討論。
基於以上原因，這也是為何「三句話自我介紹」會臨時改成麥克風傳遞給每個人，讓大家公開自我介紹給所有人的方式，其實就是臨時根據狀況而作出的一些調整。
其實我本來還自掏腰包買了白紙、便利貼與筆要分給各組使用，結果也都作罷放棄。這次是一個很好的經驗，未來在規劃活動時，就知道還要注意這些細節了。
實際參加人數 60 名，截至 2017/2/26 19:00 截止，活動問卷填寫人數為 22，回收率為 36％。
這次忘了找志工專門負責拍照，也忘了最後來一張全體大合照。
這次在活動問卷中故意問了一題「如果不搶票改用抽籤的方式比運氣⋯⋯」，得到的回饋還挺有趣的，這裡就故意賣個關子了。
針對一些活動問卷中的一些重要的意見，這裡也做一些我個人的回覆（僅代表個人意見）：
「不要強迫互動，會想要認識新朋友的人就會主動去認識了。」
同意也不同意，同意的原因是人本來就很多元，有內向、外向及 Ambivert，所以可以理解一定會有不想互動的人，在尊重每位個體的前提下，同意這樣的想法。
至於我個人最近的體悟是，我本來以為我是內向的人，但在經過參與了多次的社群活動之後發現，其實我比較屬於 Ambivert，而這是經過了一段自我覺察的歷程之後才確認的，因此個人覺得有時候給予對象一些不同的刺激並不是什麼壞事。
另外就是個人認為社群必須具備一定的「互動性」，如當晚 Meetup 開場所說的「社群」真正的價值是建立在「人與人的互動」之上，所以這次 Meetup 就是一次小實驗，試試看不同的做法能不能產生不一樣的火花。當然做法上有許多改進的空間，這部分我們會持續改善。
「希望可以舉辦聯誼或者閒聊的活動，讓有興趣的人特地去認識大家」
好意見，志工們已在思考該如何進行，也許會先從咖啡廳小聚開始嘗試舉辦。
「會有devops conf Taiwan 之類的大型活動嗎？」
這個，國內恐怕暫時還是只有 iThome 主辦的 DevOps Summit，我想今年 iThome 應該還是會繼續舉辦。
至於離我們比較近的國家，北京或日本東京都會舉辦 DevOpsDays，也許可以考慮飛過去參加。新加坡目前好像還沒看到 2017 的消息，不知道會不會辦。
「辦一日戰鬥營、實戰篇、實務類講題⋯⋯」
這個只能再次呼籲，歡迎各路高手跳出來當講者喔！
「會前提供（包含在臉書PO的）該主題的基本認識，對會眾非常有幫助」
感謝您的支持，原來 FB 社團上的文章是有人在看的，您知道人有時候會感覺有一點孤單覺得冷。
「還缺志工嗎 ～～～～」
下次 Meetup 來跟其他志工聊聊吧！
「可以提早一點，讓講者時間更充裕，或者有更多Ｑ＆Ａ的時間」
好意見，志工們會在活動規劃上再做出調整。不過夜間時段就是這麼長，這次活動最後幾乎是拖到快十點才結束，要不是這次場地贊助者的偷偷默許，不然本來 21:20 就要趕人散場了喔。
「不適合討論。回音太大。」
感謝您的意見，經過這次的實驗我們也發現了這個問題，針對討論類型的活動我們會尋找更合適的場地，如果您有好的 50 ~ 100 人次的免費場地也歡迎提供參考。
「關於暖場活動、分組⋯⋯」
感謝各位的意見，對於這次的暖場活動尚有自知，知道結果是不成功的，所以各位的回饋意見更是重要啊，除了表達覺得活動辦的不好之外，希望還能給予我們實際的建議做法，讓我們參考一下喔。
再次感謝
本次 Meetup 能成功舉辦真的要感謝的太多了，再次感謝極客窩 (Geek Cave) 、感謝講者安德魯前輩、感謝志工群。
最後再次宣傳
如果對 DevOps Taiwan 社群有任何好的想法，歡迎提供給志工們參考，我們會認真看待大家的回饋，希望能讓社群越辦越好。
如果你有意願擔任講者，歡迎與志工聯繫！如果擔心自己的經驗不足，或覺得有些經驗想要分享，但是卻不知該如何組織出一個完整的題目，沒問題，請與志工們聯繫，我們可以協助你釐清思緒！說一句實在話，除了在台下聽講之外，上台分享經驗也是一種很棒的成長機會，分享對於個人成長絕對是有助益的！
如果貴單位、貴公司有意願贊助 DevOps Taiwan 社群，也歡迎與志工聯繫喔！
