#34699 Pues como la gente que desarrolla una aplicación que se ejecuta en docker. No necesariamente por ser un contenedor es elástico. Conozco varios devs que no tienen claro el concepto de stateless o que para que vaya todo rápido mantienen en memoria todas las sesiones de todos los usuarios indefinidamente en RAM. memcached, redis, que es eso?
#34711 un clásico, dockerfiles infumables con arranques que tardan 10 minutos en levantar, que aún te dicen que son escalables. Eso sí, actualmente no escalan porque esta pendiente de hacer 
Siempre dicen las empresas que diseñan sus arquitecturas para escalabilidad, seguridad, performance y patos y patas, y siempre es mentira. Ni cuacs tienen.
#34711 #34712 Hablo sin saber mucho de Docker y habiéndolo estado usando más fuertemente de forma reciente, pero... ¿no se supone que es mejor en términos de escalabilidad, manejar dockers distintos? ¿Estoy patinando mucho? xDDD.
Para un proyectito reciente, por ejemplo, manejábamos un Docker pequeñito para un NATS (servicio de mensajería muy dope), otro para una MongoDB, y otro para la app en sí. Al ser algo pequeño es difícil de saber si es lo óptimo, pero me tiene pinta de que en una arquitectura de microservicios, con un Docker para cada servicio, debería ser perfectamente escalable y no generar problemas.
#34715 Los Kubernetes son para lanzar containers pequeños pero de forma organizada, ¿no? Vamos, lo que venía diciendo. A mí tampoco se me ocurriría hacer dockers demasiado grandes, bajo mi humilde experiencia con ellos. Están muy guay pero me parece que cae de cajón que no son escalables ad infinitum.
Por qué Kubernetes y no docker-compose? No conozco ninguno de los dos, no pasó de levantar un contenedor aislado.
#34692 estoy en proceso de negociacion de salario y me preguntaba si negociaste tu salario o si tienes algun consejo
#34718 yo pediría hasta que digan que no pueden subir más, pero vamos, los salarios suelen ser buenos
#34714 Cada contenedor debe gestionar un solo servicio, sí.
Pero si una instancia de tu servidor de aplicación X puede gestionar hasta Y usuarios, en el momento en que empiezas a tener más (por un pico de demanda atípico, por ejemplo), el orquestador automáticamente instancia otro(s) contenedor(es) para poder atender esa demanda extra. También es el propio orquestador el que se encarga de configurar el balanceador de carga para incluir dinámicamente las nuevas instancias en el pool.
Por otro lado, el almacenamiento persistente no debería ser un contenedor, si no un servidor externo dedicado a DB, aunque para entornos de desarrollo y QA no es raro que la DB esté en contenedor, ya que así es de "usar y tirar".
#34717 Docker compose solo es una forma fácil de levantar stacks de servicios en un Docker/Docker Swarm. Kubernetes hace más cosas, como el tema del balanceo automático que comentaba antes.
#34720 Creo que entiendo gracias, yo ahora mismo como digo no paso de levantar una bd o algún contenedor aislado ya que solo desarrollo sin desplegar nada.
#34716 k8s tiene un montón de cosas ya integradas y un ecosistema open source muy amplio.
así a bote pronto, load balancing, service discovery y monitorización y mantenimiento de los componentes del sistema te lo lleva todo ello, y mil cosas más
#34728 Se nota que no conocen al pato, en la última viñeta quedaba perfecto un: “De aquí a un año me cuentas”.
#34733 Como te pille alguien que programé en CLIPS te mata. Pero claro, habrá dos personas en el mundo xD
