架構設計目標
- 最低的開發時間成本。
- 工程師開發時間就是金錢,省時間就是省錢。
- 初期開發成本,複雜度。
- 維護成本,複雜度。
- 成長擴充成本,複雜度。
- 最低的運行成本。
開發架構順序
如何用最低成本最快速度開發上線初期產品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
- Stickiness KPI - 客戶使用者retention
- Virality KPI - 客戶使用者compound effect
- Paid KPI - 客戶使用者付費意願
- Google Analytics
- Firebase
如何開始容納高流量
- 資料庫需要自己架設及維護。
- 可以使用比較完整的架構(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分享,謝謝!