Desarrollo de aplicaciones con Kubernetes

Kubernetes es ampliamente considerado como la plataforma ideal para equipos de organizaciones grandes y medianas con requisitos de alta disponibilidad y escalado automático. Sin embargo, también ha añadido fricciones a los flujos de trabajo de desarrolladores existentes. Este cambio puede entenderse como parte de un impulso más amplio hacia la adopción del paradigma de los microservicios y la creciente complejidad de la forma en que se ejecuta el software. En este artículo, examinaremos cómo ha evolucionado el problema del desarrollo de software con este cambio de paradigma.

Bucle de desarrollo

Empecemos por el concepto de bucle de desarrollo y su papel en los flujos de trabajo de desarrollo. El ciclo de desarrollo de cualquier proyecto de software consiste en dos bucles separados que se cruzan sobre git.

Estos son -

• Bucle de desarrollo interno: el proceso implica escribir, compilar y probar un fragmento de código en la propia estación de trabajo del desarrollador. Este ciclo continúa hasta que un fragmento de código satisfactorio se traslada a Git.
• Bucle de desarrollo externo: este bucle se activa después de mover el código de la estación de trabajo del desarrollador a Git. Implica la ejecución de pruebas y la implementación del producto final. Lo ideal es que este proceso se configure como un bucle continuo, en el que las implementaciones se realicen con cada introducción de código que supere las pruebas.

Estos bucles se alimentan entre sí y forman un ciclo de vida completo de desarrollo de software.

El auge del microservicio

La llegada de los microservicios ha traído componentes de software pequeños, independientes y poco acoplados que ofrecen una mejor escalabilidad y confiabilidad. No vamos a hablar de las ventajas aquí, ya que ha recibido mucha publicidad, pero nos preocupa el consiguiente aumento de la complejidad operativa.

Consideremos una configuración sencilla en la que interfaz llama al api, que a su vez se comunica con otros dos servicios denominados identidad y db. En este escenario, nuestro desarrollador trabaja en el api capa, que tiene dependencias tanto descendentes (frontend) como ascendentes (identity, db). Exploremos cómo funciona el proceso de desarrollo de api cambios de servicio en los dos circuitos de desarrollo diferentes -

Bucle de desarrollo interno

• Acceso a dependencias ascendentes - api el servicio necesita comunicarse con los servicios de identidad y base de datos para ejecutarse correctamente.
• Acceso a las dependencias posteriores: para comprobar si los cambios que se están realizando en el api el servicio es compatible con sus dependencias descendentes. También es importante redirigir las solicitudes descendentes a este servicio.

Bucle de desarrollo externo

• Dependencias ascendentes: para que se ejecute una prueba e2e para el api servicio, es necesario tener acceso a una copia en ejecución de identidad y db servicios
• Dependencias posteriores: también se necesita una forma de permitir la interfaz para acceder a este servicio con fines de prueba.
• Punto final hospedado: además de los requisitos mencionados anteriormente, también necesitamos alojar esta copia del api servicio para que pueda probarse directamente

El problema del bucle de desarrollo interno es algo que Telepresencia de Laboratorios Ambassador ha resuelto para. Hemos intentado resolver el problema del bucle de desarrollo externo en Plataforma TrueFoundry por Intercepta.

Presentamos TrueFoundry Intercepts

El concepto de TrueFoundry Intercepts funciona resolviendo los tres problemas del bucle de desarrollo externo descritos en las secciones anteriores. Para abordar este problema, seguimos la siguiente estrategia:

• Vista previa de las URL: con la propia plataforma, es fácil implementar una copia de un servicio existente en un SHA de confirmación específico. Esto te permite crear URL de vista previa dedicadas a una solicitud de confirmación o incorporación de cambios en particular.
• Intercepciones basadas en encabezados: las interceptaciones permiten que un servicio continúe usando la misma URL mientras agrega un encabezado adicional que redirige a la copia de vista previa. Por ejemplo, podemos adjuntar una intercepción a api servicio que redirige a una copia de vista previa en función de un encabezado que se le pasa. Esto significa interfaz puede seguir funcionando con la misma URL simplemente pasando un encabezado adicional durante la prueba.

💡

Para obtener más información sobre las interceptaciones de TrueFoundry, consulte nuestros documentos - https://docs.truefoundry.com/docs/intercepts

Conclusión

Hemos analizado los cambios en el flujo de desarrollo provocados por la llegada de los microservicios y cómo estamos intentando abordarlos. Esta sigue siendo una cuestión pendiente, y podemos esperar soluciones aún más innovadoras en este ámbito en el futuro.

Chatea con nosotros

Si quieres maximizar los beneficios de tus proyectos de LLM y ayudar a tu empresa a aprovechar la IA de la manera correcta, nos encantaría charlar e intercambiar notas.

Disfruta de un ☕️ con nosotros

Descubra cómo TrueFoundry lo ayuda a implementar LLM en 5 minutos:

Deploy and Fine-tune Open Source LLMs With a Few Clicks!

TrueFoundry offers an intuitive solution for LLM deployment and fine-tuning. With our Model Catalogue, companies can self-host LLMs on Kubernetes, reducing inference costs by 10x in just one click. Discover how to deploy a Dolly-v2-3b model and fine-tune a Pythia-70m using TrueFoundry in our blog.

TrueFoundry Blog Truefoundry