转载

搞清这四个问题，再对应用程序容器化！

众所周知，Docker很容易试用。可是对拥有整体式应用程序，对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对明白容器化后果的企业组织来说极其有效，不过前提是你问对了问题。

正文到此结束