[翻译] 再见 docker

  |   2 评论   |   254 浏览

原文链接:https://technodrone.blogspot.com/2019/02/goodbye-docker-and-thanks-for-all-fish.html

早在20187月,我开始撰写一篇关于即将死亡的Docker作为一家公司(也可能是一项技术)的博客文章,但我还没有完成并发布该帖子,现在是时候实际发布该帖子了。

https://twitter.com/maishsk?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1019115484673970176&ref_url=https%3A%2F%2Ftechnodrone.blogspot.com%2F2019%2F02%2Fgoodbye-docker-and-thanks-for-all-fish.html

所以就是这样

当然docker仍然活着,大多数人也在使用docker。并且将在可预见的未来继续这样做(可预见的未来有多远 - 尚待确定)。我之所以选择这个博客标题是因为,我认为Docker作为一家公司的日子已经屈指可数,也许也是一项技术。如果我会用几分钟的时间放飞自我 - 我将与你分享我的思想。

多年前 - Docker是改变世界的公司 - 我们可以肯定地说 - 现在仍在改变世界。容器和容器背后的技术已经存在很多年了,早在docker这个词被人们想到之前,甚至变成了动词(“Dockerize all the things”),但是Docker是让大众消费这种技术的公司容器,简单易行。大多数技术公司(或者至少是那些认为自己是现代科技公司的公司)将使用Docker或容器作为其产品或管道的一部分 - 因为它非常有意义,并为整个过程带来了如此多的好处。

在过去的12-24个月里,人们逐渐意识到docker工作已经走上了正轨,而且技术无法为他们今天所拥有的东西提供额外的价值 - 并决定开始寻找其他地方额外的优势。

Kubernetes赢得了容器编排的战争,我认为任何人都不能否认这一事实。Docker本身采用了Kubernetes。总会有专门的玩家为Docker Swarm,Mesos,Marathon,Nomad提供特定用例 - 但事实上的标准是Kubernetes。所有3大云提供商现在都拥有一个管理的Kubernetes解决方案,他们为客户提供解决方案(因此最终会落幕他们自己多年来建立的自制解决方案 - 因为只有一个解决方案。每个人都在构建更多服务并提供更多解决方案,以吸引更多客户,增加收入。

故事已经完成,这没什么。接下来

有点闪亮的事情......目前,Kubernetes使用docker作为底层容器引擎。我认为Kubernetes社区了解Docker作为容器运行时(我特意使用这个术语)是尽快将产品推出门的最终解决方案。他们(明智地)很早就明白他们需要选择切换容器运行时 - 并允许Kubernetes的消费者做出选择。

该OCI(Open__Container__Initiative)(http://www.opencontainers.org/)-与它带来的Runtime规范- 它打开了大门,允许我们所有人使用除了docker之外的其他东西作为运行时。他们正在稳步增长。Docker不再是唯一正在使用的运行时。他们是社区的成长 - 慢慢地分享除了Docker之外如何使用其他东西的知识。Kelsey Hightower -多年来从CRI-O%20v1.0.0-beta.0)到容器再到gvisor一直在努力更新他的Kubernetes(很棒的工作 - 老实说),所有潮流的人都不再只使用docker作为底层运行时。今天有许多其他选择明确的容器katacontainers和名单不断增长。

大多数人(包括我自己)没有足够的知识和专业知识,如何将runtime换成他们想要的东西,通常只是默认开箱即用。当人们明白他们可以轻松地做出更换容器运行时的选择,并且知识就在那里并且容易随时可用时,我认为我们没有任何理由让我们再使用docker,因此Docker作为一种技术而作为一家公司将慢慢消失。与Docker提供的相比,即将推出的其他容器运行时将更快,更安全,更智能,功能更丰富(其中一些已经存在)。如果您拥有更好,更智能,更安全的产品 - 为什么人们会继续使用不再适合其不断增长的需求的技术?

对于Docker - 为了避免这种结果 - 我建议尽可能多地投入精力 - 为任何工作负载创建最佳的运行时 - 这样docker仍然是每个人都使用的事实上的标准。这个陈述的问题是容器运行时没有钱。Docker从未在运行时赚钱,他们在上面的企业功能和容器运行时上寻找收入。他们将如何解决这个问题 - 超出了我和本文的范围。

docker社区一直在稳步下降,事件的受欢迎程度一直在下降,新功能和公告的数量正在下降,并且在过去一两年中一直在下降。

有人告诉我一段时间 - 对事情说不好或给坏消息通常很容易。我们可以很容易地说这是错误的,这没有用,这应该改变。但是,如果没有对某些事情做出积极的改变 - 你就会成为“厄运和沮丧”,“死神”。不要成为那样的人。

我想听听他们的建议,并加上一些关于 - 这对你今天意味着什么。你应该开始投资了解这些其他运行时如何能够帮助你,适合他们的地方,增加你的知识和专业知识 - 这样你就可以为此做好准备而不会在其他人停止使用docker时感到惊讶,你发现自己不得不急于适应所有基础设施。我认为这是不可避免的。

这是我想在8个月前写的帖子......

触动我今天完成这篇文章的原因是来自Scott Mccarty的一篇文章- 关于即将推出的RHEL 8 beta -Enterprise Linux 8 Beta:一套新的容器工具- 以及我发布的推文

---------------------------------------------------------------
>> 博客地址:https://blog.mufengs.com
>> 邮箱地址:mufeng5619@gmail.com
>> 微信帐号:Do8080
>> Github : https://github.com/mufengcoding
---------------------------------------------------------------

评论

  • mufengcoding 回复»

    有关系啊,在熟悉目前实现的基础上,学习准备其他优秀的实现,作为备用方案。避免灾难来临时的无从下手。这大概就是作者想说的把

  • 88250 回复»

    只有用的人多的东西才会成为主流,OCI 可以看作是把 docker 实现中容易抽象统一的部分制定成规范接口,docker 作为标准参考实现。但话说回来,规范(Spec)在很多时候只是一种产品包装的噱头。比如 “XXX 厂商的产品实现了 XXX 规范”,实际上某些关键部分还是只能直接用底层实现。

    类似活生生的案例可以参考 Java 领域,Spring、Hibernate 这类实现引领着 JSR 规范,但实际开发中很少有开发者去用规范定义的接口,都是直接用实现,因为实现好用啊。 中间件厂商可以标榜他们实现了各种规范,而推动规范的也正是它们自己,联盟的城墙又高又厚了一些,完美。

    功能类似的同类竞品只要稍微有点思考能力,肯定是不会去实现所谓的规范,他们会另辟蹊径,从技术上打败已有规范,占领自己的山头,再次竖起另一面规范的大旗。

    没错,这是一个悲伤的故事。但和我们基层码农有关系么?

发表评论