檔案或是物件？
如前所述，物件儲存有其適合的應用場景，如果主要的用途是以檔案為基礎的，企業或許應該要考慮使用分散式檔案系統而不是物件儲存。企業在評估以本地物件儲存產品來管理非結構性化資料的高速成長時，應該要瞭解如果把物件儲存拿來當成通用、非結構化資料的儲存使用時，最佳應用場景與它挑戰會是什麼？
圖片來源：pinterest
成本不應該是採用物件儲存的主要驅動因素，因為物件儲存的成本節省通常發生在大規模（上 PB 級）的部署時。當非結構化資料量沒有那麼大時，單純的檔案儲存系統也許會更適合。
請再度回憶一下物件儲存最佳應用場景，並不是非結構化資料就非得用物件儲存！
閘道器
雲閘道器或是檔案閘道器是企業採用物件儲存便捷方式之一。如果想用閘道器，就要考慮是否為物件儲存平台原生支援與供應商的支援程度的問題。透過一個檔案閘道器來讓使用者以物件儲存存放個人資料和家目錄或許並不是很好的應用案例，但如果檔案閘道器和物件儲存平台來自不同的供應，又出現了不相容的情形，那就是最糟的應用場景了。
早期採用者也會利用物件儲存產品做為本地與公有雲端環境間的橋接功能（閘道器），建構一個混合雲的環境。簡單的是以層級的方式來提供，把公有雲儲存做為一個較便宜的資料目的地；但現代化的工作流程應該要有原生的雙向路徑。公有雲的支援程度，也是必須要考量的，用什麼方式支援公有雲？是原生支援或是相容？在不同的公有雲間移動會不會困難？
Amazon S3 (Simple Storage Service)
物件儲存平台，即使是那些部署在本地的平台，最終都會支援 Amazon S3 這項可以說是在雲端世界裡的創新通訊協定，這個服務幾乎與現代物件儲存劃上等號。
軟體發展人員會使用 S3 的主要原因是，它很容易就可以儲存大量的非結構化資料，也不會受到傳統檔案系統的限制。但是開發人員對本地物件儲存產品的採用不如公有雲中的 Amazon S3 快，因為許多本地應用程式仍然需要檔案系統而不是物件 API，這就會拖慢部署的進度。S3 的支援程度同樣也是必須要詳加瞭解的重點，特別是在相容性上，只是相容支援 S3，還是支援最新版本全功能的 S3？這是有差距的！
部署與運營
筆者的建議是，不要貪快，如果物件儲存真的是你們家非結構化資料的救贖，那就花點時間做驗證吧！這裡指的是把應用搬上去試試吧！現代化物件儲存平台「應該」都會支援 RESTful API，所以應用測試驗證的改寫花不了多少時間的。RESTful API 與傳統 API 不同的是它簡易且通用，有經驗的程式開發人員應該可以在很短的時間內就把以檔案通訊協定的應用改寫成用 RESTful API 來存取物件。
除了功能驗證外，資料量體是很重要的。如果未來的資料「數量」是巨大的，那就要試著去驗證一下巨量的物件數時，在效能與操作上能不能維持？
供應商在本地的支援能力也是很重要的，不是每一家儲存供應商的本地團隊都具備支援物件儲存的技術能力，他們不見得能提供企業所要的諮詢與架構設計建議，這需要時間與經驗的累積。
如果有多站點的部署最好要有找尋有經驗與實績的供應商，因為在這樣的部署中對於那些比較不成熟的產品，可靠性是最大的挑戰。
