Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
Kubernetes versus Docker Swarm, ¿cuál es el mejor? Y bueno, el mejor es Kubernetes.
Y se acabó la discusión. Cortemos la grabación, apagamos las luces y hagamos otras cosas, Kubernetes es mejor. Y se acabó.
Juan (00:07)
Listo, gracias, nos vemos.
Ya en este momento
hay muchas personas que ya te pusieron en su lista negra, estoy seguro.
Douglas (00:21)
Bueno, O hay personas que tal vez ahorita dejaron de ver el episodio y dije, bueno, ya contestaron mi pregunta, ya me voy. ¿Cuál es el mejor? Kubernetes, si que si nos vamos objetivamente, Juan, esa es una realidad. Si nos vamos a la tecnología como tal y las diferentes funcionalidades y servicios, Kubernetes es mejor, es una realidad. Pero la pregunta más apropiada sería,
Kubernetes versus Docker Swarm ¿Cuál es mejor para tu aplicación o tu equipo? Ahí la respuesta cambia. Ahí el enfoque es diferente. Eso es lo que vamos a hablar hoy. De esa manera lo vamos a afrontar hoy. Kubernetes versus Docker Swarm.
cuál es el más apropiado para tu aplicación o tu equipo,
Hola a todos y bienvenidos a un episodio más de Dev & Ops. Este es su podcast favorito en donde hablamos de tecnología, desarrollo, DevOps y su cultura en general. Y le doy la cordial bienvenida a mi amigo Juan Ramos. Juan, ¿qué tal estás?
Juan (01:24)
Hola Douglas, me encuentro muy bien, muy a gusto de tener esta plática nuevamente con vos, poder discutir estos temas que siempre son interesantes y para mí es como algo que me relaja mucho el venir a platicar de todas estas cosas que normalmente no puedo platicar con cualquier persona, que es muy interesante después de tener todo un día ajetreado, día estresante a veces, venir a platicar aquí.
estoy muy emocionado.
Douglas (01:56)
Qué bueno, qué bueno, y coincido con vos en esa parte. Me alegra poder tener estas discusiones, estas pláticas, que no se han seguido, sobre todo porque no todas las personas, y esto no es nada malo, ¿no?, pero no todas las personas con las que nos relacionamos son interesadas o apasionadas por estos temas, y por esa misma razón es que tratamos de compartir nuestras conversaciones con aquellas otras personas de la comunidad que tienen interés en estos temas.
Y bueno, hablando de eso Juan, pues el tema que pensamos discutir hoy, que por cierto es un versus, tenemos otro versus, donde ponemos dos prácticas o dos tecnologías o dos servicios uno contra otro y definimos cuál es el mejor. Aunque si no han visto nuestros versus anteriores que son el de GUI versus CLI y el de configurar tu aplicación con variables de entorno o con config files, son los otros versus anteriores.
Si no los han visto, les recomendamos que vayan a verlos para que ustedes puedan darse cuenta cuál es nuestro enfoque al momento de abordar estos temas y que al final procuramos que nuestras preferencias o nuestro sesgo particular no interfieran con un comentario objetivo. Eso es lo que intentamos. Esperamos a verlo.
Juan (03:07)
Sí.
Sí, al final cada quien
toma su decisión. Lo que tratamos de hacer es dar ciertos puntos que hemos encontrado nosotros en nuestra experiencia, con lo que nos hemos topado. Y obviamente, al final del día es inevitable tener ciertas preferencias cada uno de nosotros. Pero aún así, tratamos de exponer las cosas buenas de cada una de las tecnologías que hemos enfrentado. Y ya cada quien puede tomar la decisión acorde a su situación,
al stack que tienen de tecnología, de acuerdo a la realidad de cada quien.
Douglas (04:00)
Así es, no, así es, no pudiste haberlo dicho de mejor manera, Juan, y bueno, para arrancar, para arrancar ya con este Versus de esta ocasión, vamos a estar discutiendo Orquestadores de Contenedores, y vamos a irnos por los dos más conocidos.
aunque realmente hay solo uno que es el más usado, es una realidad, existen otros, aparte de estos dos que vamos a mencionar o que vamos a comparar el día de hoy, ¿verdad? Pero nos vamos a enfocar en Kubernetes versus Docker Swarm. Y la pregunta, Juan, ¿cuál es el mejor? Kubernetes versus Docker Swarm, ¿cuál es el mejor? Y bueno, el mejor es Kubernetes.
Y se acabó la discusión. Cortemos la grabación, apagamos las luces y hagamos otras cosas, Kubernetes es mejor. Y se acabó. Y sin...
Juan (04:52)
Listo, gracias, nos vemos.
Ya en este momento
hay muchas personas que ya te pusieron en su lista negra, estoy seguro.
Douglas (05:10)
Bueno, puede ser. O hay personas que tal vez ahorita dejaron de ver el episodio y dije, bueno, ya contestaron mi pregunta, ya me voy. ¿Cuál es el mejor? Kubernetes, si que si nos vamos objetivamente, Juan, esa es una realidad. Si nos vamos a la tecnología como tal y las diferentes funcionalidades y servicios, Kubernetes es mejor, es una realidad. Pero la pregunta más apropiada sería,
Kubernetes versus Docker Swarm ¿Cuál es mejor para tu aplicación o tu equipo? Ahí la respuesta cambia. Ahí el enfoque es diferente. Eso es lo que vamos a hablar hoy. De esa manera lo vamos a afrontar hoy. Kubernetes versus Docker Swarm.
cuál es el más apropiado para tu aplicación o tu equipo, verdad, y le pediría a las personas que nos ven y nos escuchan hoy que mantengan esa parte de la conversación o ese enfoque en mente a medida que progresamos, porque de nuevo, si nos vamos a la tecnología por sí sola, basado en hechos, Kubernetes es mejor.
Habiendo definido Juan el fundamento, la base, las reglas de este enfrentamiento, ¿verdad? Las reglas en las cuales se van a enfrentar Kubernetes contra Docker Swarm de lo contrario sería una pelea demasiado dispareja, como dicen, ¿verdad? Desde tu perspectiva como programador, porque yo sé que vos has trabajado con ambos, no sé si en ambos de manera tan directa, pero has trabajado con servicios, microservicios,
que se despliegan a ambos, tanto Dockerswarm como Kubernetes. Entonces me gustaría comenzar con tu perspectiva alrededor de esto, que nos dé como un pequeño resumen de tu experiencia con ambos.
Juan (07:02)
Bueno, en mi caso, al estar en las trincheras de los developers...
no suelo tener acceso a la configuración directa de los orquestadores y todo lo que es la infraestructura de las aplicaciones en las empresas donde he trabajado. Así que he trabajado con ambas tecnologías, he utilizado ambas tecnologías, sin embargo no he tenido un acercamiento tan directo con las dos. Con la que sí he tenido un acercamiento más directo y que la he utilizado
en proyectos personales ha sido DockerSwarm. A pesar de que objetivamente, como decías, Kubernetes es mejor,
Para los casos en los que me he visto necesitado por una tecnología de estas, me ha sido más fácil o más conveniente utilizar Docker Swarm. Esto va ligado a diferentes factores, debo admitir. El primero es que por motivos de tiempo no tengo la disponibilidad tan alta como para ponerme a aprender Kubernetes desde el inicio para entregar un proyecto que tengo uno o dos meses.
para entregarlo así que tengo que apañármelas con lo que ya sé y aquí yo creo que esa es la primera ventaja entre comillas de Docker Swarm y es que para los developers que ya utilizamos Docker en nuestro local pasar a Docker Swarm es es muy muy simple es bastante simple de hecho me da mucha pena el hecho de que el equipo de Docker Swarm no haya invertido tanto tiempo en esta tecnología
No sé muy bien qué habrá pasado, no estoy muy al tanto de cuál fue la situación de todo este equipo de desarrollo. Pero sí tengo entendido que en cierto momento ellos creo que se rindieron y dijeron bueno ya no vamos a invertirle tanto a Dockerswarm y es lo que es. Pero sí me da mucha pena porque realmente creo que si hubieran desarrollado algo tan grande y tan versátil como lo es Kubernetes, realmente se hubieran comido el mercado.
porque me parece una evolución muy natural el hecho de pasar de tu contenedor un Docker Run, un Docker Compose, a luego pasar a un Docker Swarm con ya los stacks y las reglas de deployment y todo eso. Así que bueno, en mi caso he utilizado más Docker Swarm, me refiero a yo configurarlo, yo poner todos los parámetros que requieren, porque han sido proyectos muy pequeños. Cuando digo pequeños, Douglas,
Me refiero a que yo despliego dos o tres servicios o aplicaciones y no necesito y yo sé que no voy a necesitar desplegar más. Entonces no voy a aprovechar las bondades que me va dar Kubernetes donde puedo generar nuevos DnS records, puedo generar diferentes recursos casi pues digamos de manera automática porque yo sé que ya lo que despliego una vez no va a cambiar. Lo que va a cambiar es las versiones.
estoy haciendo del código. Así que en ese caso he tenido esa experiencia más clara con Docker Swarm. Por otro lado, en mi trabajo y más precisamente actualmente donde trabajo, lo que se utiliza es Docker, perdón, Kubernetes. Y no hay ninguna duda del por qué. Estamos hablando de una aplicación que tiene número uno
de usuarios, número dos, son usuarios muy fuertes, estamos hablando de record labels en diferentes países, entonces...
Necesitamos una infraestructura que sea lo suficientemente robusta y lo suficientemente flexible para poder acoplarnos a cualquier situación de todas estas aplicaciones que estamos lanzando constantemente. Constantemente estamos lanzando diferentes microservicios, diferentes aplicaciones, módulos de aplicaciones.
un mismo microservicio puede tener una versión que es solamente para HTTP, otra versión que solamente se encarga de escuchar eventos, otra versión que puede ser gRPC, entonces necesitamos desplegar muchas cosas de manera muy más fácil para nosotros los developers, estoy seguro que la configuración no es tan fácil y menos a la inicia, pero una vez que ya está todo configurado como es el caso donde estoy, realmente para los developers es
muy fácil, es una maravilla realmente porque ya simplemente me preocupo por hacer mi aplicación, configurar dos que tres parámetros y yo sé que al final eso se va a traducir en un nuevo servicio en el servidor.
Pero bueno, por ahí ha sido mi experiencia Douglas con estas dos tecnologías donde dependiendo de ciertas circunstancias he tenido un acercamiento con una y otro tipo de acercamiento con la otra. Pero de nuevo es por mi background como developer, como alguien que no está confiando esto constantemente.
Douglas (12:30)
Sí, pero realmente que tu perspectiva es muy importante aquí, Juan, pues en primer lugar porque nuestro contenido y conversaciones van dirigidas tanto a desarrolladores como a personas de sistemas, operaciones. Pero también de manera directa o indirecta, todos en un equipo de todas las personas encargadas del ciclo de vida de una aplicación en cualquier empresa o equipo de trabajo que implementen Cultura DevOps, de cierta manera
interactúan con Kubernetes, como vos acabaste de decir, con el orquestrador de contenedores. En este caso Kubernetes, que es donde vos estás, pero cualquiera que sea. Porque en este caso vos mencionaste cosas como sabes qué parámetros agregar para que Kubernetes traduzca eso a un nuevo load balancer o a un nuevo servicio, a un nuevo record, etcétera. Entonces, aunque no lo configuras, toca interactuar y por eso tu perspectiva es muy importante aquí. Y yo creo que tal vez Juan que cuando
Juan (13:04)
Correcto.
Douglas (13:59)
partes que se mueven de manera constante eso es lo que le agrega complejidad no es como un reloj de los famosos relojerías suiza o las relojerías japonesas que tienen muchas partes y diferentes mecanismos o un reloj de esos baratos que fácilmente se mueve y pues ambos te dan la hora y te dan la hora bien pero el suizo tiene más complejidad
Juan (14:15)
jajaja
algo muy curioso lo que está mencionando porque bueno no lo había dimensionado
y creo que aquí tengo un sesgo debido al tipo de aplicaciones con las que trabajo constantemente en mi día a día porque en el día a día yo estoy trabajando con aplicaciones o sistemas que tienen múltiples microservicios que tienen múltiples productos o sea varias aplicaciones que al final se comunican entre sí que comparten recursos
diferentes usuarios, multi-tenants y cosas así. Entonces cuando llego a una aplicación que pues que se yo una aplicación de inventario de e-commerce no sé si categorizarla como una aplicación simple
Pero definitivamente es más simple que lo que suelo hacer en el día a día. Entonces ahí no sé cómo podría ser la métrica para decir que es más pequeña o si no es tan pequeña. Lo que sí marca la diferencia para mi Douglas es el hecho de como mencionaba
son sistemas y aplicaciones que yo sé de antemano que no van a requerir requerir estar haciendo despliegues tan dinámicos por decirlo de alguna forma y digo dinámicos por falta de un un vocabulario más extenso de este tipo de tecnologías pero me refiero a que como como decía no en mi trabajo si yo necesito un nuevo microservicio ya el departamento de de box me ha dado las herramientas
para simplemente escribir dentro del mismo repositorio una serie de parámetros y yo sé que eso se tiene que traducir en un nuevo servicio, un nuevo contenedor y pues por detrás va a hacer todos los
los malabares necesarios para alocar los recursos y todo esto. En cambio estas otras aplicaciones con las que yo he trabajado de nuevo, soy yo solo o un grupo muy reducido de personas donde no tengo que hacer eso. Si acaso pues...
una redundancia de servicios donde pues si se cae uno está el otro y a veces ni siquiera eso porque son aplicaciones que salen como aplicaciones piloto entonces es bastante reducido el presupuesto y bueno entonces allí es donde para mí son como más pequeñas por decirlo de alguna forma
y no tengo que complicarme la vida para dejar algo tan dinámico que al final no lo voy a utilizar pero bueno en aplicaciones más complejas y que tienen muchos usuarios obviamente ahí Kubernetes sería la solución
Douglas (17:16)
Sí, sí, no, mira, lo entiendo, ¿verdad? Lo entiendo perfectamente y yo creo que tal vez acá lo que yo trato de agregar o aportar, sí, sí, y me doy cuenta que tal vez no entendí así en tu comentario y que bueno que lo estás aclarando, Tal vez lo que yo trato de agregar aquí es no es que una aplicación pequeña o grande se define por su complejidad.
Yo creo que eso lo que trato de decir, porque puede ser un sitio de WordPress con WooCommerce y vender cientos de miles o incluso millones de dólares al mes con un sitio en WordPress o WooCommerce, o puede ser un...
Juan (17:46)
Ok
Douglas (18:07)
tienda con servicios, microservicios que interactúe con inventarios de diferentes lugares, ¿verdad? Con servicios de cola intermedio para guardar envase de datos y generar reportes y visibilidad y todo lo que se te pueda ocurrir. Y tal vez puede vender la mitad que lo que vende esta tienda de WordPress con WooCommerce porque depende de otros factores, depende del producto final, etcétera. Entonces, tal vez la parte que yo quiero porque me he visto en este tipo
Juan (18:27)
Sí.
Douglas (18:37)
de situaciones en el pasado donde la complejidad...
no necesariamente se traduce a que una aplicación sea grande o no. Va a ser más llamativa para alguien como nosotros que estamos en sistemas, a mí me va a llamar más la atención toda esa complejidad que mencioné, que tal vez es una tienda simple en WordPress, ¿no? Pero no estoy menospreciando ni tratando de exaltar otras cosas. Solamente aclarar o mencionar eso, ¿no? De que en la experiencia que yo he tenido,
Juan (18:48)
Ok.
Douglas (19:12)
complejidad no se traduce siempre en grandeza, o simplicidad de una aplicación no significa que no va a alcanzar grandes mercados o grandes cosas. Pero, muy de acuerdo con vos, entre más compleja llega a ser la aplicación, más necesidad de un orquestador como Kubernetes vamos a tener.
Y yo creo que tal vez esto nos da la plataforma para que iniciemos un poco más con él, como que le demos un poco más a este Versus, ¿verdad?
Juan (19:44)
Perfecto.
Douglas (19:46)
Con tu experiencia que nos has contado, creo que estamos definiendo claro que objetivamente Kubernetes es mejor. es, nace Cloud Native, verdad, y para quienes no sepan Cloud Native es aplicaciones que están preparadas y listas para correr en la nube, para interactuar con diferentes servicios en la nube. Y lo hemos mencionado antes, la nube no es necesariamente solo estos proveedores grandes, Amazon,
web services, Azure, Google, etcétera. También empresas con su propio data center tienen su propio anube porque interactúan con sus propios servicios internos como si fuera la nube por medio de APIs y servicios internos que son los que crean una nube al final. ¿Verdad? Pero Kubernetes es más cloud-native.
Kubernetes se integra con casi todo y cuando digo integra es prácticamente crear recursos con casi todo dentro de Kubernetes y fuera de Kubernetes desde records de DNS, certificados TLS, SSL, storage, diferentes tipos de storage en tus proveedores, alerta, monitoreo, se crean o se eliminan de manera automática, manejo de logs, exportar logs, etcétera, incluso infra
⁓ porque hay herramientas que corren desde Kubernetes porque Kubernetes funciona con recursos, crea recursos internos y esos recursos son los que...
definen el estado de cómo crea y cómo está modificando algo. Y tendencias modernas utilizan clústeres de Kubernetes para infraestructuras code para definir la creación de infraestructura, crear otros clústeres de Kubernetes, instancias, networking, subnets y todo lo que tiene que ver con infraestructura, incluso en Kubernetes. Entonces, por eso dijimos...
que objetivamente, como tecnología Kubernetes es más completo, es mejor. Ahora Juan.
Juan (21:54)
Kubernetes
es casi como las raíces de un árbol que se empieza a expandir y llega a la profundidad de nuestra infraestructura y está en todo lo que involucra nuestro sistema, ¿no? Bases de datos, servidores y otros tipos de recursos que creo que más adelante los vas a mencionar.
Douglas (22:16)
Sí, tal cual. Y Kubernetes es ese base de árbol que puede aguantar tantas ramas necesites. Tantas ramas necesites. Comparado con Dr. Swan, que sería un fundamento y un árbol sólido con algunas cuantas ramas donde es complicado querer agregarle más o es complicado querer modificar las que ya tiene.
pero sin embargo es un árbol fuerte y sólido con dado la referencia que vos hiciste, ¿no? ¿Verdad? Pero eso es la comparación y esos Kubernetes así de completo. Ahora, así como es de completo, es mucho más complejo de administrar.
Juan (22:48)
Sí.
Douglas (23:03)
verdad, muchísimo más complejo y esto Juan, porque aquí yo recuerdo cuando yo inicié con contenedores e inicié con Kubernetes, yo he contado esto un poquito antes en otros episodios, como alguien de sistemas, mi primera entrada a Kubernetes fue querer instalarlo, estoy hablando hace muchos años que creo que, ya no me acuerdo, como 2015, si no es que, por ahí.
Pero mi primera entrada fue querer instalarlo. No, fue antes, fíjate. Yo no recuerdo exactamente, pero fue antes porque estoy recordando acontecimientos personales que marcan un antes y después en mi vida y fue antes de eso. Sí, sí, sí, dan ese antes y después de Cristo, pero a nivel personal a mí, en mi propio calendario.
Juan (23:34)
Wow.
que te dicen qué año es.
Douglas (23:50)
Pero el punto que quiero hacer Juan es de que cuando quise entrar con Kubernetes como algodéis sistemas, mi primera introducción fue querer instalarlo. Y qué complejo, complejo. O sea, hay cosas complejas y luego está encima de ellos instalar Kubernetes, ¿verdad? Es así de complejo. A medida...
Juan (24:14)
porque no es solamente
descargar un binario o hacer un apt-get install y listo.
Douglas (24:22)
Si no es un apk install o un jump install y un archivo de configuración. Son múltiples servicios y tecnologías interactuando una con otra donde puedes instalar varias en un mismo servidor. Idealmente varios servidores, servidores individuales para cada una de ellas. Y high availability a cada uno de esos servicios que comunican entre ellos para no depender de un solo servidor en uno de ellos. Es súper complejo, ¿verdad?
Hoy en día tenemos servicios para cosas como Rancher Labs, ejemplo, sé que tienen, y yo lo he usado un poquito, para crear clusters de manera más fácil y con bastante abstracción, lo cual es fenomenal y muy recomendado. O también tenemos las versiones de tu proveedor de nube, ¿verdad? El Kubernetes de, el EKS, que es el Elastic Kubernetes Services.
de AWS, el AKS que es el de Azure, tenemos el GKE que es el Google Kubernetes Engine que con ese en particular no he trabajado, aunque solo escucho cosas buenas de ese servicio, verdad, simplemente pues hasta el momento mi interacción pues nadie ha estado ajusteado en la nube de Google, no que sea mala, simplemente ha sido cosas del destino, también está el de trabajar con el de Digital
digital ocean perdón y hay otros no pero aunque usemos eso y sea relativamente fácil aunque hacemos esa versión y sea relativamente fácil
ponerlas a correr, hay mucha complejidad, hay que instalar add-ons, hay que crear políticas, dependiendo de tu proveedor de nube que hay, Ambrose o Policies en AWS y para dar diferentes servicios. Con Azure se usa el Microsoft Entra, que es el nuevo Active Directory y maneja permisos y cosas internas y hay una complejidad alrededor de ello para correr los reales.
no solo bien para correr lo mínimo, para configurar lo mínimo a pesar de que usemos estas, estas versiones de los proveedores de nube, verdad, no solo es un clic y ponerlo a correr, entonces es complejo, pero pues ya sabemos que en IT normalmente complejo es igual a robusto, verdad.
es muy robusto por esa misma razón, pero es ahí donde empezamos a poner la balanza de qué nos conviene, en cuándo voy a usar esa robustez y bueno, definiendo que Kubernetes es más complejo, es donde queremos ver, es donde sale la pregunta, ¿qué es mejor para tu aplicación o tu equipo? Si Kubernetes o Docker Swarm, ¿verdad?
viéndolo de esta manera, verdad. Si tu aplicación va a beneficiarse de las funcionalidades complejas de Kubernetes, ese es como los parámetros que vamos a usar, ¿verdad? Si tu aplicación va a beneficiarse de las funcionalidades complejas de Kubernetes, si tu equipo tiene integrantes con suficiente habilidad técnica para administrar Kubernetes, ¿verdad? Vos ya lo dijiste cuando nos comentaste esta experiencia con ambos.
que inicialmente estas aplicaciones no se beneficiaban de lo que hacía Dockerswarm, perdón, de lo que hacía Kubernetes. O se pueden beneficiar, pero no llegaban a profundidad con todo. Entonces no era necesario. Y más o menos esa es la perspectiva que queremos seguir.
Juan (28:04)
Sí.
Sí, de hecho...
De hecho, creo que se cumplían ambos parámetros que acaba de mencionar porque no iba a aprovechar todas las ventajas y las ventajas de Kubernetes.
Y yo tampoco tengo las habilidades necesarias como para ponerme a experimentar con Kubernetes. Que también en cierto momento he intentado, pero pues creo que no paso de la introducción de Kubernetes y digo no, mejor regreso a mi cPanel que es más facilito.
Douglas (28:46)
Bueno, vamos a tener que hacer algo porque regresar a cualquier cosa menos a cipano.
Bueno, pero...
Juan (28:53)
Pero
con estas métricas que estás dando, habilidad más aprovechamiento de las ventajas.
pues en la experiencia que he tenido, ya lo mencionaba este tipo de aplicaciones, pues no cumplía con esto. Y es que a veces también Douglas creo que hay que tomar en cuenta. Y esto lo vemos cuando te toca arquitectar un sistema, cuando sos el responsable de dar un entregable, de entregar un producto.
ya te das cuenta que no estás para empezar a experimentar y jugar. Tenés que jugar alrededor de lo que sos capaz de hacer. Y eso es muy importante. Cuando estamos haciendo, qué sé yo, un proyecto de clase, pues no está de más intentarlo. Yo personalmente he hecho ciertos proyectos de clase donde la asignación era una y yo me fui 180 grados porque quería probar nuevas
tecnologías y ese tipo de cosas. Pero cuando tenemos que entregar algo que es real pues ni modo, hay que ajustarse a lo que uno realmente puede hacer y que realmente te de un producto terminado.
Douglas (30:12)
Si, fíjate que eso que acaba de decir de los entregables, teniendo eso en mente realmente pesa al momento de elegir y lo vamos a ver un poquito puesto en práctica más adelante. Sin embargo, ahorita que estamos ya entrando a las cualidades de este versus de Kubernetes versus Docker Swarm, recordando que lo estamos haciendo desde la perspectiva de qué es mejor para tu equipo o aplicación, no cuál es mejor como tecnología en sí. Y aquí quiero aclarar algo, Juan.
que va a contrastar un poquito con algo que vos mencionaste antes de que es fácil brincar de docker
Juan (30:47)
Ok.
Douglas (30:52)
en el caso de orquestador de contenedores. Y es que en realidad se requiere de un conocimiento entre básico e intermedio de ciertos servicios y tecnologías para realmente manejarlo. Yo creo que tal vez te estás separando un poco el hecho de que...
vos le dedicás tiempo a muchas otras cosas fuera de tu área y que eso te hicieron fácilmente transicionar hace unos cuantos episodios atrás nos compartiste como estas trabajando en tu home lab
En tu propio HomeLab y como manejas tus propios servicios, lo cual no es muy común entre developers, entre desarrolladores, sin embargo es muy recomendado y vos mismo de tu experiencia lo compartiste porque te ayuda a entender muchas cosas, ¿verdad? Recordemos que estamos hablando, volviendo al tema de Docker Swarm, orquestador de contenedores.
lo que significa que hay que tener ya un conocimiento entre intermedio y avanzado de contenedores por sí solos. Antes de pasar a orquestar algo, tienes que saber trabajar muy bien con la unidad.
Entonces, eso por sí solo requiere que alguien realmente trabaje con Kubernetes. Encima de eso, hay que entender conocimientos de lo que es un load balancer, de lo que es storage en la nube, de lo que son DNS records, de lo que son TLS, SSL certificate. ¿Verdad? Que muchas personas solo saben que eso no da el HTTPS, pero realmente, ¿cómo funciona? ¿Cómo...
¿Cómo se genera uno, ¿Cómo se crea un... perdón, cómo demostras que ese es tu dominio para que te den un certificado de seguridad? Hay que entender eso, aunque sea lo básico. Networking básico, VLANs, VPCs, ruteo interno, hay que entender esas cosas básicas. ¿Qué es un ingres? ¿Verdad? Entonces, ¿por qué aclaro esto? Porque si bien es cierto, hemos dicho que...
Dr. Swam tiene menos complejidad, no estamos diciendo de que la curva de aprendizaje es cero. Nada que ver, nada que ver. Sin estos conocimientos, realmente por pequeño que sea el equipo o por poco compleja que consideres tu aplicación, sin estos conocimientos no vas a lograr lanzarla en contenedores. Es realmente así de simple.
No sé Juan, uno que pensas y dos, si sentís que hay un conocimiento, ya sea básico, intermedio o avanzado que agregar para realmente poder comenzar a trabajar con orquestadores de contenedores.
Juan (33:44)
no lo había pensado para ser honesto y eso es algo que me pasa muchas veces que... Olvido lo que ya he recorrido.
y pues asumo a veces que ya estoy dado ciertos conocimientos que ya deberíamos tener pero tenés mucha razón el hecho de que Dockerswarm sea menos complejo que Kubernetes no significa que no sea complejo en su totalidad porque en Dockerswarm hay que manejar muchas cosas como lo que mencionabas, el load balancer podemos decidir si una aplicación vamos a lanzar múltiples réplicas
estas replicas van a ir a un worker, un manager o a un nodo en específico podemos definirle diferentes limites de los recursos que queremos asignar y son cositas que uno va pues aprendiendo poco a poco de hecho cuando estaba iniciando con mi HomeLab
En cierto momento, creo que te comentaba esto, Douglas, pero lo comparto a la audiencia. Yo quería implementar Kubernetes porque he visto que en la comunidad de HomeLavng cada vez están utilizando más Kubernetes porque hay ciertas versiones, creo que esa sería la definición correcta, versiones de Kubernetes como más light, más ligeras que las están corriendo en servidores caseros.
No lo hice porque el hardware que yo tengo, siento que no iba a dar la talla, entonces me fui más por el camino un poco más fácil, pero definitivamente es algo que aún no tengo en la mira porque me gustaría hacer un upgrade. Hay cosas que se pueden hacer con Kubernetes que con Docker Swarm no se puede.
y bueno, pero son parte de las cosas que se tienen que hacer. Pero bueno, regresando a lo que mencionabas, los conocimientos básicos, intermedios, definitivamente hay que saber los recursos, cómo está arquitectada la infraestructura, dónde vas a desplegar todo, tenés que saber un poco...
aunque esto normalmente viene por parte de los developers, esta es una información que viene de los developers, cuáles son los límites, cuáles son los recursos necesarios para que una aplicación se ejecute correctamente y pues todas estas partes que llevan estas ramificaciones.
Hace unos episodios atrás tuvimos un taller en vivo con Douglas. Lamentablemente no lo pudimos terminar como queríamos, pero pudimos mostrarle a la audiencia cómo hacíamos un despliegue de una aplicación con dos que tres servicios y vos explicabas, recuerdo, la parte de Kubernetes y cómo podías manejar todo, ¿no? Todo, desde la base de datos, el caché que se va a levantar, todo, todo. Y pues de mi lado yo solamente me...
sola, entre comillas, me dedicaba pues a especificar cómo iba funcionar la aplicación. bueno, sí, es un conocimiento que se va transfiriendo y a veces también son cosas que se van dando poco a poco. En mi caso no he tenido la oportunidad o no he tenido el tiempo libre o algo que me motive a dedicarle más tiempo a Kubernetes.
cosa que no lo hice en su momento, antes le dediqué más tiempo a Dr. Swarm porque pues es lo que estaba y pues hoy en día es un poco más difícil por mi situación personal pero definitivamente Kubernetes vale la pena y es algo que no
Bueno, lo que quiero decir es que si alguien se está como desanimando un poco porque escucha que es muy complejo, la realidad es que no vamos a aprender todo de un solo. Estoy seguro que Douglas, que tenés tu experiencia muy amplia en Kubernetes, pues al inicio fue poco a poco. Entonces la gente tiene que tener eso en cuenta también.
Douglas (37:51)
Sí, no, mira, muy de acuerdo con vos y pues me gusta que nos des tu perspectiva porque de nuevo yo tenía esa impresión cuando hiciste el comentario de que tal vez estabas asumiendo algunas cosas y olvidando el camino que vos has recorrido y las cosas que sabes por las cuales dar el salto de docker en tu local.
a Docker Swarm no te fue complejo, ¿verdad? Y con lo que dijiste respecto a la experiencia que por gracia de Dios tengo hoy en día y es similar a cómo vos has crecido también en tu propia área, me gustaría que contemos una experiencia y digo contemos, Juan, porque resulta un poco gracioso, a la vez interesante, que la primera experiencia real de con contenedores
en producción, porque Estador de Contenedores en producción fue trabajando juntos en un proyecto que fue migrar aplicaciones monolíticas a servicios y microservicios y aparte de eso pues dockerizarlas y lanzarlas en DockerSwarm. Y porque quisiera contar brevemente la experiencia.
Juan (38:52)
sí.
Douglas (39:09)
porque en su momento, y bueno, luego vos nos vas a dar tu perspectiva también breve, Juan, pero en su momento estuvimos investigando cómo implementar los orquestadores de contenedores y por qué herramienta decidirnos, ¿verdad? Y alguna de las cosas que nos llevó ahí fue uno, ver la complejidad de...
de Kubernetes comparado con la complejidad de los servicios que íbamos a lanzar nosotros inicialmente, pero no solo inicialmente, sino que un pequeño roadmap que nos incluía algunos cuantos años en el camino y que nos diera a avanzar. Y segundo, el hecho de que nosotros estábamos trabajando esta empresa en la que nosotros estábamos tenía sus propios data centers.
en diferentes localidades, eran dos data centers principales grandes y había otros pequeños por ahí. Pero ese tipo de situaciones nos hizo ver de que iniciar aprendiendo Kubernetes, luego instalando y manteniendo Kubernetes y luego dockerizar aplicaciones, luego tratar de hacerlas trabajar juntas, si hay CDPyplans y todo ese tipo de cosas.
Juan (40:26)
jajaja
Douglas (40:29)
Fue ahí donde nos dimos cuenta que Docker Swarm no sólo tenía lo que ocupábamos, sino que todavía nos daba espacio para crecer, espacio para implementar cosas nuevas, de nuevo, aun sabiendo que eventualmente estas aplicaciones iban a crecer más, pero no iban a crecer más en complejidad en dos o tres años. Y era un proyecto un poco extendido en su momento.
Y eso nos llevó a escoger Dr. Swan, Y es una decisión que no solo no me arrepiento, por el contrario, me parece que fue la mejor decisión. Quiero aclarar que hay circunstancias específicas.
Yo creo que ya fue claro, ¿no? Es propio data center, sabía que manejar todo de manera interna. Nosotros mismos administrabamos absolutamente todo desde el storage, load balancer, los servidores, las instancias, etcétera, etcétera, etcétera. Todo lo que se maneja por nube. Nosotros, cuando digo nosotros, me refiero al departamento de Sysadmin y SRE. Manejábamos absolutamente todo ese tipo de cosas. Y encima de ellos, Juan, las personas que estábamos en SRE,
Juan (41:31)
Claro.
Douglas (41:38)
ese momento recuerdo que pudimos crear una estrategia para administrar Swarm con prácticas de GitOps. Para quienes no saben GitOps en Kubernetes es muy utilizado para la configuración tanto del Closer de Kubernetes en sí como de las aplicaciones que corren en Kubernetes.
Y hay muchas herramientas y hay dos o tres que son muy utilizadas y muy adoptadas por la comunidad, sin embargo no existe una sola herramienta de GitOps para DockerSwarm.
No existe una sola. Y nosotros el equipo de DSRI en ese momento creamos una estrategia de GitOps para utilizar con Docker Swarm. Esa estrategia fue tan buena, que luego yo ahorita donde estoy en field, antes se llamaba 10 Up, ya lo he mencionado yo.
Uno de los clientes bien grandes, no digo el nombre del cliente por motivos de seguridad y es parte del profesionalismo, pero usted ya me ha escuchado nombrar los clientes grandes con los que yo tengo la oportunidad de trabajar y uno de esos bien grandes tenía su infraestructura de todo lo que tiene que ver Blogs corriendo en Docker Swarm y yo tuve la oportunidad de implementar esa estrategia de GitOps en Docker Swarm manejando archivos de configuración, manejando los despliegues,
múltiples ambientes y eso fue una configuración muy muy robusta y les acabo de mencionar que uno de estas empresas grandes y reconocidas a nivel global usando Docker Swarm. Entonces
Juan (43:19)
O sea,
trajiste una estrategia que habías implementado anteriormente cuando iniciamos y que ya fue testiada básicamente esa vez que funciona y estoy seguro que ahora le introdujiste un poco más de lo que has aprendido a lo largo de los años y pudiste desarrollar algo que quedó un poquito mejor incluso, me imagino yo.
Douglas (43:41)
Sí, sí, así tal cual quedó, mejoró, mejoró y realmente, bueno no es por nada, no, al final en ese tipo de cosas los hechos hablan, no fue un poquito mejor, realmente fue mucho mejor, ya era muy buena y ya llegó un punto de excelencia a ese nivel, a ese punto, ¿verdad? Pero así fue como nosotros decidimos entrar a...
Juan (43:45)
jajaja
Ok.
Douglas (44:04)
a orquestadores de contenedores y por eso nos decidimos con Docker Swarm y por el tiempo que estuvimos ahí, utilizamos Docker Swarm y nos permitió crecer bastante e implementar muchas cosas. Pero Juan, contámos vos ahora por favor tu lado de la historia porque a vos te tocaba la parte del desarrollo de los servicios y microservicios, pero nos tocó colaborar mucho, sobre todo con lo que tenía que ver con Ingress, los servicios, el balanceador,
el API Gateway que se implementaba, etc. Entonces, contanos tu lado de la experiencia, por favor.
Juan (44:42)
Fue un realmente fue un proyecto muy interesante no estoy seguro de cuántas personas han tenido la la fortuna voy a decir de enfrentarse con un desafío como ese porque hay que ponernos en contexto donde veníamos de tener una aplicación monolítica
se hacían deployments de manera manual a servidores, ⁓ a VMs y luego todo cambió, fuimos de cero a cien, ¿no? El hecho de implementar CI, CD, implementar contenedores, implementar orquestadores, todo esto fue al mismo tiempo.
y realmente éramos, si no me equivoco, éramos un equipo muy pequeño. Claro, sin mencionar pues o sin tomar en cuenta a los managers que estaban pues dirigiendo todo. Estaba, recuerdo al no recuerdo el nombre del puesto, pero era quien hacía toda la arquitectura del diseño de la aplicación y realmente fue muy interesante para mí el hecho de trabajar de esa manera donde estás aprendiendo.
mismo tiempo tenés que entregar algo. La ventaja que tuvimos nosotros y es que la ventaja creo yo más grande es que nos dieron el tiempo suficiente para investigar e implementar, investigar, testear e implementar.
eso creo que fue una ventaja muy grande que estoy seguro que no es a cualquiera hay muchas personas que les dicen bueno necesito esto para el próximo mes y pues a ver cómo sale desde el lado del desarrollo realmente creo que allí es donde fue una
algo muy bueno el hecho de haber utilizado Docker Swarm creo que fue la mejor opción como mencionabas porque los developers nuevamente estábamos aprendiendo sobre el concepto fundacional de lo que era un contenedor y al mismo tiempo teníamos que preparar estas imágenes y recuerdo invertir mucho tiempo en aprender y entender cómo funcionaba el Docker File entender cómo generar una imagen, dónde se iba a alojar
esta imagen de Docker y cómo incluirla en todo en el pipeline del Continuous Integration realmente fue algo muy muy interesante y creo que ahí es donde pues a veces olvido ese proceso tan
intenso diría yo de aprendizaje que tuvimos ahí es donde pues al menos de mi parte yo afiancé muchos conocimientos sobre lo que eran los contenedores ¿por qué? porque literalmente de eso dependía nuestro trabajo teníamos que aprender esto sí o sí así que no fue algo que aprendimos por nuestra cuenta aparte y luego lo llevamos al trabajo de hey aprendí esto, intentemos que es muy válido y generalmente yo así he llevado
algunas ideas a la empresa en la que estoy pero aquí no aquí era éramos como el grupo de search and development básicamente así que muy muy curioso cómo íbamos aprendiendo obviamente sobre la marcha íbamos
haciendo algunos errorcitos y se iban corrigiendo poco a poco, ¿no? Pero creo que ahí es donde, de nuevo, Dockerswarm nos dio este margen de aprendizaje donde lo que ya estábamos implementando de manera local lo podíamos traducir con ajustes, entre comillas, mínimos, al ambiente de producción. Eso creo que fue muy beneficioso. Obviamente...
Todos sabíamos que con el tiempo sí o sí vamos a tener que pasar a Kubernetes. Esa es la parte que a veces muchas personas no toman en cuenta, creo yo Douglas. Si bien desde el inicio hemos dicho que la opción objetiva, la mejor opción objetivamente es Kubernetes, en ningún momento hemos dicho la mejor herramienta, correcto, sí. En ningún momento hemos dicho que Docker Swarm es una mala elección.
Douglas (48:52)
La mejor herramienta, la mejor herramienta efectivamente.
Juan (49:01)
Al contrario, que irónicamente hemos hablado muy bien de Docker Swarm y creo que eso es algo que muchas personas, menos, bueno, hablándonos de lo que veo en internet, comentarios y todo eso, muchas personas a veces creo que no le dan el valor que se merece a esta herramienta. Definitivamente es una herramienta que se puede implementar siempre y cuando no te limite, creo yo.
Douglas (49:30)
Sí, no, mirad, tal cual, tal cual y pues yo creo que la intención es simplemente que las personas que van a escoger, que están tal vez en ese momento de qué implementar, lo consideren...
Y miren si es su opción. Vos dijiste algo muy importante que nosotros sabíamos que eventualmente íbamos a necesitar Kubernetes. Sin embargo, habían tantas cosas como una de ellas en el roadmap, tampoco iba pasar. O sea, yo creo que lo más pronto que hubiese ocurrido eran de cuatro a cinco años en el roadmap que teníamos por tantas cosas que había que implementar en el camino. No esa es una de ellas. Y segundo, todo lo que había que implementar.
de la mano o en paralelo que el ir usando Dr. Swarm para ir entrando a ese mundo, para ir ganando esa experiencia a la vez que nos da tiempo de implementar otro tipo de cosas desde registry para las imágenes, pipelines, escaneo de seguridad y la cantidad de cosas que hubo que hacer en ese momento, Dr. Swarm nos daba ese beneficio y aquí estamos entendiendo y reconociendo que es situacional.
No todas las situaciones son las mismas. Si alguien me pregunta ahorita sin contexto, ¿qué aprendo? ¿Cubernetes o Dockers Farm? Yo le diría Kubernetes. Kubernetes. Pero si me das más contexto y me explicás un poco cuál es la proyección.
hay una posibilidad en la que Docker Swarm sea la mejor opción para vos, para tu equipo, para tu empresa. Y lo único que queremos con este Versus es que entiendan esas cosas. De nuevo, recordemos la perspectiva. ¿Cuál es mejor para tu aplicación o tu equipo? ¿Es situacional? La mayoría de los casos, y puedo atreverme a decir, la gran mayoría de los casos, ¿va a ser Kubernetes? Sí.
pero no todos, y es ahí donde es importante. Es ahí donde es importante. Y entonces, Juan, entrando a... Yo creo que no es la respuesta, y la respuesta ya está clara, y ya la dijimos y la hemos mencionado varias veces. ¿Cuál es mejor para tu aplicación? O ¿cuándo escoger cuál? Mientras no te limite, Docker Swarm.
o si no vas a aprovechar la mayoría de los beneficios que te genera Kubernetes con su complejidad, entonces es ahí donde Docker Swarm va a ser muy probablemente la opción para tu aplicación o tu equipo, ¿verdad? Se puede ver desde ambos lados, ambas opciones se encuentran en el mismo punto, ¿verdad? O la complejidad de Kubernetes no la vas a usar toda y no vale la pena.
o docker swarm no me limita y ahí se encuentran ambas y es ahí donde nos permite escoger ahora yo quisiera Juan ahorita dar algunos detalles de esas funcionalidades
que ofrece tanto Kubernetes comparado con DockerSwarm y en qué casos pudiera aplicar DockerSwarm y que eso termine de cerrar este circuito de cuándo es conveniente o cuándo gana DockerSwarm comparado con Kubernetes respecto de nuevo a tu aplicación y tu servicio. es que...
Ya dijimos claro que de los atributos grandes de Kubernetes, comparado con Dr. Swarmer, el hecho de que Kubernetes te deja crear recursos dentro y fuera.
del clóset de Kubernetes como cosas como records de DNS, storage fuera de Kubernetes, alerta para monitoreo, registrarse, autoregistrarse al servicio de manera automática, certificado de seguridad, etcétera, etcétera, etcétera, ¿verdad?
Juan (53:25)
Cuando
hablamos de fuera de Kubernetes, estamos hablando en otros servidores o siempre dentro del mismo cluster de servidores.
Douglas (53:37)
Sí, buena pregunta. hablando en otros servidores, Juan. Estamos hablando en otros servicios. Estamos hablando en otros proveedores. puedes tener corriendo tu servidor de Kubernetes en AWS y crear récords de DNS en Cloudflare.
totalmente fuera del mismo proveedor, así de potente. O puedes tener corriendo tu cluster de Kubernetes en Azure y usar Crossplane para crear clusters en AWS, crear infraestructura en AWS. Entonces, a eso me refiero con crear recursos dentro y fuera del... ⁓
del clúster, pero también puede ser dentro de la misma nube. Puedes pedir un storage y fuera del clúster de Kubernetes va a ir a AWS a darte un storage de acuerdo a la clase que estás pidiendo. Puede ser un EBS storage, puede ser un EFS que es como el mismo NFS, pero para AWS puede ser recursos fuera, puede ir a llamar a crear una nueva VLAN, puede crear un load balancer.
que está fuera del clóset de Kubernetes. fuera puede ser dentro de tu misma nube o puede ser absolutamente en otro proveedor incluso, dependiendo de lo que querés. Y Kubernetes puede hacer eso, ¿verdad? En cambio, Dr. Swan...
pues ofrece recursos como ingres interno que es el roteo interno, un servicio se va a ir a estas réplicas, arriba vos tenés que hacerle manualmente o de alguna manera un dos balancer para que se conecte a él, verdad, no lo va a hacer hacia afuera sino que va a ser un ingres interno, si te puede crear certificado de seguridad en ingres que esos sí son externos y los crea, valida externo y los crea adentro, verdad, entonces básicamente
Juan (55:31)
Ok
Douglas (55:33)
con esta comparación si tu equipo o tu app no está lanzando nuevas versiones, nuevas aplicaciones, no nuevas versiones, si tu equipo no está lanzando nuevas apps constantemente o tu app no necesita estar creando servicios externos de manera constante puede que Docker Swarm sea tu solución, verdad, porque no tienes que estar creando esos servicios.
Juan (56:00)
quitando y poniendo cosas.
Douglas (56:02)
o modificándolos,
¿verdad? O modificándolos cada cierto tiempo porque pues tomas el tiempo de configurarlo, vos creas el load balancer de manera manual, ya sea que te lo da AWS o tenés tu propio servicio de load balancer, vos creas tu DNS record, mandás a pedir el storage y lo configuras una vez y luego bajo eso mismo que hace Creo vas a estar publicando una y otra y otra y otra vez por el ciclo de vida de tu aplicación. Y si eso es lo que necesitas.
Dr. Swarm es suficiente. ¿Verdad?
Juan (56:34)
¿Cuál dirías
que es la funcionalidad más significativa que te haría cambiarte de Docker Swarm a Kubernetes? Claro, estamos hablando que te ofrece de todo, ¿no? Kubernetes te permite hacer todo. Pero ¿cuál dirías que sea la que en Docker Swarm definitivamente no lo puedes hacer o sería demasiado complejo que es mejor pasarse a Kubernetes?
Douglas (57:00)
Mira, me gusta esa pregunta Juan y es mucho más compleja de lo que crees. La respuesta. Entonces, si te parece, vayamos abordando la respuesta escenario a escenario. Porque cada escenario te va a llevar a ello. A veces puede ser lo que alguien creería que es lo menos complejo, pero dentro de tu aplicación eso es lo más complejo. Y si Dr. Swarm.
Juan (57:06)
Ok.
Douglas (57:23)
no tiene esa capacidad te va a obligar a moverte a Kubernetes. Puede ser no estás creando recursos afuera, no estás pidiendo a cada rato que se actualice una alerta o algo, pero puede ser una feature, una funcionalidad de seguridad o de aislamiento que Docker Swarm no te ofrece pero es crítico para vos y digas bueno la única manera es moviendo a Kubernetes, verdad. Entonces si te parece vayámosla respondiendo por escenario en este caso
Juan (57:42)
Ok
Douglas (57:53)
⁓
en este ejemplo que docker Kubernetes si crea recursos fuera del mismo cluster y docker swarm es más estático en ese sentido, sólido pero más estático, si ocupara estar creando mi aplicación o mi equipo constantemente recursos fuera, estar pidiendo storage, estar pidiendo records de DNS, estar pidiendo recursos alerta, mandar logs, todo de manera dinámica
Juan (58:02)
No
Douglas (58:20)
Ahí necesito Kubernetes, de lo contrario, do que su alma sirve. ¿Verdad? Do que su alma sirve.
Miremos otra funcionalidad, ¿verdad? Si tu aplicación no necesita, Advanced Scrolling. Y el Scrolling en un orquestador de contenedores es lo que define en qué nodo se va a levantar un contenedor, en qué nodo va correr, decide en este nodo va a correr. La complejidad, si tu aplicación no necesita, complejidad para definir en qué nodo corre.
Juan (58:28)
Ok
orquestador.
Douglas (58:56)
y probablemente lo que se llama es suficiente porque Kubernetes ofrece pod affinity o anti affinity para decirle a un pod, nodos que tengan esto, ahí corres o si tienen esto ahí no corres, verdad. Ofrecen taints en toleration para definir dónde puede correr, node selectors, seleccionar un node en específico y esto es muy importante Juan porque a veces uno puede crear nodos
o node pools, son pools con nodos, una piscina de nodos, para cierta funcionalidad yo puedo crear un node pools en Kubernetes que me corra con compute power alto.
O para procesamiento alto ahí puedo levantar o con memoria, rápidos en memoria puedo levantar cosas como REDI's, puedo levantar algo que me demande más, incluso un Elasticsearch, verdad, y entonces son esos nodos donde va a correr. Pero puedo tener otros nodos incluso con nodos ARM.
para manejar procesos más sencillos, más simples y los corro ahí y tengo todo eso parte del mismo Closor de Kubernetes y usando este Advanced Scheduling cualquiera de las que mencioné antes puedo decidir a dónde lo mando, verdad.
Juan (1:00:05)
ok
porque en su
arm creo que solo puedes elegir si es un worker, manager o ID.
Douglas (1:00:30)
Exacto, exacto. Entonces si nos vamos ahora a Swarm, Swarm ofrece cosas simples como correr x cantidad de réplicas de tu aplicación y te pide, tiene reglas básicas para balancear como vos dijiste si queres que corra un nodo, un worker o basado en una etiqueta que tenga el nodo y basado en esa etiqueta pues que balancee los contenedores entre esos nodos.
Juan (1:00:47)
pónete quieta, cierto.
Douglas (1:00:55)
funciones básicas en ese sentido, funciones básicas para reiniciar un contenedor si falla, verdad. Entonces, si tu explicación no necesita todo eso que mencioné que Kubernetes ofrece...
si un esquero básico que no es que es poco, no es es que es simple, pero es más básico y mucho más básico si lo comparamos con Kubernetes, ⁓ Por si no tienes que estar exacto comparado con. Entonces, si no tienes que estar haciendo eso, lo que suelo decirle te sirve suficiente porque puedes usar etiquetas para mandar el tráfico a ciertos nodos y eso lo puedes aprovechar para hacer ciertas cosas. Sin embargo, es un poco.
Juan (1:01:14)
jajaja
Claro, comparado con...
Douglas (1:01:37)
una estrategia un poco más manual y tendrás que documentar bien esta etiqueta para tal cosa, etiqueta, entonces si lo vas a hacer mucho y tu flujo depende de ello, yo me iría con Kubernetes, pero si ocupas, es hora de, correcto, ese puede ser el indicador, verdad, pero si tu flujo es un poco más, si ocupas algunos cuantos tipos de nodos, pero luego de eso,
Juan (1:01:50)
Ya es hora de...
Douglas (1:02:01)
no va a estar cambiando, Docker Swarm te va servir. Docker Swarm va a ser más que suficiente y si en tu equipo o vienen comenzando o no hay alguien que tenga la habilidad de Kubernetes, mientras no ocupes eso, no necesitas irte a Kubernetes. Si tienes a alguien que tiene la habilidad, pues lo puedes hacer ahí de un solo. Pero de nuevo, estamos poniendo la perspectiva de cuándo puede servir y cuándo no. Otro.
Si tu aplicación no necesita networking avanzado, Kubernetes te ofrece cosas como CNI plugins, ofrece políticas de networking, te ofrece bot to bot overlay, que no vamos a entrar a profundidad de todos estos conceptos, Juan, porque no es una clase donde estamos enseñando Kubernetes si no sabes qué es alguna de estas cosas. Y aún sin saberlo,
tu aplicación funciona bien, entonces muy probablemente es otro caso para el favor de Docker Swarm, ¿no? ¿Verdad? Pero si sabes que es ello y lo necesitas, si necesitas dual stack, correr al mismo tiempo de manera interna dentro del clóster IPv4 y IPv6, un ingres avanzado, reglas más complejas de ingres, pues necesitas Kubernetes.
Juan (1:02:59)
jejejeje
Douglas (1:03:21)
Porque ¿qué me ofrece Swarm? Me ofrece el networking overlay simple.
Es simple, pero claro, vos podés tener diferentes networks o diferentes billings de manera interna. No es que solo es una sola red interna y ya estuvo, pero es más simple. Ofrece un Service Discovery interno. Hice Service Discovery, me acuerdo que lo usamos nosotros bastante trabajando con API Gateway, porque cuando agregas, publicás o se agregan nuevas réplicas a tu servicio...
Juan (1:03:29)
Sí.
Douglas (1:03:53)
el auto descubre, sea, tiene sus funcionalidades, el auto descubre si alguna falla porque falló los health check, él la remueve, ¿verdad? O que su amor te ofrece ese tipo de cosas. También te ofrece Ingress básico con NGINX Ingress, que por cierto, NGINX Ingress va a ser dado de baja ahorita en este año que viene, se van a cortar el soporte porque pues simplemente
pues la comunidad que lo mantiene se ha vuelto como muy pequeña y es un poco complejo porque es una herramienta tan buena que eso lo vuelve que se necesita poco aporte y apoyo porque como todo funciona no hay nuevos pull requests, ¿verdad?
Juan (1:04:37)
otra herramienta
que ha matado a Kubernetes.
Douglas (1:04:40)
Sí, sí, sí.
Pero bueno, en fin, te permiten las reglas básicas de Ingress, Dockers Farm, y es mayormente pues para ruteo interno. Hacia afuera vos tienes que tener como yo decía tu load balancer para que lleguen las peticiones hasta ahí. Pero si vos con eso que mencioné que de nuevo no es poquito, solo que es mucho menos comparado con Kubernetes, menos complejo comparado con Kubernetes. Pero si las differentes bilans internas te sirven, el service de
discovery que es muy bueno, te sirve y el ingres básico, doctor son va a ser tu opción. Arriba de ahí vas a tener que irte Kubernetes, vas a tener que irte a Kubernetes así de simple.
Juan (1:05:25)
Que interesante, tantas cosas que realmente no tenía idea. Para ser muy honesto, pensé que ibas a mencionar algo como el auto-scaling. Como que tal vez esa idea. Pero wow, hay muchos otros escenarios que realmente no tenía idea, que si tienes razón, pueden hacer que un equipo necesite moverse a Kubernetes. o sí. Muy interesante.
Douglas (1:05:49)
Sí,
no, tal cual, tal cual Juan. Y interesante que digas auto scaling porque pues es el que sigue, es el que sigue, verdad. Si tu aplicación necesita un auto scaling complejo, mira que te ofrece Kubernetes. Kubernetes se ofrece algo que se llama HPA, que son siglas en inglés de horizontal, horizontal, ⁓ pod auto scaling.
Juan (1:05:58)
Ah, ok, ok.
Douglas (1:06:17)
son las réplicas o los contenedores y eso básicamente vos le puedes decir que lo haga en base a CPU o en base a memoria y cuando tenga cierta memoria que me agregue más réplicas eso es escalar de manera horizontal agregar más réplicas pero con Kubernetes me ofrece agregar leer métricas de otro servicio
The Prometheus me permite ver no solo mi servicio acá en los web servers, pero tal vez estar viendo si un query de la base de datos me devuelve x resultados, eso significa que hay que incrementar. O si una métrica de un servicio externo me está diciendo que tengo x cantidad de usuarios, ahí incrementar. Y no están basados en las memorias que te da ahí mismo él, ¿verdad? Él puede ir afuera a leer métricas. Y en base a eso, definir si escala o no escala.
lo cual es lo cual es muy muy potente, clúster autoskeler integrado en base al tráfico y entonces tu aplicación necesita nuevas réplicas pero no hay nodos para lanzar esas réplicas entonces Kubernetes puede pedir un nodo, hacer el provisioning, agregarlo al clúster y luego lanzar las réplicas ahí
y cuando el tráfico bajó entonces redujo la cantidad de réplicas porque no las necesito y entonces me quedó vacío ese nodo de nuevo y lo vamos a lo vamos a quitar para salvar, verdad. Incluso yo lo mencioné antes, un Kubernetes que tiene un servicio que se llama, es externo, un AeroScaler externo que se llama Carpenter.
que yo he estado trabajando con él, y este permite de manera fácil, estos nodos que se agregan o se eliminan pueden ser Spot Instances, que en la nube las Spot Instances son las más baratas, pero AWS te las puede quitar en cualquier momento, te da dos minutos de notificación y te las quita, pero es mucho más barata, o pueden ser Instances o Demand y pueden ser de diferentes tamaños.
puede ser que los pods que voy a agregar tienen bastante capacidad. Entonces voy a agregar una instancia grande para que vaya el nuevo pod en ella. O tal vez solo voy agregar dos pods y son pequeños. Entonces me voy a agregar al cluster una instancia pequeña para que no me quede ese espacio subutilizado y ahorrar dinero en la nube. Entonces Kubernetes ofrece todo ese tipo de situaciones.
¿Qué me ofrece Docker Swarm? Service autoscaling básico. Tienes tu aplicación con x cantidad de réplicas y pods y vos le decís mínimo tanto, máximo tanto y va a escalar y desescalar bien. ¿Verdad? No te ofrece autoscaling en base a los nodos que están en tu cluster. Sin embargo, pudieras aprovechar, pero ya esto te toca hacerlo manual, pudieras aprovechar un autoscaling de tu proveedor de
crear un auto scaling en AWS por ejemplo y basado en utilización de los nodos que agreguen o quiten y vos le agregas un proceso para que fácilmente se agreguen o quiten entonces te toca hacer cierto trabajo manual pero si todo lo que ocupas es agregar y quitar la misma tipo de instancia y no ocupamos más te va a tocar un poquito de trabajo manual pero ahí ya queda y lo que suave te sirve y te solventa ¿Verdad?
más que suficiente. si tu aplicación tiene como un tráfico predecible y estable, DocorSign va a ser suficiente, Pero si ya necesitas todo este tipo de cosas, considerando salvar costos, considerando que a veces va agregar más instancias, menos instancias, tráfico impredecible, etcétera, vas a necesitar Kubernetes, ¿verdad?
Pero de nuevo, tienes una aplicación donde vos sabes que tienes tres réplicas que van a estar utilizando un 70 % y que con un spike de tráfico van a subir a un 80, 90, está bien. O que eventualmente va necesitar un nuevo nodo y configurar el auto scaling de AWS para que él haga eso. No de manera interna, sino que el AWS lo va a hacer y ya con eso estás bien. No ocupas entrar a la complejidad, ¿verdad?
Entonces eso por...
Juan (1:10:39)
es increíble todo
lo que ofrece Kubernetes. Obviamente...
es algo que se sabe, se sabe o sea cualquiera que escuchado Kubernetes sabe que es muy potente pero ya cuando empezas a listar todas las funcionalidades me parece increíble y creo que es más increíble porque como te mencionaba he tenido más acercamiento con DockerSwarm y pues sé que en DockerSwarm se mantiene todo más pequeño o más contenido mejor dicho en cambio Kubernetes se expande hacia afuera
muy increíble. Definitivamente creo que es una carrera muy interesante cuando empezás a perseguir y especializarte con Kubernetes y todas estas tecnologías de la nube. Me parece que es muy interesante para cualquiera que le llame la atención y que quiera perseguir ese objetivo.
Douglas (1:11:36)
Por supuesto,
no, por supuesto. Es super interesante y a igual depende de tus funciones, porque si no es esa tu función, pues no vas a tener el tiempo. Pero por eso estamos haciendo esto porque, aunque sea esa tu función, si por un buen tiempo no vas a sobrepasar lo que te da, lo que ya te ofrece Dr. Swarm, no hay necesidad de entrar en la complejidad de Kubernetes, ¿verdad?
Y quiero mencionar uno más, Juan, no son los únicos, quiero aclarar, no son los únicos, pero quise nombrar algunos para que este Versus tuviera ciertos puntos de comparación, para que tuviera carnita y podamos escoger, para que cada quien pueda escoger, acorde a su contexto, su situación, su experiencia, su aplicación, su equipo, cuál le conviene, ¿verdad? Y el otro que quiero mencionar es que si tu aplicación no necesita aislamiento,
Juan (1:12:13)
ver a carnita.
Sí.
Douglas (1:12:32)
con namespaces, aislamiento es que el tráfico de una no se mezcle con la otra, que el recurso de una no se mezcle con la otra, o que los permisos de acceso de usuarios o de aplicaciones no se mezclen.
Juan (1:12:38)
Sí, sí, sí.
Douglas (1:12:47)
Entonces si tu aplicación no necesita eso, es muy probable que Docker Swarm sea suficiente porque Kubernetes me ofrece cosas como RBAC, son permisos granulares para diferentes usuarios con diferentes políticas y roles, ofrece los namespaces, que eso por sí solo aíslan los recursos que están corriendo y puede darle permisos a alguien, ya sea un usuario de una aplicación.
usuario para un proceso automático o un usuario o una persona real que sólo pueda ver esos ciertos namespaces. Ofrece cosas como service accounts. Los service accounts son cuentas o políticas que se le atachan o se le agregan a los pods. Entonces el pod se crea como un service account y ese service account tiene diferentes permisos.
Juan (1:13:34)
Ok.
Douglas (1:13:39)
Por ejemplo, si vos tenes un servicio del que te mencionaba, del cluster autoscaler, el que va agregar y quitar mas replicas. Esos son pods dentro de Kubernetes que están corriendo, están inspeccionando cuando ocupa servicio para pedir uno nuevo. Esos pods van a tener un service account pegado a ellos. Y ese service account tiene que tener permisos para...
llamar al API de AWS y tiene que tener los permisos para que decida al API de AWS que agregue una nueva instancia. Entonces, eso es un service account y puedes hacer lo mismo para interactuar con muchas otras cosas.
Y hay otros más que no, de nuevo no los voy a mencionar porque Kubernetes es bien amplio, pero en cuestión de aislamiento, Kubernetes se ofrece muchísimas opciones, sin contar, muchísimas opciones nativas, sin contar cómo te puedes agregar a otros servicios que estén validando esos permisos, esos privilegios, ¿verdad? ¿Qué te ofrece?
Juan (1:14:34)
jajaja
Los namespaces
para mi han sido bien útiles.
precisamente para mí cuando estoy revisando logs porque puedo irme directamente a un namespace en específico y todos los logs están asociados ahí y los puedo filtrar de manera más fácil y igual cuando estoy viendo las métricas de los servicios y todo pues de nuevo me permite filtrar de manera más fácil y ya sé de a veces ni siquiera sé qué es un servicio que estoy viendo pero sé que pertenece a un namespace
específico entonces ok sé si esto me va afectar o no para esta otra aplicación realmente es muy útil para para todo el equipo
Douglas (1:15:22)
Sí, sí, muy útil Juan en ese sentido porque la segmentación es importante uno por organización o dos por seguridad. Puedes tener un servicio que maneja transacciones de tarjeta de crédito y eso es que eres aislado tanto por seguridad interna como probablemente normas internacionales o externas o normas de tu país te van a pedir que donde o el banco que para darte permiso eso tiene que estar aislado y no cualquiera
Juan (1:15:33)
por seguridad.
Douglas (1:15:52)
pueda acceder a él. En Kubernetes eso es simple, aunque en el mismo cluster corren muchas aplicaciones. ¿Qué te ofrece Docker Swarm en este sentido? Básicamente es una seguridad flat. el cluster, casi que quien tiene acceso al cluster tiene acceso a todo. Pero mira, si tu aplicación, si solo corres una aplicación por cluster o si tu aplicación no necesita ese aislamiento, Docker Swarm es suficiente.
Juan (1:16:09)
Es un parque ahí.
correcto.
Douglas (1:16:22)
incluso
puede ser de nuevo, si vos tenés varias aplicaciones pero no van a estar cambiando constantemente, vas a estar publicando las mismas y tenés el servicio de tarjeta de crédito que es crítico, puedes tener el cluster donde solo corran servicios de tarjeta de crédito o solo esas cosas seguras y otro cluster donde corran otras cosas y con eso hiciste el trabajo y cumpliste, ¿no?
¿Por qué? ¿Por qué no ir a Kubernetes ahí de nuevo? Porque no va a estar ocurriendo tan seguido, no va a estar ocurriendo tan constante, ¿verdad? Pero en el momento en que más de eso, porque si fuera del aislamiento, ya si necesitas el RBAX, si necesitas Service Accounts con permisos específicos, si necesitas hacerlo más seguido o más dinámico, vas a tener que irte a Kubernetes, ¿verdad? Pero de nuevo, si tu aplicación no lo necesita y mayormente,
o encima de eso, agregado a eso, en tu equipo no hay alguien con la experiencia necesaria para manejar, administrar Kubernetes?
Dockerswarm va a ser suficiente y en el Versus que te vas a poner de qué herramienta escoger, es muy probable que Dockerswarm sea la que va a salir arriba, así como nos tocó a nosotros en su momento. Y esto no es una campaña en favor de Dockerswarm, hemos sido claros de que Kubernetes es una mejor herramienta y que en la mayoría de los escenarios Kubernetes va a ser. Pero estamos queriendo poner la perspectiva de que hay escenarios donde Dockerswarm sí es una solución más que suficiente.
y no hay necesidad de agregar esa complejidad cuando no se va a utilizar. son las opciones que quería dar Juan para que estuvieran en la balanza y cada quien haga la decisión acorde a su contexto y realidad. No sé qué queremos agregar ahí en ese sentido.
Juan (1:18:18)
Tengo muy poco que agregar en este aspecto porque estoy totalmente de acuerdo con lo que estás mencionando. Al final del día depende de cada quien que tome su decisión. Yo creo que aquí lo que me queda a mí claro Douglas con lo que hemos charlado el día de hoy es que...
Kubernetes es una gran herramienta siempre y cuando realmente la necesites. Y es necesario y vale la pena evaluar cuáles son nuestros requerimientos reales. Ya lo hemos hablado en otros episodios donde por la naturaleza de los ingenieros de tecnología siempre queremos saltar a las soluciones, herramientas que son más interesantes, más modernas. Pero muchas veces la
la mejor opción es la que entre comillas es la más aburrida o la que no te ofrece tantas cosas porque necesitamos algo que al final del día nos dé una solución y una solución que tenga sentido dentro de nuestro contexto porque bueno ya mencionaba Kubernetes tenés que estar tenés que no solamente en un solo servidor sino es un cluster con diferentes servicios etcétera pues eso también incurre en costos
Entonces si tenemos un presupuesto un poquito apretado, es una aplicación más o menos estática, entonces hay que evaluar bien lo que necesitamos. Yo creo que el mensaje con el que yo me quedo sería ese. Evaluar bien cuál es nuestra situación y contener nuestras ganas de probar nuevas tecnologías. Evaluar bien lo que necesitamos.
Douglas (1:20:04)
Sí, mira, me gusta, me gusta y la verdad es que voy a montarme, como dicen en esas, en esa reflexión tuya para llegar al cierre, ¿verdad?, para llegar al cierre. De mi parte, yo lo que les quiero mencionar o sugerir es no sobrecompliquemos las cosas en nuestro trabajo o equipo si no es necesario.
No agreguemos esa complejidad si no es necesario. Y en el versus de Kubernetes contra Dockerswarm, sobre todo si en nuestro equipo no hay alguien que tenga la habilidad de mantener un clóset de Kubernetes, sobre todo ahí no lleguemos a eso. Pero como decía Juan y echo a tus palabras, aunque yo sepa, aunque yo pueda, no es recomendable irme con Kubernetes.
si no le voy a sacar ese beneficio. Y en un buen lapso, ¿verdad? Muchas personas me han dicho a mí, yo recuerdo eso cuando iniciábamos y recuerdo por lo menos unas tres de estas situaciones donde decían, yo voy a empezar con Kubernetes para estar preparado para cuando la aplicación crezca.
Lleva, hicieron cinco años y seguían publicando la misma aplicación, sin nuevas funcionalidades, sin nueva complejidad, de nuevo no estoy diciendo...
Juan (1:21:24)
Con cinco usuarios.
Douglas (1:21:28)
No
estoy diciendo que era pequeña, pero era la misma complejidad por cinco años y aún en el roadmap que tenían no habían features que iban a agregar complejidad que justificaran Kubernetes. Sin embargo, el tiempo que les tardó implementarlos fue exagerado, Por la curva de aprendizaje que tuvieron que llevar. no siempre es así. Para nosotros fue, como ya lo mencionamos, de mucha utilidad haber comenzado con dos
no solo no me arrepiento fue la mejor decisión soy consciente que no va a ser el caso para todos pero queremos dejarles la reflexión de que analicen primero cuál es su realidad y miren si doctor swamp doctor swamp les va a resolver con todo lo que necesitan verdad
si no va a ser una limitante antes de pensar y saltar a Kubernetes. Juan, ¿alguna última palabra para cerrar?
Juan (1:22:28)
Bueno yo lo que estoy pensando es que necesito mejorar mi HomeLab, tengo que comprar nuevo equipo para poder instalar Kubernetes.
No, pero ya en serio la verdad es que, bueno número uno, muchas gracias Douglas por compartirnos estas cosas que vos has ido aprendiendo poco a poco, estoy seguro que son, yo personalmente no los he escuchado tan seguido o no los he escuchado para nada en internet ni nada de eso, que muchas gracias por compartirlo. Y dos, realmente pues Kubernetes me deja como una
un gran interés por ello pero también es un poco intimidante así que me no sé cómo verbalizarlo pero
me compadezco por decirlo de alguna forma o entiendo cuando una persona quiere iniciar en Kubernetes y se asusta realmente es complejo tiene muchas cosas es una es una gran como diría el tío Ben es una gran poder conlleva una gran responsabilidad pero realmente vale la pena en los casos en los que sí necesitamos Kubernetes vale la pena al 100 % bueno ya lo mencionaba yo al inicio
en mi trabajo, toda la infraestructura que ha sido creada con Kubernetes realmente ahora nos hace la vida más fácil tanto para nosotros como desarrolladores como para el mismo departamento de DevOps y SRE porque es muy robusto así que eso les permite a ellos ya dedicarse a otras cosas y no estar pues apagando incendios a cada rato así que realmente vale la pena Kubernetes también vale la pena
su arm, todo depende de la situación de cada quien. que eso es lo que la reflexión final, evaluamos bien lo que tenemos que implementar y elijamos acorde a lo que tenemos.
Douglas (1:24:33)
Bueno, palabras sabias y no hay mucho más que agregar a ellas así que con esta despedimos este episodio nos veremos en el futuro próximo. Bye.