Actualmente, SAP BTP permite la creación y el consumo de microservicios de dos maneras: SAP BTP, entorno Cloud Foundry y SAP BTP, tiempo de ejecución de Kyma.

SAP BTPentorno Cloud Foundry, permite la creación y el despliegue de microservicios. SAP HANA los servicios de aplicaciones extendidas, el modelo avanzado (SAP HANA XSA) para aplicaciones locales y Cloud Foundry para aplicaciones basadas en la nube proporcionan las plataformas para aplicaciones web políglotas basadas en microservicios.

El entorno de Kyma ahora también está disponible con SAP BTP, que permite el desarrollo y la implementación de microservicios (y funciones).

Para Cloud Foundry, los contenedores de aplicaciones brindan una capa de aislamiento entre los microservicios, que se pueden escribir en idiomas separados, ya que una parte central del servidor de aplicaciones para ese idioma en particular se implementa en el contenedor de aplicaciones correspondiente.

Se puede desarrollar una función particular para usar como microservicio utilizando cualquiera de los paquetes de compilación disponibles. Para Javael framework Spring es útil y bastante poderoso con su framework de inyección de dependencia.

Para las aplicaciones basadas en web, se requiere un servidor web, y Tomcat es el servidor web predeterminado compatible con Cloud Foundry y con la plataforma Neo desde que SAP Cloud Platform (ahora SAP BTP) estuvo disponible. Una de sus muchas ventajas es que Tomcat requiere poca memoria para ejecutarse y también es parte del paquete de compilación SAP Java.

Por lo tanto, para diseñar una aplicación y sus microservicios, necesita Estudio de aplicaciones empresariales de SAP (o SAP Web IDE), y necesita acceso a los servicios alrededor de los cuales desea crear su aplicación. Su aplicación se creará como un .mta archivo, que es un archivo de aplicación multidestino (MTA) que puede incluir una interfaz de usuario (UI), lógica empresarial y uno o más flujos de trabajo o un servicio de Internet de las cosas (IoT). Dependiendo de qué aplicación sea la característica central de su aplicación, puede usar las pestañas de desarrollo correspondientes en los espacios de SAP Business Application Studio.

Como se muestra en la figura a continuación, los diferentes componentes trabajan juntos para implementar aplicaciones, incluidos sus microservicios, en Cloud Foundry. Estos detalles también serán bastante transparentes para sus desarrolladores.

Exploremos cómo los diferentes componentes funcionan juntos.

Cuenta de usuario y autenticación (UAA) es un servicio para la autenticación regular y para la autenticación federada, que es útil para autenticar el acceso de usuarios técnicos o de plataforma a una instancia de SAP Business Technology Platform. UAA es proporcionado por un servidor OAuth2 y servidores de inicio de sesión que trabajan juntos.

Sin embargo, los servicios extendidos para cuenta de usuario y autenticación (XSUAA) llevan a cabo la autenticación desde una perspectiva comercial, verificando si un usuario tiene la autorización para acceder a una aplicación específica y realizar una tarea específica. El enrutador de aplicaciones de plataforma (que no es lo mismo que AppRouter) enruta el tráfico entrante al componente adecuado, ya sea un componente de Cloud Controller o una aplicación alojada que se ejecuta en una celda Diego.

El enrutador consulta el sistema de tablón de anuncios Diego (BBS) para determinar en qué celdas y contenedores se ejecuta actualmente cada aplicación. Esta consulta se realiza periódicamente y esta información ayuda al enrutador de la aplicación de la plataforma a recalcular nuevas tablas de enrutamiento.

La solicitud pasa por Cloud Controller y los paquetes de compilación (incluidos algunos paquetes de compilación de aplicaciones implementadas en el código de la aplicación) y los droplets se conservan en el almacén de objetos binarios grandes (blob), que almacena archivos binarios grandes.

Diego es el sistema de administración de contenedores y el tiempo de ejecución de Cloud Foundry, que consta de un administrador interno, que es un sistema de tablero de anuncios. Este administrador verifica qué aplicaciones aún se están ejecutando.

Una aplicación puede proporcionar un punto final de estado personalizado al que llamar para verificar esta información, pero esta verificación es opcional. Si una aplicación no está en buen estado, Diego la detendrá, la eliminará del contenedor y, a continuación, volverá a crear y reiniciará la aplicación con la información que se encuentra en el almacén de blobs. Si una aplicación está en buen estado, se asigna una ruta a la instancia de la aplicación.

Diego básicamente distingue entre tareas (como migraciones de esquemas de bases de datos) y procesos de ejecución prolongada (LRP) y, según esta distinción, decide en qué contenedor de celdas se debe implementar la aplicación. En general, una aplicación se implementa en un contenedor individual. Este aislamiento lo ayuda a escalar horizontalmente porque una aplicación, cuando se ejecuta de forma aislada, puede tener otras instancias ejecutándose junto a ella.

Luego, el balanceador de carga puede distribuir la carga entre varias instancias de la aplicación. La figura anterior también muestra una aplicación vinculada a un servicio externo a través del concepto de servicios proporcionados por el usuario, o la aplicación puede vincularse a una instancia de servicio administrado.

El intermediario de servicios es responsable de proporcionar la instancia de servicio a una aplicación, que tiene el servicio aprovisionado y vinculado a ella. Este servicio puede ser cualquier servicio proporcionado dentro de la organización o la plataforma o a través de proveedores de software como servicio (SaaS) de terceros. El agente de servicios es responsable de crear un Estibador contenedor y para implementar la instancia de servicio en ese contenedor. Además, el intermediario de servicios es responsable de vincular esta instancia de servicio administrado, como MongoDB, a todas las instancias de la aplicación. Por lo tanto, el agente de servicios es básicamente un microservicio que implementa solo algunos puntos finales que luego ejecuta Cloud Foundry. El agregador de registros transmite el registro de la aplicación para los operadores, mientras que el recopilador de métricas recopila métricas y estadísticas de los componentes, lo que ayuda a los usuarios a monitorear una implementación de Cloud Foundry. Todos los componentes deben proporcionar un punto final que ofrezca este tipo de información.

Desde el punto de vista de aprovechar SAP BTP, el tiempo de ejecución de Kyma, para consumir o crear microservicios, la arquitectura es bastante transparente para los desarrolladores. En este caso, Kyma se ejecuta en un clúster de Kubernetes y está disponible como un servicio administrado además de SAP BTP. Puede crear un microservicio en cualquier idioma en Kyma.

SAP BTP, Kyma runtime, admite una arquitectura basada en microservicios, manejo o consumo de eventos, autenticación, registro, seguimiento (que a su vez ayuda a monitorear y alertar en caso de fallas o problemas), consumo de servicios proporcionados por hiperescaladores y también API servicios de administración. Todas estas características están habilitadas a través de la opción de servicio administrado en SAP BTP.

Consideraciones de diseño de microservicios

Si bien los microservicios brindan muchas ventajas en términos de reutilización, escalabilidad independiente y más, algunos costos están asociados con estos beneficios. Se incurre en estos costos al interactuar entre sí (sobrecarga de comunicación) o al tener una persistencia separada que requiere sincronización, lo que aumentará la latencia general. Por lo tanto, debe considerar algunos puntos al diseñar una aplicación y los microservicios que se utilizarán dentro de ella, como los siguientes.

Diseño basado en dominios

Puede aplicar el diseño basado en dominios, un concepto inventado por Eric Evans, mediante el uso de un contexto comercial particular limitado a un modelo para ese dominio. Un ejemplo de dominio podría ser seguros, finanzas o fabricación. En otras palabras, en un dominio particular, un modelo de datos no puede admitir todos los subdominios de ese dominio, especialmente si el dominio es bastante grande. Un modelo de datos puede tener perspectivas basadas en usos particulares, y si todas estas perspectivas se fusionan, puede terminar con un modelo enorme y desordenado que puede no funcionar en absoluto. Por lo tanto, debe tener dominios y subdominios que se modelen de forma independiente. Como se muestra en la figura a continuación, se pueden considerar tres tipos de dominios: El dominio central es el área principal de innovación y propiedad intelectual, y este dominio recibirá el impacto comercial y responderá a la pregunta de por qué se está construyendo el sistema. Luego, se requiere un dominio genérico para ejecutar cualquier aplicación y no es diferenciador para su negocio, como la administración de usuarios o la seguridad; simplemente debe comprar este dominio. Finalmente, los dominios de soporte actúan como el código de unión entre partes específicas de su sistema, pero en realidad no sirven como núcleo.

granularidad

Una consideración importante es la granularidad. No todas las funciones deben dividirse en microservicios de un minuto. Por lo tanto, una aplicación monolítica debe dividirse en una cantidad limitada de microservicios, pero no aleatoriamente en cientos de microservicios.

Escalabilidad

Si una función en particular debe hacerse más escalable o resistente, entonces tiene sentido crear la función como un microservicio separado. Si desea escalar horizontalmente, diseñe la función para tener más instancias de aplicaciones para asumir la carga.

Diseño de microservicio API-First

Dependiendo de los requisitos de su negocio, primero se puede diseñar una API y luego se pueden construir los otros componentes del microservicio, por ejemplo, la interfaz de usuario para una aplicación móvil o una aplicación web. Si la API está bien diseñada, será fácil reutilizarla y, por lo tanto, se pueden crear muchas aplicaciones con esta API. A veces, si una API pública está disponible y es adecuada para una necesidad comercial particular, esta API puede servir como punto de partida para diseñar un microservicio.

Tipo de llamadas de servicio

Si todas las llamadas de servicio dentro de una aplicación usan API REST y/o una decisión de diseño genera muchas llamadas entre servicios, puede surgir un alto grado de latencia en el tiempo de respuesta, especialmente si todas las llamadas de servicio son sincrónicas. Además, el desacoplamiento de servicios es un parámetro de diseño esencial. Debe evitar transacciones entre microservicios porque las llamadas entre microservicios pueden ser miles de veces más lentas que las llamadas dentro de un microservicio. Para los mensajes, el rendimiento no debería ser un problema, pero con las llamadas REST sincrónicas, es posible que observe problemas de rendimiento. Recuerde que los tiempos de respuesta a menudo se acumulan.

Enfoque de modelado de afuera hacia adentro

Este enfoque significa que el enfoque del diseño está en los eventos comerciales, que se modelan con la ayuda de expertos en el dominio. La relación entre eventos, entre entradas/requisitos previos y resultados, también se traza. Este modelo puede luego traducirse en una solución técnica.

Resistencia

La resiliencia integrada en un microservicio significa que la aplicación puede tener varias funciones como unidades implementadas de forma independiente. Si alguna unidad no se implementa o tiene un error, debería poder aislar la unidad sin cerrar toda la aplicación.

Aplicación de doce factores

La aplicación de doce factores es una metodología moderna para ayudar a diseñar soluciones SaaS. Esta metodología también se puede aplicar al dominio SAP.

Los principios de la aplicación de doce factores establecen lo siguiente:

1. Base de código: una base de código rastreada en el control de revisión, muchas implementaciones.
2. Dependencia: declara y aísla explícitamente las dependencias.
3. Config: Almacenar la configuración en el entorno.
4. Servicios de respaldo: Trate los servicios de respaldo como recursos adjuntos.
5. Compilación, publicación, ejecución: separe estrictamente las etapas de compilación y ejecución.
6. Procesos: ejecuta la aplicación como uno o más procesos sin estado.
7. Vinculación de puertos: Exporte servicios a través de la vinculación de puertos, que es manejada por la plataforma SAP y no necesita ninguna acción adicional.
8. Simultaneidad: Escale horizontalmente a través del modelo de proceso.
9. Desechabilidad: maximice la robustez con inicios rápidos y apagados elegantes.
10. Paridad de desarrollo/producción: mantenga el desarrollo, la puesta en escena y la producción lo más similares posible.
11. Registros: mantenga registros como flujos de eventos.
12. Proceso de administración: ejecute tareas de administración/gestión como procesos únicos.

Más información sobre los principios de diseño de aplicaciones de doce factores está disponible aquí.

Nota del editor: esta publicación ha sido adaptada de una sección del libro. Desarrollo de aplicaciones con SAP Business Technology Platform por Gairik Acharya, Govind Bajaj, Avijit Dhar, Anup Ghosh y Asidhara Lahiri.