Startup 需不需要一開始就注意 Scale 的問題?

标签: 個人經驗談 | 发表时间:2011-07-26 15:32 | 作者:xdite Ben
出处:http://blog.xdite.net

在 Inside 的 Facebook 看到這個他們的論壇上有這個問題,看了一下回覆,覺得算蠻有趣的議題。剛剛朋友問我看法,簡單聊了一下,後來乾脆決定來這裡寫下我的想法。

我的想法是「通常不需要」。還有,開始寫 projects 時,請將你的「注意 Scale」這個問題定義清楚。

在這個議題中,我覺得最容易混淆的點是:將 "Scalability" (擴充性)與 "Maintainability" (維護性)混在一起講。

我會將常見的行為進行這樣的歸納:

* Scalability

1. 能夠將 project deploy 到多台機器上,做 High Availability
2. 使用 NoSQL 做高寫
3. 對 MySQL 做 Database Sharding
4. 買很貴很貴的 Load Balancer 和很貴很貴的 Disk Array
5. 實作 SOA

* Maintainability

1. 將 code 依照 MVC 放好,使用 ORM 與 Framework,DB schema 正規化
2. 使用物件導向觀念寫作 code
3. 遵循一定的 code convention 與 team rule 寫作程式碼
4. 使用自動化工具維護系統相依套件與 deploy 專案
5. 執行 code review
6. 定期將 code refactor 成 module 或者是包裝成 gem

如果不把 Maintainability 做好,很快的,你的 code 在三個月之內就會腐爛而且臭不可聞。光是開發維護成本就會非常高昂,「人事費用」也會一路追加,甚至你無法順利完成這個 project 的第一輪 prototype 或者是第一輪調整。

沒有「完成」產品,自然沒有討論「Scalability」的必要。(你要完成一個產品,從這個產品上面賺到流量、金主的信心、客戶的現金,Startup 才能繼續發展)

一個產品需要被重視「Scalability」,通常是在人為的「調整」費用高過「直接買機器」、「轉換成為另外一種架構」的成本這一類的狀況,才有可能發生。

通常這種「成長」是「可以被預期和估算出來」的。

除非你是做 Google Plus 這樣的新創服務(一開始就預計*絕對*會有數千萬的用戶),否則在初期重視 「Scalability」是沒有任何意義的。

而多數 *High Performance* 的架構,又都是往 denormalized 的方向去進行,自然比 normal 的狀況難寫非常非常多。(這也使開發成本直線上升)

那你又會問,服務暴紅怎麼辦,我要不要考慮這個問題,到時候會不會有時間讓我改,如果不穩了用戶是否會跑掉?

我建議你回想 2007 時的 twitter、2008 時的 plurk

當然,回過頭來。我覺得還是老話一句:「做任何事之前,考量你的現有籌碼,而不是考量你的未來收益。」

因為現實是:輸光籌碼你只能出局…

相关 [startup 需要 注意] 推荐:

Startup 需不需要一開始就注意 Scale 的問題?

- Ben - Blog.XDite.net
在 Inside 的 Facebook 看到這個他們的論壇上有這個問題,看了一下回覆,覺得算蠻有趣的議題. 剛剛朋友問我看法,簡單聊了一下,後來乾脆決定來這裡寫下我的想法. 還有,開始寫 projects 時,請將你的「注意 Scale」這個問題定義清楚. 在這個議題中,我覺得最容易混淆的點是:將 "Scalability" (擴充性)與 "Maintainability" (維護性)混在一起講.

Startup 需不需要一開始注意資金的問題?

- kivava - Blog.XDite.net
接續上一篇「Startup 需不需要一開始注意 Scale 的問題. 這一篇想來聊,Startup 需不需要一開始注意資金的問題. 沒有錢就會倒,這是大家都知道的事. 但是如同 Scale 問題一樣,在看過不少網路公司起與落之後,我覺得不少人也沒有把「注意資金」的這件事定義清楚. (當然,你必須自己親手創過公司或是掌舵過某個事業才能比較深的感受到這件事).

性能优化需要注意的点

- - CSDN博客推荐文章
除非必要,一开始不要优化(尤其是开发阶段). 有些优化准则已经过时,需要考虑当下的软硬件环境(不要墨守成规). 不要过分强调某些系统级指标,如cache 命中率,而应该聚焦性能瓶颈点. 不盲从,测试、找到系统的性能瓶颈,再确定优化手段. 注意权衡优化的成本和收益(有些优化可能需要现有架构做出调整、增加开发/运维成本).

Web Startup 適合使用的服務與工具

- Yuancheng - Blog.XDite.net
剛剛在 DK 的 blog 看到這篇,分析 Y Combinator 的 Startup 所使用的服務…. 因為自己的工作都是在沾 Startup(不是在 Startup 工作,就是被 hire 去 startup 一個部門),手癢來寫一下自己做 Startup 會用到哪些東西拼裝….. - 這是我擅長而且穩定的技術.

Startup School:科技界知名人士讲述创业经验

- - 爱范儿 · Beats of Bits
Startup School 是著名的创业孵化公司 Y Combinator 举办的聚会. 在聚会上,科技界的著名人士会分享自己投资、创业的经验. 今年是第七届聚会,Evernote 创始人 Phil Libin、天使投资人 Ron Conway、Twitter 联合创始人 Jack Dorsey 都 分享了自己的经验.

如何建立一个创业公司——How to Start a Startup

- - CSDN博客互联网推荐文章
原文是Y Combinator创始人Paul Graham很多年前的一片文章. 建立一个成功的创业公司,起码需要三个条件:好的创业伙伴,较好的满足用户的需求,少烧钱. 大部分创业公司之所以失败,就是没有遵循上述三个条件的一个或多个. 如果你都符合,那你成功的把握会很大. 因为创业公司有了起色,会让你走上小康之路.

相亲时需要注意的10个细节

- - 佳人
相亲时需要注意的10个细节,帮你收获第一眼爱情. 过多的家长里短会让对方感觉你是个情感依赖者,以后一旦遇到不如意,就会找他大吐苦水. 在这种负面心理防御下,很少有人愿意与你深入交往. 相反在第一次见面时,如果你只对个人情况蜻蜓点水,只说个大概,反而能给对方留下神秘感,期待与你下次见面. 2、永远留给对方说话时间充分尊重他的话语权.

用 managedQuery() 时需要注意的一个陷阱

- - ITeye博客
文章来源: http://www.eyeandroid.com/thread-691-1-1.html. Activity 里面提供了一个 managedQuery() 方法,按照 Android SDK 里面的说明,“the activity will manage its lifecycle for you.” 听起来很好,Activity 可以替你管理 Cursor 的生命周期了,就不用记着去 close() 了,代码可以更简洁.

界面设计中需要注意的小细节

- - 优设(UISDC)
界面设计包括哪些细节、如何深入. 我们常说“细节决定成败”,有些界面会让人觉得不精致,缺细节,而这些细节又包括哪些呢. 不妨来看本文作者,百度用户界面设计师 @JJ-Ying 为您娓娓道来:. 界面元素的对齐,我见过很多同学对齐是永远靠眼睛的. 确实在布局的时候经常需要做到视觉上的对齐,而不是机械的对齐,但这不是界面元素可以随意摆放的借口,该对齐的内容需要对齐,有时候只是举手之劳,养成好习惯很重要,有点强迫症也不是坏事情.

选购电热水袋需要注意什么?

- - 知乎每日精选
市面上常见的电热水袋其实有两种,一种是电极式,一种是电热丝式,两种外表看起来都一样,但是实际上有很大区别. 电极式电热水袋很不安全,依靠电极加热,加热过程中内部溶液是带电的,安全依赖于外部的温控器和人眼(你没看错,电极式电热水袋放气相对频繁,如果鼓了你不放气就热闹了). 这种电热水袋实际上国家已经禁止了,只不过他还在不停的卖…….