Los días de programas gigantescos y monolíticos son arcaicos; francamente, la complejidad del enfoque de un solo programa es abrumadora. Un enfoque modular de la arquitectura es, por lo tanto, el claro ganador y una elección lógica. Los sistemas modulares admiten una estructura de descomposición del trabajo (WBS) de la funcionalidad de un sistema más grande en partes más pequeñas, y los buenos diseños de arquitectura usan microservicios dentro de su arquitectura para acomodar los principios de diseño basados ​​en servicios para acomodar la funcionalidad requerida.

La modularización se basa en el principio de dividir el programa en módulos o unidades pequeños y discretos que son independientes, no secuenciales, generalmente de corta duración y limitados en alcance y función. Los microservicios describen tanto un enfoque de la arquitectura de software que crea aplicaciones grandes y complejas a partir de múltiples componentes pequeños como el término para los propios componentes pequeños. En este enfoque, una aplicación se construye con una o más funciones que se pueden llamar para proporcionar una Servicio al programa de llamada.

La arquitectura de microservicio es comparable y es una variante del estilo de aplicación de programa de arquitectura orientada a servicios (SOA), que organiza una aplicación en servicios acoplados que cumplen una o más funciones del programa. En una arquitectura de microservicio, los servicios son muy detallados, en lugar de monolíticos, y los protocolos a los que se comunica el servicio son ligeros.

El objetivo de tal estructura es dividir el todo en funciones más pequeñas y manejables. El acoplamiento flexible reduce las dependencias, las restricciones y la complejidad, cuyo objetivo es admitir la modularización y no forzar los cambios del sistema en otros componentes del sistema. Este enfoque de modularidad, junto con el acoplamiento flexible, fomenta una arquitectura en la que una versión anterior de un microservicio se puede desconectar de los sistemas y una nueva versión puede reemplazar la versión anterior con una interrupción mínima o nula. Esto tiene enormes consecuencias para los sistemas en crecimiento que crecen rápido y son grandes. Los requisitos de comunicaciones y las dependencias de las aplicaciones se reducen significativamente, lo que promueve la independencia del servicio. Tener múltiples interfaces para el mismo servicio, o múltiples versiones (redundantes) del mismo servicio minimiza o incluso elimina las interrupciones de los consumidores existentes de la interfaz de la aplicación.

Un enfoque de microservicios para la arquitectura

En los primeros días de la creación de interfaces de programación de aplicaciones (API), los sistemas completos debían reconstruirse o desconectarse para implementar nuevas versiones. Esto está anticuado, es ineficiente y crea un riesgo significativo a medida que se introducen cambios en el sistema. Si la nueva API no es compatible con todas las integraciones, entonces puede haber consecuencias para otros componentes del sistema, por lo tanto, «romper» otros sistemas y hacer que la aplicación falle. Esta es una causa importante en las actualizaciones y mejoras del sistema. Causan la introducción de un riesgo significativo si la API falla. En un entorno de microservicio con múltiples interfaces redundantes, este problema se reduce significativamente.

Considere el siguiente ejemplo.

En el enfoque tradicional, existe un único punto de integración en las interfaces de programación de aplicaciones. Hay una estructura monolítica que sigue creciendo a medida que crece la aplicación. Solo hay una forma de llamar a la función a través de una única API. A medida que el sistema crece, también lo hace la complejidad y el riesgo. El enfoque y este modelo no son sostenibles.

En un enfoque de microservicios, hay múltiples servicios disponibles. Las llamadas a cada uno de los servicios se pueden desacoplar y cambiar para adaptarse a la nueva funcionalidad sin interrumpir la funcionalidad anterior. Esto permite que el sistema en general crezca y aumente de manera segura los cambios requeridos, ayuda a administrar la complejidad a medida que la complejidad crece a través de los requisitos y minimiza el riesgo de una manera aceptable. En un enfoque de microservicios, los servicios y las integraciones se modifican para adaptarse a la nueva funcionalidad. En el enfoque tradicional, se debe considerar todo, y los puntos de contacto para el código de la aplicación se convierten en casi todo en el sistema.

Una consecuencia de las arquitecturas tradicionales

No hace falta decir que el valor de tener una arquitectura mediante la cual se controle la personalización a través de un desarrollo flexible es inconmensurable. Las arquitecturas tradicionales tienden a crecer hasta alcanzar proporciones monolíticas y rápidamente se salen de control. Las consecuencias son enormes.

La más obvia es que no es sostenible. A medida que crece la aplicación, también lo hace la complejidad. Esto es normal y no necesariamente una mala consecuencia, pero gestionar el cambio rápidamente se convierte en una pesadilla. A menudo, esto depende de la experiencia personal del administrador del sistema para diseñar cambios que sean manejables, ejecutables y que se puedan acomodar. Sin embargo, la mayoría de las veces, el sistema se sale de control y llega a un punto en el que las actualizaciones, actualizaciones y parches ya no son factibles simplemente debido a la complejidad y el riesgo de hacerlo, lo que puede «romper» el sistema sin posibilidad de reparación.

Gestionar el ritmo de la innovación

La innovación viene mediante la introducción de cambios en el sistema para apoyar la innovación. Para los clientes de SAP, la adopción de funciones innovadoras es importante para su éxito como empresa. Nadie diría que quedarse quieto, sin desarrollo y sin adaptarse al cambio del mercado, acelera su capacidad de cambiar y crecer con él. Durante la historia de SAP que se remonta a 1972, se dieron cuenta de que estaban escribiendo un gran código y brindando nuevas funcionalidades, pero a su base de clientes le resultaba difícil mantenerse al día con las actualizaciones debido a las arquitecturas tradicionales.

Luego, SAP ingresó a la nube y comenzó a implementar servicios basados ​​en la nube. Al pasar a la nube, las empresas podrían acelerar el ritmo de innovación y adopción, pero solo a expensas de la personalización. La personalización de sistemas y aplicaciones se volvió difícil de implementar por temor a volver a la complejidad de las arquitecturas tradicionales.

SAP quiere innovar con sus clientes. Los clientes deben adaptarse a posiciones de mercado en constante cambio y cambiar sus sistemas para no solo mantener el negocio, sino también crecer y mejorar.

Los beneficios de una arquitectura modular

Hay numerosos beneficios para tal arquitectura. Estos incluyen compatibilidad, independencia, escalabilidad, solución de problemas y entrega continua ágil y eficiente.

Compatibilidad

Como se consideran diferentes puntos de interacción, estos deben en algún momento tener contacto con la solución de la aplicación. Estos deben ser simples, abiertos, al admitir múltiples llamadas a funciones, y flexibles. Es por eso que la mayoría de los desarrolladores de microservicios usan servicios de API RESTful. Los protocolos uniformes y los métodos simples como GET o POST permiten que los microservicios se comuniquen e intercambien información fácilmente.

Independencia

Lo primero y más importante es la independencia. Con un enfoque de microservicios, los equipos de desarrollo operan con más autonomía. Cada grupo de proyecto tiene la libertad de coordinarse con otros equipos, pero también de operar de forma independiente.

El valor es importante. Los equipos pueden centrarse en la solución que mejor se adapte a sus propias tareas del proyecto y no en la que limita a otros equipos. Esto podría implicar cambios en el código, cambios en la base de datos y cambios en la API. En una arquitectura ágil de microservicios, cada equipo puede trabajar en conjunto o de forma independiente, lo que tenga más sentido.

Escalabilidad

Las arquitecturas de microservicios brindan a los desarrolladores de aplicaciones la capacidad de escalar hasta la minucia de los detalles. Cuando se consideran las mejoras, solo se deben considerar el proyecto y las funciones de la función de servicio, no la totalidad de la aplicación. Esto hace que el proyecto sea más ligero y, por lo tanto, más ágil, ahorrando, por supuesto, tiempo y costes. También apoya la gestión del cambio al controlar el riesgo de manera adecuada. Se puede agregar funcionalidad adicional creando nuevos servicios y código de aplicación para admitir el servicio. Los cambios en la base de datos pueden tomar un nuevo contexto, o se pueden agregar nuevas columnas o filas para adaptarse a la nueva funcionalidad sin la necesidad de dar marcha atrás y cambiar todo el sistema. De esta manera, un sistema puede crecer y escalar sin “romper” algo incidentalmente.

Aquí no hay absolutos y, por supuesto, se deben considerar los cambios en el sistema, así como las limitaciones, restricciones y dependencias de múltiples proyectos. Sin embargo, los microservicios prometen la esperanza de una mayor flexibilidad y crecimiento con un riesgo sustancialmente reducido.

Solución de problemas

Otra ventaja de la independencia del sistema es que si el servicio falla, la aplicación completa no fallará; solo el servicio y sus componentes asociados pueden verse afectados. Esto también hace que la resolución de problemas sea mucho más fácil. En lugar de investigar un código exorbitante, el problema estará contenido dentro de un subconjunto relativamente pequeño de funciones.

Entrega continua ágil ágil

La entrega continua es un beneficio final ya que el software se actualiza constantemente. La arquitectura de microservicio brinda tanto a SAP como a sus clientes la opción de no tener que actualizar grandes porciones, y las actualizaciones más pequeñas se pueden acomodar fácilmente en una metodología ágil y esbelta. Es mucho más fácil administrar un servicio que tiene una función, ya que consume muchos menos recursos. Compare eso con las arquitecturas tradicionales que pueden ser muy costosas y, peor aún, proyectos de alto riesgo.

Solo por esta razón, SAP ha visto que sus clientes a menudo no parchean, actualizan o mejoran sus sistemas. En algún momento, los clientes llegan a un punto de saturación de riesgo en el que el sistema se vuelve demasiado grande y arriesgado para modificarlo, independientemente de la necesidad de implementar parches y actualizaciones.

Por último, la capacidad de respaldar múltiples proyectos y múltiples equipos que actúan de forma independiente mejora la eficiencia de la finalización del proyecto, ya que se pueden implementar más proyectos de menor alcance, lo que reduce la complejidad y el riesgo del cambio. Desde la perspectiva de un desarrollador, las nuevas funciones o las correcciones de errores son menos probables dado el alcance más pequeño del servicio. Los cambios son rápidos y, por lo tanto, es más probable que mantengan la estabilidad general del sistema a largo plazo.

Recomendaciones arquitectónicas

La arquitectura de aplicaciones es simplemente la organización de un sistema, donde un sistema incluye la suma total de todas las aplicaciones. Puede haber uno o más sistemas, o la totalidad de una sección de soluciones de aplicación puede contener múltiples sistemas, trabajando juntos para formar un gran sistema. El sistema incluye todos los componentes y cómo interactúan entre sí, y el entorno en el que operan.

Un enfoque arquitectónico proporciona una estrategia en la que se basan una misión específica y un diseño general. Forma la gobernanza del diseño y sus principios operativos para obtener los beneficios de dicho enfoque. La estructura del diseño impacta numerosas decisiones materiales, por lo que las consideraciones son apropiadas para respaldar la misión de la empresa y para obtener los mejores resultados posibles.

Debe quedar claro en este punto el valor de la modularización de componentes y microservicios, como un enfoque de diseño arquitectónico. Los principios básicos de estos dos enfoques brindan numerosos beneficios y son la base de las recomendaciones de más alto nivel para un enfoque de diseño.

Mark Ciminello es vicepresidente y arquitecto jefe de SAP Global Security (SGS), con experiencia en la nube, seguridad de la información y privacidad de datos. Posee numerosas certificaciones, incluidas CISSP (seguridad), CCSP (seguridad en la nube) y PMP (gestión de proyectos), tiene un MBA en administración, una licenciatura en estudios generales con énfasis en contabilidad y tiene más de 30 años de experiencia empresarial. Recientemente, ha asistido a cursos avanzados en la Universidad de Harvard.

Descargo de responsabilidad

© 2023 SAP SE o una empresa filial de SAP. Todos los derechos reservados. Consulte el Aviso legal en www.sap.com/legal-notice para conocer los términos de uso, las exenciones de responsabilidad, las divulgaciones o las restricciones relacionadas con los Materiales de SAP para el público en general.