Arquitectura técnica para aplicaciones nativas en la nube: parte 1
By s4pcademy
En el panorama tecnológico de rápida evolución actual, mantenerse actualizado con los últimos avances es más importante que nunca. Esto es especialmente cierto para los arquitectos de SAP, que se enfrentan al desafío de integrar sistemas SAP complejos con tecnologías de nube modernas que se ejecutan en plataformas de tecnología Hyperscalers.
Por otro lado, hay una nueva generación de arquitectos de la nube que son expertos en tecnologías de vanguardia, pero pueden carecer de experiencia con ERP grandes y complejos, lo que les dificulta comprender las complejidades de las aplicaciones empresariales.
Mi objetivo para estas publicaciones de blog es explorar los patrones empleados en la construcción de aplicaciones a gran escala que sean escalables, confiables y de alto rendimiento. Proporcionaré una explicación detallada paso a paso de cómo se pueden utilizar estos patrones para escalar una aplicación, lo que le permite admitir a millones de usuarios. Además, destacaré cómo se utilizan patrones similares en SAP para desarrollar nuestras aplicaciones SAP.
Parte 1: tendencias de la arquitectura de software (esta publicación de blog)
Parte 2: cómo crear una aplicación escalable: de 1 a 10 000 usuarios.
Parte 3 – Cómo construir una aplicación escalable – De 10K a 100.000K usuarios
Parte 4: cómo crear una aplicación escalable: hasta un millón de usuarios
Pero antes de comenzar a hablar sobre cómo crear aplicaciones modernas en la nube, echemos un vistazo a cómo ha evolucionado la arquitectura de software a lo largo de los años…
Tendencias en arquitectura de software
La tendencia en tecnología ha evolucionado desde grandes aplicaciones estrechamente acopladas hasta servicios más pequeños e independientes llamados arquitectura de microservicios. Actualmente, la atención se centra en arquitecturas sin servidor y basadas en eventos.
Patrones de arquitectura de software
Simultáneamente, ha habido una evolución en la complejidad y requisitos de las aplicaciones. Las aplicaciones actuales están basadas en la nube, lo que requiere el procesamiento de enormes cantidades de datos que generalmente superan las capacidades de las bases de datos relacionales tradicionales y exigen un acceso global e instantáneo.
ERP frente a aplicaciones nativas en la nube
Tradicionalmente, las aplicaciones de las grandes empresas han tenido un origen monolítico. Dichos monolitos tienen una escalabilidad limitada y pueden convertirse en un desafío para desarrollar a medida que se expande la aplicación. Sin embargo, hay algunas excepciones notables, incluidos los mainframes utilizados en la banca, los seguros y los mercados bursátiles desde la década de 1960 y el kernel de Linux, que se ejecuta en una amplia gama de dispositivos. Estos ejemplos demuestran que las aplicaciones monolíticas, a pesar de sus limitaciones, siguen siendo relevantes.
Aplicaciones monolíticas
Vale la pena mencionar que Monolítico, en este contexto, significa compuesto todo en una sola pieza, diseñado para ser autónomo. Los componentes del programa están interconectados y son interdependientes en lugar de acoplarse libremente. Podemos ver cómo el software SAP ERP, a pesar de ser monolítico, ha evolucionado a lo largo de los años:
Diferentes tipos de monolitos.
La arquitectura orientada a servicios (SOA) se hizo popular entre principios y mediados de la década de 2000 como respuesta a las limitaciones de las arquitecturas monolíticas. Este fue un momento en que las organizaciones comenzaban a construir sistemas de software más complejos y distribuidos, y había una necesidad creciente de mayor flexibilidad, escalabilidad y reutilización en el diseño de aplicaciones.
La idea principal detrás de SOA era separar la aplicación en componentes o servicios más pequeños e independientes que se pueden desarrollar, implementar y mantener de forma independiente. Este enfoque permite una mayor flexibilidad, escalabilidad y tolerancia a fallas, lo que facilita la adaptación a las cambiantes necesidades comerciales y los avances tecnológicos.
El auge de los servicios web y la creciente adopción de XML como estándar para el intercambio de datos también contribuyeron a la popularidad de SOA durante este período. Si bien la popularidad de SOA ha disminuido desde entonces, muchos de sus principios y conceptos continúan influyendo en la arquitectura de software y las prácticas de desarrollo modernas.
Arquitectura Orientada a Servicios (SOA)
SAP no fue una excepción y, a mediados de la década de 2000, introdujimos el concepto de SAP Netweaver como una plataforma de procesos comerciales, junto con el repositorio de servicios empresariales y las aplicaciones componibles. El objetivo era mantener un núcleo ERP estable agregando innovación a través de Enhancement Packages (Enterprise SOA by Evolution) y, al mismo tiempo, también permitir el desarrollo de extensiones en paralelo a través de aplicaciones componibles (Enterprise SOA by Design).
Arquitectura Orientada a Servicios (SOA) en SAP
SOA fue un paso en la dirección correcta, recuerdo el «bombo» en torno a SOA y lo prometedor que era, pero como muchas tecnologías, SOA también era un término usado en exceso que significaba diferentes cosas para diferentes personas. Pero como denominador común, SOA significaba que estructuraba su aplicación descomponiéndola en múltiples servicios (más comúnmente como servicios HTTP) que se pueden clasificar en diferentes tipos, como subsistemas o niveles.
La arquitectura de microservicios y SOA están relacionadas, pero existen diferencias clave entre las dos.
Si bien SOA implica la descomposición de aplicaciones en múltiples servicios, a menudo se basa en grandes intermediarios centrales, orquestadores centrales e implementaciones de Enterprise Service Bus (ESB). Por el contrario, la arquitectura de microservicios enfatiza el uso de servicios pequeños e independientes que se pueden implementar y escalar de forma independiente. Como dice un dicho popular: “La arquitectura de microservicios es SOA bien hecha”.
microservicios
Una de las ideas principales detrás de la arquitectura de microservicios es que cada microservicio posee sus propios datos y su propia lógica de dominio. Este es también uno de los principales defectos de diseño de las aplicaciones empresariales, ya que los arquitectos deben decidir entre solicitar datos de otros microservicios o duplicar los datos, lo que introduce la idea de «coherencia eventual», que normalmente no es una buena idea en aplicaciones empresariales grandes.
SAP S/4HANA: cómo SAP está despegando el monolito
El siguiente paso en la evolución de la arquitectura del software ha sido la idea de la computación sin servidor.
Los microservicios y la computación sin servidor tienen diferentes propósitos y no son mutuamente excluyentes.
Si bien los microservicios brindan beneficios en términos de escalabilidad y flexibilidad, aún requieren que los desarrolladores administren y escalen la infraestructura.
La computación sin servidor elimina por completo la necesidad de administrar la infraestructura, lo que permite a los desarrolladores concentrarse únicamente en escribir código. Con funciones sin servidor, los proveedores de la nube administran la infraestructura y asignan automáticamente los recursos informáticos según sea necesario en respuesta a eventos o solicitudes. Los desarrolladores escriben código en forma de funciones, que se ejecutan en contenedores sin estado y se cobran solo por el tiempo que se ejecutan.
Computación sin servidor
¿Por qué Serverless si ya teníamos microservicios? La característica clave de las arquitecturas nativas de la nube es su capacidad para escalar dinámicamente y admitir una gran cantidad de usuarios, eventos y solicitudes en aplicaciones y equipos distribuidos. La informática sin servidor puede ayudar a gestionar estos desafíos sin agobiar a los desarrolladores con preocupaciones sobre la infraestructura o la aplicación completa.
Este enfoque permite múltiples y diversos casos de uso como:
| Cree una API web | Implemente un punto final para sus aplicaciones web utilizando el activador HTTP |
| Procesar cargas de archivos | Ejecute el código cuando se cargue o cambie un archivo en el almacenamiento de blobs |
| Cree un flujo de trabajo sin servidor | Cree un flujo de trabajo basado en eventos a partir de una serie de funciones utilizando funciones duraderas |
| Responder al cambio de la base de datos | Ejecute una lógica personalizada cuando se cree o actualice un documento en la base de datos o el almacenamiento |
| Ejecutar tareas programadas | Ejecutar código en intervalos de tiempo predefinidos |
| Sistemas confiables de colas de mensajes | Procesar colas de mensajes mediante Queue Storage, Service Bus o Event Hubs |
| Y muchos más… |
Funciones sin servidor
Las funciones sin servidor y las arquitecturas basadas en eventos son conceptos estrechamente relacionados que a menudo se usan juntos para crear aplicaciones modernas.
Como se mencionó anteriormente, las funciones sin servidor son un tipo de servicio de computación en la nube donde el proveedor de la nube administra la infraestructura y escala automáticamente los recursos según sea necesario.
Las arquitecturas impulsadas por eventos, por otro lado, son un patrón de diseño de software donde el flujo de datos y el procesamiento están determinados por eventos, en lugar de por una estructura de control centralizada. En una arquitectura basada en eventos, diferentes componentes del sistema se comunican entre sí publicando y suscribiéndose a eventos. Cuando ocurre un evento, el sistema activa la respuesta adecuada, que podría incluir la ejecución de una función sin servidor.
Por lo tanto, las funciones sin servidor se utilizan a menudo como un componente clave de las arquitecturas basadas en eventos. Por ejemplo, una función sin servidor podría desencadenarse por un evento como la adición de un nuevo registro a una base de datos o la recepción de un mensaje de una cola. Esto permite que la aplicación responda rápida y eficientemente a los eventos, sin necesidad de administrar servidores o mantener una infraestructura compleja.
Servicios web nativos en la nube: sin servidor y basados en eventos
De manera similar, SAP también está adoptando esta tendencia de arquitectura y permite que el cliente desarrolle una extensión en paralelo en SAP Business Technology Platform que se puede desarrollar utilizando el tiempo de ejecución de SAP Kyma y los servicios SAP Event Mesh para implementar aplicaciones sin servicio + impulsadas por eventos:
Arquitectura Serveless y Event Driven en SAP
Reflexiones finales y próximos pasos
Brindamos una breve descripción general de la evolución de la arquitectura de software, desde aplicaciones monolíticas hasta microservicios y computación sin servidor. Además, hemos descrito cómo SAP también está en un viaje gradual para adaptar SAP S/4HANA y el software Intelligent Suite a estos patrones de arquitectura.
En nuestras próximas publicaciones de blog, profundizaremos en la aplicación práctica de estos patrones para construir sistemas a gran escala escalables, confiables y de alto rendimiento. Demostraremos cómo se pueden combinar varias tecnologías para crear una aplicación que pueda escalar desde un solo usuario hasta potencialmente millones de usuarios. Además, compararemos cómo SAP aprovecha estos mismos patrones para abordar los mismos problemas de escalabilidad.
¡Mantente sintonizado para más!
