The Art of Readable Code && High Performance Comments

我在 re:Invent 的分享中提到 There’s no lock-in in AWS. You’re just locking yourself out ,並且在 Facebook 上稍有討論;在此簡單整理我的論點。

不存在 Lock

所謂的 Lock,應該是指系統設下特定限制,使用戶難以更替;這在 AWS 是從未發生的事情。甚至 AWS 上的許多服務能夠善用其彈性,因而能在無損品質的前提下,進行服務的移轉。這要在自管服務上實現,難度往往大得多。

要是把 protocol 不相容,而無法無腦更替也當作 Lock-In 的話,那麼大多數作業系統、Linux Distribution、程式語言、資料庫、訊息佇列或快取系統間的藩籬,皆不亞於 AWS 與其他替代服務;其轉換甚至比從 AWS 移到其他服務提供者更加困難(至少對 AWS 服務可以做到 API 相容),影響也更加深遠,怎不見有人因 Python 會造成 Lock-In 而避免使用。反過來看,連以 C” 複製 C’ 的 API 與功能的可行性都要存疑,不禁令人懷疑是否能完成 C” -> C 的開發。

簡而言之,能者面前不存在 Lock,而弱者(如在下)沒有能力實作出更好的系統;因此使用 AWS 服務時,無需擔憂 Lock-In。

加快開發進程

若專案由組件 A, B, 與 C 構成,而 AWS 的服務 C’ 能用於實作組建 C,則使用 C’ 可以省下開發 C 所需時間。在大多數情況下,如果 C 也能由自行開發 C” 來實現,則因 AWS 的服務文件完整,並且多半將備份、整合、HA 與 Elasticity 納入架構考量,除非已有熟悉 C” 的人選,否則選用 managed service C’ 將有較低成本,而其性能與調教良好的 C” 相差有限(假設開發人員對 C’ 與 C” 的理解程度相仿)。

最大的差別是,選用 C’ 可以延後自行開發 C” 的時機,從而加快產品開發的進程。若是產品成功,並且需要移出 AWS,再去轉換 C 也不遲。

強迫鬆散耦合

若架構師遇見未來需要移出,則在使用 AWS 服務時,會更注意包裹底層 API,以降低未來移轉的功耗。這樣的架構不但強迫與 AWS 服務間為鬆散耦合,也有助於用戶程式間的妥善分層。無論未來程式運行於雲端或機房,這樣良好架構的系統將具有較佳的伸展性與可靠性,也更容易添增功能。

發表迴響

分類

%d 位部落客按了讚: