訂閱本網誌: Facebook, Google+, 電子報, RSS

什麼時候 Scale?

July 27th, 2011 by Jamie

前陣子,在他們的產品發表會,Gulu 的 Jimmy 在台上脫口說了:「Jamie 說技術不重要!」回來之後,為了澄清這句話的前因後果,我於是寫了一篇「技術到底重不重要」。

而這個討論就從那邊開始延續了下去,除了我的文章下面出現的 75 則回應之外 (蠻精彩的,你們可以去讀讀),Jimmy 幾天前也在他自己的網誌闡述了他的想法 — Scalability Matters for Web Startup,他說:

(W)eb startup developers… should think about scale before they write their application. Building your app, for example, using scala on mongoDB and set it up to autoscale on AWS is smart, is free, and is easy!

基本上的意思就是說 Scale 並不難,也不貴,所以你應該從一開始就做。

而接下來的幾天,大家便在 Inside 討論了起來。到了昨晚,Xdite 也在他的網誌發表了「Startup 需不需要一開始就注意 Scale 的問題?」,他說:

在這個議題中,我覺得最容易混淆的點是:將 “Scalability” (擴充性)與 “Maintainability” (維護性)混在一起講… 如果不把 Maintainability 做好,很快的,你的 code 在三個月之內就會腐爛而且臭不可聞… 一個產品需要被重視「Scalability」,通常是在人為的「調整」費用高過「直接買機器」、「轉換成為另外一種架構」的成本這一類的狀況,才有可能發生…

很清楚也很棒的解釋。

其實如果你仔細想想,這個問題的核心根本不是「Scalability 重不重要?」,因為廢話它當然重要,只是重要的「時間點」到底在哪裡。也就是說,講這麼多,大家其實真正在討論的根本就是「什麼時候 Scale?」。而這個問題是沒有標準答案的,所以能夠有這麼多人發表他們的意見,是非常棒的一件事。但最後你們自己要參考各方觀點之後,根據你們自己的能力和資源,去做出你們自己的安排。

未知需求 vs 成本風險

對我來說,這是一個「未知需求」 vs 「成本風險」問題 — 當你不確定有沒有人喜歡你的產品,先開發給 1,000 人用的 MVP (Minimal Viable Product),花的時間和力氣比較少,風險相對的也比較低。

appWorks 輔導 50 個創業團隊下來,我的經驗是通常你的前面 5~10 個 MVP 是沒有人要用的,因為你對市場的理解度還很低。所以當你可以用少一點的時間、少一點的開發精力去驗證你對市場的假設,如果事實證明你是錯的,至少不會那麼心痛。

接著你會不斷的 pivot,到了第 11 個 MVP,終於讓你找到了 PMF (Product Market Fit) — 也就是確定了這個產品真的有 1,000,000 人要用。這時候,你再花資源下去,把它升級成 1,000,000 人用的架構。沒錯,這裡面可能有很多code 要重寫,但是至少前面 10 個嘗試,你沒有浪費太多珍貴的資源。

假設你對市場的理解度不高,用這樣的 Lean Startup 方式去創業,11 個嘗試下來你的期望值是比較高的。當然,如果你對掌握市場的需求很有自信,或是已經有明確的通路,那就相反,應該像 Google+ 一樣,從一開始就用規劃給 1 百萬甚至是 1 億人的 Waterfall 方式執行。

另外,從 1,000 人規模化到 1,000,000 人,其實也不一定要大幅的重新寫 code。我的經驗和 Xdite 說得很像,有時候就只是把機器從 AWS 的 Micro Instance 升級到 XL Instance,或是加上 App Server Load Balancing 架構而已。唯有當這些架構升級都已經無法滿足,或是邊際成本過高時,你才會真的去大幅度的把程式碼 refactor。

以上,希望這些討論能讓你對於 Scale 這件事情有更深入的了解,也更能決定自己的規模策略,加油!

有興趣多了解 Lean Startup 的精神和方法?第四屆 appWorks 育成計畫即將在下周正式開始接受申請,敬請期待。

歡迎在 Google+ 上加入我們的討論

(Image via jdhancock, CC license)

  • Minimal Viable Producth才是關鍵,Scale是結果…
    改謝分享…

  • 感謝Jamie的分享~受益良多

    請問在不了解市場~或者是第一次踏入市場的時候~
    如何去判斷不去浪費珍貴的資源呢?

    Google+ 一樣,從一開始就用規劃給 1 百萬甚至是 1 億人的 Waterfall 方式執行。

    GOOGLE又是用甚麼方法判斷他們GOOGLE+的服務一開始PMF需要給多少人使用呢?

    其實GOOGLE手上應該有很多統計資料可以判斷
    畢竟從搜尋搭配FACEBOOK人數做參考

    但是Pivot的時候究竟該如何判斷與預期使用人數呢?

  • 每天早晨看看 Mr Jamie 昨晚有没有用功,已经成为我的清晨心灵大补丸,感谢也感恩!  这一年以来,我像海绵一样不断吸收不断”PIVOT”  尝试在传统产业中融入新元素,新观念,还真的有些领悟,也有些进展,基本功做好了,再来打通任督二脉,功力大增,接着就可以行走江湖啦!一个阶段有当时该做的事,计划和策略都是要灵活又有弹性才好!这些都是在Jamie的几十篇网志中反复阐述的,请大家珍惜也 激励一下 ,用功一些,别浪费了这么好的资源与平台! 

  • Poya

    怎麼這麼厲害,每次都能找到這麼切題的圖片?

  • 也是因為每天都想到要跟你們交待,更敦促了我自己更努力。

  • 把產品 (MVP) 推出去後,市場自然會跟你說。

  • 應該說 Product Market Fit 之後,Scale 是自然的結果。

  • 找到一張好圖也是一件我每天給自己的功課

  • 鬼野特

    看來 Pivot 出現才是 Scale 的時機

  • Timing Is Overrated. 就像創業本身,很多人都在尋求 “best timing”, “right time” 然後才肯去創業,但是往往結果是等啊等,所謂的 best timing, right time 卻始終等不到,重點還是要跳下去,才知道創業是怎麼一回事。

    跳下去創業之後,MVP (Minimal Viable Product) 就是在試市場的水溫,就像是你要參加鐵人三項比賽前,各種姿勢的調整,等你找到了最適合自己的姿勢 (PMF),你就知道要以這個姿勢在比賽的時候,去全力衝刺 (Scale) 了。

  • Scale 的問題通常跟效能、平台工具有正相關。
    去年花水木找我幫忙獎金獵人處理一個效能的問題,其實一直到後面,我們才發現那是一個 Scale 的問題。

    不管如何,在我眼疾發生前,我們用的還是老方法:升級硬體來解決這個問題。
    在此之前也試過一些軟體的調教方法,但不是效果不彰,就是限制頗多。

    Scale 問題基本上我認為比較接近是經驗問題,而非技術問題。
    你碰過、有解法之後你才會知道,有點類似巴哈之前碰過 DDos 一樣。
    解法或許不只一種,但在當時就只用了後來我們所知道的那種~

    其影響就是,之後你得繼續維持網站的效能與穩定、並持續開發新功能。
    在當時說實在話我已經有點力不從心,人少這也是沒辦法的事情,但我就是不了解接下來要持續擴大 Scale 該怎麼辦~

    Google 可以提供你很多不錯的解法,但都得花資源去嘗試,不論是金錢或是時間。
    最重要的是,這些嘗試必須在目前已經在 Run 的機器上試,不然就沒有意義~
    但這是個極具風險的作法,至今我也沒辦法模擬出一個實驗環境去重現當時會發生的一些問題(當然該問題也沒有真正被解決)。

  • Guest

    上禮拜不錯的文章 重要的是最後一段

    我的一個好友在矽谷經營一個新創公司. 他是一個精實創業的死忠愛好者. 他使用PHP跟MySQL快速的做了一個原型程式, 並架在一個Linode上面. 最後發現他的app只能夠同時服務300名用戶. 他最後發現事情發展並未如他所願. 他花了99%的時間在scale他的app, 並幾乎無法增加新功能. 兩個月後, 為了解決scale的問題, 他決定讓他的app下線並從頭寫過, 並增加許多新功能. 他在三個禮拜後重新讓他的app上線, 但是失去了90%的流量並且在也沒有上升過.

    One of my really good friends ran a startup in the valley. He is a
    die-hard lean startup guy. He built his app on PHP and mysql. He
    prototyped it quickly. He ran it on a linode server. Turned out his app
    can only handle 300 concurrent users. He then, against his wish, spent
    99% of his time trying to scale his application and almost zero time on
    new feature request. After two months, he decided he needed to take down
    his app to rewrite it so that it can scale, and for good measures, he
    added many of the feature requests. He relaunched his app in 3 weeks.
    However, by then, he lost 90% of the traffic and could never get it
    back.

    有些事情就像地心引力 是你不能抗拒的

  • 如果每篇文章可以連到 Google+ 對應的討論串就更好了

  • 研究看看

  • 研究看看

  • 謝謝分享

  • 謝謝分享

  • 但是創業失敗常常是 Timing 不對哦

  • 但是創業失敗常常是 Timing 不對哦

  • 應該是 Product Market Fit 出現

  • 應該是 Product Market Fit 出現

  • 在產品雛形的時候 Scalability 並不是很重要。

    但是開發人員有沒有 Scalability 的 sense 很重要。 一開始在開發的時候有思考到這些點。 流量變大的時候,只要進行程式的優化,很簡單的就可以把 scalabitity 增加。如果沒有思考到scalability 。 後續可能要打掉重做,才有辦法應付流量變大。 目前很多雲端的服務跑出來, scalablity 的成本非常便宜。 如果對 amazon  aws 熟習的話,db 擴增,加 cache ,做 load balance 基本上就在彈指間搞定。 處理 百萬 pv 的流量。費用也不會超過 一個月 10 萬的。

  • 很棒的解釋,謝謝分享。

©2018 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成