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 注意 scale] 推荐:

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

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

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

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

web-scale OLAP系统应用解决方案

- - 冰火岛
为了支持linkedin在线应用“Who’s Viewed My Profile?” 和 “Who’s Viewed This Job?”等等. 构建OLAP 一个可伸缩和快速的serving system called Avatara to solve this many, small cubes problem.

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很多年前的一片文章. 建立一个成功的创业公司,起码需要三个条件:好的创业伙伴,较好的满足用户的需求,少烧钱. 大部分创业公司之所以失败,就是没有遵循上述三个条件的一个或多个. 如果你都符合,那你成功的把握会很大. 因为创业公司有了起色,会让你走上小康之路.

Startup Delayer – 开机后延时启动程序 | 小众软件 > 系统工具

- —————— - 小众软件 - Appinn
如果你有很多软件需要开机自动启动,但又不想延缓开机时间,那么 Startup Delayer 可以帮到你. Startup Delayer 可以设定在开机后 CPU 或者硬盘空闲时启动程序,不仅提高了程序的启动响应速度,而且还不占用开机时间,相当方便. 修复了注册文件未找到崩溃的问题. 修复了快捷方式未找到崩溃的我能提.

一种可以避免数据迁移的分库分表scale-out扩容方式

- LightingMan - 淘宝JAVA中间件团队博客
一种可以避免数据迁移的分库分表scale-out扩容方式. 目前绝大多数应用采取的两种分库分表规则. dayofweek系列日期方式(所有星期1的数据在一个库/表,或所有?月份的数据在一个库表). 这两种方式有个本质的特点,就是离散性加周期性. 例如以一个表的主键对3取余数的方式分库或分表:. 那么随着数据量的增大,每个表或库的数据量都是各自增长.

Redmine Backlog tracker注意事项

- - CSDN博客研发管理推荐文章
最重要的,story和task的tracker不能相同. 否则在taskboard中会将task和story并列显示,尽管它们是父子关系. 因此比较好的做法是,story使用redmine默认的tracker:Support, Bug 和Feature. 而另外创建一些tracker用来跟踪task.

js 注意事项(转)

- - zzm
<!-- Articles--> 对象使用和属性. JavaScript 中所有变量都是对象,除了两个例外. 一个常见的误解是数字的字面值(literal)不是对象. 这是因为 JavaScript 解析器的一个错误, 它试图将. 点操作符解析为浮点数字面值的一部分. 2.toString(); // 出错:SyntaxError.