Hoy en día, los microservicios se consideran la base de las arquitecturas de aplicaciones modernas. En lugar de un software monolítico y torpe, toda la funcionalidad se distribuye en subsistemas manejables. Los servicios resultantes suelen estar disponibles a través de Internet y API RESTful.

El camino del desarrollo de software se encuentra una vez más en una encrucijada. Los días de las aplicaciones de software complejas y en ocasiones engorrosas han terminado. En cambio, debes lidiar con un alto nivel de diversidad y flexibilidad en todas partes.

Amplia variedad de sistemas operativos

Además de una amplia variedad de tipos de dispositivos, desde computadoras de escritorio hasta computadoras portátiles y tabletas y teléfonos inteligentes, también se utiliza una amplia variedad de sistemas operativos: Windows, macOS, Linux, iOS y Android. Estos desarrollos tienen muchas consecuencias para el desarrollo de software.

En particular, la arquitectura utilizó cambios. El camino se está alejando del sistema de aplicaciones monolítico hacia una arquitectura esbelta y flexible basada en microservicios. También es importante transferir las aplicaciones existentes a través de la migración para cumplir con estos requisitos.

Acceso permanente a la red

Se puede suponer que una aplicación tiene acceso casi constante a datos y servicios a través de Internet. Las conexiones rápidas a Internet para dispositivos móviles, en particular, permiten el acceso a servicios remotos y grandes cantidades de datos.

La funcionalidad se divide en muchas unidades más pequeñas que se acoplan libremente entre sí. Una vez programados, los servicios se pueden reutilizar fácilmente en varias aplicaciones.

El camino hacia la arquitectura de software moderna

Las aplicaciones de software integrales que no están explícitamente separadas en diferentes subsistemas se denominan sistemas de TI monolíticos. Las funciones de un sistema de aplicación de este tipo (gestión de datos, lógica de aplicación, interfaz de usuario) están estrechamente relacionadas y fusionadas en un sistema global. Un sistema de TI monolítico tiene las siguientes desventajas:

• Alta complejidad: los submódulos muestran una variedad de interdependencias.

• Mala capacidad de mantenimiento: no es posible reemplazar partes individuales de la aplicación con tecnologías más nuevas sin que esto tenga un impacto directo en otros componentes del software.

• Reutilización restringida: la reutilización de componentes de software individuales es casi imposible.

• Baja flexibilidad: la extensibilidad y escalabilidad están severamente restringidas.

Desde la perspectiva actual, los sistemas de TI monolíticos están desactualizados. A menudo son el resultado de un constante desarrollo y adaptación. Sin embargo, muchos de estos sistemas todavía están en uso. Se conocen como sistemas heredados. Su modernización y adaptación (migración) es difícil. Es mejor dividir la aplicación general en capas, generalmente para la gestión, el procesamiento y la presentación de datos.

Arquitectura orientada a Servicios

En el entorno industrial, las arquitecturas orientadas a servicios (SOA) se han establecido como una forma de arquitectura de sistemas distribuidos. El principio SOA consiste en el hecho de que los usuarios (consumidores de servicios) pueden implementar aplicaciones complejas casi combinando servicios. La idea subyacente es agrupar funciones de aplicaciones relacionadas en una unidad y ofrecerlas como servicios (servicios SOA).

De esta manera, los servicios existentes se pueden reutilizar y se pueden ahorrar costos de desarrollo. Todos los servicios disponibles se dan a conocer a través de un registro. El vínculo real entre el consumidor de servicios de elementos de software y el proveedor de servicios tiene lugar en el momento de la ejecución mediante asignación dinámica. SOA tiene como objetivo hacer que la TI corporativa sea más flexible.

Con los microservicios, los módulos se pueden poner en producción de forma independiente entre sí. Los servicios se pueden utilizar de forma flexible a través de una amplia variedad de sistemas de aplicación, que no se limitan a tu propia empresa. La integración generalmente se realiza a través de «RESTful http«, es decir, a través de una interfaz uniforme.

Del monolito al microservicio, basado en una idea de Capgemini

Por ejemplo, si una aplicación usa el servicio, solo necesitas conocer las convenciones de llamada de la API. La implementación técnica del servicio no es de interés. Si la interfaz no cambia, los ajustes al servicio no tienen ningún efecto en el software que lo utiliza. La figura 1 anterior muestra una comparación de los enfoques arquitectónicos.

Oportunidades y desafíos de los microservicios

Los microservicios ofrecen una serie de oportunidades:

• Cada módulo se puede diseñar, implementar, probar y desplegar individualmente.

• Los módulos son independientes entre sí en términos de tecnología.

• Los cambios en un módulo no afectan a otros módulos mientras la interfaz permanezca sin cambios.

• Los módulos individuales se pueden utilizar muy bien en diferentes contextos de aplicación.

• Los módulos pueden ser funcionalmente independientes entre sí.

• Es posible una buena asignación organizativa de responsabilidades.

Deben superarse los siguientes desafíos:

• Asignación de los servicios a las capas, como datos, lógica y nivel de interfaz de usuario.

• Introducción de una infraestructura de microservicios, por ejemplo, para automatizar la implementación.

• Limitación y selección de las tecnologías utilizadas a un nivel aceptable.

El último punto en particular puede ser un verdadero desafío. Al construir un panorama de software complejo, se requiere una amplia variedad de tecnologías por parte del cliente. El cambio a una arquitectura de microservicio muy rápidamente requiere dominar otras tecnologías.

Estos incluyen marcos de microservicio, Docker, Kubernetes, JavaScript del lado del servidor en marcos adicionales como Node.js y mucho más. Por lo tanto, se requieren enfoques que aseguren un ciclo de desarrollo continuo desde el cliente hasta el servicio RESTful en el lado del servidor, para poder diseñar todo el proceso de desarrollo de manera eficiente.

Conclusión

La arquitectura de los sistemas de aplicaciones se vuelve más flexible a través del enfoque de microservicios. Los servicios individuales están desacoplados entre sí. Esto hace posible controlar la creciente complejidad y tamaño de los sistemas de software. Para reducir el esfuerzo, los costos y el tiempo de desarrollo, no debería haber interrupciones importantes del sistema entre el desarrollo del cliente y el servidor, si es posible.

Idealmente, se pueden utilizar las mismas herramientas y lenguajes de programación. La ventaja es obvia. El conocimiento del desarrollo se puede utilizar directamente y los costes de conversión siguen siendo limitados.