Let’s talk about SaaS/Managed Services and Self-Hosted today!

SaaS/Managed Services派的人會說，我不想管機器。
自架派的會說，我喜歡掌握所有東西的感覺。
但到底哪個好？

名詞解釋

---

感謝社團大大指出，AWS不算是全SaaS服務，它包含了SaaS/PaaS/IaaS，所以應該屬於Cloud Provider，提供Managed Services

• SaaS
  SaaS 全名是 Software as a Service ，軟體即服務。 通常為直接面對客戶的應用程式，像是 Office365/Slack/LastPass/Splunk。

• Managed Service
  Managed Service 是指託管在雲上的服務。 像是 EKS/Elasticache/Elasticsearch。

• 所以我要講的是什麼？
  因為我太懶的關係 本文以下所稱 SaaS 或是 Managed Services 即代表 SaaS 或是 Managed Service 兩者互相通用的意思。
  但更準確的說我要表達的是 XXXX AS A SERVICE 的這種商業與開發模式。

• SaaS = Managed Services ?
  其實他們是不一樣的意思，所以特別在這邊解釋。
  不過本文並非名詞探討，就不多就不多寫了，怕會離題歪樓。

先看看案例

---

SaaS儼然已經成為趨勢，看看現今的軟體世界，你會發現不知不覺中生活裡已經充滿SaaS了。

• UBER
  像是常用的Uber，你打開App所看到的地圖，Uber並沒有自行開發，而是付費使用Google Map API。

• 金流
  又像是電商最愛的藍星/綠界這些金流服務，你也並沒有自己寫一套金流服務去跟銀行串接，而是付費使用別人已經寫好的東西。

• 再把範圍放大一些，飛利浦從以前的賣燈泡，現在改成賣照明服務了，以照明時數計費。

• AWS，幫你把你常用的東西全部做成服務，讓你想用的時候就可以快速搭建好你所需要的東西。

• 以前大家都需要的Mail Server，現在幾乎已經快被G-Suite取代。

這個時代，你想得到的都能成為SaaS。

區塊鏈/交易所可以變成SaaS服務、工作溝通軟體可以變成SaaS (Slack)、
你常用的Word/Powerpoint也可變成SaaS (Google文件/簡報, Office365)、
甚至是你的代碼儲存庫也可以(GitHub)、
連Adobe都變成Adobe Cloud並採用訂閱制了、
電商開店平台也變成SaaS (Shopline/91APP)、 資安居然也有SaaS的方案了。

就連工程師的世界也發生很多改變，開始出現Kubernetes as a Service, Logging as a Service, Instance as a Service等等的這些東西，連DevOps as a Service都出現了。

為什麼？ 聽起來很虧啊，我自己都可以做到的事我還要花錢讓別人幫我服務？

---

因為就算你很行，你一天還是只有24HR可以用，而厲害的你，會想把時間花在刀口上。

使用SaaS服務，你需要做的事變少了，哪邊有問題就往哪邊的客服打去。
老闆問說怎麼壞了，你很輕鬆地回答：喔，XXX家的服務又掛了，下次要考慮換一家了。
千錯萬錯，都不會是你的錯。

而你使用SaaS花的錢真的會比較多嗎？我只能說 “Hm… It depends…"。
一開始投入的金錢可能會看起來多了些，但是長久來看，SaaS幫你節省的人力成本以及客戶服務還有SLA的保證跟不需要擔心Scaling的問題，在我看來是非常值得的一件事。

隱藏成本，永遠是我們最常忽略的事。

從技術面剖析

---

以技術面來說，你一個人或者你是一個20人的團隊，你有自信做出比10家廠商加起來可能200人的團隊做出來的東西好嗎？

就算以個體來說，你一對一單挑一定可以贏，但是當這10個系統同時出現問題，你可以化身為鳴人使用影分身之術一起解決問題嗎？

當面臨軟體背後所採用的套件需要升級的時候，針對相容性做測試，你覺得你有多少時間從規劃到執行最後還可以保證SLA？

再談Scaling, 流量進來的時候，你要是一個人負責全部的服務，會不會手動Scale到死？
Oh, 你有Auto-Scaling. 那恭喜你，但你知道Auto-Scaling要應付瞬間流量的前提是你provisioning的時間要夠短嗎？ 不然等你機器開好了，流量也過了。

更別說你只有一雙眼睛，要監控一堆服務，尤其在這個微服務興起的時代。

看不見的影響。 你最優秀的工程師為何一個一個離去？

---

而節省下來的時間，可以拿去做針對公司核心服務的效能優化或是補齊單元測試又或者是定期的軟體及Infra上的重構。

先不說定期重構跟優化很重要這件事，這件事背後的意義遠大於實質上的意義。

你想留住你公司最好的軟體人才，你需要讓他有真正的事可以做，也就是讓他有發揮的舞台。  

效能優化以及重構都是相對你第一次寫商業邏輯來的有挑戰性許多，只有讓developers感覺他們自己有在長大，長大的同時還有發亮的機會，這才能把他們留在公司裡。
你問為什麼？ 你可以問問馬斯洛為什麼把自我實現放在需求金字塔的頂端。

你要是叫一個優秀的團隊整天修Bug，這邊調調Config那邊改改IP，改完重啟服務，然後測試。每天除了這些之外，發生問題還要一直去救火，PM/Manager還站在你旁邊看你修，有已知流量要來的時候還要幫忙預先開好機器，時間一到還要忙著監控服務。這樣就佔據你大部分的時間了，別說做什麼有趣的新專案，還要忙軟體升級都忙不過來了。

這時候開始有人會覺得自己的才能被淹沒，我有想法有技能，為什麼要在這裡每天做一樣的事？我應該要做些更有意義的事的。然後到達臨界值，你將會漸漸地失去人才。

Managed Services / SaaS 的缺點

---

唬爛了這麼多，Managed Services / SaaS 真的沒有缺點？ 有啊，當然有。

都交給別人做很方便，但是萬一你選到很爛的廠商，那也很難置身其外。
資安以及合規的問題，也是都要特別注意。

像是銀行，涉及到金流的廠商，是很難信任第三方把資料交給別人的。
再談到使用SaaS服務，Secrets跟權限控管也會變成很嚴重的問題。
還有就是你會被綁死在某個平台上，像是AWS。

轉換思考角度

---

Managed Services 改變的不只是軟體發展，更改變了這個世界，管理者必須要轉換角度去思考。

你不可以說：「喔我自架的時候我都可以控制整個Config調參數，現在都不行了。 Managed Services really sucks!!」

這世界是需要你等價交換的，你不能魚跟熊掌你都要，除非你很有錢。
拿錢叫廠商幫你客製化，我相信沒有做不出來的，如果有就是你口袋還不夠深！ ;)

案例思考 - GitLab CI

---

再舉個例子。你不可以說我自架GitLab的時候要跑CI，AWS的Secret都不用交給別人，我放內網很安全，但是換成Cloud版本我就要擔心我的Key被偷走。

Okay. 你需要擔心的還有GitLab升級的時候你要做哪些事，還有那個該死的Database資料不見了你要去哪裡找所有的Code給你的同事們。

風險是相對的，沒有零風險這件事，你只能選擇相對風險小的去做。

案例思考 - EKS

---

你也不能說EKS很爛，因為他版本永遠追不上社群版本阿。然後EKS上我連Dashboard, metrics-server都要自己裝，那跟我自架有什麼不同？

EKS提供給你的是相對穩定的Master (至少你不需要自己Scale Master & Etcd)，還提供給你結合IAM的RBAC以及可以整合Fargate的優勢。

案例思考 - 前端服務

---

你也可以比較前端該怎麼Hosting。

Nginx+ALB+CloudFront or S3+CloudFront?

你不能說Nginx的Config讓你想怎樣就怎樣，S3連加個Security Header都要透過Lambda幫我去做。

這其中的成本一樣涉及了管理以及人力，S3至少還有AWS可以給你靠甚至是versioning，你自己管的Nginx呢？

自架真的不流行了嗎？

---

當然Managed Services不是什麼萬靈丹，在你取捨之下你發現自架帶給你的好處更多，那你為何不自架？

• Google 為什麼都自己架？
  像是 Google 部門劃分仔細，大家都專注負責自己的那一塊，Infra跟VM有專職的Ops處理，Database有DBA處理，Issue有SRE Team可以處理，搭配完善的DevOps流程，在這種環境下你想要自架，你可以有足夠的時間專研好一個軟體而不是一知半解的為了用而用，你也有足夠的時間處理這個服務上線後所產生的失敗，可以去完善他，那你為何不自架呢？

• 但我們都不是Google, Microsoft, Apple, Netflix…
  你可以發現在台灣，甚是是全世界，現在新創軟體公司崛起，有多少DevOps是身兼多職的呢？
  你真的認為你可以在沒有完善的流程下handle這麼多東西嗎？
  出了意外手忙腳亂都來不及了，只會讓技術棧越疊越歪。

沒有制度/流程/人力下的自架，只會讓你在意外發生的時候更亂。  

而當你走了之後如果沒有文件，你可以擔保下一個接手的人很清楚你做了什麼嗎？   
通常只會為了快速解而workaround。 

到最後，就會產生越來越多的技術債。

良好的運用第三方托管服務，可以使風險減少到最低，至少接手的人如果熟悉你用的平台，像是AWS，他至少不會做出太偏離你當初設計想法的路徑。

總結

---

我真的不是要鞭打自架多不好，我相信民間出高手，這真的沒有絕對

最近正好遇到純自架派的高手同事，讓我反覆思考到底架構是怎麼一回事，因此才寫了這篇。 我也很佩服那位同事所擁有的超強架設技能，沒有一種東西可以難的倒他的，Ansible+Terraform一寫，整個天下都是我的！ 但也正讓我反思，我是SaaS派，到底我覺得SaaS有哪些優勢跟為什麼我會想用SaaS。

但從以上的案例應該可以看出我想表達的是我們要轉換思考模式。

沒有誰比較好，只有誰最適合你。  
你永遠只能選擇對你來說相對風險小的去做，那你勢必得要犧牲一些東西。

記得等價交換的原則。

管理者的角色必須轉變，你必須思考你使用了哪些服務，而他們是不是真的Cloud-Native?

你必須要站在Managed Services的角度去理解Managed Services，不能一昧地拿自架跟Managed Services相比，那是沒有意義的事。

你該思考的是該怎麼做，你要付出的代價最少？

可以讓你專心去發揮你的才華，給你滿滿的大平台，進而滿足心裡的成就感（馬斯洛需求 - 自我實現的需要），也正因應文章一開始的圖片。

同樣一句話，沒有萬能解，沒有複製貼上就會成功的架構，只有最適合你的架構。

走入XXXaaS的時代，你準備好改變你的思維了嗎？