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

Rate this content
Bookmark

Los microservicios presentan muchas ventajas para ejecutar software moderno, pero también traen nuevos desafíos tanto para las tareas de despliegue como operativas. Esta sesión discutirá las ventajas y desafíos de los microservicios y revisará las mejores prácticas para desarrollar una arquitectura basada en microservicios.

Discutiremos cómo la orquestación de contenedores usando Kubernetes o Red Hat OpenShift puede ayudarnos y lo uniremos todo con un ejemplo de tuberías de Integración Continua y Entrega Continua (CI/CD) en OpenShift.

Sasha Rosenbaum
Sasha Rosenbaum
33 min
01 Jul, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla discute los beneficios de los microservicios y contenedores para construir tuberías de CI-CD. Explica cómo la tecnología de contenedores permite la portabilidad y escalabilidad. Los desafíos de los microservicios incluyen la comunicación de red y las pruebas en aislamiento. La charla presenta Tacton, una tubería CICD nativa de la nube para Kubernetes, y destaca el uso de GitOps y Argo CD. También discute la importancia de mantener la integridad referencial entre los microservicios y el papel en evolución de los operadores en el mundo DevOps.

Available in English

1. Introducción y Antecedentes

Short description:

Hola, soy Sasha Rosenbaum, y hoy estoy presentando sobre la construcción de CI-CD para aplicaciones de microservicios. He estado en desarrollo, operaciones, ruta de desarrollo y éxito del cliente. He estado involucrado en los días de DevOps desde 2014. Puedes encontrarme en Twitter como devineops.

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.

2. Microservicios y Sus Beneficios

Short description:

Hablemos de microservicios. Hubo una vez un monolito, y era más fácil de manejar porque tenías control total. Sin embargo, había desafíos, como la colaboración entre diferentes equipos y la necesidad de pruebas de regresión. La solución a estos desafíos se convirtió en microservicios, que implican modularizar diferentes partes de la aplicación y dividirlas en servicios separados. Cada microservicio idealmente debería tener sus propios datos. Los microservicios se separan por lógica de negocio.

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.

3. Microservicios y Contenedores

Short description:

Y puede escalar independientemente del oyente HTTP que sirve a la aplicación web. El mayor beneficio de los microservicios y la razón por la que toda la industria optó por los microservicios es que los microservicios permiten la agilidad. Los beneficios de los microservicios provienen directamente de la descripción arquitectónica. ¿Por qué usar contenedores? La industria del transporte solía enviar cada carga de trabajo en un tipo separado de caja y manejarla por separado. Y luego la industria del transporte adoptó contenedores.

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.

4. Tecnología de Contenedores e Implementación de CI-CD

Short description:

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. 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? 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, 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. 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. 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, 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, de esta manera, acabamos de empaquetar toda la versión de nuestra aplicación en un contenedor.

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.

5. Tecnología de Contenedores y Desafíos

Short description:

Y ahora puedo iniciar este contenedor en diferentes entornos. Las imágenes de contenedores se almacenan en el registro de imágenes. Este Kubernetes está en todas partes y es el estándar para la orquestación. Los desafíos con los microservicios incluyen hacer que se lleven bien entre sí y manejar las fallas de red. Un microservicio solo puede hacer una cosa, pero eso puede llevar a desafíos adicionales.

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.

6. Desafíos de los Microservicios

Short description:

Si tu microservicio solo hace una cosa, no puede tener un error porque eso sería una cosa adicional. Los desafíos de los microservicios incluyen identificar agentes o contenedores atascados, manejar la comunicación de red, disminuir el rendimiento debido a saltos de red y serialización, probar en aislamiento, depurar y monitorear a través de servicios, y soportar múltiples versiones de API.

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.

7. CI-CD con Tacton para Kubernetes

Short description:

Así que estoy gestionando despliegues y finalmente llegamos a la parte de CIC. Podrías usar la tubería existente, como Jenkins o Azure DevOps, para desplegar microservicios en las plataformas Kubernetes o OpenShift. Sin embargo, ayuda a usar una tubería CICD nativa de la nube diseñada para Kubernetes. Tacton es un proyecto de código abierto que proporciona CICD declarativo y nativo de Kubernetes. Elimina la necesidad de mantener un servidor Jenkins y ofrece una biblioteca de tareas con integraciones para las herramientas existentes. Una tubería Tacton consta de tareas y pasos, permitiendo la ejecución secuencial y concurrente con lógica condicional y reintentos. Proporciona una implementación de CI para contenedores de Kubernetes y aplicaciones de microservicios.

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.

8. GitHubs y Desarrollo Nativo en la Nube

Short description:

GitHubs es un enfoque para DevOps y CICD, donde todo se controla a través de Git y es declarativo. Argo CD se utiliza para la parte de CD de la aplicación, definiendo los entornos de despliegue. Las tuberías de Tacton construyen imágenes de contenedores y las envían al registro de imágenes. Las configuraciones declarativas a través de Argo CD definen la aplicación en cada entorno. El desarrollo de aplicaciones nativas en la nube permite un despliegue más rápido. Gracias por estar aquí. Soy Sasha Rosenbaum, me puedes encontrar en Twitter y GitHub como DevineOps.

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.

9. Introducción y Respuesta del Público

Short description:

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. Es interesante ver que la mayoría de la gente es realmente nueva en diferentes tipos de arquitecturas, arquitectura orientada a servicios y microservicios, contenedores. La gran idea de cambiar a Kubernetes y a las orquestaciones de contenedores era liberar a los desarrolladores de lidiar con la infraestructura, pero es importante entender CICD y todas estas cosas.

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.

QnA

Integridad Referencial y Versiones de API

Short description:

Sergio pregunta sobre cómo mantener la integridad referencial entre microservicios con múltiples bases de datos. El desafío radica en que cada microservicio posee sus propios datos, ya que las bases de datos a menudo son propiedad de diferentes equipos. La idea es consumir de diferentes API e interactuar con las partes que importan. El soporte de múltiples versiones de API requiere pautas y mantener la compatibilidad hacia atrás. Enfoques de implementación como escribir en campos antiguos y nuevos pueden facilitar la transición. Kubernetes se está convirtiendo en el estándar de facto para la implementación, aunque coexisten otras tecnologías como serverless. Los microservicios son más flexibles que las funciones, que tienen limitaciones inherentes. La historia de DevOps se está expandiendo a otras tecnologías, incluyendo esta conferencia con DevOps.

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.

Evolución de DevOps y Puntos de Control en las Pipelines

Short description:

JS discute la evolución del mundo DevOps y el cambiante papel de los operadores. Ahora el enfoque está en resolver desafíos más interesantes y ajustar la tecnología para satisfacer las expectativas del negocio. El estado ideal para los desarrolladores es centrarse en entregar valor al negocio en lugar de en los detalles de implementación. Los puntos de control en las pipelines son cruciales para garantizar un funcionamiento adecuado, incluyendo revisiones de código, construcción, pruebas, revisiones de registros de imágenes y revisiones de seguridad. Aprovechar herramientas gratuitas y fáciles de implementar puede ayudar a garantizar la seguridad y funcionalidad de la aplicación.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Levelling up Monorepos with npm Workspaces
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Levelling up Monorepos with npm Workspaces
Top Content
Learn more about how to leverage the default features of npm workspaces to help you manage your monorepo project while also checking out some of the new npm cli features.
Automating All the Code & Testing Things with GitHub Actions
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
Fine-tuning DevOps for People over Perfection
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Top Content
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
Why is CI so Damn Slow?
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
The Zen of Yarn
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
End the Pain: Rethinking CI for Large Monorepos
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
End the Pain: Rethinking CI for Large Monorepos
Scaling large codebases, especially monorepos, can be a nightmare on Continuous Integration (CI) systems. The current landscape of CI tools leans towards being machine-oriented, low-level, and demanding in terms of maintenance. What's worse, they're often disassociated from the developer's actual needs and workflow.Why is CI a stumbling block? Because current CI systems are jacks-of-all-trades, with no specific understanding of your codebase. They can't take advantage of the context they operate in to offer optimizations.In this talk, we'll explore the future of CI, designed specifically for large codebases and monorepos. Imagine a CI system that understands the structure of your workspace, dynamically parallelizes tasks across machines using historical data, and does all of this with a minimal, high-level configuration. Let's rethink CI, making it smarter, more efficient, and aligned with developer needs.

Workshops on related topic

Decomposing Monolith NestJS API into GRPC Microservices
Node Congress 2023Node Congress 2023
119 min
Decomposing Monolith NestJS API into GRPC Microservices
Workshop
Alex Korzhikov
Alex Korzhikov
The workshop focuses on concepts, algorithms, and practices to decompose a monolithic application into GRPC microservices. It overviews architecture principles, design patterns, and technologies used to build microservices. It covers the theory of the GRPC framework and protocol buffers mechanism, as well as techniques and specifics of building isolated TypeScript services in the Node.js stack. The workshop includes a live use case demo of decomposing an API application into a set of microservices. It fits the best architects, tech leads, and developers who want to learn microservices patterns.
Level: AdvancedPatterns: DDD, MicroservicesTechnologies: GRPC, Protocol Buffers, Node.js, TypeScript, NestJS, Express.js, PostgreSQL, TurborepoExample structure: monorepo configuration, packages configuration, common utilities, demo servicePractical exercise: refactor monolith app
Deploying React Native Apps in the Cloud
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Cecelia Martinez
Cecelia Martinez
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
Decoupling in Practice
Node Congress 2023Node Congress 2023
102 min
Decoupling in Practice
WorkshopFree
Chad Carlson
Chad Carlson
Deploying decoupled and microservice applications isn't just a problem to be solved on migration day. Moving forward with these architectures depends completely on what your team's workflow experience will look like day-to-day post-migration.
The hardest part of this can often be the number of vendors involved. Some targets are best suited for specific frontend frameworks, while others are more so for CMSs and custom APIs. Unfortunately their assumptions, workflows, APIs, and notions of security can be quite different. While there are certain advantages to relying on a strict contract between apps – where backend and frontend teams work is limited to a single vendor – this isn't always realistic. This could be because you're still experimenting, or simply the size of your organization doesn't allow for this kind of specialization just yet.
In this workshop, you'll have a chance to explore a different, single vendor approach to microservices using Strapi and Next.js as an example. You'll deploy each app individually, establishing a workflow from the start that simplifies customization, introducing new features, investigating performance issues, and even framework interchangeability from the start.
Structure:- Getting started- Overview of Strapi- Overview of Platform.sh workflow- Deploying the project- Switching services- Adding the frontend
Prerequisites:- A Platform.sh trial account created- The Platform.sh CLI installed
MERN Stack Application Deployment in Kubernetes
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Joel Lord
Joel Lord
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
Azure Static Web Apps (SWA) with Azure DevOps
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Juarez Barbosa Junior
Juarez Barbosa Junior
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.