Microsoft recientemente anunció la creación de un proyecto de código abierto, el cual es OAM, un nuevo estándar para desarrollar y ejecutar aplicaciones en Kubernetes y otras plataformas. Este nuevo proyecto fue lanzado debido a que Kubernetes se ha convertido en el principal entorno de orquestación de contenedores.
Su éxito ha llevado al notable crecimiento de los servicios en todas las nubes públicas. Sin embargo, los recursos centrales de Kubernetes, como Servicios e Implementaciones, representan elementos dispares de una aplicación global. No representan la aplicación en sí. Del mismo modo, los objetos como los gráficos de Helm representan una aplicación potencialmente desplegable, pero una vez implementada, no existe un modelo que se centre en la aplicación actual.
Es por eso que Microsoft y Alibaba Cloud crearon el proyecto Open Application Model (OAM) bajo Open Web Foundation.
OAM es una especificación para describir aplicaciones para que la descripción de la aplicación se separe de los detalles de cómo la infraestructura implementa y administra la aplicación. Esta separación de preocupaciones es útil por varias razones.
En el mundo real, cada clúster de Kubernetes es diferente, desde la entrada a la Interfaz de red de contenedores (CNI) hasta la malla de servicios.
Al separar la definición de la aplicación de los detalles operativos del clúster, los desarrolladores de aplicaciones pueden centrarse en los elementos clave de su aplicación en lugar de los detalles operativos de su implementación.
Además, la separación de preocupaciones también permite a los arquitectos de la plataforma desarrollar componentes reutilizables y desarrolladores de aplicaciones para centrarse en la integración de estos componentes en su código para crear rápida y fácilmente aplicaciones confiables.
En todo esto, el objetivo del modelo de aplicación abierta es hacer que las aplicaciones simples sean fáciles y que las aplicaciones complejas sean manejables.
En OAM, una aplicación consta de varios conceptos. El primero son los componentes que componen una aplicación. Estos componentes pueden ser servicios como una base de datos MySQL o un servidor PHP replicado con un equilibrador de carga correspondiente.
Los desarrolladores pueden crear código que empaquetan como un componente, luego el autor manifiesta que describe la relación entre ese componente y otros microservicios. Los componentes permiten a los arquitectos de plataformas y a otros crear módulos reutilizables que se sabe que encapsulan las mejores prácticas en seguridad y despliegue escalable.
También permiten separar la implementación del componente de la descripción de cómo se combinan estos componentes en una arquitectura de
Para convertir estos componentes en una aplicación concreta, los operadores de aplicaciones utilizan una configuración de estos componentes para formar una instancia específica de una aplicación para implementar.
El recurso de configuración es lo que permite que un operador de aplicación ejecute una aplicación real desde los componentes proporcionados por desarrolladores y plataformas.
El concepto final es un conjunto de características que describen las características del entorno de la aplicación, incluidas características como el autoescalado y la entrada que son importantes para el funcionamiento de las aplicaciones, pero que se puede implementar de diferentes maneras en diferentes entornos.
Un ejemplo simple de tales diferencias podría ser un equilibrador de carga de hiperescala proporcionado por la nube vs un equilibrador de carga de hardware local.
Desde el punto de vista del desarrollador de la aplicación, son completamente idénticos, mientras que desde el punto de vista del operador, son completamente diferentes. Los rasgos permiten esta separación de problemas, de modo que la aplicación puede ejecutar donde se desplieguen sus características necesarias.
Luego, los operadores de infraestructura pueden configurar estas características para cumplir con los requisitos operativos únicos de su entorno (como el cumplimiento y la seguridad).
A diferencia de un modelo de aplicación PaaS más tradicional, OAM tiene características únicas. Más importante aún, él es una plataforma agnóstica. Microsoft señala que aunque su inicial OAM, llamada Rudr, se basa en Kubernetes, OAM en sí no está estrechamente relacionado con Kubernetes.
Es posible desarrollar implementaciones para muchos otros entornos, incluso para formatos pequeños relacionados con dispositivos, donde Kubernetes puede no ser la opción correcta. También debemos pensar en entornos sin servidores donde los usuarios no quieren o no necesitan la complejidad de Kubernetes.