El concepto de Microservicios está a la orden del día y muchas empresas miran o estudian esta alternativa para la implementación de su Software. Este artículo trata de analizar tres temas principales de esta tecnología para que los CIO de la empresas tengan más elementos a la hora de tomar decisiones:
Concepto de Microservicios
Escenarios para adopción de este diseño de Software
Características de la arquitectura y retos de implementación
Concepto de Microservicios
No existe una definición única, pero en general al hablar de microservicios nos enfocamos en una arquitectura en donde se implementa la funcionalidad en silos de programación específicos definidos por el dominio del negocio (DDD). Estos servicios en conjunto, unos con otros, sirven cierta funcionalidad que podríamos denominar el Software producto. Así, en un clásica aplicación de compras en línea podríamos decir que el Software producto está dividido en dominios como inventario de productos, carrito de compras, procesamiento de pagos, sistema de entregas, servicio al cliente, etc., cada uno de ellos se concibe como una micro aplicación que se despliega independientemente de las otras en su proceso y que en la mayoría de casos en general tiene su propio repositorio de datos.
Delante de ellos y por la dinámica de los negocios en la actualidad se construyen los “front-end” que van desde páginas web, aplicaciones móviles, etc., hasta aplicaciones de consolas como Xbox, los cuales interactúan con estas micro aplicaciones a través de API gateway. Muchas de estas aplicaciones se intercomunican entre sí para proveer su funcionalidad, de una forma auto-gestionada, natural en una práctica conocida como coreografía. (Esto a diferencia del concepto de orquestación que se define en SOA[1]).
Existen muchos comparaciones o símiles con una arquitectura SOA (incluso inicialmente Netflix llamaba a esta arquitectura como SOA finamente desglosado[3]), y de un lado y del otro las opiniones tienen puntos válidos acerca de las razones.
En esta perspectiva ponemos a consideración dos puntos:
SOA es una estrategia empresarial que busca alinear la tecnología con la visión estratégica del negocio a través de la orientación a servicios.
Los Microservicios están pensados para simplificar la complejidad de una aplicación empresarial buscando productividad, escalabilidad y reutilización en base al diseño de funcionalidades en silos de programación concebidos como servicios.
Escenarios para adopción de este diseño de Software
La arquitectura de Microservicios en la mayoría de casos puede no ser necesaria pues las aplicaciones con la arquitectura monolítica tradicional funcionan y se vuelven menos complejas de administrar, siendo esta dinámica la más común en las empresas que no tienen un portafolio grande de aplicaciones y/o requerimientos funcionales.
En las empresas de mayor volumen la realidad es diferente, el negocio ha requerido un portafolio grande de software que cubre requerimientos operacionales y comerciales. Aquí la propuesta del uso de esta arquitectura tiene que ver con dos aspectos:
Estrategia del negocio: En este contexto el negocio presenta una dinámica en la cual muchas funcionalidades son requeridas por otros sistemas propios o de terceros. Este podría ser el caso del sistema para emisión de boletos aéreos, el cual es requerido por diferentes canales como kioscos, la página web, los centros de servicio, los sistemas de las agencias de viajes, cajeros automáticos de bancos, etc. , aquí es importante poder cumplir con todos ellos y no perder la oportunidad. En un esquema monolítico donde existe un sistema principal, la disponibilidad de este producto estratégico depende de este sistema principal en donde existen otras funcionalidades no interesantes para el negocio como la administración de usuarios por ejemplo, y presenta riesgos asociados con su evolución, disponibilidad y escalabilidad como tal. Es razonable pensar en abstraer este producto del sistema principal, buscando responder al negocio y su dinámica de forma ágil con un enfoque apropiado buscando su innovación y escalabilidad, en consecuencia podemos pensarlo como un servicio.
Complejidad: En un sistema monolítico sumamente extenso, por toda la funcionalidad que provee, es complejo el mantenimiento porque conceptos como pruebas, validación, despliegue y el conocimiento en sí del negocio se entiende como un todo. Ponemos como ejemplo la adición del campo «referencia» en un formulario de datos de direcciones de los clientes, parte de un sistema de seguros; aquí la tarea se identificada como sencilla, pero dado a que el módulo de clientes es parte de una aplicación monolítica, el cambio tiene un impacto en todo el software, y como tal sus procesos de validación y puesta en producción son extensos, demorados y restringidos. En este escenario se evidencia que la administración debe dividirse para responder al negocio a la velocidad que lo requiere y evitar sobre esfuerzos en tareas simples. Si abstraemos este dominio del negocio y los demás es más probable que este requerimiento sea atendido con prontitud y evitar incluso costos asociados.
Características de la arquitectura y retos de implementación
La adopción de la arquitectura en Microservicios requiere además, del análisis de varios aspectos técnicos y organizacionales que debe prever la empresa para no verse inmersa en problemas de gestión y en consecuencia implementaciones no exitosas y llenas de problemas.
Ponemos a consideración las siguientes características:
La concepción de un servicio debe ser en función de un dominio específico y bien delimitado del negocio, generalmente organizados alrededor de una capacidad del negocio.
Los servicios deben ser independientes, disponibles en su propio proceso lo cual nos permite una escalabilidad vertical y no como en las aplicaciones monolíticas que es horizontal.
A un servicio se lo entiende como un producto, por tanto evoluciona como tal y cuenta con un equipo multidisciplinario de desarrollo, su objetivo siempre es mejorar la capacidad de negocio.
Un servicio tiene un punto de conexión inteligente que es capaz de reconocer el mensaje y el mecanismo de acceso con protocolos simples como HTTP básico.
La plataforma tecnológica de un servicio está pensada en la solución correcta y no en estándares corporativos, así podemos crear servicios con diferentes lenguajes de programación y con diferentes repositorios de datos como bases de datos relacionales. documentales o clave-valor.
Esta arquitectura al tener varios servicios requiere varios procesos de despliegue, por lo que es crítico tener un plan de automatización de los mismos evitando sobrecargas de esfuerzo y errores manuales, son muy útiles las tendencias de despliegue como Devops.
La transaccionalidad debe estar preparada para fallos, estamos en un escenario que básicamente es programación distribuida y este concepto requiere experiencia. La atomicidad de la transacción no existe debido al riesgo de falla por la latencia en redes o cortes de servicio, así mismo por otros temas como errores de ejecución
La sobre-arquitectura es una tendencia que puede afectar al diseño de servicios, la idea es crearlos simples pero con una visión evolutiva que crezca a la par del requerimiento de negocio. Aunque la tendencia es desarrollar servicios que toleran cambios en sus proveedores es probable que se requiera de estrategias/políticas más formales como versionamiento y niveles de servicio.
Conclusión
Este artículo presenta tres conceptos principales a tomar en cuenta para la adopción de la arquitectura Microservicios, si bien su adopción puede ser parcial o total se requiere planificar otros aspectos para que la empresa esté preparada para su implementación. Animamos a todos a exponer en este medio sus puntos de vista y su conocimiento para mejorar este contenido y crear elementos de decisión sobre el paradigma.
Casos de éxito:
Finalmente queremos dejar dos enlaces a casos de éxito en la implementación de esta arquitectura para su evaluación y como elemento de decisión:
From a Monolith to Microservices + REST: the Evolution of LinkedIn’s Service Architecture[4]
[:es]Microservicios en aplicaciones empresariales[:]
[:es]
El concepto de Microservicios está a la orden del día y muchas empresas miran o estudian esta alternativa para la implementación de su Software. Este artículo trata de analizar tres temas principales de esta tecnología para que los CIO de la empresas tengan más elementos a la hora de tomar decisiones:
Concepto de Microservicios
No existe una definición única, pero en general al hablar de microservicios nos enfocamos en una arquitectura en donde se implementa la funcionalidad en silos de programación específicos definidos por el dominio del negocio (DDD). Estos servicios en conjunto, unos con otros, sirven cierta funcionalidad que podríamos denominar el Software producto. Así, en un clásica aplicación de compras en línea podríamos decir que el Software producto está dividido en dominios como inventario de productos, carrito de compras, procesamiento de pagos, sistema de entregas, servicio al cliente, etc., cada uno de ellos se concibe como una micro aplicación que se despliega independientemente de las otras en su proceso y que en la mayoría de casos en general tiene su propio repositorio de datos.
Delante de ellos y por la dinámica de los negocios en la actualidad se construyen los “front-end” que van desde páginas web, aplicaciones móviles, etc., hasta aplicaciones de consolas como Xbox, los cuales interactúan con estas micro aplicaciones a través de API gateway. Muchas de estas aplicaciones se intercomunican entre sí para proveer su funcionalidad, de una forma auto-gestionada, natural en una práctica conocida como coreografía. (Esto a diferencia del concepto de orquestación que se define en SOA[1]).
Existen muchos comparaciones o símiles con una arquitectura SOA (incluso inicialmente Netflix llamaba a esta arquitectura como SOA finamente desglosado[3]), y de un lado y del otro las opiniones tienen puntos válidos acerca de las razones.
En esta perspectiva ponemos a consideración dos puntos:
Escenarios para adopción de este diseño de Software
La arquitectura de Microservicios en la mayoría de casos puede no ser necesaria pues las aplicaciones con la arquitectura monolítica tradicional funcionan y se vuelven menos complejas de administrar, siendo esta dinámica la más común en las empresas que no tienen un portafolio grande de aplicaciones y/o requerimientos funcionales.
En las empresas de mayor volumen la realidad es diferente, el negocio ha requerido un portafolio grande de software que cubre requerimientos operacionales y comerciales. Aquí la propuesta del uso de esta arquitectura tiene que ver con dos aspectos:
Características de la arquitectura y retos de implementación
La adopción de la arquitectura en Microservicios requiere además, del análisis de varios aspectos técnicos y organizacionales que debe prever la empresa para no verse inmersa en problemas de gestión y en consecuencia implementaciones no exitosas y llenas de problemas.
Ponemos a consideración las siguientes características:
Conclusión
Este artículo presenta tres conceptos principales a tomar en cuenta para la adopción de la arquitectura Microservicios, si bien su adopción puede ser parcial o total se requiere planificar otros aspectos para que la empresa esté preparada para su implementación. Animamos a todos a exponer en este medio sus puntos de vista y su conocimiento para mejorar este contenido y crear elementos de decisión sobre el paradigma.
Casos de éxito:
Finalmente queremos dejar dos enlaces a casos de éxito en la implementación de esta arquitectura para su evaluación y como elemento de decisión:
Referencias:
[:]
Categorías
Tags
Contactos
De las Alondras, E10-115
+593 979 733 071
olivia@softwareevolutivo.net
8:30am-6:00pm