译见|谋定而后动,将应用 Docker 化之前的 4 道必答题

译见系列|DaoCloud 现推出「译见」系列,每周为开发者提供国外精品译文,主要关注云计算领域的技术和前沿趋势。

译者注

欧洲 DockerCon 大会将于今天在巴塞罗那开幕,届时又会有诸多重磅新闻。毫无疑问,在过去的两年里,Docker 容器技术的风靡,证明了它的价值。然而喧嚣背后,如何在企业中使用 Docker,这是横亘在首席执行官们面前最重要的议题。

作者介绍

译见系列-Jason2
Jason Mckay,Logicworks 公司高级副总裁兼首席技术官。Logicworks 是一家云计算战略与管理咨询公司。创立于 1983 年,总部位于纽约,提供世界级的复杂 IT 解决方案,他们的客户包括美国最大的卫生保健、法律和公共部门。

本期内容

Docker 因使用简单而闻名。然而对于采用一体化应用同时对 Docker 感兴趣的企业来说,缺乏实际使用 Docker 的相关信息。甚至在敏捷爱好者当中,对于微服务模型是否值得一试也存在巨大争议。

如果你希望提升已有的一体化应用的灵活性,如何来决定 Docker 是最佳答案?容器部署的收益是否能够抵扣切割或重写应用的工作?以下列出了 4 个问题,你需要在容器化应用之前好好想想。

1)你希望采用 Docker 或微服务吗?

Docker 是高效部署微服务的解决方案,但是它并不能自动创建微服务进程或者团队。在你开始使用 Docker 之前,你得决定自己是否能够全盘接受微服务的优点和风险。然后你得在构建或重构微服务应用的道路上不断尝试,Docker 只是其中的一小部分。

也就是说,一体化应用的某些组件是能够容器化的。独立或单一功能的组件,特别是不需要保持本地状态的组件,尤其适合进行 Docker 的早期尝试。这些服务成熟快,能够横向扩展,也能在简单的部署包中打包复杂的功能。

 

2)你是否准备好管理多个语言/库/镜像仓库?

去年,我们遇到的一个机构部署了模块化应用,同时允许自己的开发人员随个人喜好来构建单一组件。想法虽好,最后却变成了噩梦——单纯追逐模块化设计的理想,却毫不考虑这一复杂性给运营带来的影响。

尽管该组织后来对使用 Docker 减轻部署压力大有兴趣,我们还是强烈建议他们在解决根本问题之前不要使用 Docker。对于长期维护应用所需的部署栈所带来的困难,简化不同应用的部署并非一剂解药。

 

3)你是否已经有了日志、监控或者成熟的部署方案?

如果应用早已采用了传输日志、在正确时间将数据备份到正确位置的框架,那大有机会。要使用 Docker,你不仅要重复虚拟机环境里的日志行为,还要让你的合规团队为这些变化做好准备。Docker 社区一向都有新工具加入,然而在稳定性和成熟度方面,它们比不上现有方案。部分更新、回滚和其它常见的部署任务可能需要重新设计,从而符合容器化部署。

不破不立。如果你已经在构建持续集成/持续交付的流水线上投入了大量的时间,那容器化那些遗留应用可能是得不偿失。

 

4)云端自动化将会压倒容器化?

在11月举行的 AWS Re:Invent 大会上,亚马逊首席技术官 Werner Vogels 在自己的主题演讲中,用大量篇幅介绍了 AWS Lambda,一款基于代码部署基础设施的自动化工具。Vogels 也提及了 AWS 的容器服务,不过他强调对于开发者来说,Lambda 对零基础设施的处理,更适合配置和部署容器。

容器技术在业界迅速风靡,必将成为许多专业持续集成/持续交付流水线的重要组成部分。然而身为技术专家和首席技术官,你的职责是迎接新技术和新服务的挑战,妥善权衡早期采用的风险。我相信 Docker 对于理解容器化后果的组织来说非常有效,前提是你能正确回答我提出的这些问题。

 

译见系列往期内容:

Leave a Reply

Your email address will not be published. Required fields are marked *