Athenz 基本運作概念與相關名詞

在 Athenz 權限系統中，有幾個比較重要的基本概念和名詞，簡單記錄一下。不過在那之前，因為 Athenz 的結構幾乎跟 AWS IAM 一樣，所以可以先討論一下 AWS IAM 的運作方式 [1]，再回來看 Athenz 對應的概念。而且其實我覺得 AWS 的文件整體來說寫得比較好 XD。

Athenz 的授權流程

Athenz 是 Yahoo 開源的權限系統 [1]，基於 X.509 Certificate 的架構來提供權限認證的功能。運作上跟 AWS IAM 蠻類似的，是以 Role 為基礎，透過指定某個 Role 對某個 Resource 允許或拒絕某些 Action 來達成授權行為。

plugin execution not covered by lifecycle configuration

公司的 Maven Plugin 在 eclipse 上會跑出標題的錯誤訊息，實際上問題好像是出在 m2e plugin。幾種不同的解法可以參考 [1]。比較完整的做法似乎應該在 dependencyManagement 上追加設定，不過因為在公司裡只有我用 eclipse，其他同事都用 Intellij....所以目前是直接從 eclipse 的 Maven 設定處把這個錯誤忽略掉 XD。

具體來說，就是從 Preferences → Maven → Errors/Warnings → 在 plugin execution not covered by lifecycle configuration 處選擇 “ignore”。

參考資料

1. Maven —— Plugin execution not covered by lifecycle configuration 错误

(書籤) Factory 的比較

參考資料

1. Design Patterns: Factory vs Factory method vs Abstract Factory
2. 白話 Design Pattern (二) Simple Factory, Factory Method
3. Design Pattern 比對(2) Factory Method和 Abstract Factory的異同

繼承（Inheritance）與合成（Composition）

在 Design Pattern 的書裡，大概都會提到「多用合成、少用繼承」，不過具體來說到底繼承會產生什麼問題、合成又能解決什麼問題，一直到現在才有比較明確的感覺。但由於不太擅長描述這種有些抽象的問題，所以這裡就簡單地紀錄一些感覺到的重點，細節就請參閱底下的參考資料吧 XD。

首先，一切的源頭都是為了 OCP（Open-Closed Principle），也就是要盡可能滿足「對擴充開放、對修改封閉」這樣的準則。不過要滿足這個準則，其實會讓程式碼變得複雜，所以在選擇的過程也必須謹慎小心，盡可能只在真正需要的地方去滿足，而不要把這個準則套用到整個系統的每個角落 [1]。

在考量 OCP 的前提之下，由於繼承是屬於在編譯期間的關聯，因此很容易會導致使用繼承時，擴充會需要修改既有的程式碼。這就會導致違反了 OCP 當中的「對修改封閉」的要件。

另外繼承在可能性眾多的情況，也很容易導致子類別的數量爆炸，造成日後維護的困難。

反過來說，合成是屬於在執行期間的關聯，因此較有機會可以避免上述的問題。不過依據狀況的不同，合成也有可能形成子類別較多的現象，雖然不至於到數量爆炸的程度，但往往也會使得 API 變得難以掌握。這類的問題就得複合多種 Design Pattern 來隱藏問題，讓呼叫者不需要對細節有太多的了解。

不過同時也需要注意的是，雖然說概念上提到「少用繼承」，但使用合成其實並不表示完全不使用繼承。關鍵在於「不繼承行為」，但合成常常會需要「繼承型別」（然而這或許只限定在像是 Java 這類強型別的語言上）。

參考資料

1. 深入淺出設計模式
2. 物件導向程式設計：為何說composition優於inheritance？
3. 請問，為什麼要『多用合成，少用繼承』? (java程式語言)
4. 省思物件導向設計 第2回－ 物件導向設計方法面臨的問題 

為什麼需要 CI/CD？

Continuous Integration（持續整合）和 Continuous Delivery（持續發佈），有些時候也會用 DevOps 來稱呼，有在關注技術發展的話就會發現這個詞非常火紅，好像每個人都應該要知道的樣子。不過它可以解決什麼問題呢？

(書籤) git 的 flow

之前曾經稍微看過一點關於版本控管流程的資料，不過沒有很認真在深入了解各種流程的訴求和差異。最近正在努力重新學習 git，所以順帶先暫存一下一些跟流程有關的資料。

然後現在才發現我一直用的流程是 GitHub flow。（遮臉）

參考資料

1. Understanding the GitHub flow
2. GitHub Flow 及 Git Flow 流程使用時機
3. git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度

Shuffle Sharding：AWS 如何最小化 blast radius？

在 AWS 社群看到有趣的研究，在講述 AWS 的架構中如何讓 blast radius（爆炸的影響範圍）最小？或者說當服務節點出問題時，讓受到影響的客戶端影響最小。以客戶端來說，狀況的假設是客戶端發出 request，request 透過某種 Routing 送進後端的服務節點，不過因為某種原因 request 造成了服務節點崩潰。此時客戶端會繼續嘗試重發 request，然後如果 Routing 的機制沒有特別地設計的話，終究客戶端的 request 會一台一台地把所有後端服務節點全部弄掛，導致整個服務中斷。

(書籤) 微服務的管理

微服務在最近幾年蠻盛行的，嗯…或者該說是非常盛行？不過概念上我目前的認知是，它把本來巨大的服務拆解成很多比較小的服務，以達成讓每個比較小的服務容易維護的目的。但同時這會帶來副作用，也就是微服務之間的管理成本會大幅提昇 [1]。實際上這也是很容易想像的事情，因為本來我們認為巨大的服務內部有混亂的互相呼叫的關係（Spaghetti Code [2] 的一種），讓程式碼變得難以維護；而當我們把它拆解成比較小的服務時，各個微服務內就會比較沒有那麼混亂的關係，進而讓每個微服務變得容易維護。但到這裡其實我們根本沒有解決問題！微服務跟微服務之間依然需要互相呼叫，也就是那些所謂的 Spaghetti Code 的關係並沒有被消除，只是被從程式碼內拿到程式碼外而已。所以雖然每個微服務的維運變容易了，但那些混亂又複雜的關係依然存在，而且變成存在於微服務和微服務之間，從程式碼問題變成是架構問題。這點在 [1] 這本書中開頭就有明確地提到，微服務是一種取捨、而不是 silver bullet，它不會解決所有的問題。當我們選擇微服務時，必須同時意識到它將要帶來的缺陷，並且要明確地確認組織能夠處理這個缺陷，才能夠往微服務發展。

在 TWJUG 的活動 [3] 中聽到 Apache Camel 這個工具，雖然說嚴格來講覺得沒有真的打到點，不過再看到最近社群到處轉貼的文章 [4]，就覺得好像有點靈光一閃 (?)，所以就先做個紀錄 XD。

參考資料

1. 建構微服務｜設計細微化的系統 (Building Microservices)
2. Wikipedia - Spaghetti code
3. Camel & Camel K & Camel K on K native
4. 使用 Workflow Engine 來實作 Microservices SAGA pattern

使用其他工具透過 SSH 連接 GCP 的 VM

網路上其實已經有很多文章在講要怎麼用其他工具 SSH 連進 GCP 的 VM，不過中間大多有個小地方寫得不太清楚。

通常來說，多數文章會講說可以用 PuTTYgen 這個工具來產生 RSA 金鑰，然後這裡要記得選一下演算法和金鑰長度。產生好金鑰以後，PuTTYgen 會直接在介面上顯示出 public key，然後可以選填 key comment 和 passphrase。這時最重要的問題來了！這裡其實輸入的 key comment 就是未來用這個金鑰作為 SSH 登入管道時的使用者帳號，並不是一定要輸入什麼指定的東西，所以不必限定在一定要用 GCP 帳號的名稱、當然也不要直接用 PuTTYgen 預設的字串（雖然說預設字串也蠻不容易被猜到的啦….）。

後面就是一般操作，把 private key 存檔，並且把 public key 貼到 GCP 的 metadata 裡面，稍微等一下下，就可以用這個金鑰去 VM 登入了。

參考資料

1. [教學] Google Compute Engine ( GCE ) 使用 PuTTY SSH 登入實例
2. 使用進階方法連線至執行個體