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)
saber si Kubernetes es de verdad la solución que necesitas...
esa pregunta tuvo que haber sido respondida en esa etapa de investigación, lo que ocurre Juan es que vemos tanto Kubernetes, vemos a tanto grandes usar Kubernetes, queremos hacer lo que los grandes hacen que muchas veces forzamos entre comillas la implementación de Kubernetes, verdad, porque todos los usan. Kubernetes es una tecnología muy compleja.
Juan (00:26)
Sí.
Douglas (00:31)
es muy compleja para lanzar un sitio simple, llámese una página estática, un landing page, llámese un API sencillo,
Hola a todos y bienvenidos a un episodio más de Dev & Ops, su podcast favorito de desarrollo, tecnología, DevOps y su cultura en general. Y me acompaña como siempre mi buen amigo Juan Ramos a quien le doy la más cordial bienvenida. Juan, bienvenido, ¿qué tal estás para este nuevo episodio?
Juan (01:05)
Hola, Douglas. Pues muy bien. Muy bien de que estamos grabando juntos otra vez. A veces tenemos interrupciones por cosas que pasan. Pero siempre es bonito el formato tradicional de una plática en la que estamos conversando todas estas cosas que nos interesan, nos llaman la atención y que creemos que les va a servir a los que nos escuchan y que nos ven también.
Douglas (01:29)
Sí, además es la esencia de nuestro podcast, Necesitamos a Juan el Deb y a Douglas el Ops para complementar el Deb and Ops. Sin embargo, son los beneficios de la alta disponibilidad, la de redundancia. Cuando uno a nosotros se le complican las cosas, el otro normalmente puede estar disponible. Y de esa manera podemos entregarles a ustedes nuestra audiencia un episodio más como hemos estado acostumbrados ya por un año, Juan, por un año. Imagínate, increíble.
Juan (01:56)
Sí, ya, Como pasa el tiempo. Básicamente somos un pod de dos réplicas.
Douglas (02:02)
sí yo creo que sí
un pot de dos réplicas muy bien o dos dos réplicas dos pots bueno lo importante es que tenemos redundancia y aquí estamos y justo aquí estamos jugando con un nuevo tema y qué interesante que dijeras un pot con dos réplicas
Juan (02:13)
No sé.
Douglas (02:26)
porque hoy vamos a hablar de algo que tiene que ver con los pods y es de Kubernetes. Hoy quisiéramos, Juan, mencionar algunas consideraciones.
antes de implementar Kubernetes. Esto es, ya que te tomaste el tiempo de venir y decir, ok, necesitamos mover nuestras aplicaciones a contenedores. Sea aplicaciones móviles, sean REST APIs, sean microservicios o servicios, sean monolípticos, han tomado la decisión por los diferentes beneficios que conllevan moverlas a contenedores y están
han hecho su análisis, verdad, y dijeron vamos a implementar Kubernetes, es una decisión tomada. Y es que...
Kubernetes es la primera, muy probablemente, palabra o tecnología que aparece en nuestro tiempo de investigación cuando estamos queriendo implementar contenedores. O no es así, Juante, parece que hay otras palabras o tecnologías que surgen antes que Kubernetes en Google, en las búsquedas.
Juan (03:36)
Supongo que sí, supongo que sí saldría Kubernetes. Lo que pasa es que, bueno, cuando empecé a ver sobre el término y el concepto de contenedores, a mí lo que me parecía era Docker. Y pues me fui introduciendo a este mundillo con Docker y, bueno, ya lo hemos hablado en otros episodios. Nosotros también luego pasamos a Docker Swarm. Y aunque podríamos argumentar a favor en contra de cada uno, pues...
Desde aquel entonces no he vuelto a indagar, sea, ya no sé muy bien qué es lo que le saldría a alguien que es como primerizo entre este término. Pero definitivamente cuando empezamos a ver cómo desplegar aplicaciones a un nivel profesional, a un nivel de gran escala, alta disponibilidad y todas estas cosas, pues actualmente Kubernetes es quien tiene el 90, 90 y tanto por ciento del
del market share en la actualidad. De una u otra forma, vamos a llegar a Kubernetes.
Douglas (04:39)
Sí, no, fíjate que me gusta que lo dijeras porque en realidad que cuando buscas implementar contenedores en producción es cuando brinca Kubernetes. Cuando solo vemos contenedores definitivamente Docker, la búsqueda se va hacia lo local, hacia nuestro ambiente de desarrollo o hacia contenedores en general como tal, Pero cuando ya queremos implementar contenedores en producción Kubernetes es el que toma la delantera.
cuestión de información, en cuestión de sugerencias en internet y esto es lo que muchas veces lleva a muchas personas, muchos equipos, a muchas empresas a decidir implementar Kubernetes cuando van a migrar sus aplicaciones a contenedores. O también puede ser una empresa, un startup que viene comenzando.
Y estos van a lanzar el producto y escogieron Kubernetes por las diferentes razones que su propio descubrimiento, que su propio research les arrojó. Entonces Juan, pasemos a la primera consideración, ¿verdad? De un solo y aquí voy a tal vez causar un poco de controversia entre lo que he venido diciendo y la primera consideración y es que la primera consideración sería, asegurarnos que Kubernetes es de verdad la solución
que necesitamos, ¿verdad? No debería ser una suje... no debería estar entre las consideraciones porque ya dije que vamos a orientar el contenido de este episodio a que ya pasaste tu etapa de investigación y que ya decidiste implementar Kubernetes. Entonces, saber si Kubernetes es de verdad la solución que necesitas...
esa pregunta tuvo que haber sido respondida en esa etapa de investigación, lo que ocurre Juan es que vemos tanto Kubernetes, vemos a tanto grandes usar Kubernetes, queremos hacer lo que los grandes hacen que muchas veces forzamos entre comillas la implementación de Kubernetes, verdad, porque todos los usan. Kubernetes es una tecnología muy compleja.
Juan (06:50)
Sí.
Douglas (06:54)
es muy compleja para lanzar un sitio simple, llámese una página estática, un landing page, llámese un API sencillo,
necesitas mínimo dos pods, lo que estábamos diciendo, lo que estaba diciendo de nuestro podcast, necesitas mínimo dos pods para alta disponibilidad, verdad, y eso considerando que cada pod
puede tener varios contenedores. En Kubernetes el objeto más pequeño es un pod y dentro del pod está un contenedor normalmente, pero pudiera tener más de un contenedor. Entonces, pero vaya, ocupas mínimo dos pods y asumamos que cada pod tiene un contenedor, ocupas un servicio.
Para balancear la carga entre esos dos bots y para poder conectarte a tu aplicación para que pueda redirigir el tráfico hacia ella, ocupas un ingress para exponer ese servicio hacia el internet, hacia afuera, perdón, del contenedor, ya sea para acceso a otras aplicaciones internas o para acceso desde internet. Hay otros métodos, pero ingress es el que realmente se usa en producción para hacerlo de manera propia. Ocupas un deployment para poder...
lanzar todo esto. Entonces mencioné como cuatro o cinco diferentes recursos para un landing page o para una página estática o para la aplicación más simple que se te pueda ocurrir que si lo lanzaras en tu VM no ocuparas tanto.
Eso sin considerar que las aplicaciones van a necesitar, muy probablemente cuando ya trabajas con datos dinámicos y despliegue continuos, vas a necesitar config maps para configuraciones, secrets, volúmenes, entre muchas otras cosas, verdad. Entonces Kubernetes tiene bastantes partes móviles, eso lo vuelve bien robusto porque en cada una de estas partes móviles vos podés customizar, vos podés agregar seguridad, vos podés agregar límites, vos podés agregar
operaciones, chequeo de headers, inyectar cosas en cada una de estas piezas y eso lo vuelve muy robusto. Pero a la vez es complicado y si no vas a necesitar, no te vas a beneficiar de todo eso que el Kubernetes te ofrece, con lo más básico, no lo necesitas.
Juan (08:59)
Sí.
Douglas (09:13)
no lo necesitas, es la realidad, no trates de forzarlo. Si lo que quieres son contenedores en producción, orquestrados de manera correcta, lista para producción, que puedan escalar, que tengas ingres para entrar, tener los volúmenes, rollbacks automáticos si ocupas, los beneficios de contenedores en producción sin...
Sin la necesidad de la complejidad que le agregan los otros beneficios de Kubernetes porque esta aplicación no la va a usar, nuestra recomendación es Docker Swarm. Entonces, primera consideración, Juan es bien interesante, como primera consideración, realmente reevaluá.
Si Kubernetes es lo que queremos, lo que necesitas implementar, no estamos buscando desanimar a nadie, solo estamos buscando que tome una decisión correcta. ¿O te parece, O'Juan, que Kubernetes sigue así?
Juan (10:12)
No, yo creo que esta es como esas preguntas de ¿querés utilizar Kubernetes? Sí. ¿Estás seguro? Es como una doble confirmación porque a veces estamos tal vez muy emocionados porque descubrimos esta tecnología, queremos implementarla, pero el hecho de poder hacerlo no necesariamente significa que debas hacerlo.
Casualmente, el día de hoy, no tiene que ver con Kubernetes, creo que la situación es similar a este primer consejo que estás dando. En una reunión de trabajo estábamos hablando de diversos temas y un compañero estaba proponiendo crear como una base de datos de conocimiento.
el hecho de tener pues cómo funciona cada uno de los microservicios y tener todo muy bien estructurado y luego de alguna forma como conectarlo con la IA para poder hacer preguntas algo tan simple como bueno al momento de procesar este archivo qué sucede en el sistema en general. Muy interesante la propuesta
pero muchos estábamos como, bueno yo me incluyo, yo no lo pregunté pero estábamos como viendo y luego nuestro jefe preguntó, ok pero ¿por qué? ¿por qué quieres hacerlo? y ahí es donde mi compañero pues empezó como a revaluar como decís y... ajá porque se puede, porque suena muy bien y la verdad es que sí, si estuviera ya implementado estaría cool
Douglas (11:26)
Sí.
¿Por qué IA
Juan (11:41)
Pero empezamos entre todos a evaluar la propuesta, cuáles serían los beneficios, los pros y cons. Entonces, trayéndolo de nuevo al tema de este momento, pues...
Si vale la pena revaluarlo y creo que también tal vez no solo en nosotros recae sino compartirlo con el equipo estamos hablando ya de estás tratando de implementarlo en una empresa en tu equipo de trabajo ya sea una empresa grande o pequeña o mediana pero pues creo que a veces vale la pena tomar otros inputs de otras personas para revisar si realmente es lo conveniente en el canal tenemos un vídeo específicamente hablando sobre Docker Swarm versus Kubernetes
por si alguien le quiere echar un ojo, ahí mostramos algunas de las ventajas y desventajas de cada uno de ellos. bueno, pero brevemente, creo que Docker Swarm, como decías Douglas, es muy buen punto de partida, dependiendo de si es una... si el scope del sistema lo amerita, porque es muy fácil, no necesitas tanto una infraestructura tan compleja.
Y no necesita... Dependiendo de las situaciones, en ese capítulo lo hablamos más detalladamente, pero si es muy pequeño... No pequeño, la palabra no es pequeño, no es tan complejo.
el sistema, Docker Swarm va a ser muy buena opción y si ya empezamos a ver que Docker Swarm no se ajustaría a lo que necesitamos, que yo necesito que esto escale automáticamente dependiendo del tráfico y todo eso, ⁓ ok, entonces sí, regresemos a Kubernetes y veamos cómo lo implementamos. Siempre es bueno reanalizar lo que estábamos pensando, creo yo, en todos los aspectos.
Douglas (13:29)
Me gusta que lo digas porque definitivamente es un tema que hemos tocado antes y comencé con esta consideración como para resumir un poco temas que hemos hablado antes para personas que hasta ahorita nos ven y nos escuchan.
Y también porque la comunidad, Juan, en general se olvida de Docker Swarm. Cada vez que subimos un clip corto, obviamente, quienes nos siguen desde hace tiempo lo saben, algunos tal vez no, pero cada episodio sacamos clips cortos para poner en diferentes redes sociales con la intención de que nuestro contenido pueda ser compartido fácilmente y que las personas vengan a los episodios completos y escuchen todo el contexto, Pero cada vez que en un clip corto hemos mencionado
ya sea vos Juan o yo que Docker Compose y Docker Run no son para producción la gente rapidito salta a decir no vas a solo complicar las cosas con Kubernetes si solo quieres un landing para qué vas a meter Kubernetes y solo Kubernetes Kubernetes Kubernetes y los entiendo si en la balanza tenés
Docker Compose o Docker Run contra Kubernetes para un sitio sencillo. Nadie va creer Kubernetes, ¿no? Pero nos olvidamos de que existe Docker Swarm.
que es muchísimo más simple, pero me trae un montón de bondades para producción, ¿verdad? Entonces, esos son los motivos por los cuales esta es la primera consideración, básicamente, evaluar si Docker Swarm es más que suficiente para tus necesidades. Si no es suficiente, tomaste la decisión correcta en querer implementar docker, perdón, Kubernetes, en querer implementar Kubernetes. Ahora, ya decidimos.
Juan (15:11)
Sí.
Douglas (15:15)
sí, Kubernetes, ya hicimos la validación, como dijiste, me causó un poco de gracia lo que dijiste, Juan, como esa estrategia que se volvió meme del password, ingresas al password correcto y la primera vez te dice que está erróneo para evitar hacking, ¿no? La primera vez te dice que está erróneo, aunque sí estaba bueno, ya decidiste Kubernetes, volvemos a validar, ¿de verdad necesitas Kubernetes? Volvés a valor, ¿sí, lo necesito? Ok, la siguiente consideración que sería
No implementes todas las herramientas, tecnologías y servicios que hay alrededor de Kubernetes desde el principio. La configuración base de un clúster de Kubernetes incluye ingress, configurar ingress. Ingress es cómo se exponen los servicios hacia afuera. Ingress va a variar según tu proveedor de nube, va a variar según tu infraestructura local, va a variar...
según las tecnologías que utilizas. Ocupas un Cert Manager para estar generando certificados porque no vas a estar agregando certificados de manera manual en todos los servicios porque entonces el mantenimiento va a ser extremadamente complejo. Ocupas External DNS, ya sea para crear DNS records de tus servicios en tu red interna local, en tu WAN o hacia el internet. Ocupas Cluster Auto Scaler que es para cuando tenés más tráfico.
que te agregue más nodos para en esos nodos poder levantar más pot pero cuando tenés menos tráfico que te quite nodos, verdad, para que no tengas que pagar dinero por nodos corriendo sin hacer nada cuando tenés bajo tráfico bajo. Necesitás un storage class para volúmenes permanentes entonces eso por sí solo
Eso estoy hablando como un mínimo que tienes que tener en un clóset de Kubernetes, Eso por sí solo, cuando no hemos tenido experiencia previa con Kubernetes, toma un tiempo de adaptarse. Todo viene, todas estas cosas vienen de conocimientos previos, de conceptos previos que tenemos de trabajar en infraestructura. Quienes hemos trabajado con servidores físicos o con VMs y trabajamos con un load balancer y exponemos servicios, sobre todo si has trabajado en la nube.
todo viene de conceptos previos, pero Kubernetes los integra de manera interna. adaptarte a ello toma tiempo. Entonces, agregarle más complejidad con servicios que los grandes utilizan o que otras empresas utilizan porque les sacan beneficio.
sería sobre complicarnos porque cada cosa que le agregamos a Kubernetes lo complica más. ¿A qué tipo de servicios me refiero? Uno de ellos es Service Mesh, por ejemplo, ¿verdad? Service Mesh tiene que ver con la red interna de Kubernetes, tiene que ver con el tráfico. Service Mesh es un concepto bien complejo.
que solo los grandes utilizan, ¿verdad? Solo los grandes utilizan por los complejos. Creo que es la palabra sencilla, ¿no? Los grandes lo utilizan por los complejos, pero porque lo necesitan, ¿no? Cuando lo necesitas, porque es muy robusto, cuando lo necesitas vale la pena, ¿verdad? Pero ServiceMesh...
Juan (18:26)
Sí, sí, sí.
¿Y por qué es robusto?
Douglas (18:37)
ServiceMesh es uno de ellos. Carpenter, por ejemplo Carpenter es un auto scaling, les mencionaba que podés tener el cluster auto scaling que te agrega nodos y te quita nodos dependiendo del tráfico. Con Carpenter lo hace de una manera más inteligente, de una manera más dinámica porque entonces si tengo poco tráfico.
El cluster a Rowskeler normal yo le digo que tipo de instancia agrego, entonces digamos que me agrego una instancia, tengo configurado instancia de 16 gigas de RAM, por decir algo, entonces me hacen falta 2 gigas de RAM para levantar un nuevo pod, cluster a Rowskeler me va a levantar otra instancia de 16 gigas, porque así está configurado, pues así funciona, pero Carpenter lo personalizo para que sea más inteligente, entonces él va a poder levantar una instancia de 4 gigas, por ejemplo.
para ahí lanzar el nuevo pod y me estoy ahorrando dinero al no tener recursos subutilizados. Yo he mencionado Carpenter antes, ¿verdad? Porque yo lo he implementado donde estoy, pero al principio...
Juan (19:30)
Ok.
Douglas (19:43)
realmente venimos adaptándonos a Kubernetes, venimos adaptándonos al concepto como tal de cluster autoscaler que de nuevo es un autoscaling group, verdad, que agrega y quita instancias, no son conceptos nuevos pero no dentro de Kubernetes, todavía no sabes cómo se comporta un cuando se agrega un nuevo nodo y ese pod se va a mover ahí
verdad, no sabes cómo se comporta cuando quita pods porque va a quitar nodos todavía no te has interactuado con eso como para agregarle la complejidad de carpenter y otra solución, cosa que no necesitas agregar de entrada y aquí vamos a tener un poquito de tal vez verdad o un poquito de consideraciones más es GitOps
Juan (20:30)
Un depende.
Douglas (20:31)
Ahí depende, van a haber escenarios donde sí te vale un poco la pena si tenés el entendimiento por es GitOps, ¿verdad? Para que no sepan, GitOps es administrar la configuración de Kubernetes y el despliegue de las aplicaciones en Kubernetes usando Git como la fuente de verdad, como quien tiene la última palabra en cuestión de la configuración y el código que está ahí, ¿verdad? Y Kubernetes está constantemente un...
operador que está constantemente viendo tu repositorio y cuando hay un cambio los aplica él de manera automática a tu código. Quienes han trabajado con Puppet pueden hacerse una idea que es como no es igualito porque en Kubernetes es diferente, es un operador, pero para que se hagan una idea es como que si hubiese un agente viendo cuál es el estado deseado y lo está aplicando constantemente ese tipo de configuración, verdad. De nuevo hay escenarios en los que eso va a ser válido.
hay escenario donde eso sí te va a dar beneficio de entrada, pero cuando no, no es necesario agregar GitOps de entrada. En lo personal Juan, pues yo como te digo trabajo con Carpenter ya a estas alturas, ¿verdad? Con Service Mesh hasta el momento yo he trabajado con
diferentes tipos de aplicaciones, diferentes tipos de clóset de Kubernetes, diferentes clientes, hasta el momento yo no he tenido la necesidad de trabajar con ServiceMesh, por ejemplo.
tengo algo de experiencia con él y ya lo estamos evaluando en field donde yo trabajo, de hecho llevamos como unos ocho meses evaluando y ya estamos comenzando a que le vamos a dedicar un tiempo para implementarlo para ahorrar costos por ancho de banda y comunicándose entre availability zones en AWS, ¿verdad? Cuando te comunicas a otro availability zone, es otro data center en la misma región.
Juan (22:32)
Ok
Douglas (22:33)
pero
lo suficientemente largo porque si existe un desastre natural no le afecte entonces esa es una comunicación hacia otro data center y es un poco más cara entonces con service mesh vos podés hacer que los servicios que el pod corriendo el backend
no se vaya a conectar a la base de datos que está en otro availability zone, que vaya el mismo availability zone. ServiceMesh hace ese tipo de cosas. Entonces, en los años que tengo trabajando Kubernetes, hasta ahorita me encuentro en la necesidad de que realmente alguien se beneficia de ello. Juan, no sé si vos concordás conmigo, me parece que sí lo vas a hacer porque estos conceptos se aplican aún cuando se trabaja con microservicios, ¿verdad? o servicios y que no te vas a ir a lo último que hacen todos.
porque de entrada ni sabes si lo necesitas. Es el uso, el entenderlo bien en lo que te va a hacer darte cuenta. Necesito ServiceMesh, ya estoy listo para ello, necesito un auto scaling más inteligente, voy a implementar Carpenter. ¿Qué opinas vos al respecto?
Juan (23:42)
Pues fíjate que más que... O sea, sí estoy de acuerdo, pero al mismo tiempo te confieso que creo que tengo algunas dudas y me gustaría hacértelas porque tal vez alguien que no está escuchando pueda que tenga las mismas que estoy teniendo. La primera, retrocediendo un poco a lo que hablabas al inicio, mencionabas el tema del Certificate Manager, creo que mencionaste.
Douglas (24:09)
Sí.
Juan (24:11)
¿No es suficiente utilizar solamente Let's Encrypt, por ejemplo? ¿Cuál sería la desventaja o ventaja?
Douglas (24:17)
certificat...
No, muy buena pregunta, muy buena pregunta. Fiat Certificate Manager usa diferentes validadores y detrás de él está normalmente LessonCrip. O sea, usa LessonCrip.
Lo que ocurre es que Certificate Manager es un operador que está integrado con Kubernetes, que va a validar, ya sea por DNS o por API, lo que le diste para configurar va a validar con Lesson Group General Certificado, lo guarda en un secret de Kubernetes y lo tiene disponible para que otros servicios lo monten por medio del secret. O sea, Certificate Manager es ese operador.
que controla que se genere y que se guarde y compartirlo a los diferentes pods o servicios de manera segura dentro de Kubernetes. Pero en el backend mayormente usa Let's Encrypt. Si tu empresa usa otro validador se puede configurar a que lo use. Pero entonces sí es Let's Encrypt pero de nuevo. Como son varios lugares y cómo se almacena dentro de Cert ⁓ Manager se encarga de manejar eso por vos.
Juan (25:16)
que
Si, es la abstracción donde no vas a depender solamente de Let's Encrypt si quieres cambiar y también cómo hace todo lo demás. Ah, ok, interesante. Lo otro que te iba a preguntar, siempre escucho sobre Service Mesh, siempre escucho que hablan sobre esto. Creo que tal vez tenía el concepto erróneo o tal vez no sé si me podrías dar una...
Douglas (25:37)
Sí, sí.
Juan (25:54)
medio explicación. Para mi Service Mesh era la manera en que tienen como Kubernetes para comunicarse entre contenedores entre sí y yo lo estaba viendo más como una especie de load balancer casi pero asumo que no es así porque si no lo necesitabas pues como como haría el load balancen si no lo utilizas
Douglas (26:15)
Sí, mira, muy buena pregunta. Lo voy a resumir, simple, Service Mesh es un servicio paralelo a la es la capa de, no literalmente, pero lo que es la capa de networking interna de Kubernetes. Básicamente lo que hace es que en cada pod te levanta otro contenedor. Recordad que dijimos al principio que cada pod puede tener varios contenedores, ¿no? Y siempre dentro de ellos todos esos contenedores tienen el mismo localhost. Para ellos localhost es lo mismo.
Entonces levanta otro contenedor en cada pod y él va revisando todo el tráfico de red, y es ahí donde tiene el poder donde vos le configuras si querés que ciertas aplicaciones, ciertos servicios, ciertos pods con cierta etiqueta, ciertos pods en tal región o en tal lugar, que el tráfico de ellos vaya hacia cierto lugar.
Juan (26:46)
Sí.
Douglas (27:10)
o el tráfico de este otro se bloquee, se cancele, o este tráfico genere una acción que va a generar algo y luego eso genera auto scaling, o sea, te da esa integración y más allá
en lo que es una integración agregada en lo que es la capa de red porque está inspeccionando el tráfico de red que entra y sale de cada pod y en base a ello toma decisiones que vos le permitís, pero por defecto Kubernetes se comunica por sí solo entre servicios de manera interna y tiene como exponerse hacia afuera cuando le configuras Ingress, por defecto lo hace de esa manera, obviamente es un...
balanceador round robin cuando está balanceando carga por defecto y eso puede hacer de que si vos estás en AWS en la zona 1A y ahí llegó el request hacia el API, cuando el API llame la base de datos
Juan (27:57)
Ajá.
Douglas (28:10)
puede que lo mande a la 1C y vaya hasta el otro data center y es lo que querés controlar, ServiceMesh, inspecciona ese tráfico y dice, hey, pues estás en la zona 1B, te voy a mandar a la base de datos en 1B para que no gastes más dinero. Pero entonces, es un sidecar agregado a tus servicios, a tus bots que inspecciona el tráfico de red con la intención de hacer lo que necesites con esa información.
Juan (28:36)
Sí.
OK, OK, súper interesante. Definitivamente está muy interesante y, bueno, te deja claro todas las capacidades que tiene Kubernetes. Y eso que solo has mencionado dos que tres en este momento. Y yo creo que aquí Douglas lo que yo podría tal vez aportar un poco a los que nos están escuchando y viendo. ¿Por qué no vale la pena implementarlo desde el inicio?
es que depende de cuánto tiempo tenemos para investigar, hacer pruebas, familiarizarnos porque bueno, tal vez podríamos decir sí, lo quiero implementar, tal vez es un overkill pero pues lo quiero poner. Ok, cuánto tiempo tenemos para realmente hacer el cambio y lanzar los productos que tiene la empresa y todo eso. Si tenemos mucho tiempo, bueno, está bien, investiguemos, familiaricémonos y hagámoslo.
Desde el inicio pongamos todo, pero lo más probable es que no tengamos el suficiente tiempo. Así que hay que ir planeando en base a etapas, en base a lo mínimo entregable al inicio, luego que podemos ir agregando con el tiempo y así. Así que nunca es favorable hacer todo desde el mero inicio.
Douglas (29:57)
sino y que también Juan no probablemente no lo vas a ocupar. Cuando trabajamos con producción, con sistemas que están generando dinero, el overkill es un gasto.
Juan (30:01)
también.
Douglas (30:11)
El Overkill está bien para tu ambiente personal, tu sandbox donde probas cosas, ahí hace Overkill. Yo tengo, ya les he mencionado que nuestro sitio web aquí en Debenhub se está corriendo en Kubernetes, no necesita correr en Kubernetes, pero pues yo tengo un clóset de Kubernetes donde corro mis cosas y ahí está, verdad, bastante seguro y corriendo desde ahí. Pero ya que tenga que ver con producción y eso, el Overkill no...
te va a hacer perder dinero. Entonces hay que irnos a la solución que es, de nuevo, Juan menciona un punto muy importante, el tiempo, y el tiempo suele ser un problema porque el tiempo es dinero, pero aunque lo tuvieras, inicialmente te vas a complicar la vida mucho, y siempre se mide, Juan, cuando se agregan este tipo de herramientas, ya que traes el tema, siempre se mide que el tiempo de mantenerla...
Juan (30:37)
Sí.
Douglas (31:04)
sobrepase el gasto que estás haciendo, porque ya dijimos cada capa que le agregamos genera complejidad. nuestro caso que estamos usando Carpenter, todavía solo está... Carpenter que es el que te decía del Auro Scaling inteligente de nodos, este Carpenter lo tenemos solo en algunos clusters aún.
Juan (31:09)
ok
Douglas (31:28)
no se ha sacado a todos los clusters porque se está viendo si el beneficio de mantenerlo va a ser mayor verdad a lo que nos vamos a ahorrar no sé si no sé si lo dije al revés creo que lo dije al revés ahorita que lo que lo pienso en mi mente pero creo que me transmito la idea no que que lo que nos vamos a ahorrar de dinero sea mayor al extra que se va a invertir en personas en recursos administrando carpenter esa es la
esa es la idea que quería transmitir y eso con cada cosa que vamos a implementar. El beneficio tiene que ser mayor a la inversión de tiempo, recursos, dinero que estamos haciendo en ello.
Juan (32:10)
Así que, que en verdad sea rentable, básicamente.
Douglas (32:14)
porque no lo dije de esa manera, así, que en verdad sea rentable. Gracias Juan. Bueno, pasemos a otra consideración si te parece Juan, verdad, y la otra consideración es que automatizemos el despliegue de la infraestructura de Kubernetes desde el principio cuando vamos cuando ya hemos decidido implementar Kubernetes, verdad.
Juan (32:15)
Sí.
Douglas (32:41)
¿Por qué lo digo? Porque normalmente cuando comenzamos, una cosa es tu etapa de investigación. Ahí haces click-ups, le decimos, ¿no? Clickeas, creas un cluster y clickeas aquí, conectas cosas, agregas plugins y cosas a Kubernetes y haces lo necesario en tu etapa de investigación. Cuando empiezas a implementarlo, la sugerencia es comenzar automatizando el despliegue de la infraestructura de Kubernetes desde el principio.
que inicialmente se siente una traba, se siente un problema porque a medida que estás creando, normalmente Juan vas a lanzar tu aplicación a Kubernetes, primero que haces es crear un ambiente de prueba, seguir con tu aplicación en VMs, pero creas un ambiente de prueba de la aplicación y los programadores están probando cosas y te dicen no, mira que esto falló, ⁓ en contra voy a cambiar algo y molesta ir a...
a tu automatización, a cambiar las cosas para el despliegue y desplegó, ⁓ me desplegó mal, me cambió lo que no era, no, y vuelvo a ir y vuelve a desplegar, entonces lo sentimos incómodo al principio, ¿verdad? Pero una vez que se acaba esa etapa, una vez que estás listo, ya todo funciona y estás listo para replicar eso en más clusters,
resulta que se te olvidó cómo configuraste algo o que se te olvidó siquiera un fix rápido que el developer te dijo fíjate que me falla esa conectividad ⁓ no es ese security group está malo ya está dale ok si funcionó y se te olvidó siquiera que lo hiciste y empezás al momento de replicar empezás a ver las configuraciones una por una aquí y empezás a ver en el otro
y se te olvidó ver alguna. Entonces yo creo que a este punto ya transmití la idea que yo quería compartirles.
Cuando empezamos a replicar tenerlo como código, que ese código sea la fuerte, la fuente de verdad es, les va ayudar increíblemente, esto es algo que lo he visto pasar de primera mano, ¿verdad? Y aparte de que terminas con clústeres inconsistentes, este tiene una configuración, este otro no, cuando haces troubleshooting de la otra aplicación, estás asumiendo que algo que implementaste en otro clúster, está implementado en el que está dando problemas, pero no está
implementado entonces es un gran problema comenzar ya sea con terraform con pulumi con la herramienta de infrastructure infrastructure no puedo hablar inglés o es como as code que verdad que prefieras comenzar desde el inicio pero hacerlo de esa manera porque te garantizo te garantizo que te vas a ahorrar dolores de cabeza al futuro a medida agregadas más cluster
¿Qué pensás de esta idea, Juan? ¿La compartís?
Juan (35:32)
Sí.
Sí la comparto bastante y de hecho se ve bastante con lo que mencionabas antes del gear ups porque básicamente eso es esa configuración o esa automatización se vuelve tu el estado deseado del sistema y eso te facilita mucho algo que por ejemplo
Bueno, si lo traigo algo más simple, porque yo no configuro Kubernetes, pero sí he visto, y algo que me ha gustado mucho o que veo en ciertos sistemas operativos como lo que es Nix OS, y creo que tiene un package manager o algo así, te permite tener un sistema que es declarativo, de definir todo, definir, al momento de instalarlo va a tener
estos programas corriendo, a estos servicios y va a estar configurado así y así con estos usuarios, todo ¿no? Muy muy útil, por ejemplo a mí me pasa mucho que tengo un nodo de mi cluster que es un single board computer y por algún motivo no tiene soporte para RnBn así que estoy utilizando una imagen que realmente no
que es una imagen para desktop, que la tengo que quitar todo lo de desktop para que quede para el servidor. No es el nodo más robusto que hay en mi cluster y a veces falla. Y qué complicado es el tener que volver a configurar todo. Y como decías al inicio, tenés que recordar cómo lo configuraste, qué cosas hiciste.
y a veces hay errores, eso pasa, incluso en aplicaciones que tenemos hay errores específicos que tienes que hacer uno que otro tweak y uno que otro así arreglito por aquí por allá y con el tiempo se nos olvida y vuelve a aparecer el error y es como, ok, yo ya lo solucioné pero no recuerdo cómo era y hay que volver a... en cambio si ya tenemos todo escrito en piedra pues solo...
ejecutamos todo de nuevo y vuelve a funcionar como estaba. Realmente eso es una de las grandes ventajas que tenemos hoy en día, que hay tantas herramientas para lograr esto. Y Kubernetes es uno de ellas y te lo ponen bandeja de plata cuando lo entendés, cuando sabes cómo se hace. Porque hay una curva de aprendizaje claramente.
Pero bueno, la ventaja que obtendés al momento de tenerlo ya configurado versus simplemente ir y clicar y agregarlo manualmente, el día y la noche la comparación. Es muy, muy diferente. Así que sí, dirías que eso es una etapa que vendría antes de la primera implementación. O tengo mi empresa y vamos a empezar a utilizar Kubernetes. Esto debería estar desde el mero inicio o
Debería ser un poquito después. ¿Cómo lo verías vos?
Douglas (38:35)
No, el inicio. ClickOps es válido, sea, cada quien lo puede hacer como quiere. Es una consideración antes de que en los comentarios la gente se disguste conmigo. Pero ClickOps realmente es aceptable durante la etapa de prueba de investigación, porque no estás comenzando nada, estás probando cosas, estás haciendo laboratorios para ver que funcione. Una vez que vas a lanzar tu primer clúster para que se comience
a migrar cosas sabemos que ahí todavía hay prueba pero la decisión ya está, pero todavía hay pruebas, se están adaptando cosas, se está cambiando código, etcétera, ya tiene que ir idealmente, es la sugerencia que les estoy dando, ya tiene que ir con automatización.
Juan (39:11)
Ok.
Douglas (39:22)
verdad porque cuando esa es la etapa van en la que cuando estás listo para hacer el segundo a veces toma más tiempo el segundo cluster que el primero porque tenés una lista de cosas mentales que querés mejorar para el segundo pero es una lista mental y aunque la tengas escrita
te aseguro que algo se te va olvidar. Y si vos sos de los pocos unicornios que no se te olvidó, la mayoría de nosotros no somos así, es la realidad. Y encima de eso, acordémonos que el trabajo del día 2, ¿verdad? Como se le llama, tenemos que estar manteniendo ese cluster. No va a estar con la misma versión de Kubernetes toda la vida. No va a estar con la misma versión de plugins toda la vida. Hay que estarlo automatizando y hacerlo con Infrastructure as Code. Te va a facilitar la vida, sobre toda medida agregues más clusters.
Juan (39:43)
Sí, sí.
Sí.
Y también, pues normalmente no trabajamos solos. Así que si yo encontré una solución, yo encontré una configuración que, OK, así funciona como queremos, mi compañero o compañeros tienen que darse cuenta y pues lo mejor es tenerlo ya bien estructurado todo.
Douglas (40:32)
Si alguien trabaja solo, lo correcto es que lo mire como que no trabaja solo. Seamos profesionales y entendamos que la empresa, el departamento, tiene que correr este o no esté yo presente. es un punto muy válido. Ahora, no sé Juan, ¿te parece? ⁓ sí.
Juan (40:49)
Sí.
¿Sabes qué?
¿Sabes qué? Eso es algo que siempre aplico en mi día a día y es como esto que yo sé, qué pasaría, qué pasará el día que yo me vaya de la empresa. O sea, yo siempre estoy pensando en el punto en que me voy a ir. No tengo planes de irme, pero siempre pienso eso. Y por eso siempre trato.
Si encuentro algo que esto es muy complejo para que alguien lo entienda solo leyendo el código, solo viendo el readme, entonces trato de mejorar la documentación para ese tipo de casos. Creo que hay que tenerlo en mente siempre, que no somos indispensables. O más allá de ser indispensables, Douglas, que pasa cuando me quiero ir de vacaciones. Pues hay que dejar todo bien documentado.
Douglas (41:38)
Sí, ese es mi principal pensamiento cuando yo no quiero estar amarrado algo. Obviamente es lo profesional hacer, hacer vos lo dijiste y lo comparto 100 % Juan, es lo profesional hacer. Pero yo también pienso, yo no quiero estar amarrado a esto, ser la única persona que me llamen de madrugada porque nadie más tiene acceso o porque solo yo puedo, que me voy de vacaciones pero tengo que andar con la laptop. No quiero eso, ¿verdad?
Juan (42:00)
Sí.
Douglas (42:01)
No es la manera, consejo para todos, no es la manera de asegurar un trabajo. Aseguramos un trabajo siendo profesionales con la calidad de lo que entregamos.
Bueno me gusta, te parece tengo dos consideraciones más Juan para que pasemos a, para que las toquemos verdad y de las dos restantes, la primera que quiero mencionar es que utilicen Helm o Customize para desplegar las aplicaciones, eso ya cuando estás listo para desplegar las aplicaciones, Kubernetes ya está configurado, vas a desplegar las aplicaciones que utilices Helm o Customize para desplegarlas desde el principio, estas son herramientas Juan que
Juan (42:19)
Perfecto.
Douglas (42:42)
templetizan, no sé cuál será la palabra correcta en español, templetize creo que es en inglés, templetizan, sea hacen templates, hacen plantillas, hacen plantillas de los manifestos de Kubernetes. Ya mencioné que Kupas para...
Juan (42:52)
plantillas.
Douglas (43:00)
Para el despliegue ocupas los pods, los services, el deployment, ingres, necesitas todo ese tipo de cosas, incluso necesitas, ya cuando estás ahí, ocupas service accounts que dan permisos, ocupas RBAC.
para privilegios, RBAC roles, RBAC bindings, para tu aplicación, para que tu aplicación ocupa hablar con S3. Entonces tu aplicación tenga permiso por medio de un service account y por medio de RBAC al S3 bucket, pero solo al S3 bucket que necesita, no a todo. Entonces todo ese tipo de cosas están, necesarias para desplegar una aplicación en producción y cada una de esas cosas...
de esos recursos son un manifesto de Kubernetes. Cada uno de esos recursos son un manifesto de Kubernetes. Esos manifestos pueden vivir en archivos separados, Jaml, son en formato Jaml, pueden tener Jaml separados, tener un Jaml que se llame ingress.jaml, ¿verdad? Otro manifesto que sea service.jaml, otro manifesto que sea deployment.jaml y tenerlo por separado.
o tenerlo todo en el mismo archivo físico yama y lo vas separando con las tres raíces en yama separas un manifiesto del otro al final ocupas toda esa cantidad de manifestos y cuando tenés dos aplicaciones es complicado configurarlas pero ahí vas cuando le agregas 4, 5, 10 es mucho más complicado ir a cambiar a todos estos manifestos cuando haces una actualización a la estrategia de algo
y supones que ya lo tenés corriendo y está corriendo bien y hoy te dicen no mira actualizamos la versión de Ingress entonces hay que a cada manifiesto a hacerlo entonces
Estas herramientas, verdad, estas herramientas como Helm y Customize yo tengo mayor experiencia con Helm, he usado Customize pero mi experiencia va honestamente alrededor de Helm, mantengo Helm charts públicos para aplicaciones en PHP, para aplicaciones en WordPress y otros Helm charts que he hecho por ahí, tengo un operador de Kubernetes que es Open Source para crear monitoreos en Digital Ocean y tiene un Helm chart que yo lo manejo.
mucha experiencia con Helm, pero cualquiera te va funcionar. Pero hacerlo así desde el principio, y esto es algo Juan con lo que a mí me tocó lidiar aquí en Field, porque cuando yo llegué ya estaba implementado Kubernetes.
Pero no todas las aplicaciones estaban siendo desplegadas con Helm. De hecho eran pocas. Y nos tocó trabajar en migrar esas aplicaciones a Helm porque era un dolor de cabeza comenzar a mantenerlas. no es un error que yo cometí directamente, que no sé si no lo hubiese cometido.
no tampoco quiero yo aquí salir como el que el que jamás hubiese cometido ese error no sé porque no nunca había estado en esa situación pero si estaba en la situación que me toca corregir que se haya cometido ese error entonces háganse un favor ustedes mismos y cuando comiencen a desplegar aplicaciones en Kubernetes háganlo desde el principio con Helm.
Idealmente creen sus propios HelmCharts, pero si un HelmChart público le sirve y es seguro, utilicenlo, no hay ningún problema, pero utilicen Helm Customize. No sé qué tanta experiencia tenés con este tipo de herramientas, Helm y Customize. Entiendo que estás acostumbrado a publicar desde Argo, pero asumiría que Argo CD está desplegando un HelmChart o un Customize.
sabes al respecto, pero danos tu pensamiento, tu punto de vista.
Juan (46:59)
Bueno, la verdad es que sí, como mencionas no tengo experiencia creando y configurándolos. Sería válido decir que es como el equivalente entre comillas de lo que son los Compose files, donde se define cuánto CPU, memoria, puertos.
Douglas (47:18)
eso sería un manifesto, el
equivalente al Compose File sería el manifesto, pero mira Helm como si tuvieras un Compose File con un montón de variables para la imagen, para la versión, para los mount points, con un montón de variables, como un template de Golland, Go tiene su util...
Juan (47:34)
Sí.
Sí, de hecho está utilizando ese engine.
Douglas (47:46)
es correcto, utiliza el mismo engine. Entonces como un template de Go donde por medio de un file Jaml vos populas que imagen queres, que versión de la imagen. Entonces vos solo estás populando un Jaml file y con el mismo Helm Chart y diferentes values files.
puedes desplegar tu aplicación de desarrollo, staging, preproducción, puedes desplegar otras aplicaciones. Entonces esa es tal vez la mejor forma en que lo puedo ilustrar.
Juan (48:10)
Uh-huh.
Ok, perfecto. De hecho sí, como te digo no los configuro, pues cuando estoy debugging o estoy revisando las aplicaciones dentro de Argo sí, también te permite ver el template que tiene dicho servicio.
y pues es muy útil para ver, ok, con qué valores se publicó o se desplegó esta aplicación, entonces ya uno puede revisar. Es bastante intuitivo, creo yo, al menos de leer. Obviamente configurarlo es diferente porque tenés que saber qué vas a incluir, qué opciones tenés, etcétera, ¿no? Pero creo que es bastante intuitivo de leer. Por lo mismo, es un template engine, es el mismo de Go y pues...
muy muy fácil de utilizar. La verdad es que es interesante como básicamente incluye un package manager. Básicamente eso lo que sería el mismo Helm. Es como un package manager de todos estos manifiestos que puedes descargar o crear y todo lo que tiene. Es curioso, por ejemplo, en trayendo de nuevo la comparación con Docker, Swarm y Compose files y ese tipo de cosas.
este aspecto de reemplazar valores y tener variables pues no es definitivamente no está hasta donde yo recuerde y si lo que puedes implementar desde cero pues es medio complicadito al menos lo que yo he utilizado así que wow la verdad es que Kubernetes te da muchas formas
Yo creo que ahí viene la complejidad ahora que lo pienso Douglas. Es una herramienta que te da tantas cosas, te permite hacer tantas, modificar tanto que es muy fácil perderse entre todas las opciones y también es muy fácil como dicen, darte un disparo en el pie. Es como...
te podrías arruinar tu mismo stack haciendo cosas que no deberías porque la misma aplicación o infraestructura te lo permite. Pero bueno, sí, definitivamente no tengo experiencia, pero es muy, muy interesante. Y para los developers que solo estamos utilizándolo, bastante útil, bastante fácil de entender, la verdad.
Douglas (50:40)
Sí, lo que da cara al developer realmente no es complejo de entender. Y lo que estamos en sistemas tampoco lo es. Cuando hemos tenido experiencia con tecnologías anteriores, sin embargo, no deja de ser complejo y tedioso. Y si antes con VMs levantamos un cluster para una sola aplicación,
Kubernetes en un clúster podemos correr muchas aplicaciones. Entonces o podemos traerle los beneficios de Kubernetes a muchas aplicaciones de un solo o podemos botar muchas aplicaciones de un solo con un error. Entonces ese disparo en el pie yo creo que es más...
Juan (51:26)
Es como una escopeta.
Douglas (51:28)
Sí,
es una escopeta, sí. Pero bueno, vale la consideración. Si te parece, Juan, la última consideración que quiero darles a estas personas, equipos, empresas que han decidido implementar Kubernetes y tal vez siguen en esa etapa es que implementen monitoreo y observabilidad, aunque sea básico desde el principio.
Esto no todo el mundo lo ve, ya me he topado con situaciones así. De hecho, hablando de Docker Swarm, en esta empresa donde vos y yo nos conocimos, cuando lanzamos Docker Swarm por primera vez, no teníamos una...
observabilidad y monitoreo profundo más allá de sabix en las bienes físicas verdad no que era cero no es que era cero pero haciendo retrospectiva no era el mínimo que me hubiese gustado tener verdad no era cero pero no era mismo que me hubiera gustado tener y en Kubernetes eso es todavía mucho más verdad hacer troubleshooting en Kubernetes es complicado y si no tenemos un lugar centralizado con logs con métricas con toda esta información necesaria no si no tenemos
algo que nos estén viendo alertas, cuando...
hay un problema o cuando está a punto de pasar un problema si no tenemos un dashboard centralizado para ver cosas, el troubleshooting va a ser bien complejo, ¿verdad? La interacción con Kubernetes es normalmente por el comando de kubectl o kubectl control, como le quieran llamar. Existen algunos dashboards por ahí que te permiten visualizar cosas, pero ninguno de esos dashboards es realmente completo.
para monitoreo, ¿verdad? Yo, la recomendación Juan, si no quieren invertirle mucho tiempo al principio, pero siempre lanzar algo que sea decente, el stack base de Prometheus y Grafana, existen Helm Charts que te lo instalan y te instalan base dashboards que la comunidad hace y mantiene, que te dan suficiente información como para empezar.
y que te va ayudar con tu debugging, te va a ayudar con tu troubleshooting y a medida pasa el tiempo le vas agregando lo que necesitas pero no arranquen sin monitoreo y observabilidad porque si comienzan a haber errores en la aplicación no van a saber. Imagínense un cluster que no tenga logueo centralizado
y entonces tenés que estarte conectando a cada VM para ver los logs en un cluster normal, no de web. Entonces ahora imaginate que tenés un cluster, tenés una aplicación con error y ni siquiera sabes en... porque luego de conectarte a la VM tenés que conectarte a un...
a un pod, a un contenedor, ni siquiera sabes en cuál está o empezás con Keep City All Commands que sí lo va, te va a identificar dónde está, pero se vuelve complejo, créanme, créanme, se vuelve complejo, entonces no pasen por alto ⁓
dedicarle tiempo al monitoreo y a la observabilidad. No tienen que dedicarle la mitad del tiempo de toda la implementación, pero si con un 10%, un 15 % del tiempo implementarles la base de Prometheus y Grafana, entenderlo bien, configurar las alertas, no es que eso lo van a poner a correr y ya estuvo, pero no le va tomar tanto tiempo y el beneficio va a ser grandísimo.
medida progresan. como esta es la última sugerencia, me gustaría darte espacio para que nos digas qué pensás, pero despacio que nos dejes tus palabras de cierre sobre el tema que tocamos hoy.
Juan (55:12)
Ah, ok, perfecto. Primero me gustaría mencionar que yo opino Douglas que si bien es cierto es una gran consideración al momento de implementar Kubernetes, no se limita solo a Kubernetes. Yo creo que casi en cualquier infraestructura hoy en día, yo no veo la justificación para no tener un sistema de logs, un sistema de observabilidad.
y bueno doy un ejemplo muy simple de nuevo, simple pero eso lo estoy experimentando con mi Homelab mi Homelab solamente tengo un Masternode y tengo dos workers y ya se está volviendo complejo porque no tengo implementada observabilidad ni nada de eso porque no lo necesito hasta...
hasta el momento, ¿no? Pero ya se está volviendo complicado porque ya cada vez estoy agregando más aplicaciones, más servicios y ya es complicado el hecho de, ok, tengo que ir a revisar este SSH en este otro servicio, SSH en este otro y empezar a buscar y a veces los logs quedan, ¿cómo se les dice? truncados, no me muestra todo, tengo que... es frustrante cuando empiezo a revisar múltiples aplicaciones.
Y ya estoy, bueno, ya llegué a la conclusión, ok, ya tengo, ya estoy en un punto donde necesito observabilidad y lo veo centralizado. Pero yo estoy hablando de mi homelab, está en mi casa, es mi hobby y aún así ya estoy empezando a notarlo. En una empresa no, como digo, no veo justificación de no agregar esto.
Douglas (56:45)
Claro, claro.
Juan (56:54)
En Kubernetes mejor aún porque ya tenemos un sistema que es muy complejo y ya lo mencionabas, ya querer hacerlo a pie todo esto es pérdida de tiempo. que sí, definitivamente creo que es obligatorio para cualquier sistema y en Kubernetes lo exponenciamos a la 2, creo yo, la necesidad de hacerlo.
Me ha gustado mucho la plática, Douglas. Creo que va a ser un buen punto de referencia para las personas que están queriendo implementar esto desde cero. Y, bueno, estoy seguro que han investigado en otros lugares, han leído documentación. Estoy seguro que han leído documentación. Y, bueno, con esto, al menos van a tener una pequeña pauta de a qué cosas van a tener que ponerle atención desde el inicio para optimizar su proceso, mejor dicho.
Me gusta mucho. Ojalá que podamos tener algún otro episodio hablando un poco más sobre Kubernetes porque en lo personal es un tema que no manejo, pero me gusta mucho. Me gusta ir entendiéndolo más. De hecho, te cuento, hace poco estuve tentado nuevamente a cambiarme a Kubernetes en mi HomeLab. Pero como ya tengo muchas aplicaciones, dio pereza. No lo quise hacer. Pero creo que va a llegar un punto donde lo voy a hacer.
Definitivamente Kubernetes es la norma hoy en día y siempre es beneficioso entenderlo y saber utilizarlo bien tanto para optimizar tus recursos, para no gastar dinero y pues para tener sistemas robustos que sean sistemas que como ya lo dicho anteriormente que sean lo suficientemente complejos para que justifiquen el uso de esta herramienta.
Si caen en esa categoría, Kubernetes les va a hacer la vida mucho más fácil. Para terminar Douglas, me gustaría agradecer a la gente y recordarles que
que por favor le den like a nuestras páginas. Hemos tenido un aumento en nuestros seguidores de Facebook, así que muchas gracias en esa red social. A las demás, ¿qué pasa? Por favor, poco más. No, es broma, es broma. Muy agradecidos con todo nuestra audiencia. La verdad es que nos dejan comentarios, nos dejan likes. La verdad es que siempre es interesante cuando nos preguntan algo y tratar de darles la mejor respuesta posible. Y estoy seguro que...
en este episodio de Kubernetes nos van a llegar ciertas preguntas porque pues la naturaleza del tema lo amerita.
Douglas (59:32)
Sí, lo esperaríamos. Ojalá. Y gracias, Juana, a vos por el valor que nos has aportado por tu perspectiva. Porque, al final del día en esto con Kubernetes, los developers terminan usándolo, lo sepan o no, y que tanto interactúen con él o no. Pero los developers son los que lo terminan usando en su día a día porque ahí es donde desplegamos sus aplicaciones. Gracias por esa perspectiva, el valor que nos aportaste. Y a las personas que nos ven y nos escuchan, realmente,
deseamos que esta información les haya sido de valor, si ustedes están en esa etapa en su equipo de trabajo, en su empresa o conocen a alguien que justo está en esa etapa, verdad, un amigo, un compañero de otra empresa, etcétera, compartanle este episodio por favor para que pueda tomar esto en consideración, les agradecemos por su apoyo, les agradecemos por su tiempo, por su sintonía, esperamos vernos en el próximo episodio de Dev&Ops adiós.