本文翻譯自一篇GIGAOM的文章，原帖地址，作者為Jonathan Boutelle，他是著名站點SlideShare的CTO和創始人之一。

　　對初創公司而言，云計算可謂是利器，因為只要通過鼠標點擊就能一下子擁有幾乎無限的計算能力，而且通過這些計算能力能夠很好地開創新的機遇。通過鼠標點擊就能一下子啟動或者關閉上千臺服務器是一個非常強大的能力，但就好象漫畫書所教我們的那樣“great power comes great responsibility（能力越大，責任越大）”。

　　我公司Slideshare在我們幾乎所有的事情中都使用到了云計算，這也導致，我們在使用云計算方面也出現一些大錯，下面是兩個最明顯的例子：

　　在沒有試用之前就浪費了五千美元

　　幾個月前，我們開始非常著迷于Hadoop，我們甚至在辦公室中組織了一個Hadoop黑客日（Hackday），并非常迅速地編寫一些Hadoop原型代碼來對SlideShare用戶的數據進行分析，

　　Hadoop分析本身是一個極為適合云計算的任務。雖然你需要一大堆電腦，但卻僅需一天就能把所有的數據都給處理了。但當我們開始使用越來越多和越來越真實數據集來測試我們的原型代碼時，它開始花費越來越多的時間來完成一個任務。

在那個時刻，我決定將機器的數目翻四倍（從20臺升至75臺）。這個決定是非常有意義的，如果一個任務需要100個計算時才能完成，那么100臺機器就只需1個小時就能將這個任務快速地完成。

　　在我做這個決定的幾小時后，一次大型站點事故引起所有工程團隊人員的注意，為了解決處理這個事故和其它相關的事故，我們連續工作一個晚上和一個整天，最終直到周五的下午才全部搞定。在我們心安理得享受了一個周末之后，周一上班的時候我們發現在事故之前運行的Hadoop分析任務還在繼續運行著。我們包含Bug的代碼以一種我們沒有預想到的方式失敗了，以至于在這個問題上就算加入再多的硬件也解決不了這個問題，同時，我們收到了一張來自Amazon Web Service的五千美元的賬單。

　　我們的教訓是：如果你真正想使用云計算的力量，那么你需要不停地觀測支出，并且確保它沒有出現亂來的情況或者超出預算，特別當你快速地伸展和縮小使用云計算的規模時。不巧的是，Amazon Web Service并沒有提供任何提醒或者圖表工具來幫助用戶簡單地跟蹤支出，雖然跟蹤支出是一個牽涉到下載CSV文件，將它們導入Excel并進行分析的繁瑣流程，但它卻是不可或缺的。

　　使用云存儲的麻煩

　　我們最近發現我們在存儲（S3）方面的開支急劇地增大，經過多天的調查，發現我們在使用存儲方面沒有明確的原則，比如，一些可以被刪去的文件還保留著；不同類型的文件被放置在同一個目錄；還有些文件我們根本不知道它們的來源和它們還是否需要。

　　Amazon S3，和其它類似的云存儲，都可以被認為是一個大型的文件系統，它們不會對數據的位置進行任何控制，它由使用者來確保這個存儲是否被有條理的使用。如果一個人寫代碼，這是很簡單，但是讓一個團隊來寫多個依賴云存儲的程序時，是很容易忘記刪除某些文件的。你需要確保你們沒有浪費存儲，唯一的方法是需要非常明確地定義那些數據存放在那些地方。一個最佳實踐是將不同類型的資源放置在不同的”bucket（桶，S3的最高層的目錄）“，這也是唯一地能讓你得到每種類型數據的占有空間的方法。

　　蜘蛛俠的原則

　　在上面兩個例子中，我們知道了我們并沒有很嚴格地使用云計算的力量，如果讓我們之前借用硬件的話，我們也會觸及硬件的限制（比如，磁盤空間用完），這是一件麻煩的事情，但去逼迫我們總結一下過去的行為，來更合理地支出。擁有強大的云計算力量是一件好事，但是如果你要使用它，就要有一定的責任心。