Arquitectura de Tres Capas a Microservicios

Arquitectura Tres Capas a Microservicios

Introducción:
Todo gestor debe conocer aspectos técnicos y funcionales del negocio que tiene a su cargo, el no saber o desconocer estos temas resta a la disrupción que busca en incrementar valor y aperturar nuevas líneas de su negocio. La Arquitectura es fundamental saber interpretarla y más debatirlo porque es esa frontera donde la gestión no pisa fuerte pero que debe estar preparado para saber discutir unos temas de tendencia que interesa no a las áreas sino a la empresa que rinde servicio.

Marco Conceptual:
En la última década, se sabe que la tendencia en esos años era la arquitectura de tres niveles, usadas en ASP.NET y Java EE. Sin embargo, estos formato de arquitectura viene desde finales de los años 90 como un medio para entregar aplicaciones web pero el gobierno de IT exige una estrategia para establecer una arquitectura de aplicaciones que brinde más que una aplicación web. Los clientes ahora exigen acceso a través de múltiples canales: sitios web, aplicaciones móviles, redes sociales, notificaciones, correo electrónico y más. Las presiones competitivas están impulsando a las organizaciones a proporcionar UX que superan las expectativas, y los principales conocedores de negocios digitales aseguran que los usuarios deben tener experiencias optimizadas, continuas y ambientales a medida que ingresan a estos canales.

Sustento:

• Primero la arquitectura de tres niveles o más divide lógicamente una solución en tres o más niveles. El nivel superior gestiona la interacción del usuario, el nivel intermedio implementa la lógica de negocio y el nivel inferior administra el acceso a los datos. 
• El principal problema es que define las aplicaciones en una sola dimensión. Toda la aplicación está dedicada a soportar una sola experiencia porque conecta la interfaz de usuario a la base de datos. De arriba hacia abajo y viceversa, una simple línea recta, una dimensión, un solo tamaño para todos.
• Con la nueva generación y herramientas colaborativas ya no podemos describir con precisión el flujo de aplicaciones de arriba hacia abajo o viceversa. En su lugar, las aplicaciones deben permitir múltiples y distintas experiencias de aplicación, a las que se accede a través de múltiples canales de cliente. La lógica de negocio debe soportar varios flujos de trabajo para soportar esas experiencias.
• Es muy común que ahora un desarrollo para una aplicación adicione funcionalidad de otras aplicaciones y comparta información con sistemas externos. Los datos suelen venir de múltiples fuentes, se empuja en múltiples direcciones y se almacena en diversos formatos y modelos. Las fuentes de datos suelen ser resumidas y encapsuladas por los servicios que las administran, microservicios.
• Por último, en lugar de un simple modelo lineal se debe tener un moderno diagrama de arquitectura de aplicaciones que sea o asimile una malla de aplicaciones y servicios independientes. Los servicios independientes pueden ser desplegados en las instalaciones de tu negocio o en la nube, e inclusive desde fuentes de terceros.

Cómo enfocar una aplicación moderna:

Preocupate si recién nos encaminamos porque esto ya ha comenzado entrando a un laberinto virtual que brinda un abanico de soluciones y conceptos para enfrentar este cambio tecnológico. Te menciono tres consideraciones que debes tener en tu desarrollo o al momento de discutir con Arquitectura:

• Primera regla y la más importante, los usuarios quieren tener acceso a la funcionalidad para realizar sus tareas desde cualquier lugar y en cualquier lugar: en casa o en la oficina, en un restaurante,desde el automóvil o un avión, o donde sea.
• Las organizaciones deben diseñar aplicaciones pequeñas enfocadas para los distintos canales y que garantice que las aplicaciones puedan compartir un conjunto común de servicios de fondo.
• No se debe crear ni mantener aplicaciones separadas para cada canal con un conjunto exhaustivo de características, siempre se debe enfocar en desarrollar soluciones que consideren interfaces que posteriormente pueden ser implementadas.

En el sustento hablamos de flujo en dos sentidos (arriba/abajo), ahora analicemos cada extremo y comencemos con la parte visible para el cliente. Es posible que las aplicaciones necesiten soportar una amplia gama de interfaces de usuario que se ejecutan en una serie de dispositivos PC, tablets, teléfonos inteligentes, relojes, quioscos, paneles de vehículos, dispositivos GPS y reproductores de medios. Adicionamos el soporte a múltiples canales lógicos, incluyendo navegadores, aplicaciones, redes sociales, asistentes personales digitales, robots (bots) y otros servicios. Siendo extremistas es posible que tengan que aceptar solicitudes de dispositivos IoT y procesos automatizados. Entonces la lista se vuelve complicada y creciente sumandole que de todo lo mencionado algunos serán desarrollos propios y otros de terceros. Técnicamente tenemos que pensar en una interfaz que no solo sea parte de un extremo sino un conjunto de puntos de acceso para garantizar la atención a los usuarios.

Recordemos que una aplicación proporciona un UX específico para una aplicación. Necesitamos proporcionar una experiencia apta para el propósito de una persona en particular que ejecuta una tarea específica usando un canal por eso y con énfasis "una aplicación está diseñada para simplificar e intuir". Por este motivo una aplicación de tres capas está diseñada para soportar todos los tipos de usuarios y tareas desde una interfaz, pero un sistema moderno tendrá varias aplicaciones, cada una de ellas para un rol de usuario definido, una idea contrapuesta a la de una aplicación que admite una interfaz de cliente. Ahora el factor más importante para decir si una interfaz es la más apropiada será la que tenga mayor contenido humano, ¿que?!, si humano porque cada vez IT se está haciendo más complejo y sobrepasa el entendimiento mecanizando nuestro uso.

Ahora hablemos del extremo inferior, base de datos comúnmente considerada. Hoy muchas aplicaciones, por no decir todas, emplean múltiples fuentes de datos y modelos de persistencia, todos los cuales pueden ser controlados por diferentes partes de la empresa o incluso diferentes empresas. En muchas situaciones, un servicio encapsula y administra sus propios datos y utiliza un modelo de persistencia que mejor se adapte a los requisitos del negocio. Pero esto resulta en aplicaciones que se basan en múltiples mecanismos de almacenamiento de datos y acceso a datos: Base de datos relacionales, NoSQL, Big Data, Feeds, Video e inclusive otras aplicaciones.

Beneficios que pueda esperar:

Un entorno digital requiere respuesta rápida a las oportunidades: Por eso, la arquitectura de la aplicación debe ser lo suficientemente ágil como para permitir la entrega continua de las nuevas características. Las arquitecturas de un enfoque lineal impiden la agilidad, por la siguiente premisa: cada nueva característica debe ser integrada en la próxima versión, y para la mayoría de las empresas, los plazos de entrega de las versiones se miden en meses, en el mejor de los casos. La arquitectura de los microservicios descompone la lógica de la aplicación lineal en servicios que se pueden desplegar de forma independiente y que se pueden implementar tan pronto como se completen. Bien! Agilidad y Entrega Continua.

La agilidad y entrega continua han sido las principales motivaciones para que las empresas inviertan en la arquitectura de microservicios. La implementación de esta arquitectura puede aumentar la complejidad de la aplicación y requiere la inversión asociada en nuevas infraestructuras y procesos; Pero, como inversión, los beneficios asociados superan con creces los efectos que puedan tener en su transición. Las empresas que emplean arquitectura no moderna corren el riesgo de obsolescencia del producto incluso antes de que la nueva versión sea lanzada. Por otro lado, la entrega de software y servicios más rápidamente puede traducirse en nuevos negocios y mayor cuota de mercado. Por eso Arquitectura debe saber eso, y si no de una vez en practica.

Transición

Para la mayoría de las empresas, la migración de Arquitectura tres niveles a microservicios debe ser gradual en lugar de una transición de "big bang". Muchas aplicaciones pueden permanecer como son, pero sus iniciativas empresariales digitales requerirán que sus desarrollos evolucionen a una Arquitectura de Microservicios. Ahora, esta transición exige cambios culturales y tecnológicos desde la alta gerencia y la parte operativa, por eso el coaching y experiencias ya se tienen disponibles para afrontar una correcta transición que lo revisaremos en otro post exclusivo para ese tema.

Muchas gracias.

Saludos.