Todavía no uses Kubernetes
(matt-rickard.com)Las startups en etapa temprana no deberían adoptar Kubernetes apresuradamente.
En la mayoría de los casos, todavía es demasiado pronto.
Para equipos pequeños (1 a 10 personas), es mejor usar un servicio de contenedores serverless.
(AWS ECS - Fargate, GCP Google Cloud Run)
13 comentarios
¿No es que
k8sya no es una cuestión de gustos, sino de supervivencia?Más allá de AWS, creo que hemos llegado a un punto en el que sí o sí hay que conocer
k8s.No estoy de acuerdo con esta opinión.
Creo que la única desventaja que tiene k8s es, precisamente, la curva de aprendizaje.
Aunque el equipo tenga unas 5 personas, al principio será difícil, pero una vez que se alcanza cierto nivel de dominio de k8s, es imposible volver atrás. La mejora en productividad que eso genera ni siquiera se puede comparar.
CI/CD, GitOps, despliegues canary, etc., se pueden hacer incluso sin k8s, pero hacerlo junto con k8s es más fácil de entender y más sencillo de administrar.
Como alguien que ha vivido personalmente una migración, decir que todavía es demasiado pronto
me recuerda a la época on-premise, cuando se dudaba en adoptar AWS Cloud solo porque resultaba desconocido.
No es una cuestión tan genérica como decir "concéntrate en el negocio"; me cuesta estar de acuerdo con decisiones que terminan atándote a alguna tecnología específica.
Si hubiera sido un artículo que recomendara aprovechar activamente PaaS como beanstalk/app engine/heroku, estaría totalmente de acuerdo, pero hoy en día es casi nula la ventaja que obtiene un equipo pequeño al elegir ECS/cloud run/docker swarm. Tal vez hace 4 o 5 años habría sido distinto.
Desde el punto de vista de costos, serverless es abrumadoramente más ventajoso.
Yo también estoy de acuerdo. En la mayoría de los casos,
docker-swarmo inclusodocker-composeson más que suficientesEsta es una opinión que también apareció muchísimo en los comentarios de Hacker News..... [1]
Me resulta un poco confuso porque el artículo parte de la premisa de que "Kubernetes es difícil".
Hoy en día el ecosistema de Kubernetes ha madurado bastante, así que, a menos que instales Kubernetes directamente on-prem, no es algo tan difícil.
Además, en la operación de Kubernetes uno mismo puede decidir hasta cierto punto el nivel de complejidad, y no es tan complicado armar una configuración básica. Claro, después, si le vas sumando todo tipo de add-ons, obviamente se vuelve más difícil.
También ya hay muchas personas que, como yo, conocieron un entorno de despliegue empezando directamente con EKS.
Para decirlo de forma concreta: no entiendo por qué configurar un
DeploymenteIngressbásicos de k8s (por supuesto, con la base de datos en un servicio administrado aparte) sería particularmente más difícil que configurar directamente AWS ECS Fargate, como dice ese artículo.Al final, en ambos casos igual tienes que configurar la VPC, el clúster, el CDN y el balanceador de carga... Incluso en los comentarios hay muchos que dicen que ECS les resultó más incómodo.
[1] https://news.ycombinator.com/item?id=31795160
Estoy de acuerdo. No creo que la configuración básica sea tan difícil, ni que el nivel de dificultad del mantenimiento sea tan alto. Si en la nube pasas una configuración compleja a una configuración en yml de Kubernetes, la verdad es que no podría decir qué tiene de mejor.
En nuestra empresa, como ya superamos los 100 desarrolladores, sentimos la necesidad de hacer la transición de ECS -> EKS, aunque a veces también nos arrepentimos un poco.
Dicen que "la operación de Kubernetes permite decidir por cuenta propia, hasta cierto punto, cuánta complejidad asumir", pero desde la perspectiva de alguien que no lo conoce bien, uno tiende a pensar que todo lo que se menciona dentro del ecosistema de Kubernetes debe ser necesario, así que termina metiendo de todo.
Dijeron que igual hay que configurar el balanceador de carga, pero creo que sí hay una diferencia entre que baste con conocer ALB y tener que conocer ALB + Ingress.
Así como no se necesita MSA en escalas pequeñas, Kubernetes tiene más cosas de las que uno imagina que hay que aprender, así que creo que sí es un overkill para organizaciones que todavía están en una escala donde hay que "concentrarse en la aplicación".
Aun así, si alguien ya dejó bien construido el entorno de Kubernetes, me pareció que desplegar aplicaciones encima de eso, al definirse con una forma más independiente de la nube, podría reducir un poco el efecto de lock-in.
Por lo que comenta, definitivamente parece que sí puede haber aspectos así. Creo que di demasiado por sentado las cosas que aprendí usando Kubernetes.
Y también reconozco que, como últimamente están saliendo demasiados add-ons en Kubernetes, es difícil decidir cuáles elegir.
Como no he tenido experiencia migrando, por ejemplo, de ECS -> EKS... me da curiosidad saber si, más allá del efecto de lock-in, hubo algo que haya mejorado después del cambio.
Ah, por cierto, mi experiencia la comento tomando como referencia EKS. Es muy distinto de instalar k8s directamente on-prem y operar uno mismo
etcdy el Control Plane jaja.Desde la perspectiva de alguien que empezó directamente con k8s, mientras leía el artículo pensaba más bien lo contrario: ¿realmente hace falta dedicar tiempo a aprender ECS...?
De todos modos, creo que no hace falta definirlo oficialmente de esa manera; primero habría que usarlo del modo que al equipo le resulte más cómodo.
Estoy de acuerdo con la postura de empezar con k8s.
Coincido muchísimo.
No solo en equipos de 10 personas; también soy escéptico con la adopción de k8s en empresas de un tamaño más o menos considerable.
Me parece que solo tiene sentido cuando el lock-in con el proveedor cloud llega a un nivel crítico, o cuando se usan infraestructuras como on-prem junto con la nube.
Creo que sí había algo de inercia en seguir sin pensar el stack tecnológico de empresas de nivel enterprise.
Justo apareció en Hacker News algo ordenado en un texto sobre eso, así que lo comparto.