Cómo construir pipelines 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 implementación como para las 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 utilizando Kubernetes o Red Hat OpenShift puede ayudarnos y lo pondremos todo junto con un ejemplo de pipelines de Integración Continua y Entrega Continua (CI/CD) sobre OpenShift.

33 min
01 Jul, 2021

Video Summary and Transcription

Esta charla discute los beneficios de los microservicios y los contenedores para construir pipelines 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 en red y las pruebas en aislamiento. La charla presenta Tacton, un pipeline CI/CD nativo de la nube para Kubernetes, y destaca el uso de GitOps y Argo CD. También se discute la importancia de mantener la integridad referencial entre los microservicios y el papel en evolución de los operadores en el mundo de DevOps.

Available in English

1. Introducción y Antecedentes

Short description:

Hola, soy Sasha Rosenbaum y hoy voy a presentar 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 voy a presentarles sobre la construcción de CI-CD para aplicaciones de microservicios. Así que primero, solo un poco de introducción sobre mí. Actualmente soy Líder de Equipo en un equipo de OpenShift BlackBell administrado en Red Hat. Y en mi carrera, he estado en desarrollo, en operaciones, brevemente en ruta de desarrollo y he pasado bastante tiempo en éxito del cliente. Aún me considero un desarrollador. Pero como pueden 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 pueden verlo en el gráfico. Y pueden encontrarme en Twitter como devineops. Publico muchas fotos de gatos y algunas opiniones técnicas en Twitter. Así que no duden en seguirme en Twitter.

2. Microservices and Their Benefits

Short description:

Entonces hablemos de microservicios. Érase una vez, había 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. Idealmente, cada microservicio debería ser dueño de sus propios datos. Los microservicios se separan por lógica empresarial.

Entonces hablemos de microservicios. Mientras construía esta presentación, pensé que además de cómo hacer las cosas, también es importante hablar de por qué hacemos las cosas. Y especialmente si estamos hablando desde el punto de vista de un desarrollador, es importante hablar de por qué incluso usamos microservicios, por qué usamos contenedores y sumergirnos en una visión general de toda la arquitectura.

Entonces empecemos con esto. Érase una vez, había un monolito, ¿verdad? Y el monolito era bonito y realmente disfrutábamos trabajar con él, y todo estaba relativamente bien. Y les contaré un pequeño secreto del que a nadie le gusta hablar más, y es que el monolito en realidad era más fácil de manejar, porque en 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 una verdad universal.

Pero el monolito también tenía desafíos y estos desafíos eran muchos. Muchos equipos diferentes necesitaban colaborar. Tenías que colaborar en diferentes partes de una empresa. Y si la empresa era grande, a menudo significaba que algo como una aerolínea.com grande se convertía en un monstruo, se convertía en una bestia enorme y todos los equipos diferentes tenían que estar involucrados en la construcción de esa enorme aplicación. Todos tenían que usar la misma tecnología. Entonces, 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, lo mismo con diferentes tipos de sistemas operativos y cosas así. Cada cambio requería una prueba de regresión de todo el sistema, lo que puede llevar mucho tiempo. Por lo tanto, la implementación era lenta, ¿verdad? Porque los equipos a menudo se encontraban con problemas de fusión y la escalabilidad era difícil. Escalar una aplicación enorme no suele ser un picnic. Porque donde hay desafíos, siempre hay soluciones. Y en este caso en particular, la solución se convirtió en microservicios.

Entonces, ¿qué son realmente los microservicios? Comenzamos con una aplicación y luego comenzamos a hablar sobre los patrones adecuados de desarrollo. Modularizamos diferentes partes de la aplicación. Y luego comenzamos a hablar de descomponer estos diferentes módulos en diferentes servicios. Y a medida que avanzábamos, se convirtió en una red de servicios. En una implementación adecuada, cada microservicio también se supone que es dueño de sus propios datos. En la práctica, esto no siempre sucede, pero es la mejor práctica de implementación para que cada microservicio también sea dueño de la base de datos. A menudo escucho preguntas sobre la arquitectura orientada a servicios versus microservicios. Entonces, si estás en el lado izquierdo de este diagrama y tienes una capa de datos, una capa de lógica empresarial y una capa web, incluso si estas tres capas están separadas, estás en microservicios. Separarse por preocupaciones verticales aún no es microservicios. Los microservicios se separan por lógica empresarial. En este caso, por ejemplo, la autenticación sería un microservicio separado.

3. Microservices and Containers

Short description:

Y puede escalar de forma independiente del oyente HTTP que sirve la aplicación web. El mayor beneficio de los microservicios y la razón por la que toda la industria adoptó los microservicios es que permiten la agilidad. Los beneficios de los microservicios se derivan directamente de la descripción arquitectónica. Entonces, ¿por qué usar contenedores? La industria naviera solía enviar cada carga de trabajo en un tipo de contenedor separado y manejarlo de forma independiente. Y luego la industria naviera adoptó los contenedores.

Entonces, si estás dividiendo por propósito empresarial, estás en un mundo de microservicios. Entonces, microservicios, y esto es de microservices.io, ¿verdad? Se definen como un patrón de arquitectura de una colección de servicios que están débilmente acoplados, se pueden implementar de forma independiente, se organizan por capacidades empresariales y son propiedad de equipos pequeños.

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

Entonces, los beneficios de los microservicios se derivan directamente de la descripción arquitectónica. Por lo tanto, pueden escalar de forma independiente. Entonces, si solo necesitas una instancia o solo tres instancias del servicio de autenticación, y necesitas 15 instancias del servicio de carga de fotos, puedes escalarlos de forma independiente. No tienes que crear una máquina virtual para todo el monolito que hace todas estas cosas. Puedes implementarlos de forma independiente, lo que permite la agilidad. Puedes confiar en diferentes pilas tecnológicas. Entonces, si quiero usar Python y tú quieres usar Java, definitivamente podemos hacerlo y cada servicio admitirá la tecnología que mejor se aplique a él. Y luego pueden depender de dependencias conflictivas, lo que también puede ser un gran beneficio, ¿verdad? Porque si necesito la versión dos de Python y tú necesitas la versión tres de Python, si estuviéramos en un monolito, estaríamos en conflicto entre nosotros. Pero ahora podemos tener diferentes microservicios que dependen de diferentes versiones de la misma biblioteca. Y lo más importante, serás un desarrollador de microservicios, lo que te convertirá en un unicornio de Silicon Valley de la manera adecuada. Esta imagen es de GitHub.com 503. Es un error 503, pero se ve realmente bien.

Entonces, ¿por qué usar contenedores? Escucho a mucha gente decir que los contenedores son imprescindibles para la implementación de microservicios. Me gusta esta cita de Jeffrey Richter, que escribió como 18 libros diferentes sobre informática. Básicamente, los microservicios son un patrón de diseño arquitectónico y los contenedores son una implementación que a menudo ayuda. Técnicamente, no es necesario tener contenedores para implementar microservicios, pero a menudo facilita tu vida. Entonces, ¿por qué usamos contenedores? Bueno, aquí, una metáfora de la industria naviera realmente ayuda. La industria naviera solía enviar cada carga de trabajo en un tipo de contenedor separado y manejarla de forma independiente. Y luego la industria naviera adoptó los contenedores. Estos enormes contenedores de envío. Y puedes ver que en los años 70, cuando la industria naviera adoptó los contenedores, hubo un crecimiento exponencial del comercio mundial, ¿verdad? Porque los contenedores de envío eran mucho más fáciles. Podías estandarizar en un procedimiento particular. Y así no tenías que manejar cada carga de trabajo de manera diferente.

4. Container Technology and CI-CD Implementation

Short description:

Y eso te permitió construir barcos que admiten contenedores, construir procedimientos para la descarga, carga en barcos y cosas así, básicamente habilitó un crecimiento explosivo en toda la industria. Entonces, si estamos hablando de la tecnología de contenedores, es inmutable, es portátil y se basa en código abierto y estándares abiertos, ¿verdad? En una vida anterior, solía ser un desarrollador e implementaba algo y funcionaba perfectamente en mi máquina. Y luego, cuando llegaba al entorno de prueba, las cosas dejaban de funcionar. Entonces, básicamente, encontramos una forma de enviar una máquina de desarrollo y ese contenedor se puede enviar y funcionar de manera portátil en diferentes entornos. Así que hablemos de los contenedores, porque en realidad es relevante para implementar CI-CD para microservicios, y específicamente si estás ejecutando una implementación de Kubernetes, lo cual probablemente estés haciendo. Un contenedor es la unidad de cómputo más pequeña y se instancia a partir de una imagen de contenedor. La imagen de contenedor tiene diferentes capas, así que básicamente comienzas con el sistema operativo base de Linux. Por lo general, es Linux, hay contenedores de Windows, pero no hay muchos de ellos. 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 y tu aplicación. Y luego tienes la capa de la aplicación real. De esta manera, empaquetamos toda la versión de nuestra aplicación en un contenedor.

Y eso te permitió construir barcos que admiten contenedores, construir procedimientos para la descarga, carga en barcos y cosas así, básicamente habilitó un crecimiento explosivo en toda la industria. Y de alguna manera, esos beneficios también son ciertos para los contenedores de cómputo.

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

En una vida anterior, solía ser un desarrollador e implementaba algo y funcionaba perfectamente en mi máquina. Y luego, cuando llegaba al entorno de prueba, las cosas dejaban de funcionar. Básicamente, este meme proviene del blog de Cam, pero dice `funciona en mi máquina`. Vamos a enviar tu máquina, y así es como nació Docker. Básicamente, encontramos una forma de enviar una máquina de desarrollo y ese contenedor se puede enviar y 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 la computadora 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. Así que hablemos de los contenedores, porque en realidad es relevante para implementar CI-CD para microservicios, y específicamente si estás ejecutando una implementación de Kubernetes, lo cual probablemente estés haciendo. Entonces, un contenedor es la unidad de cómputo más pequeña y se instancia a partir de una imagen de contenedor.

Es un poco similar a una imagen de máquina virtual, si estás familiarizado con ellas. 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. La imagen de contenedor tiene diferentes capas, así que básicamente comienzas con el sistema operativo base de Linux. Por lo general, es Linux, hay contenedores de Windows, pero no hay muchos de ellos. 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 y tu aplicación. Y luego tienes la capa de la aplicación real. Básicamente, la anatomía de un archivo Docker para una aplicación de JavaScript es similar a esto. Básicamente, estás descargando una imagen de un registro, generalmente hay un registro donde viven las imágenes. Y si estás en una empresa grande, probablemente estés descargando desde un registro interno. Si estás construyendo solo para ti, entonces tal vez estés descargando desde Docker Hub o algún registro público disponible. Luego básicamente defines tus variables de entorno. Puedes instalar dependencias. Tus dependencias de herramientas básicamente dependen de tu imagen base y del tiempo de ejecución que necesitas. En este caso, vamos a copiar el archivo package JSON, copiar el archivo package 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 ejecutamos la aplicación, ¿verdad? De esta manera, empaquetamos toda la versión de nuestra aplicación en un contenedor.

5. Container Technology and Challenges

Short description:

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

Y ahora puedo ejecutar este contenedor en diferentes entornos. Y como dije, será portátil, funcionará de la misma manera en muchos lugares diferentes. Básicamente, las imágenes de contenedor se almacenan en un registro de imágenes. Y luego podría tener diferentes versiones del mismo contenedor en el registro, ¿verdad? A medida que creo nuevas versiones de mi aplicación, puedo crear nuevas versiones de mi imagen de contenedor y luego puedo enviarlas al registro. Y luego están disponibles. Básicamente, también podría obtener las diferentes versiones. Entonces, si quisiera ejecutar, digamos, frontend 2.0 con Mongo 3.6, podría ejecutar esta combinación de servicios. De facto, este Kubernetes está en todas partes y básicamente es el estándar para la orquestación de la entrega de aplicaciones. Proporciona mucha extensibilidad, mucha personalización y una gran community de colaboradores de código abierto, y se convirtió en esta gran tecnología que impulsa todo. Y luego, sí, por supuesto, la perspectiva del desarrollador es como, solo quiero escribir código, ¿verdad? Déjame solo escribir código. Realmente no me importa la plataforma. Y ahí es donde estamos tratando de llegar, donde la plataforma Kubernetes puede ser 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 luego puedes ponerlo en tu currículum y convertirte en un desarrollador de Kubernetes en una empresa de Silicon Valley. Entonces, hablemos brevemente sobre los desafíos con los microservicios. No todo es perfecto. No resolvimos todos tus problemas. Solo creamos diferentes tipos de problemas con los microservicios. Básicamente, crear microservicios es fácil. Hacer que los microservicios funcionen bien entre sí puede ser difícil. Entonces, una de las cosas que sucede es que los microservicios están definidos por la integración de API publicadas por el usuario. Piénsalo como un contrato. Básicamente, tienes contratos entre diferentes microservicios. Y si alguien rompe este contrato sin actualizar la documentation, sin actualizar a tu equipo, esencialmente puede romper todos los servicios que dependen de ellos. En lugar de tener un infierno de fusiones e integraciones, donde todos los equipos se juntan y luego tienen que fusionarlo, esencialmente tienes esta situación en la que alguien puede enviar un cambio sin depender de ti, pero luego puedes descubrir que ya no funciona con tu servicio en particular. La otra cosa es que es una red. Entonces, cuando hay una falla en la red, puede crear una falla en cascada en toda la red, lo que 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. Entonces, un microservicio, es un dicho común que un microservicio solo puede hacer una cosa, ¿verdad? Solo estás haciendo un microservicio si es responsable de una única lógica empresarial.

6. Challenges of Microservices

Short description:

Si tu microservicio solo hace una cosa, no puede tener un error porque eso sería algo adicional. Los desafíos de los microservicios incluyen identificar agentes o contenedores bloqueados, manejar la comunicación de red, disminuir el rendimiento debido a los saltos de red y la serialización, realizar pruebas de forma aislada, depurar y monitorear entre servicios, y admitir múltiples versiones de API.

Pero luego está esta broma de que si tu microservicio solo hace una cosa, no puede tener un error porque eso sería algo adicional. Ahora, suena como una broma, pero en realidad es cierto, y en muchas implementaciones patterns. Si tu agente está bloqueado, si tu contenedor en particular está bloqueado, puede ser realmente difícil identificar si todavía está trabajando en algo o si está realmente bloqueado y necesita ser detenido. Entonces, esto es algo de lo que también debemos preocuparnos a nivel de contenedorización. En resumen, los desafíos de los microservicios esencialmente implican que más servicios significan más comunicación de red, lo que requiere más códigos de recuperación de fallas y tiempos de espera. Esto es algo de lo que tú, como desarrollador, debes preocuparte. Disminuye el rendimiento general debido a los saltos de red y la continua serialización y deserialización de objetos. Es difícil realizar pruebas de forma aislada sin los servicios dependientes. Entonces, puede ser realmente difícil detener todo y poder probar un servicio de forma aislada. Es difícil depurar y monitorear entre diferentes servicios. Y los nuevos servicios deben admitir todos los nuevos contratos de API simultáneamente, lo cual es, nuevamente, si implementaste CIC antes, es posible que también te hayas preocupado por esto, porque quieres admitir múltiples versiones del mismo código. Pero a medida que implementas nuevos microservicios, 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 seleccionar la versión de API con la que realmente pueden trabajar.

7. CI-CD with Tacton for Kubernetes

Short description:

Entonces, estoy gestionando implementaciones y finalmente llegamos a la parte de CIC. Podrías usar el pipeline existente, como Jenkins o Azure DevOps, para implementar microservicios en plataformas Kubernetes o OpenShift. Sin embargo, es útil utilizar un pipeline de CICD nativo de la nube diseñado para Kubernetes. Tacton es un proyecto de código abierto que proporciona CICD declarativo nativo de Kubernetes. Elimina la necesidad de mantener un servidor Jenkins y ofrece una biblioteca de tareas con integraciones para herramientas existentes. Un pipeline de Tacton consta de tareas y pasos, lo que permite la ejecución secuencial y concurrente con lógica condicional y reintentos. Proporciona una implementación de CI para contenedores Kubernetes y aplicaciones de microservicios.

Entonces, estoy gestionando implementaciones y finalmente llegamos a la parte de CIC. Básicamente, podrías usar el pipeline existente. Espero que ya tengas pipelines de CIC de algún tipo, y podrías usar Jenkins o Azure DevOps o algo así, seguro, para implementar Kubernetes, para implementar microservicios en Kubernetes o plataformas OpenShift. Pero es útil usar algo que sea... Y usaremos el término de moda nativo de la nube, CICD nativo de la nube, que está diseñado para Kubernetes.

Entonces, básicamente es un pipeline como un servicio, por lo que estamos poniendo todo en contenedores. Los pipelines se ejecutan en contenedores y son nativos de Kubernetes. Son nativos de la autenticación de Kubernetes y cosas así. Uno de los servicios potenciales, y el que utiliza Red Hat, es Tacton. Tacton es un proyecto de código abierto respaldado por la Continuous Delivery Foundation. Básicamente, es CICD declarativo nativo de Kubernetes. Los pipelines se ejecutan bajo demanda en contenedores aislados. No tienes que mantener un servidor Jenkins o algo así. Hay una biblioteca de tareas de la que puedes obtener, nuevamente, se integra con Kubernetes y tiene muchas integraciones con herramientas existentes.

Entonces, básicamente, un pipeline de Tacton es similar a los pipelines que podrías haber visto antes. Básicamente, está compuesto por tareas y cada tarea está compuesta por pasos. 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 usando. Básicamente, necesitas descargar esa imagen de contenedor. Luego, una tarea es una lista de diferentes pasos. 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 y secuencial de pasos que necesitas realizar para completar una tarea. Las tareas pueden ser preimplementadas, esencialmente, las tareas se pueden encontrar en Tacton Hub, que es un registro público, un hub público para tareas de Tacton. Entonces, para cosas que ocurren todo el tiempo, como tareas de AWS CLI o algo así, puedes obtenerlo de esta biblioteca. Y una vez que tienes la tarea definida, puedes unirla en un pipeline. Un pipeline es esencialmente un gráfico de tareas que se pueden ejecutar de forma secuencial o concurrente. Pueden ejecutarse en nodos diferentes. Pueden tener lógica condicional y reintentos. Entonces, si un paso en particular no tuvo éxito, podemos ejecutarlo nuevamente hasta que tenga éxito, ¿verdad? Y pueden compartir datos entre tareas, lo cual, nuevamente, es algo que debe suceder porque a menudo se manejan artefactos entre diferentes etapas del pipeline. En resumen, te brinda una implementación de CI para tus contenedores Kubernetes, lo que también significa tu aplicación de microservicios. Y solo porque necesitábamos más términos de moda en esta industria, creamos un término de moda para GitHubs.

8. GitHubs and Cloud-native Development

Short description:

GitHubs es un enfoque de 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 implementación. Los pipelines 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 de la nube permite una implementación más rápida. Gracias por estar aquí. Soy Sasha Rosenbaum, encuéntrame en Twitter y GitHub como DevineOps.

GitHubs es esencialmente un enfoque de DevOps, de CICD, donde todo se implementa, controlado a través de Git y todo es básicamente declarativo. En particular con OpenShift, y nuevamente, puedes hacer lo mismo con Manila Kubernetes, puedes usar Argo CD para la parte de CD de la aplicación. Entonces, básicamente, tendrías pipelines de CI en Tacton, y tendrás Argo CD en el lado de CD, y luego Argo CD es la definición declarativa de GitHubs que define en qué entorno se implementa realmente tu código. Y me gusta este diagrama. Básicamente, tus pipelines de Tacton están construyendo tus imágenes de contenedores y enviándolas al registro de imágenes. Y luego defines, básicamente, agregas manifiestos que dicen, ok, para este tipo de imagen va al entorno de desarrollo, este tipo de imagen de contenedor va al entorno de preparación, y así sucesivamente. Entonces, esencialmente, se implementa de manera declarativa, configuraciones de estado decididas 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 del Valle del Silicio, y todos están muy contentos y todos están utilizando microservicios con éxito. Entonces, el desarrollo de aplicaciones cloud-nativas se trata de ser más rápido. No necesariamente va a hacer tu vida más fácil en todas las dimensiones, pero permite a las empresas en particular, a los equipos de desarrollo, moverse más rápido con la implementación 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. Introduction and Crowd Response

Short description:

Hola, Sasha. ¡Hola! Estoy muy feliz de estar aquí y estoy realmente emocionado de que seas mi anfitriona porque siempre es divertido charlar contigo también. Es interesante ver que la mayoría de las personas son nuevas en diferentes tipos de arquitecturas, arquitectura orientada a servicios y microservicios, contenedores. La gran idea de cambiar a Kubernetes y las orquestaciones de contenedores era liberar a los desarrolladores de lidiar con la infraestructura, pero es importante comprender CICD y todas estas cosas.

Hola, Sasha. ¡Hola! Estoy muy feliz de estar aquí y estoy realmente emocionado de que seas mi anfitriona porque siempre es divertido charlar contigo también. De hecho, tuve la oportunidad de elegir a quién presentaré, 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 audiencia, y preguntaste si las personas tienen experiencia con diferentes tipos de arquitecturas, arquitectura orientada a servicios y microservicios, contenedores. Y es interesante ver que la mayoría de las personas son nuevas en todo lo mencionado anteriormente, lo cual no me sorprende, ya que es más una conferencia de front-end, pero es interesante ver cómo se está produciendo ese cambio, ¿verdad? ¿Qué piensas? Bueno, creo que la gran idea de cambiar a Kubernetes y las orquestaciones de contenedores y cosas así era liberar a los desarrolladores de lidiar con la infraestructura, y creo que en cierto sentido lo que está sucediendo es lo contrario, ¿verdad? Y estamos logrando que los desarrolladores aprendan más sobre la infraestructura. En un sentido, es mejor porque los desarrolladores y las operaciones se unen 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 así ya es suficientemente difícil hacer front-end si también tienes que preocuparte por las implementaciones, eso puede no ser ideal. Es bueno comprender, ya sabes, CICD y todas estas cosas, pero también es genial cuando podemos tener pipelines como un servicio y no preocuparnos por esas cosas en absoluto. Sí, estoy completamente de acuerdo. Es como si hubiera un cambio tan grande, como si el rol de todos se estuviera expandiendo.

QnA

Referential Integrity and API Versions

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 suelen ser propiedad de diferentes equipos. La idea es consumir de diferentes APIs e interactuar con las partes relevantes. 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 otras tecnologías como serverless coexisten. 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 de la audiencia, ¿cómo podemos mantener la integridad referencial entre microservicios cuando tenemos varias bases de datos? Sí, desafortunadamente, tienes que comunicarte con la base de datos que te importa, ¿verdad? Y eso, no es necesariamente fácil, ¿verdad? No es necesariamente fácil para que cada microservicio posea sus propios datos. Muchas veces, las bases de datos son propiedad de otro equipo y tienes que empezar a comunicarte con la misma base de datos, lo cual rompe parte del propósito de los microservicios y la separación de responsabilidades. Pero sí, la idea es seguir consumiendo de diferentes APIs e interactuar con las partes que te importan.

Genial, y luego hubo otra pregunta, ¿cuáles son las mejores estrategias para admitir varias versiones de API con una arquitectura de microservicios? Sí, hay pautas para tener versiones de API, comúnmente se publica la versión, ¿verdad? Como v1, v2, v3. Y cuando desarrollas microservicios, en realidad, cuando desarrollas cualquier cosa en el mundo moderno, debes admitir al menos dos versiones de tu código, ¿verdad? Nunca podrás pasar de una versión a la siguiente sin mantener la compatibilidad hacia atrás. Hay algunas implementaciones, como escribir en una base de datos, supongamos que tenías apellido y nombre como dos campos separados, y ahora quieres combinarlos, ¿verdad? Entonces, mantén ambos, ¿verdad? Ten apellido y nombre como dos campos separados, y también apellido y nombre como un mismo campo. Por un tiempo, básicamente escribe en ambos, ¿verdad? Y luego pasas a la siguiente versión de la API y puedes retirar la anterior. No retiras el código inmediatamente después de cambiarlo, lo retiras después de otra iteración, ¿verdad? Y nuevamente, la versión de la API es tu contrato, ¿verdad? Si estoy consumiendo v1 y tú pasaste a v2, si solo me dices que pasaste a v2 y ya no admites v1, entonces rompiste el contrato conmigo y tengo problemas para lidiar con eso, obviamente. Pero si admites ambos, entonces podemos trabajar juntos por un tiempo. Y luego, obviamente, en algún momento me dirás que v1 se retiró y es hora de pasar a la siguiente, ¿verdad? Sí, tiene mucho sentido.

Dennis pregunta, ¿qué tan prevalente ves que sea Kubernetes en el futuro? Las funciones en la nube cumplen algunas de las mismas necesidades. Creo que Kubernetes es el estándar de facto, ¿verdad? Y todos están implementando su versión de Kubernetes, ¿verdad? Quiero decir, cada nube tiene su propio orquestador de Kubernetes, como OpenShift, que es como un Kubernetes listo para la empresa, ¿verdad? Así que todos están en este barco y es un barco grande. Y efectivamente, es el estándar para la implementación. Obviamente, puedes implementar funciones como servicio y seguir utilizando monolitos y mainframes. Todas estas cosas coexisten. Inventamos nuevas tecnologías y nos adaptamos a ellas. Y luego, nunca sabes cuándo se va a introducir algo nuevo, ¿verdad? Así que tal vez, además de los contenedores y el serverless, tendremos nuevos patrones que surgirán en los próximos años. Creo que eso es bastante probable, sinceramente. Y en cuanto a Kubernetes versus serverless, quiero decir, hay implementaciones de serverless que utilizan Kubernetes. Así que ahora todas las líneas están borrosas. Quiero decir, los microservicios y el serverless tienen muchas cosas en común. Pero nuevamente, los microservicios son más flexibles, ¿verdad? Las funciones, por diseño, tienen limitaciones. No pondrías una aplicación web en funciones, eso simplemente no funcionaría. Eso es un ejemplo, ¿verdad? Mientras que los microservicios pueden admitir casi cualquier aplicación. No necesariamente será el camino más fácil para implementar una aplicación, pero definitivamente puede admitir casi cualquier arquitectura. Tiene sentido. Sí. Como ambos somos coorganizadores de DevOps Days en todo el mundo, creo que es muy interesante que la historia de DevOps se esté expandiendo a otras tecnologías, como esta conferencia con DevOps.

Evolution of DevOps and Pipeline Checkpoints

Short description:

JS discute la evolución del mundo de DevOps y el cambio de roles de los operadores. El enfoque ahora se centra en resolver desafíos más interesantes y ajustar la tecnología para cumplir con las expectativas empresariales. El estado ideal para los desarrolladores es enfocarse en entregar valor comercial en lugar de detalles de implementación. Los puntos de control en las canalizaciones son cruciales para garantizar un funcionamiento adecuado, incluyendo verificaciones de código, construcción, pruebas, verificaciones de registro de imágenes y verificaciones 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 suceder a continuación? ¿Cuáles son tus pensamientos sobre cómo está cambiando y evolucionando el mundo de DevOps? Es interesante. Patrick acaba de compartir un tweet de todos los sabores de DevOps de la industria y es aterrador porque casi parece el panorama de CNCF. ¿Sabes a lo que me refiero? Hay tantas palabras que describen cosas similares o diferentes, y simplemente seguimos expandiendo los niveles de preocupación en todos estos trabajos diferentes.

Creo que si miro, como, diez o algo así, en 2009, 11, casi doce años atrás cuando comenzó todo el movimiento de DevOps, a veces me hago una pregunta, como, ¿mejoramos el mundo? Y creo que sí, ¿verdad? Y seguimos haciendo eso, pero, como, si piensas en el trabajo del operador en comparación con el trabajo del operador hoy en día, creo que los operadores trabajan en desafíos mucho más interesantes, que, como sabes, en lugar de hacer clic en botones y hacer lo mismo una y otra vez y preocuparse por, no sé, las cintas de respaldo y cosas así, ahora, como, los operadores están implementando, básicamente, escribiendo código, lo cual es terrible para mí decir que escribir código es lo más genial, pero, de nuevo, como, básicamente resolvemos desafíos más interesantes. También es como que el mundo ha avanzado, ¿verdad? Hace 10 años podías tener una interrupción durante todo el sábado mientras movías tu aplicación a una nueva versión, y hoy en día, como, no hay ningún negocio en el mundo para el cual sería aceptable simplemente estar, como, fuera de servicio por mantenimiento durante todo un día. Eso simplemente ya no funciona, ¿verdad? Así que tienes que ajustar tu tecnología a las expectativas de todos, básicamente. Creo que en términos de llegar al frontend, no sé. Creo que la expectativa debería ser que las personas puedan trabajar en entregar valor comercial en lugar de preocuparse por los detalles de implementación. Y ahí es donde, como, tal vez deberíamos cerrar el círculo completo y estar en un sentido donde, como, puedes hacer clic en un botón y luego obtendrás un contenedor o lo que sea o una función o ni siquiera te importan los detalles de implementación, ¿verdad? Obtengo un contenedor de este tipo y puedo ejecutar mi aplicación en producción y todo en lo que me preocupo es el código, ¿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?, a menudo ha sido la promesa de plataformas pasadas como OpenShift que hablan de, como, desde el IDE hasta la producción. Así que es interesante cómo volvemos a ese tipo de modelo. Sí, hay, sabes, una última pregunta para concluir tu charla, ¿cuáles son los puntos de control que estableces para asegurarte de que tus canalizaciones funcionen como se espera? ¿Hay algún consejo rápido al respecto para asegurarse de que las personas estén cubiertas? Sí, quiero decir, hay múltiples, básicamente, verificaciones que puedes mostrar y, como, si tienes la tecnología configurada correctamente, tendrás puertas para que realmente puedas, como, la entrega continua no significa que siempre vayas automáticamente a producción, ¿verdad? Idealmente, tienes un punto de control después de verificar tu código y tienes un punto de control después de construirlo, tienes un punto de control después de ejecutar pruebas y puedes tener varios de esos porque puedes tener varios tipos de pruebas, básicamente. Para estos tipos de canalizaciones, tienes un punto de control cuando estás verificando la imagen en el registro de contenedores. Y luego, básicamente, el punto de control donde lo revisas y luego, el despliegue es algo completamente diferente, donde una vez que se despliega, también debes ocuparte del monitoreo y cosas así. Y luego, por lo general, ahora, muchas veces cuando estás verificando en el control de origen, pero definitivamente necesitas ejecutar verificaciones de seguridad, ¿verdad? Y nuevamente, las verificaciones de seguridad también pueden ser en múltiples etapas, ¿verdad? Puedes ejecutar análisis de código del sitio y luego puedes ejecutar seguridad como parte de tus pruebas. Y luego, obviamente, monitoreas la seguridad una vez que se despliega. Así que hay muchas cosas diferentes. Creo que, básicamente, debes aprovechar las cosas que son gratuitas y fáciles de implementar primero, y eso ya te pone por delante de muchas empresas. Y luego, comienza a buscar diferentes herramientas que te permitan asegurarte de que tus aplicaciones sean seguras y funcionen bien. Creo que la seguridad es una de las cosas que a menudo se pasan por alto cuando las personas se preocupan tanto por la velocidad de implementación. No podría estar más de acuerdo. Muchas gracias, Sasha. Siempre es un placer y un honor tenerte aquí. Únete a Sasha en su sala de conferencias inmediatamente después de su charla y en el chat espacial. Podremos hablar con ella y establecer contactos. Así que muchas gracias por unirte, como siempre, una charla excelente. 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

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.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
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.
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.
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.
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

Node Congress 2023Node Congress 2023
119 min
Decomposing Monolith NestJS API into GRPC Microservices
Workshop
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
Node Congress 2023Node Congress 2023
102 min
Decoupling in Practice
WorkshopFree
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
DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
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.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
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.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
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.