Cómo construir tuberías de CI/CD para una aplicación de microservicios

Hola, soy Sasha Rosenbaum, y hoy estoy presentando sobre la construcción de CI-CD para aplicaciones de microservices. Así que primero, solo una pequeña introducción sobre mí. Actualmente soy Líder de Equipo en un equipo de OpenShift BlackBell administrado en Red Hat. Y en mi career, he estado en desarrollo, en operaciones, brevemente en ruta de desarrollo, y he pasado bastante tiempo en éxito del cliente. Todavía me considero un desarrollador. Pero como puedes ver, he hecho muchas cosas diferentes a lo largo de los 15 años que he estado en esta industria.

He estado involucrado en los días de DevOps desde 2014. También puedes verlo en el gráfico. Y puedes encontrarme en Twitter como devineops. Publico muchas fotos de gatos y algunos Twitter, algunas opiniones técnicas candentes. Así que por favor siéntete libre de seguirme en Twitter.

Entonces, hablemos de microservices. Mientras construía esta presentación, pensaba que además de cómo hacer las cosas, también es importante hablar de por qué estamos haciendo las cosas. Y especialmente si estamos hablando desde el punto de vista de un desarrollador, es importante hablar de por qué incluso usamos microservices, por qué usamos containers, y profundizar en una especie de visión general de toda la architecture.

Entonces, comencemos con esto. Hubo una vez un monolito, ¿verdad? Y el monolito era bonito, y realmente disfrutábamos trabajando con un monolito, y todo estaba relativamente bien. Y para contarte un pequeño secreto que a nadie le gusta hablar más, es que el monolito era en realidad más fácil de manejar, porque con el monolito, tenías control total sobre todas las partes de tu aplicación, todas tus dependencias, y todas tus cosas. Y también porque los sistemas distribuidos son difíciles, y eso es simplemente una verdad universal.

Pero el monolito también tenía desafíos y estos desafíos eran entre muchos. Así que muchos equipos diferentes necesitaban colaborar. Así que tenías que colaborar a través de diferentes partes de una empresa. Y si la empresa era grande, eso a menudo significaba que algo como una gran aerolínea.com se convertía en un gigante, se convertía en una bestia enorme y todos los equipos diferentes tenían que participar en la construcción de esa enorme aplicación. Todos tenían que usar la misma tecnología. Así que si a un equipo le gustaba mucho Java y a otro equipo le gustaba mucho C-sharp, tenían que elegir entre ellos. Tenían que usar ambos, o lo mismo con diferentes tipos de SO y cosas así. Cada cambio requería una regresión testing de todo el sistema, lo cual puede ser bastante consumidor de tiempo. Por lo tanto, el despliegue era lento, ¿verdad? Porque los equipos a menudo se encontraban en un infierno de fusión y scaling era difícil. Así que scaling una bestia enorme de una aplicación generalmente no es un picnic. Entonces, porque teníamos desafíos donde hay desafíos, siempre hay soluciones. Y en este caso particular la solución se convirtió en microservices.

Entonces, ¿qué son realmente los microservices? Comenzamos con una aplicación, y luego comenzamos a hablar de los patterns de desarrollo adecuados. Así que modularizamos diferentes partes de la aplicación. Y luego comenzamos a hablar de dividir estos diferentes modules en diferentes servicios. Y a medida que avanzábamos, se convirtió en una red de servicios. En una implementación adecuada, cada microservice también se supone que debe tener sus propios data. En la práctica, esto no siempre sucede, pero esta es la mejor práctica de implementación para cada microservice también posee la database. Así que a menudo escucho preguntas sobre la architecture orientada a servicios versus microservices. Entonces, si estás a la izquierda de este diagrama, y tienes una capa de data, y tienes una capa de lógica de negocio, y tienes una capa web, incluso si estas tres capas están separadas, estás en microservices. Separar por preocupaciones verticales todavía no es microservices. Microservices se separa por lógica de negocio. Entonces, en este caso, por ejemplo, authentication sería un microservice separado.

Y puede scale independientemente del oyente HTTP que sirve a la aplicación web. Entonces, si estás dividiendo por propósito empresarial, estás en un mundo de microservices. Entonces, microservices, y esto es de microservices.io, ¿verdad? Se definen como un patrón de architecture de colección de servicios que están sueltos acoplados, desplegables de forma independiente, organizados por capacidades empresariales y propiedad de pequeños equipos.

Entonces, el mayor beneficio de los microservices y la razón por la que toda la industria optó por microservices es que los microservices permiten la agilidad. Y ese es el mayor beneficio, ¿verdad? Porque en comparación con el despliegue de millaje enorme, puedes moverte mucho más rápido con microservices. Entonces, la vieja escuela ama el monolito y la nueva escuela son las aplicaciones de microservices, que generalmente son compatibles con Kubernetes o en mi caso, trabajo para Red Hat. Así que voy a mencionar mucho OpenShift, que es una especie de versión de Kubernetes, si quieres.

Entonces, los beneficios de los microservices provienen directamente de la descripción arquitectónica. Entonces, pueden scale de forma independiente. Entonces, si solo necesitas una instancia o solo tres instancias del servicio de authentication, y necesitas 15 instancias de digamos, servicio de carga de fotos, puedes scale de forma independiente. No tienes que crear una VM para todo el monolito que hace todas estas cosas. Puedes desplegarlos de forma independiente, lo cual es algo que permite la agilidad. Puedes confiar en diferentes pilas de texto. Entonces, si quiero usar Python y tú quieres usar Java, entonces definitivamente podemos hacer eso y cada servicio soportará la tecnología que mejor se aplique a él. Y luego pueden confiar en dependencias conflictivas, lo cual también puede ser un gran beneficio, ¿verdad? Porque si necesito la versión Python dos, y tú necesitas la versión Python tres, si estuviéramos en un monolito, estaríamos en conflicto el uno con el otro. Pero ahora podemos tener diferentes microservices que dependen de diferentes versiones de la misma biblioteca. Y lo más importante, serás un desarrollador de microservices, lo que te convertirá en un unicornio de Silicon Valley en la moda adecuada. Esta imagen es de GitHub.com 503. Este es un error 503, pero resulta que se ve muy bien.

Entonces, ¿por qué usar containers? Así que escucho a mucha gente básicamente diciendo que los containers son imprescindibles para la implementación de microservices. Me gusta esta cita de Jeffrey Richter, quien escribió como 18 libros diferentes sobre computación. Básicamente, los microservices son un patrón de design arquitectónico, y los containers son una implementación que a menudo ayuda. Entonces, técnicamente no tienes que tener containers para implementar microservices, pero a menudo te facilita la vida. Entonces, ¿por qué usamos containers? Bueno, aquí, una metáfora de la industria del transporte realmente ayuda. Entonces, la industria del transporte solía enviar cada carga de trabajo en un tipo separado de caja y manejar de forma separada. Y luego la industria del transporte adoptó containers. Entonces, estos enormes containers de transporte. Y puedes ver que en los años 70, donde la industria del transporte adoptó containers, hubo un crecimiento exponencial del comercio mundial, ¿verdad? Porque el transporte de containers era mucho más fácil. Podías estandarizar un procedimiento en particular. Y así no tenías que manejar cada carga de trabajo de una manera diferente.

Y eso te permitió construir barcos que soportan contenedores, que construyen procedimientos para, descargar, desembarcar en barcos y cosas así, básicamente permitió un crecimiento explosivo en toda la industria. Y algo así como eso, esos beneficios también son ciertos para los contenedores de computación también.

Entonces, si estamos hablando de tecnología de contenedores, es inmutable, es portátil, y se basa en código abierto y estándares abiertos, ¿verdad? Y estos son grandes beneficios, pero ¿qué significa realmente? ¿Qué problema resolvimos realmente al contenerizar todo? Bueno, en realidad, resolvimos el problema de, funciona en mi máquina, ¿verdad?

Entonces, en una vida anterior, solía ser que yo podía ser un desarrollador e implementaba algo y funcionaba perfectamente en mi máquina. Y luego, cuando llegó incluso al entorno de prueba, las cosas ya no funcionaban. Así que básicamente este meme viene del blog de Cam, pero dice, funciona en mi máquina. Vamos a enviar tu máquina, y así nació Docker. Así que, esencialmente, encontramos una forma de enviar una máquina de desarrollo y ese contenedor puede ser enviado y puede funcionar de manera portátil en diferentes entornos.

Así que ya no me importa si estoy en la nube, si estoy en las instalaciones, si estoy en el portátil, ¿verdad? Puedo empaquetar con el mismo contenedor y puede ejecutarse en cualquier lugar. Ahora, esto no es necesariamente completamente transparente, pero definitivamente nos permite eliminar muchos de los desafíos de las diferencias en los entornos. Entonces, hablemos de contenedores, porque es relevante para cómo implementar CI-CD para microservicios, y específicamente si estás ejecutando en una implementación de Kubernetes, que probablemente estés. Entonces, un contenedor es la unidad de cómputo más pequeña, y en realidad se instancia a partir de una imagen de contenedor.

Entonces, es un poco similar a una imagen de VM, si estás familiarizado con esas. Básicamente, creas una imagen de un contenedor, y luego puedes instanciar un contenedor en tiempo de ejecución y puedes instanciar muchos contenedores a partir de la misma imagen de contenedor. Entonces, la imagen del contenedor tiene diferentes capas, por lo que, esencialmente, comienzas con el Linux base. Normalmente es Linux, hay contenedores de Windows por ahí, pero no hay muchos de ellos. Y luego tienes la capa de actualización del sistema operativo con las cosas que necesitas. Luego tienes una capa de tiempo de ejecución para tu lenguaje para tu aplicación. Y luego tienes la capa de la aplicación real. Entonces, básicamente, la anatomía de un archivo Docker para una aplicación de JavaScript es similar a esto. Entonces, básicamente, estás extrayendo una imagen de un registro, normalmente hay un registro donde viven las imágenes. Y si estás en una empresa en una gran empresa, probablemente estás extrayendo de un registro interno. Si estás construyendo para ti mismo, entonces tal vez estás extrayendo de Docker Hub o algún registro público disponible. Y luego estás definiendo tus variables de entorno. Puedes instalar dependencias. Entonces, tus dependencias de herramientas básicamente dependen de tu imagen base y del tiempo de ejecución que necesitas. Entonces, en este caso, vamos a copiar el paquete JSON, copiar el paquete log JSON, y ejecutar npm install para instalar nuestras dependencias. Luego vamos a copiar la aplicación real. Vamos a exponer los puertos que necesita la aplicación. Y luego, esencialmente, ejecutamos la aplicación, ¿verdad? Entonces, de esta manera, acabamos de empaquetar toda la versión de nuestra aplicación en un contenedor.

Y ahora puedo iniciar este contenedor en diferentes entornos. Y como dije, va a ser portátil, va a funcionar de la misma manera en muchos lugares diferentes. Así que esencialmente las imágenes de contenedores se almacenan en el registro de imágenes. Y entonces podría tener diferentes versiones del mismo contenedor en el registro, ¿verdad? Entonces, a medida que creo nuevas versiones de mi aplicación, puedo crear nuevas versiones de mi imagen de contenedor y luego puedo subirlas al registro. Y luego se vuelven disponibles. Así que esencialmente también podría extraer las diferentes versiones. Entonces, si quisiera ejecutar, digamos, frontend 2.0 con Mongo 3.6, podría ejecutar esta combinación de servicios. Entonces, de facto, este Kubernetes está en todas partes, y básicamente, es el estándar para la orquestación de agua y entrega de aplicaciones. Proporciona mucha extensibilidad, mucha personalización y una gran community de contribuyentes de código abierto, y se convirtió en esta gran tecnología que lo impulsa todo. Y luego, sí, por supuesto, la perspectiva del desarrollador es como, solo quiero escribir code, ¿verdad? Déjame solo escribir code. Realmente no me importa necesariamente la plataforma. Y eso es más o menos a donde estamos tratando de llegar, a donde la plataforma Kubernetes puede ser realmente obstruida, y tú, como desarrollador, no tienes que preocuparte necesariamente por dónde se está ejecutando tu aplicación. Y, por supuesto, es importante usar Kubernetes porque puedes ponerlo en tu currículum y convertirte en un desarrollador de Kubernetes en un unicornio de Silicon Valley. Entonces, hablemos brevemente sobre los desafíos con los microservices. Entonces, no todo es color de rosa. No resolvimos todos tus problemas. Solo creamos diferentes tipos de problemas con los microservices. Entonces, básicamente, crear microservices es fácil. Hacer que los microservices se lleven bien entre sí puede ser difícil. Entonces, una de las cosas que sucede es que los microservices en realidad se definen e integran mediante una API publicada. Entonces, piénsalo como un contrato. Esencialmente tienes contratos entre diferentes microservices. Entonces, si alguien rompe este contrato sin actualizar la documentation, sin actualizar tu equipo, pueden esencialmente romper cada servicio que depende de ellos. Entonces, en lugar de un infierno de fusión e integración, donde todos los equipos se unen y luego tienen que fusionarlo, esencialmente tienes esta situación en la que alguien puede enviar un cambio sin una dependencia de ti, pero luego puedes descubrir que ya no funciona con tu servicio en particular. Lo otro es que es una red. Entonces, cuando hay una falla en una red, puede crear una falla en cascada en toda la red, lo cual puede ser un gran problema. Entonces, necesitas manejar eso. Necesitas poder aislar una falla y eso puede ser difícil y puede requerir una implementación adicional. Y entonces, un microservice, es un dicho común que un microservice solo puede hacer una cosa, ¿verdad? Solo estás haciendo un microservice si es responsable de una sola cosa de lógica de negocio.

Pero entonces, hay esta broma de, si tu microservice solo hace una cosa, no puede tener un error porque eso sería una cosa adicional. Ahora, suena como una broma, pero en realidad es cierto, y en muchos patrones de implementación patterns. Si tu agente está atascado, si tu contenedor particular está atascado, puede ser realmente difícil identificar si todavía está trabajando en algo o si realmente está atascado y necesita ser eliminado. Así que, esto es algo de lo que necesitamos preocuparnos también a nivel de contenerización. Así que, para resumir los desafíos de los microservices es esencialmente que más servicios significan más comunicación de red, lo que requiere más códigos de recuperación de fallos y tiempos de espera. Así que, esto es algo de lo que tú, como desarrollador, tienes que preocuparte. Disminuye el rendimiento general debido a los saltos de red y la continua serialización y deserialización de objetos. Es difícil probar en aislamiento sin servicios dependientes. Así que, puede ser realmente difícil detener todo y ser capaz de probar un servicio en aislamiento. Es difícil depurar y monitorear a través de diferentes servicios. Y los nuevos servicios deben soportar todos los nuevos contratos de API simultáneamente, lo cual, de nuevo, si estabas implementando CIC antes, podrías haber estado preocupado por esto también, porque quieres soportar múltiples versiones del mismo code. Pero a medida que vas desplegando nuevos microservices, se vuelve aún más importante ser muy, muy claro acerca de cuál es tu versión de API, para que los servicios que dependen de ti puedan ser capaces de seleccionar la versión de API con la que realmente son capaces de trabajar.

Así que estoy gestionando despliegues, y finalmente llegamos a la parte de CIC. Básicamente podrías usar la tubería existente. Así que espero que ya tengas tuberías de CIC de algún tipo, y podrías usar Jenkins o Azure DevOps o algo así, por supuesto, para desplegar Kubernetes, para desplegar microservices en Kubernetes o plataformas OpenShift. Pero ayuda a usar algo que es... Y usaremos la palabra de moda cloud-native, CICD cloud-native, que está diseñado para Kubernetes.

Así que esencialmente es una tubería como servicio, así que estamos poniendo todo en containers. Así que las tuberías realmente se ejecutan en containers, y es nativo de Kubernetes. Es nativo de Kubernetes Authentication y cosas así. Así que uno de los servicios potenciales, y el que Red Hat está utilizando, es Tacton. Así que Tacton es un proyecto open-source apoyado por la fundación de entrega continua. Y es básicamente CICD declarativo y nativo de Kubernetes. Las tuberías se ejecutan bajo demanda en containers aislados. No tienes que mantener un servidor Jenkins o algo así. Y hay una biblioteca de tareas de la que puedes tirar, y de nuevo, se integra con Kubernetes y tiene un montón de diferentes integraciones con las herramientas existentes.

Así que esencialmente, una tubería Tacton es similar a las tuberías que podrías haber visto antes. Así que esencialmente, está compuesta de tareas y cada tarea está compuesta de pasos. Así que un paso es algo que ejecuta un comando o un script en un contenedor, y un paso también define qué tipo de contenedor estás utilizando. Así que esencialmente, esa imagen de contenedor que necesitas tirar. Luego una tarea es una lista de diferentes pasos. Así que pueden ser pasos que se ejecutan en el mismo tipo de contenedor o en un tipo de contenedor diferente. Y esencialmente, defines una secuencia reutilizable secuencial de pasos que necesitas para lograr una tarea. Las tareas pueden ser pre-implementadas esencialmente, las tareas se pueden encontrar en Tacton Hub, que es un registro público, un hub público para las tareas de Tacton. Y así para cosas que suceden todo el tiempo, como, ya sabes, tareas de AWS CLI o algo así, puedes tirar de esta biblioteca. Y luego una vez que tienes la tarea definida, puedes juntarla en una tubería. Una tubería es esencialmente un gráfico de tareas que pueden ejecutarse secuencialmente o concurrentemente. Y pueden ejecutarse en diferentes nodos. Pueden tener lógica condicional y pueden tener reintentos. Así que si cierto paso no tuvo éxito, podemos ejecutarlo de nuevo, hasta que tenga éxito, ¿verdad? Y puede compartir data entre tareas, que de nuevo, es algo que necesita suceder Porque a menudo estás manejando artefactos entre diferentes etapas de la tubería. Así que esencialmente juntándolo todo, te da una implementación de CI para tus Kubernetes containers, que también significa tu aplicación de microservices. Y luego sólo porque necesitábamos más palabras de moda en esta industria, creamos una palabra de moda para GitHubs.

GitHubs es esencialmente un enfoque para DevOps, para CICD, donde todo se implementa, se controla a través de Git, y todo es esencialmente declarativo. En particular con OpenShift, y de nuevo, puedes hacer lo mismo con Manila Kubernetes, puedes usar Argo CD para la parte de CD de la aplicación. Así que esencialmente, tendrías tuberías de CI en Tacton, y tendrías Argo CD en el lado de CD, y luego Argo CD es la definición declarativa de GitHubs que define a qué entorno se despliega realmente tu código. Y me gusta este diagrama. Así que básicamente, esencialmente, tus tuberías de Tacton están construyendo tus imágenes de contenedor y las están empujando al registro de imágenes. Y luego defines, básicamente, manifiestos que dicen, vale, para este tipo de imagen va al entorno de desarrollo, este tipo de imagen de contenedor va al entorno de preproducción, y así sucesivamente. Así que esencialmente, implementando de manera declarativa, configuraciones de estado decidido a través de Argo CD para cómo se ve realmente tu aplicación en cada entorno diferente. Y por supuesto, ahora todo está automatizado, y eres un unicornio de Silicon Valley, y todo el mundo está realmente contento y todo el mundo está usando microservicios con éxito. Así que el desarrollo de aplicaciones en la nube se trata de ser más rápido. No necesariamente va a hacer tu vida más fácil en todas las dimensiones, pero sí permite a las empresas en particular, a los equipos de desarrolladores moverse más rápido con el despliegue de sus aplicaciones en producción. Y muchas gracias por estar conmigo hoy. Soy Sasha Rosenbaum, puedes encontrarme en Twitter y GitHub como DevineOps, y es un placer conocerte.

Hola, Sasha. Hola. Estoy súper feliz de estar aquí, y estoy realmente emocionado de que seas mi anfitrión porque siempre es divertido charlar contigo también. De hecho, pude elegir a quién presento, y te elegí a ti, Sasha. ¡Sí! Oh, genial. Estoy sorprendido. Me siento apreciado. Entonces, echemos un vistazo a la pregunta que le hiciste a la multitud, y preguntaste si la gente tiene experiencia con diferentes tipos de arquitecturas, arquitectura orientada a servicios y microservices, containers. Y es interesante ver que la mayoría de la gente es realmente nueva en todo lo anterior, lo cual no me sorprende, viendo que es más una conferencia de front-end, pero es interesante ver cómo está ocurriendo ese cambio, ¿verdad? ¿Qué piensas? Bueno, creo, sabes, la gran idea de cambiar a Kubernetes y a las orquestaciones de contenedores y cosas así era liberar a los desarrolladores de lidiar con la infraestructura, y creo que en cierta medida lo que está ocurriendo es lo contrario, ¿verdad?, y tenemos a los desarrolladores aprendiendo más sobre infraestructura. Así que en un sentido, es mejor porque los desarrolladores y las operaciones se están uniendo en torno a este patrón de desarrollo que es compartido por todos, pero por otro lado, todas estas cosas son difíciles de aprender, ¿verdad? Y por lo tanto, es lo suficientemente difícil hacer front-end si también tienes que preocuparte por los despliegues, eso podría no ser ideal. Es bueno entender, sabes, CICD y todas estas cosas, pero también es genial cuando podemos simplemente tener tuberías como un servicio y no preocuparnos por esas cosas en absoluto. Sí, estoy completamente de acuerdo. Es como, hay un cambio tan grande, como que el papel de todos se está expandiendo.

Sergio hace un par de preguntas desde la multitud, ¿cómo podemos mantener la integridad referencial entre microservices cuando tenemos varias bases de datos? Sí, desafortunadamente, tienes que hablar con la database que te importa, ¿verdad? Y eso no es necesariamente muy fácil, ¿verdad? No es necesariamente muy fácil para cada microservice poseer sus propios data. Y muchas veces lo que sucede es que las bases de datos son propiedad de otro equipo y entonces básicamente tienes que empezar a llegar a la misma database, lo que rompe parte del propósito de los microservices y su separación de preocupaciones y cosas así. Pero sí, la idea es que sigas consumiendo de diferentes API e interactuando con las partes que te importan.

Genial, y luego había otra parte, ¿cuáles son las mejores estrategias para soportar varias versiones de API con la architecture de microservice? Sí, quiero decir, hay guidelines para tener versiones de API, así que comúnmente, publicarás tu versión, ¿verdad? Así como v1, v2, v3. Y cuando desarrollas microservices, en realidad, cuando desarrollas cualquier cosa en el mundo moderno, tienes que soportar al menos dos versiones de tu code, ¿verdad? Nunca podrás pasar de una versión a la siguiente sin mantener la compatibilidad hacia atrás. Así que hay algunas implementaciones, algo así como azúcar de implementación, algunos enfoques de implementación, por ejemplo, cuando escribes en una database, digamos que tenías apellido y nombre como dos campos separados, y ahora quieres combinarlos, ¿verdad? Entonces, mantén ambos, ¿verdad? Así que tienes apellido, nombre como dos campos separados, y también apellido, nombre como un mismo campo. Y durante un tiempo, básicamente escribes en ambos, ¿verdad? Y luego pasas a la siguiente versión de API, y luego puedes retirarte. Así que no retiras el code inmediatamente después de cambiarlo, lo retiras después de otra iteración, ¿verdad? Y luego, tu versión de API es tu contrato, ¿verdad? Así que si estoy consumiendo v1, y tú pasaste a v2, si me dices que pasaste a v2, y ya no soportas v1, entonces acabas de romper el contrato conmigo, y obviamente estoy teniendo problemas para lidiar con eso. Pero si soportas ambos, entonces podemos trabajar juntos por un tiempo. Y luego, obviamente, en algún momento, me vas a decir que v1 está retirada, es hora de que avances, ¿verdad? Así Sí, tiene mucho sentido.

Dennis pregunta, ¿qué tan prevalente ves a Kubernetes en el futuro? Las funciones de Cloud cumplen algunas de las mismas necesidades. Así que creo que Kubernetes es un estándar de facto, ¿verdad? Y entonces, como que, todo el mundo está sacando su versión de Kubernetes, ¿verdad? Quiero decir, cada cloud tiene un orquestador de Kubernetes de su propio sabor, que tiene OpenShift, que es como un Kubernetes listo para la empresa, si quieres, ¿verdad? Así que, como que, todo el mundo está en este barco, y es un gran barco. Y eso es efectivamente el estándar para la implementación. Quiero decir, obviamente, puedes implementar funciones como un servicio, y puedes implementar, ya sabes, seguir usando monolitos, y puedes seguir usando mainframe. Como que, todas estas cosas coexisten. Inventamos nueva tecnología, nos movemos hacia ella. Y luego, ya sabes, todavía tenemos que mantener algo de la compatibilidad hacia atrás. Y luego, obviamente, nunca sabes cuándo se va a introducir algo nuevo, ¿verdad? Así que, tal vez, además de containers y serverless, vamos a tener, ya sabes, nuevos patterns que saldrán en los próximos años. Creo que eso es bastante probable, honestamente. Y luego, en términos de Kubernetes versus serverless, quiero decir, hay implementaciones para serverless que usan Kubernetes. Así que, como que, ahora son líneas borrosas. Quiero decir, microservices y serverless tienen muchas cosas en común. Pero de nuevo, los microservices son más flexibles, ¿verdad? Las funciones por design tienen limitaciones. Como que, no pondrías una aplicación web en funciones, como que, eso simplemente funcionaría. Así que eso es un ejemplo, ¿verdad? Mientras que los microservices pueden soportar casi cualquier aplicación. No necesariamente va a ser el camino más fácil para implementar la aplicación. Pero definitivamente, puede soportar casi cualquier architecture. Tiene sentido. Sí. Así que, como ambos siendo, ya sabes, co-organizadores de DevOps Days alrededor del mundo, creo que es realmente interesante que, ya sabes, DevOps es, como, la historia de DevOps se está expandiendo a otras tecnologías, como esta conferencia con DevOps.

JS, ¿qué crees que va a pasar después? ¿Cuáles son tus pensamientos sobre cómo el mundo de DevOps está cambiando y evolucionando? Es interesante. Patrick acaba de compartir un tweet de todos los sabores de DevOps de la industria y es aterrador porque parece el paisaje de CNCF. ¿Sabes a qué me refiero? Hay tantas palabras que describen cosas similares o diferentes, y simplemente seguimos expandiendo los niveles de preocupación en todos estos diferentes trabajos.

Creo que si miro, como, hace diez o lo que sea, 2009, 11, casi doce años atrás cuando todo el movimiento DevOps comenzó, a veces me hago la pregunta, como, ¿hemos hecho el mundo mejor? Y creo que sí, ¿verdad? Y seguimos haciéndolo, pero, como, continuando, si piensas en el trabajo del operador versus el trabajo del operador hoy, creo que los operadores trabajan en desafíos mucho más interesantes, que, como, en lugar de hacer clic en botones y hacer lo mismo una y otra vez y preocuparse por, no sé, cintas de respaldo y cosas así, ahora tenemos operadores implementando, básicamente escribiendo code, que es, como, es terrible para mí decir que escribir code es lo más genial, pero, de nuevo, básicamente resolvemos desafíos más interesantes. También, como, el mundo ha avanzado, ¿verdad? Como, hace 10 años podrías tener una interrupción durante todo el sábado mientras estás moviendo tu aplicación a una nueva versión, y hoy, como, no hay negocio en el mundo para el cual sería aceptable simplemente, como, estar, oh, estamos fuera por mantenimiento durante todo un día. Como, eso simplemente ya no funciona, ¿verdad? Así que tienes que ajustar tu tecnología a las expectativas de todos, esencialmente. Creo que en términos de llegar al frontend, no lo sé. Creo que la expectativa debería ser que las personas deberían ser capaces de trabajar en entregar valor al negocio en lugar de preocuparse por los detalles de implementación. Y ahí es donde, como, tal vez deberíamos volver al principio y estar en un sentido donde, como, puedes hacer clic en un botón y luego obtienes un contenedor o lo que sea o una función o ni siquiera te preocupas por los detalles de implementación, ¿verdad? Consigo un contenedor de este, ya sabes, tipo, y puedo ejecutar mi aplicación en producción y todo lo que me preocupa es el code, ¿verdad? Y eso es simplemente, como, siento que ese es el estado ideal para que los desarrolladores puedan ser efectivos en su trabajo.

Sí. En el contexto de eso, ¿verdad? Esa ha sido a menudo la promesa de, como, plataformas pasadas como OpenShift que hablan de, como, de ID a producción. Así que es interesante cómo estamos volviendo al círculo completo a ese tipo de modelo de nuevo. Sí, hay, ya sabes, una última pregunta para terminar tu charla es ¿cuáles son los puntos de control que estableces para asegurarte de que tus pipelines están funcionando como se espera? ¿Hay algún consejo rápido sobre eso sólo para asegurarse de que la gente está cubierta? Sí, quiero decir, hay varios, básicamente, controles que puedes mostrar y, como, si tienes la tecnología configurada correctamente, tendrás puertas para que puedas, entonces la entrega continua no significa que siempre vayas automáticamente a producción, ¿verdad? Así que idealmente, tienes un punto de control después de que estás revisando tu code y tienes un punto de control después de que lo construyes, tienes un punto de control después de que ejecutas pruebas y puedes tener varios de esos porque puedes tener varios tipos de pruebas, esencialmente. Para estos tipos de pipelines, tienes un punto de control cuando estás revisando la imagen en el registro de contenedores. Y luego básicamente, el punto de control donde lo revisas y luego, el despliegue es otra cosa donde una vez que está desplegado, también tienes que cuidar del monitoreo y cosas así. Y luego usualmente ahora, muchas veces cuando estás revisando en el control de fuente, pero definitivamente necesitas ejecutar controles de security, ¿verdad? Y de nuevo, los controles de security pueden estar en varias etapas también, ¿verdad? Así que puedes ejecutar análisis de code de sitio, y luego puedes ejecutar security como parte de tus pruebas. Y luego obviamente mentor security una vez que está desplegado. Así que hay un montón de cosas diferentes. Creo que, básicamente, vas y lo editas, ya sabes, aprovecha las cosas que son gratuitas y fáciles de implementar primero, y luego eso ya te pone por delante de muchas empresas. Y luego empiezas a buscar diferentes herramientas que te permitan asegurarte de que tus aplicaciones son seguras y funcionan bien. Creo que la security es una de las cosas que a menudo se pasa por alto cuando la gente está preocupada por la velocidad de despliegue tanto. No podría estar más de acuerdo. Muchas gracias, Sasha. Siempre es un placer y un honor tenerte. Únete a Sasha en su sala de conferencias inmediatamente después de su charla y en el chat Espacial. Tendremos la oportunidad de charlar con ella y hacer networking. Así que muchas gracias por unirte a nosotros, como siempre, charla estelar. Muchas gracias. Nos vemos pronto. Cuídate. Gracias.