Herramientas de usuario

Herramientas del sitio


contenedores:mirantis

Estado de Docker y Swarm tras su compra por Mirantis

Joaquín Herrero Pintado jherrero 2019/12/16 09:41

Calendario

13 de noviembre de 2019 Mirantis compra la plataforma Docker Enterprise

13 de noviembre de 2019 Docker Restructures

  • New investment to expand Docker Desktop and Docker Hub’s roles in the developer workflow for multi-service, hybrid cloud applications
  • Scott Johnston named Chief Executive Officer
  • Company recapitalization to strengthen financial position

13 de noviembre de 2019 Explicación en el blog oficial por parte del nuevo CEO Scott Johnston

15 de noviembre de 2019 Propuesta de la comunidad de renombrar moby/moby a docker/docker

Blog de Mirantis

¿Qué está comprando exactamente Mirantis?

Mirantis está adquiriendo el negocio de Docker Enterprise, que incluye productos, tecnología, IP y relaciones con clientes y socios, y se unirá a los ex empleados de Docker Enterprise para continuar brindando a los usuarios de Docker Enterprise una experiencia de cliente de clase mundial.

  • La tecnología de la plataforma Docker Enterprise y la IP asociada: Docker Enterprise Engine, Docker Trusted Registry, Docker Unified Control Plane, Docker CLI
  • Todos los clientes y contratos de Docker Enterprise
  • Alianzas tecnológicas estratégicas y programas de socios

¿Qué pasa con Docker Swarm?

El orquestador principal en el futuro es Kubernetes. Mirantis se compromete a proporcionar una experiencia excelente a todos los clientes de la plataforma Docker Enterprise y actualmente espera brindar soporte a Swarm durante al menos dos años, dependiendo de los comentarios de los clientes en la hoja de ruta. Mirantis también está evaluando opciones para facilitar la transición a Kubernetes para los usuarios de Swarm.

Comentarios de Drew Erny, desarrollador de Swarm

Drew Erny, @dperny desarrollador principal de Swarm, lo cuenta en este hilo de su cuenta de Twitter:

He sentido estas cosas durante mucho tiempo, pero nunca las transmití públicamente por razones obvias, así que aquí está mi Big Rant sobre mi decepción por la forma en que Docker trató a Swarm.

Cuando me uní a Docker, en la cima de su desarrollo y en el momento del lanzamiento, Swarm tenía como 7 ingenieros a tiempo completo en el equipo y algo así como otra docena más o menos trabajando de manera cruzada de otros equipos. No tengo idea de por qué dejaron de invertir en él. Que yo sepa, nunca hubo ningún memo, mensaje o decisión que dijera: “Dejemos que Swarm muera lentamente por negligencia”. Por el contrario, en Docker hubo una hemorragia de empleados y nunca se molestaron en sustituirlos. Algunos de ellos volvieron a lo que estaban trabajando antes. Algunos de ellos dejaron la compañía. Algunos de ellos hicieron lo primero y luego lo segundo. No me disgusto con ninguna de estas personas, a quienes admiro mucho y con las que me considero más que privilegiado de haber trabajado.

Estoy enfadado con Docker, Inc. por sentarse sobre sus manos y básicamente matar el proyecto por negligencia en lugar de tener el coraje de tomar una decisión. Por no solo decidir que querían seguir este camino, sino por mantener la puerta abierta durante tanto tiempo sin tomar ninguna decisión.

Íbamos a hacer muchas cosas geniales con Swarm. Por ejemplo, íbamos a construir una malla de servicio directamente en él. Hay un enorme pozo de potencial allí, y hasta ahora ha sido desperdiciado. No creo que nadie en el liderazgo se dé cuenta de lo que tienen con Swarm. No lo que tenían sino lo que todavía tienen en Swarm. La gente lo ama. Todos dicen que Swarm es muy fácil. Swarm es orquestación para las masas. Swarm obligó a Kubernetes a mirar detenidamente su propia interfaz de usuario. Como el 80% o un número disparatadamente alto de clientes de Docker (ahora Mirantis) estaban usando Swarm. Pero hacia el final, había más personas trabajando en Kubernetes que en Swarm.

Hablo mucho sobre ser “el último responsable de Swarm”. No soy la única persona que trabaja en ello e incluso implica que eso sería un tremendo insulto para las otras personas que hacen tanto trabajo para mantenerlo en funcionamiento. En este punto, y durante el último año, ni siquiera me he molestado en tratar de invertir tiempo en el desarrollo de Swarm a largo plazo. Incluso yo reconozco que el barco está navegando. Pero quiero desesperadamente, y le he estado diciendo a todos los que escuchen, que tenemos que terminar Swarm. Tenemos algunas características importantes ya preparadas que debemos completar. Mejor dicho, que yo debo completar y no he estado haciendo últimamente. Es algo así como 1 persona-año de trabajo, más o menos. Eso es todo lo que quiero porque entonces podremos decir que el proyecto está “terminado”. No “en desuso” o “descontinuado”, sino HECHO. Esto es lo todo lo que Swarm te ofrece, estas son todas sus características, tómalas o déjalas. Honestamente creo que si agregamos demasiadas funciones podríamos complicarlo innecesariamente y terminar alejándonos de lo que hace que Swarm sea Swarm.

Ahora trabajo para Mirantis, no para Docker. Me enteré de que en Mirantis usan Swarm, y espero que esto pueda darle un poco más de vida para poder terminar los fragmentos que considero más importantes. Desearía que hubiera mejores ingenieros que yo trabajando en ello. Eso no quiere decir que yo sea un mal ingeniero. Pero solía haber mejores ingenieros trabajando en Swarm y, probablemente, si se hubieran quedado ellos en lugar de yo, el proyecto habría ido un poco más lejos. Pero supongo que precisamente porque son mejores ingenieros que yo hace tiempo que se fueron a pastos más verdes.

En vista de lo anterior, qué estrategia es la mejor para el uso de Docker?

¿Está muerto Swarm?

Parece que no, según What Docker Inc's Reorganization Means For Docker Swarm | Autoize Europe

Actualización a marzo 2020: Bret Fischer habla con Brandon Mitchell (tercer máximo solucionador de dudas sobre Docker en Stack Overflow) sobre la situación de Swarm en 2020

Rancher Whitepaper

En esta comparativa Kubernetes vs. Swarm Rancher, que es una plataforma para desplegar clústeres tanto de Kubernetes como de Docker Swarm indican:

  • Las dos plataformas tienen construcciones y arquitecturas muy diferentes (nodos/tareas versus pods), por lo que la elección del orquestador no es una decisión reversible. Las aplicaciones tienen que ser diseñadas de una forma que estén estrechamente unidas al orquestador.
  • Lograr las mismas tareas es mucho más complejo en Kubernetes que en Swarm aunque, por otra parte, Kubernetes ofrece una gran cantidad de funcionalidades adicionales, como el autoescalado.

Loom Systems Whitepaper

En DevOps Kubernetes vs. Docker Swarm vs. Apache Mesos: Container Orchestration Comparison indican que Docker Swarm es más fácil de usar, más nativo de Docker y apropiado si no se necesita un escala mayor. Kubernetes es adecuado para configuraciones más complejas, si no se necesita escalar hasta miles de servidores. Mesos/Marathon es para grandes instalaciones que necesitan escalar a miles de servidores y/o necesitan establecer restricciones de programación basadas en host, racks o cualquier otra variable específica.

contenedores/mirantis.txt · Última modificación: 2020/05/14 22:40 por jherrero