第一階段雲端服務 Firebase, ZEIT

架構設計目標

  • 最低的開發時間成本。
    • 工程師開發時間就是金錢,省時間就是省錢。
    • 初期開發成本,複雜度。
    • 維護成本,複雜度。
    • 成長擴充成本,複雜度。
  • 最低的運行成本。
    • 低流量成本。
    • 高流量成本。


開發架構順序

如何用最低成本最快速度開發上線初期產品MVP?


第一階段:Database-as-a-Service + Lambda Compute Service

MVP Stack

Database-as-a-Service

  • 不需架設資料庫及維護。
  • 不需架設server, linux。
  • 不需請DevOps或SRE維護平台。
  • 專注在code上面就夠。
服務 優點 缺點 決定
Google Firebase 最多人用   考慮
AWS Amplify AWS環境,流量多時便宜   考慮

Firebase

AWS Amplify

Static Hosting

ZEIT

  • 上線Next.js最快速最簡單的雲端服務
  • 已經幫使用者實作Server Side Render
  • ZEIT

Lambda Compute Service

  • 最基礎的初期產品可能連商業邏輯都不需要。
  • 需要一開始就把商業邏輯分開也是一種成本。
  • 但之後因為商業邏輯已分開了,比較容易叩沖及減低成本。
  • 不需架設server, linux。
  • 不需請DevOps或SRE維護平台。
  • 專注在code上面就夠。
服務 優點 缺點 決定
Google Coud Functions 跟Firebase結合容易   考慮
AWS Lambda AWS環境,流量多時便宜   考慮
Google App Engine 流量多時便宜   考慮
Azure Functions 流量多時便宜   考慮

Analytics

  1. Stickiness KPI - 客戶使用者retention
  2. Virality KPI - 客戶使用者compound effect
  3. Paid KPI - 客戶使用者付費意願
  • Google Analytics
  • Firebase


第二階段:Platform-as-a-Service

如何開始容納高流量

  • 資料庫需要自己架設及維護。
  • 可以使用比較完整的架構(Django, Rails)。
  • 商業邏輯不需要分開到Lambda Compute服務(這有好壞)。
  • 不需架設server, linux。
  • 不需請DevOps或SRE維護平台。
  • 如果網頁程式掛掉,服務會直接從新開始,不需有人監視。
服務 優點 缺點 決定
Heroku 最早開發的,一開始免費 流量多時很快就很貴 不用
AWS Elastic Beanstalk AWS環境,流量多時便宜   考慮
Google App Engine 流量多時便宜   考慮
Azure App Platform 流量多時便宜   考慮

Heroku


第三階段:Infrastructure-as-a-Service

  • 除了買電腦其他基本上全部要自己做。
  • 高流量時最便宜方案。
  • 需要請DevOps或SRE監視系統,增加成本。
服務 優點 缺點 決定
AWS EC2     考慮
Google Cloud Compute Engine     考慮
Azure Cloud     考慮
DigitalOceans     考慮
Linode     考慮


歡迎建議

如果有其他對生產架構看法或建議,請由git issue分享,謝謝!