原文：Why Docker makes sense for startups 
作者：Carlos Vega 
翻译：Vincent

译者注：以Docker为代表的容器技术已经持续成为话题好几年了，那么对于创业型公司来说，刚起步时有必要采用Docker吗？作者在本文给出了肯定的理由。以下为译文。

Docker正在渐渐成为开发和运行容器应用程序的标准。

很久以前，这一技术可能只对系统管理员和PaaS(平台作为服务)才有实际意义。但几乎没有听过哪家创业型公司会使用Docker，尤其是那种发展前景很明朗的公司。Datadog总部最近做的研究也与这些观念基本一致：

也许你会说对于创业型公司来说，这么做是否值得，那么接下来我们就详细介绍一下那些友好的容器体系结构对这些创业型公司到底提供了哪些帮助。如果你还没有使用Docker，我们会告诉你为什么需要选择使用Docker？

开发经验

如果你在一家小型的具有两个披萨原则的公司工作，那么团队中的每个人很有可能都是上知天文，下知地理的。一旦手头的项目结束了或者再也不需要了，那么你就会被打回进入到开发的深渊中去。

让我们设想一个简单的场景，某位前端工程师需要从后端工程师那里获取一份API，但是该API还没有上生产。你可以通过使用模拟数据来解决这个问题，也可以部署一个预生产环境。这些方案都很不错。但是，与后端代码本身进行集成的敏捷性相比，它们就要逊色很多了。

类似于docker-compose这样的工具为我们创造了奇迹。新人所要做的全部工作就是安装某件东西。docker-compose这类工具所需要做的事情就是祈祷Docker已经为用户安装好了所有的东西，因此就可以跳过中间所有的步骤直接到编码环节即可。

关于各个运行时组件之间是如何进行相互通信的，这些工具的声明性特性都会提供一个概述。因此也使得对顶级架构的推理变得更加容易。

services:  redis:    image: redis:alpine    ports:      - "6379"    networks:      - frontend  db:    image: postgres:9.4    volumes:      - db-data:/var/lib/postgresql/data    networks:      - backend  vote:    image: dockersamples/examplevotingapp_vote:before    ports:      - 5000:80    networks:      - frontend    depends_on:      - redis  result:    image: dockersamples/examplevotingapp_result:before    ports:      - 5001:80    networks:      - backend    depends_on:      - db  worker:    image: dockersamples/examplevotingapp_worker    networks:      - frontend      - backend networks:  frontend:  backend: volumes:  db-data:

可移植性

除了在开发中有用外，Docker还使得生产代码打包变得更加简单了。这是因为它使开发和生产环境更加对称。这是12factor的dev/prod对等点的重要作用之一。

有一些很好的语言专用工具，比如rbenv(Ruby版本管理)和nvm(节点版本管理器)。这些工具使得即使在运行时版本出现错误匹配，也不会受到什么影响。如果代码依赖于一些不知名的本地二进制文件或特定的文件系统结构，那么功能可能会更加强大。

这就是由于容器做得太过于出色而产生的结果。容器允许将应用程序和所需要的环境组合在一起。

这种可移植性在混合云的设置上也发挥了作用。关于这一点，我无需赘述太多，只需要告诉你目前我们也正在迁移到混合云上面。

由于混合云供应商当时无法提供稳定的可靠性，而且支持度也不够，因此我们非常不满。我们决定转到IaaS(基础设施作为服务)中最出色的云上面，即AWS(Amazon Web Services)。

我们能够预见这种迁移将会很快发生。因此已经将应用程序迁移到Docker上运行了好几个月。当我们告别旧云的时候，整个过渡过程只花了几天的时间。

这种范围如此之大的迁移可能被认为是非常罕见的事件。但我也没觉得迁移后灵活度方面存在任何问题。

需要注意的是并不是迁移了所有的应用程序。托管的turnkey解决方案也许可以解决诸如监视和日志记录之类的横切问题。然而，这些都可以用更容易设置的开源解决方案来代替，并也会让你避免上云黑名单。

编制

如果问你是否需要某个编排系统可能不太恰当。如果问该系统你是想让它自我管理，还是希望在凌晨3点的时候叫来修理停机的人进行人工管理更恰当。

这个类比需要考虑很多运动部件。软件系统在运行时只会比这个更加复杂和分散。当面对网络分区时，它们就会遇到很多问题。

现在，容器本身并不能解决这个问题——事实上恰恰相反。他们短暂的天性使你的系统变得如此有活力。这使得在部署时很难在石头上设置依赖项。

扩展到集群化的基础设施，情况变得更糟。它达到了永远不确定您的流程最终可能运行在何处的问题。这使得定位和处理它们变得更加困难。但是，我们需要接受这种自然，从而给一整套解决方案让路。

我们尝试了几个集群系统。其中包括谷歌的Kubernetes、Mesosphere的马拉松和Hashicorp的Nomad。

我们在Docker自己的Docker集群上解决了大多数部署，使用的是AWS cloud生成模板的简单Docker。

首先声明表示您的系统的期望状态，它应该运行的服务。然后蜂群会不断监测你的容器的实际状态。它将在节点失败的情况下将工作负载重新调度到其他节点，从而达到预期的状态。它还可以通过重新配置新服务器来自我修复，因为节点不能恢复。

提供您自己的容器集群可能会逃避您的需求。然而，新的Caas(容器- as-a- service)平台正在涌现，通常没有比基础设施使用的额外成本。

当你有卡通鲸鱼的时候，谁还需要小猫。 

您将发现服务发现、负载平衡、软件定义的网络、持久存储、任务调度和筏筏共识。这保证了一个可怕但有趣的旅程，通过一个听起来很酷的行话。

削减基础设施费用

你没有必须要再去读那些“在切换到{ { rand_language } }之后，应该如何通过{ { rand_amount } }将服务器成本削减”之类的文章了，因为本文我会提出一些不同的方法。

如今，微服务风靡一时。我们已经在Beta Labs里面把应用程序分成了几个不同的服务。这样就可以把不同的开发语言和框架进行整合和适配了，而且还可以随时使用最好的工具来工作。

请对我做一些包容。因为我将试着用十个或更少的字来简单说明一下微服务的情况。

在读完12factor的“一个代码库，多重部署”之后，我认为每个服务都应该作为它自己的应用程序部署在PaaS术语中。这恰好是大多数PaaS定价模型的规模。

我们来简单算一下。在Heroku上运行一个Ruby应用程序的设置意味着至少需要运行两个web标准的dynos。如果一个应用程序的内存限制在512MB以内，那你每个月返回$50。

每月前端服务将需要$50 GB的。为后台添加一个运行的dyno进行简单处理，那么每月就是$25。

可能还需要一些轻量级的后端服务，比如带有自定义逻辑的中间件或代理，它可以使用1个实例。你可以轻松地超过每月100美元。

那是在我们开始讨论附加组件之前。为基本的Redis和PostgreSQL实例增加每月30美元。Heroku的Logplex只是流媒体。因此，如果您想让日志保持更长时间，您还需要添加一个可以跨应用程序共享的日志服务。

让我们看看如何能够做得更好。

一个VM每个(单一的)服务vs每个VM的多个(微)服务。数据提供者:Martin Fowler 

让我们借用Martin Fowler对微服务的描述。使用带有集群系统的容器，为动态扩展服务提供了一个很赞的合适的平台。

容器被放置在具有最多可用资源的节点上。所有节点共享一个内部SDN(软件定义网络)。因此，服务可以在不离开集群的情况下互相通信。

一个3 -node- strong集群运行的例子- voting-app 

让我们回到前面的例子。这样的系统适合3个节点，t2。基于微技术的Docker集群集群，每个月大约有50美元。你可以有3GB的内存。如果你敢这么大胆的话，你甚至可以有额外的空间来运行你自己的容器。

Heroku的dynos在CPU部门更有天赋，拥有8个虚拟内核。但是，除非您使用本机线程的语言运行，否则一个多进程/ dyno设置可能会使您发现512MB内存不够快。另外，如果您的工作负载是I / O密集型的，则不会有太大的差别。

不要误会我的意思，就像让DevOps一个非问题一样，它也没有比Heroku好得多。我并不是建议你或你的团队中的任何人单独行动，花上几个晚上学习如何在PostgreSQL中获得高可用性设置。我们将把苹果比作桔子。

尽管如此，我还是觉得很重要的一点是，你要为所有的可靠性和易用性支付额外的费用。有了这些，你就可以自己判断什么是真正值得的，什么是你可以自己做的。

哦，当我们在这里的时候，别忘了你可以在Heroku运行你的Docker容器。

固有安全性

在拿Docker平台与PaaS进行比较时，这种讨论可能不会产生多大的影响。然而，你会发现，如果是跟运行多个应用程序的Ubuntu相比，某些风险漏洞会大大降低。

为什么会有所不同呢?答案就是Linux容器。这个有趣的概念是由曾经那些很喜欢使用Heroku的人在阅读指南时提出来的，现在已经成为Docker的核心了。随之而来的是一个广为人知的安全特性名词:隔离。

试想一下在服务器中远程执行代码的最坏情况。听起来太牵强?查看ImageTragick。应用程序趋向于与容器有一对一的关系。应该将那些能够对该应用程序域产生破坏的进行隔离，保留选择在主机上运行的其他内容。

这与VM(虚拟机)在相当长的一段时间内提供的特性非常类似。VM有一个比较僵化的特性，需要更长的启动和供应时间，以及运行完整的操作系统。

人们几乎可以原谅，给他们更长的生命周期，对待他们更像宠物而不是牛。这允许运行更多的应用程序，并可能带来更多秘密的妥协。

在运行集装箱化应用程序的同时，降低了这种风险，这并不是说你就是对开发商的不当行为不管不顾了。例如，您不希望妥协访问主机的Docker守护程序。 但总而言之，集装箱化的环境确实有助于减少攻击面。

只要保持谨慎，不要让你的照片公开出来。

你可能会开始有好感了

这可能完全是由我们内心作为极客的一面而导致的，是一种偏激的鼓励,但…

作为一名工程师，如果觉得能够给自己带来快乐，那么就很有可能去研究新的技术，提升自己的技能。对于创业型公司的第一个阶段来说，这应该是它能够吸引别人的全部理由吧?

如果你决定采用Docker了，在未来的几年里，你肯定会发现它带来的好处。

结论

那么，Docker是一条通往天堂的丝绸之路吗?不是。

在Docker把粗糙的问题解决完之前我们能不能先用更稳定的工具来解决?可能。

作为创业公司，如果没有采用Docker，会不会肯定失败呢?绝对不会。

是否需要再投资采用容器?我会大声的告诉你“绝对需要”。

这些观点远不是初创公司独有的。我想说这些与公司的规模无关。请放心，我的想法绝不会损害Docker在公司中的声誉。

我们并不主张Docker是解决这些一直存在得问题的唯一方法。我们还没有怎么讨论它的缺点。

但就目前而言，它仍然是最接近我们上面提到的所有常见问题的一站式解决方案。

本文章来源：CSDN社区，用户：钱曙光，版权归原作者所有