搞清這四個問題，再對應用程序容器化！
譯文【51CTO.com快譯】眾所周知，Docker很容易試用?？墒菍碛姓w式應用程序，對Docker又有興趣的企業來說，如何實際使用Docker方面的信息卻并不多。即使在敏捷開發愛好者當中，微服務模式是不是值得去做還是存在著很大的爭議。
圖：于Docker于6月22日舊金山召開的DockerCon大會上
如果你有整體式應用程序，又想改善應用程序的敏捷性，如何確定Docker是不是就是解決辦法?容器在部署方面的好處是否可以抵補劃分或重寫應用程序的前期工作量?你在開始對應用程序容器化之前，先要問清楚這四大問題：
1. 你是想要Docker還是微服務?
Docker是一種軟件解決方案，可以高效地部署微服務，但是它并不自動創建微服務進程或群組。在你開始使用Docker之前，先要確定你是不是想要擁有其所有好處和風險的微服務。然后，你要經歷構建或重構微服務應用程序的這條艱難之路，而Docker只是其中的一小部分。
話雖如此，整體式應用程序中還是有某些組件可以實現容器化：獨立或單一用途的組件尤其非常適合于早期試用Docker，如果它們并不維持任何一種本地狀態，更是如此。這種服務在迅速成熟，具有橫向擴展性，可以將復雜功能封裝成易于部署的程序包。
2. 你在運維方面是否準備好管理多種語言/代碼庫/軟件庫?
去年，我們遇到過一家企業組織，它開發了一款模塊化應用程序，讓開發人員可以“使用想要的技術”，以便構建單個組件。這是個很好的概念，卻完全是企業的惡夢――在沒有考慮這種復雜性對其運維有何影響的前提下就盲目追求理想的模塊化設計。
當時這家企業對Docker頗有興趣，因為有助于方便部署，可是我們強烈建議，這家企業在解決根源問題之前切勿使用Docker。更容易部署這些不同的應用程序克服不了維護幾種不同的開發架構，實現對這些應用程序進行長期維護帶來的難題。
3. 你是否已經有了一套日志、監控或成熟的部署解決方案?
你的應用程序很可能已經擁有一套框架，以便傳送日志、在合適的時候將數據備份到合適的地方。想實施Docker，你不僅需要在虛擬機環境下復制要求擁有的日志行為，還要讓你的合規或治理團隊為這些變化作好準備。新工具一直在涌入Docker領域，但是許多工具的穩定性和成熟性比不上現有解決方案。部分更新、回滾及其他常見的部署任務可能需要重新設計，以便適應容器化部署系統。
如果沒有壞掉，就別去修它。如果你已經投入了構建一條持續集成/持續交付(CI/CD)流水線所需的工程時間，那么對遺留應用程序進行容器化也許不值得為之投入時間。
4. 云自動化會壓倒容器化嗎?
在上個月召開的AWS Re:Invent大會上，亞馬遜***技術官Werner Vogels在發表主題演講時，用相當長的篇幅來介紹AWS Lambda，這種自動化工具可以基于你的代碼來部署基礎設施。雖然Vogels并沒有提到AWS的容器服務，不過他專注于Lambda表明，他認為對大多數開發人員來說，處理零基礎設施比配置和部署容器更可取。
容器正在企業界迅速流行起來，勢必會是許多專業CI/CD流水線的一個必要部分。但是作為技術專家和***技術官，我們的職責就是質疑新的方法和服務，并且合理評估早期采用的風險。我認為，Docker對明白容器化后果的企業組織來說極其有效，不過前提是你問對了問題。
原文標題：4 questions to ask before Dockerizing your applications
【51CTO.com獨家譯稿，合作站點轉載請注明出處】
