devops

Las empresas se están convirtiendo rápidamente en una intrincada malla de muchas aplicaciones. A medida que las empresas crean más y más microservicios, sus entornos de implementación son cada vez más elaborados. Sin las configuraciones adecuadas, una hoja de ruta de microservicios podría convertirse rápidamente en imposible de mantener.

Según el CEO de DeployHub , Tracy Ragan, si los equipos de desarrollo están presionando puntos hacia un clúster continuamente, el desarrollo de aplicaciones puede verse afectado sin una gran visibilidad de sus dependencias e interrelaciones de aplicaciones.

En su reciente charla, ” Evolucionando su tubería para microservicios con DeployHub “, presentada por la Continuous Delivery Foundation ( CDF ), Ragan, también miembro de la Junta de Gobierno de CDF, discutió las formas en que los equipos pueden obtener una mejor visión de las tuberías de entrega de microservicios.

Problemas de seguimiento de microservicios

Un estudio de 2018 realizado por O’Reilly encontró que el 86% de los encuestados alcanzó un éxito leve en la adopción de microservicios en la producción. Solo el 15% informó “éxito masivo”. Estos resultados demuestran tanto la emoción que rodea a los microservicios como la rareza de una ejecución perfecta.

“Soy un gran fanático de los microservicios”, dijo Ragan. “Este es un momento emocionante para estar en el desarrollo de software”. Los microservicios se rompen del modelo tradicional de entrega de software, dijo, obligando a los equipos a enfatizar el tiempo de ejecución. Sin embargo, con este cambio, se hace fácil perder las vistas lógicas entre las aplicaciones.

Según Tracy, el seguimiento de dependencias y el control de versiones son los principales problemas para mantener los arreglos de microservicios. Con actualizaciones continuas, puede ser un desafío realizar un seguimiento de qué versión está utilizando un servicio. “El desarrollo de microservicios se desmorona sin un enfoque de gestión coherente”, dijo.

Perder visibilidad al pasar de CI a CD

Parte de la pérdida de visibilidad proviene del cambio de CI a CD. La integración continua (CI) implica la actualización rutinaria del código fuente y el inicio del proceso de compilación. Esto a menudo se hace cada hora, en lugar de cada semana o mes. Con el CI tradicional, el sistema creó un paquete y escaneó las dependencias en la compilación . Este fue el primer paso en el viaje continuo.

Sin embargo, hoy en día, los microservicios generalmente están vinculados en tiempo de ejecución o en el archivo de implementación de Kubernetes como parte de un proceso de entrega continua (CD). Al hacerlo, hemos perdido una cierta cantidad de visibilidad que otorga CI. Ragan lo comparó con “martillar una copa de vino”, todavía tenemos las partes constituyentes, pero yacen destrozadas.

Grandes conjuntos de microservicios de 50, 100 o incluso 300 no son infrecuentes en estos días. Tales ecosistemas grandes requieren un seguimiento lógico de versiones y dependencias. Ragan argumentó que los equipos de desarrollo necesitan una capa de solución alternativa para reemplazar la gestión de configuración crítica perdida en los informes de compilación de CI. La visibilidad de las interrelaciones es necesaria para rastrear cómo los cambios en un servicio afectarán a otras aplicaciones.

Entra Ortelius

Ortelius es un paquete que ayuda con la gestión continua de microservicios. Ortelius, llamado así por Abraham Ortelius, el inventor del primer atlas, ayuda a rastrear las conexiones entre los servicios para mejorar la visibilidad de un ecosistema.

Para tener una idea de cómo se comporta, considere una tienda de comercio electrónico. Para llegar a una tubería de microservicios evolutiva, cada microservicio debe implementarse independientemente con su propio flujo de trabajo. Por ejemplo, una tienda de comercio electrónico puede requerir un microservicio de producto, un microservicio de pago y un microservicio de autenticación. Estos componentes reutilizables se pueden implementar de forma independiente, pero dependen unos de otros para funcionar como un todo.

A escala macro, una empresa con miles de dependencias entre aplicaciones se parecería visualmente a una constelación de nodos. Un ejemplo extremo de esto puede parecerse a la Estrella de la Muerte de Netflix , un conglomerado masivo de puntos de intersección. Ortelius garantiza la transparencia en un desorden enredado como un “mercado interno para microservicios”, dijo Ragan.

Emparejamiento de Ortelius con DeployHub

Ortelius es el núcleo de código abierto de DeployHub, un SaaS de código abierto para compartir y liberar microservicios. Ortelius, junto con DeployHub, permite a los equipos ver el mapa lógico de la aplicación, exponiendo la complejidad de las dependencias de microservicios.

Los desarrolladores agregan DeployHub a cualquier flujo de trabajo de desarrollo de microservicios existente antes del lanzamiento. Luego se llama a Ortelius para incrementar el servicio y registrar la información de dependencia. DepoyHub luego usa Helm o Ansible para la inserción de código real, y agrega los metadatos de registro y agrega la capa de seguimiento y mapeo. Tener esa información sigue siendo fundamental para informar, como informes dif o un informe de lista de materiales, señaló Ragan.

Este tipo de solución, propuso Ragan, también es vital para la gestión continua de la configuración: cuando cambia un microservicio, el equipo siempre estará al tanto de la nueva versión de la aplicación.

El nuevo modelo de tubería de microservicios

Como se señaló anteriormente, en el modelo tradicional, los equipos de DevOps asignan dependencias en la etapa de CI. Cuando un desarrollador de API publica en el catálogo principal, define atributos específicos basados ​​en los microservicios. Un motor de versiones generalmente se asignará para visualizar las dependencias.

Ragan describió los pasos para una nueva tubería de microservicios:

  1. Crear imagen : compila y crea la imagen del contenedor.
  2. Poner en el registro : Quay o Docker. Específico para registros de contenedores.
  3. Rastree configuraciones de aplicaciones de servicio : aquí es donde recopilamos datos de configuración para mapear las relaciones estructurales.
  4. Push to cluster : DeployHub ayuda a estandarizar este proceso en una organización.
  5. Recopile comentarios : informes de configuración y análisis de impacto.

El núcleo de este proceso es poder implementar de forma independiente microservicios y agregar información útil. Por supuesto, este es un modelo incompleto: una tubería completa utilizaría otros pasos, incluidas las pruebas y el escaneo de seguridad automatizado.

Beneficios

Al racionalizar el viaje de microservicios de esta manera, los repos se dividirán y los equipos ya no pasarán por un gran flujo de trabajo largo. Según Ragan, la visibilidad obtenida de este método podría ayudar a las organizaciones de muchas otras maneras:

  • Reduzca el tiempo : Ragan estimó que el mapeo automatizado de relaciones de aplicaciones podría reemplazar una o dos horas de trabajo manual por semana por equipo de desarrollo.
  • Reutilización : la descomposición de las aplicaciones en sus dominios ayuda a la reutilización en una organización.
  • Evite la redundancia : el uso compartido de código puede reducir significativamente el código duplicado, evitando así la redundancia y aumentando la flexibilidad.
  • Visibilidad : la aplicación detallada al servicio de conocimiento relacional podría permitir a los SRE tomar mejores decisiones basadas en datos.
  • Centralizar : ayuda a estandarizar los procesos de implementación de contenedores independientemente del tipo de clúster o colección, ayudando a las implementaciones de microservicios tradicionales y en contenedores.
  • Control de versiones : la información mejorada sobre el control de versiones ayuda cuando necesita compartir servicios externamente.

Por último, lo bueno es que Ortelius es de código abierto en GitHub . Ortelius adopta un formato de comunidad abierta para aceptar comentarios. “La democratización es la razón principal por la que tenemos código abierto”, dijo Ragan. Ortelius se puede usar de forma gratuita o con características adicionales de los precios de DeployHub para casos empresariales.

Una confluencia de estilos de entrega de software

Administrar la entrega continua de software a través de muchos microservicios conduce a problemas sin precedentes. Al resolver estos problemas, la industria parece fracturarse ligeramente. Por ejemplo, el modelo promovido por Ragan contrasta con una presentación reciente que cubrí de Codefresh .

Donde Ragan sugirió mejorar la visibilidad en las tuberías de implementación de microservicios independientes, Dan Garfield de CodeFresh sugirió adoptar una sola tubería CI / CD para operar todos los microservicios desde un solo plano de control. Como suele suceder en las herramientas de software, el caso de uso probablemente dictará la adopción.

Cualquiera sea el proceso de entrega del software, al descomponer las aplicaciones, o “llevar el martillo a la copa de vino”, como lo llamó Ragan, probablemente no deberíamos sacrificar la visibilidad de los metadatos asociados con las versiones de la aplicación y las interrelaciones entre el servicio y la aplicación. Si dichos datos se pierden o no se gestionan correctamente, podríamos perder mucho valor potencial.

Para obtener más información sobre la evolución de las canalizaciones de DevOps, vea el seminario web presentado por CDF aquí . DeployHub también publicó un artículo adyacente sobre este tema aquí . También puedes contribuir a Ortelius en GitHub .

Autor: BILL DOERRFELD Fuente: https://devops.com/how-to-use-microservices-to-evolve-devops-pipelines/

Etiquetas:

Sobre el Autor

0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments