microservicios Archives - Software Evolutivo

Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo?

Bryan Diaz — Thu, 23 Mar 2023 15:43:36 +0000

Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo?

En la actualidad, Quarkus representa la pila tecnológica de Java Nativa de Kubernetes (una colección de herramientas, marcos, lenguajes de programación y bibliotecas) diseñada para GraalVM y OpenJDK HotSpot (Máquinas Virtuales de Java).

Los desarrolladores pueden crear aplicaciones con el mismo Stack (Estructura de Datos) y microservicios más ligeros, rápidos y escalables gracias a las mejores bibliotecas y estándares de Java utilizados en su creación. Esta herramienta permite a los desarrolladores escribir código en Java/Kotlin mientras proporciona funciones de gestión de memoria y escalabilidad. Por lo tanto, “Quarkus” ayuda a los desarrolladores a trabajar de manera proactiva y eficiente si buscan una forma eficiente de desarrollar una determinada aplicación o microservicio Java, ya que es una de las mejores opciones disponibles.

Quarkus es más que un proyecto de código abierto presentado por Red Hat (Que conquistó a la comunidad Java y el primer release fué presentado en el 2019), por el hecho de que combina la productividad y la alegría del desarrollador (similar a Node.js), con la velocidad y rendimiento de GO, puesto que aquello le permite a los desarrolladores Java crear soluciones tecnológicas y arquitecturas modernas futuristas.

Turețchi (2022) muestra que Quarkus es una pila de Java nativa para la nube, basada en contenedores y diseñada para mejorar la productividad de los desarrolladores, reducir la huella de memoria de las aplicaciones y microservicios Java. Esta herramienta brinda a los desarrolladores una experiencia de tiempo de ejecución unificada y liviana mediante el uso de GraalVM, HotSpot y otros lenguajes como Kotlin, lo que permite el desarrollo eficiente de aplicaciones modernas nativas de la nube, con un enfoque en la escalabilidad y la gestión de la memoria. En consecuencia, Quarkus, como parte de un conjunto de herramientas tecnológicas, facilita la creación rápida de servicios modernos nativos en la nube.

Aplicaciones de Quarkus y por qué es actualmente el marco más popular

Quarkus es uno de los marcos de desarrollo nativos en la nube más populares en la industria tecnológica debido a sus características notables. Ofrece un tiempo de arranque rápido, una pequeña huella de memoria y una gestión escalable de la memoria. Por esta razón, el marco Quarkus con Kotlin es ampliamente utilizado en la industria. Su capacidad para reducir los tiempos de desarrollo también ayuda a mantener un alto rendimiento con servidores y redes de baja gama.

Cabe recalcar que, todos estos elementos claves, inciden en la creación de aplicaciones con un alto grado de rapidez/eficiencia, ya que se pueden implementar y escalar fácilmente en varias arquitecturas de la nube.

Con las capacidades de Quarkus, las organizaciones ahora pueden desarrollar servicios modernos con mayor velocidad y eficiencia que nunca, y usando Java o Kotlin proporciona una experiencia de desarrollo fluida con un modelo de programación reactivo moderno.

Arquitectura Empresarial Tradicional vs. Arquitectura Contenerizada.

En Quarkus, puedes desarrollar aplicaciones Java y ejecutarlas directamente en el sistema operativo subyacente sin necesidad de una máquina virtual de Java intermedia. Esto reduce significativamente el tiempo de ejecución, el consumo de memoria y otros recursos, lo que se traduce en una ejecución más eficiente y rápida de la aplicación. Quarkus lleva poco más de tres años en el mercado y ofrece una propuesta de valor para la creación de aplicaciones Java de última generación. Además, proporciona arquitecturas escalables para ejecutar aplicaciones Java y Serverless en la nube.

Arquitectura Tradicional

En la arquitectura tradicional, el primer nivel consta del hardware esencial para ejecutar el segundo nivel, que es el sistema operativo, como por ejemplo una Mac OS o Linux. En el tercer nivel, se requería la instalación de la popular Máquina Virtual de Java (JVM), mientras que en el último nivel, comúnmente utilizado en entornos empresariales, se instalaba un servidor de aplicaciones. Para ello, era necesario contar con una máquina virtual de Java capaz de comunicarse con el sistema operativo subyacente y traducir toda la aplicación al sistema operativo. Esta arquitectura era común en empresas, pero con el tiempo ha dejado de ser una buena práctica debido a sus implicaciones en el desarrollo, la agilidad y la complejidad en su mantenimiento. Actualmente, existen otras arquitecturas que ofrecen soluciones más ligeras y eficientes.

Figura 1: Arquitectura Java Tradicional

Arquitectura Contenerizadas.

En la actualidad, la arquitectura contenerizada se ha vuelto cada vez más popular gracias a la presencia de nuevas tecnologías en el mercado. Entre ellas, la tecnología Docker (Si te interesa, en un artículo anterior compartimos los Primeros pasos en Docker.) ha tomado un gran protagonismo en la mayoría de las empresas. Docker nos permite construir y empaquetar aplicaciones de forma portable, lo que significa que pueden ejecutarse en diferentes sistemas operativos y entornos sin necesidad de compilar la aplicación para un sistema operativo en particular. En esencia, Docker realiza una tarea similar a la que la máquina virtual de Java realizaba, pero aplicable a cualquier tipo de aplicación.

En la arquitectura contenerizada, el primer nivel es el hardware, seguido por el sistema operativo, que puede ser cualquiera que tenga la capacidad de ejecutar contenedores. En el siguiente nivel, se debe instalar Docker para poder colocar nuestras aplicaciones en contenedores y ejecutarlas. Gracias a esta arquitectura, podemos tener diferentes versiones de aplicaciones sin que esto suponga un problema, ya que cada una se ejecuta en un contenedor independiente. Esto nos brinda una ventaja significativa en términos de mantenimiento y evita conflictos entre versiones de aplicativos.

Figura 2: Arquitectura Contenerizadas

Quarkus representa una mejora significativa en la arquitectura contenerizada al eliminar la necesidad de tener una JVM en cada contenedor para la ejecución de nuestras aplicaciones. Esto permite un despliegue más rápido y una menor utilización de recursos, lo que se traduce en una mayor eficiencia y ahorro de costos.

Superpoderes de Quarkus: Gestión de Memoria y Escalabilidad

Los desarrolladores pueden utilizar Quarkus, un marco Java que les brinda las herramientas necesarias para administrar la memoria de manera efectiva y escalar sus aplicaciones. Quarkus cuenta con una variedad de herramientas de optimización de memoria, como administración de memoria dinámica, recolección de elementos no utilizados y dimensionamiento de almacenamiento dinámico. Además, Quarkus proporciona soluciones de escalabilidad para aplicaciones que necesitan escalar rápidamente hacia arriba o hacia abajo, a través de herramientas de escalabilidad como orquestación de contenedores, escalado automático y equilibrio de carga. Estas características permiten a los desarrolladores asegurarse de que sus aplicaciones puedan manejar grandes cantidades de tráfico sin problemas de rendimiento. Con la administración de memoria dinámica de Quarkus, los desarrolladores pueden realizar cambios en sus aplicaciones sobre la marcha sin necesidad de reiniciar la aplicación, lo que les permite probar rápidamente los cambios y optimizar el uso de la memoria. Es importante destacar que la variedad de herramientas de escalabilidad permite la escalabilidad horizontal, lo que permite a las aplicaciones manejar fácilmente una mayor carga de usuarios.

Características y ventajas de Quarkus sobre los marcos tradicionales de Java

Quarkus es un marco independiente del tiempo de ejecución diseñado para proporcionar una forma eficiente y rentable de desarrollar aplicaciones nativas de la nube. Ofrece una gestión inteligente de la memoria y herramientas que facilitan a los desarrolladores la creación de aplicaciones con menos recursos y tiempo de arranque más rápidos que los marcos de Java tradicionales, lo que permite que las aplicaciones sean escalables de forma rápida y eficiente. Además, Quarkus tiene ventajas sobre los marcos de Java tradicionales en cuanto a la gestión inteligente de la memoria, la escalabilidad y el rendimiento mejorado, y brinda a los desarrolladores la capacidad de escribir código en cualquier idioma que elijan e implementarlo como una aplicación en contenedores, lo que lo convierte en una excelente opción para aquellos que buscan aprovechar los beneficios de la computación en la nube manteniendo el control sobre sus aplicaciones.

Desventajas de Quarkus sobre los marcos tradicionales de Java

Aunque Quarkus tiene muchas ventajas para el desarrollo de aplicaciones en la nube, también tiene algunas desventajas a tener en cuenta. Una de ellas es que, al ser un marco relativamente nuevo, puede haber una curva de aprendizaje para los desarrolladores que no estén familiarizados con él. Además, debido a que Quarkus utiliza tecnologías de vanguardia, puede haber algunos problemas de compatibilidad con bibliotecas y frameworks más antiguos. Por último, aunque Quarkus es altamente escalable, puede ser menos adecuado para aplicaciones que no necesiten escalabilidad horizontal, ya que esta característica puede agregar complejidad y costo al desarrollo y la implementación.

El tamaño de la imagen nativa de Quarkus puede ser una desventaja para algunos usuarios, por el hecho de que puede resultar más grande que el tamaño de la imagen de una aplicación Java tradicional. Esto se debe a que la imagen nativa incluye todo lo necesario para que la aplicación se ejecute sin depender de una máquina virtual, lo que aumenta su tamaño. Sin embargo, es importante tener en cuenta que esta desventaja puede ser mitigada mediante la optimización de la imagen y la eliminación de componentes innecesarios. Además, el tamaño de la imagen puede ser compensado por las ventajas en cuanto a rendimiento y eficiencia que ofrece Quarkus.

Conclusiones

En resumen, Quarkus es un nuevo marco de desarrollo de Java de alto rendimiento que permite a los desarrolladores crear aplicaciones empresariales de manera fácil y rápida. Con sus características únicas como la eficiencia del tiempo de ejecución, el soporte de Java y la integración con tecnologías empresariales, Quarkus es una opción atractiva para los desarrolladores que buscan crear aplicaciones rápidas y escalables. Por esa razón, vale la pena explorar Quarkus como una opción para su próximo plan de desarrollo de aplicaciones.

Referencias

https://quarkus.io/
Gascó Compte, A. (2022). Sistema de ayuda a las pruebas de fragilidad. Obtenido de: https://repositori.uji.es/xmlui/handle/10234/200566
Turețchi, G., & Cerbu, O. (2022). Aplicarea frameworkului Quarkus în cadrul arhitecturii bazate pe microservicii. In Conferinţa tehnico-ştiinţifică a studenţilor, masteranzilor şi doctoranzilor (Vol. 1, pp. 56-59).

The post Descubriendo a Quarkus: ¿Que es, Características y por qué utilizarlo? appeared first on Software Evolutivo.

Arquitectura de Microservicios: qué es, ventajas y desventajas

Fernando Paz — Thu, 21 Jul 2022 19:57:23 +0000

Existen dos grandes paradigmas a la hora de diseñar Software: la Arquitectura Monolítica y la Arquitectura de Microservicios. En este artículo vamos a revisar qué es la Arquitectura de Microservicios, y cuáles son sus ventajas y desventajas.

Qué es la Arquitectura de Microservicios
Características de los Microservicios
Ventajas de la Arquitectura de Microservicios
Desventajas de la Arquitectura de Microservicios

Qué es la Arquitectura de Microservicios

Antes de hablar de la Arquitectura de Microservicios, vamos a partir identificando a su predecesor que es la Arquitectura Monolítica.

La Arquitectura Monolítica, es un enfoque en donde todos los conceptos y dominios de negocio de un producto de Software se implementan como componentes completamente acoplados, por lo que, tanto las entradas como las salidas de cada componente tienen su razón y especificación en contexto de un único producto de Software que es indivisible.

Iniciando desde la interfaz del usuario (en algunos casos), pasando por una o varias capas de lógica de negocio, la capa de persistencia, y, hasta la base de datos, el producto de Software se construía como un solo concepto, y a menudo se ejecuta como un solo binario o unidad entregable (JAR, WAR, EAR, Folder, etc.).

La Arquitectura de Microservicios es un enfoque para el desarrollo de un producto de Software, en donde cada concepto específico de negocio es construido en una unidad pequeña de código accesible a través de una API liviana y bien definida.

El TODO del producto de Software entonces, constituye la ejecución sincronizada de un conjunto de estos servicios, cada uno con su propia e independiente definición, para el proceso de una transacción padre disparada desde una interfaz de usuario o sistema.

Características de los Microservicios

Aunque parece no existir una especificación única para crear Microservicios, y más depende del caso de negocio y/o planificación; generalmente se sugiere que deban cumplir las siguientes características:

Interfaz Única

Cada Microservicio debe proveer una interfaz ligera y bien definida para consumo, que aísle todos los detalles técnicos, estructura de datos y datos de la capacidad de negocio que maneja, a sus clientes.

Especializado

Cada servicio es diseñado con un conjunto limitado de capacidades que resuelvan uno y solo un problema de negocio, y que incluye su propia estructura de datos persistentes.

Autónomo

Cada servicio puede ser desarrollado, desplegado, operado y escalado sin afectar o depender de otros servicios o sistemas, o, de otros datos fuera de su especialización.

Claramente una Arquitectura de Microservicios es una aplicación del paradigma de Cómputo Distribuido, lo que representa muchas ventajas para el negocio pero también muchos retos en la operación y mantenimiento.

Ventajas de la Arquitectura de Microservicios

Agilidad Este paradigma de desarrollo permite crear equipos pequeños e independientes que se apropian de la especialización de los servicios, acelerando el tiempo de desarrollo, facilitando la auto-organización e incluso el soporte post-producción.	Escalamiento Esta división de funcionalidad hace más fácil la medición y observabilidad de la implementación, permitiendo planificar mejor la disponibilidad y escalabilidad.
Simplificación de Despliegue Una unidad pequeña de implementación, permite ciclos de CI/CD más simples, reduciendo el tiempo de despliegue de la misma y el rollback en caso de fallos. Esto agiliza las operaciones y al mismo tiempo reduce el riesgo de innovación con nuevas características.	Resiliencia A diferencia de una Arquitectura Monolítica, un fallo en una Arquitectura de Microservicios compete a un componente específico, lo que hace más fácil su recuperación y no desestabiliza el producto de Software por completo, sino la capacidad de negocio concreta que le compete.
Independencia Tecnológica El uso de una sola tecnología no es una restricción en la Arquitectura de Microservicios, dado que su interfaz de consumo abstrae los detalles de implementación y habilita a la selección de la mejor herramienta de acuerdo a la especialización del servicio.	Reutilización de Código Evidentemente una vez construido un servicio que atiende una capacidad de negocio, el mismo puede ser utilizado por otros productos de Software de forma que su construcción aproveche la funcionalidad ya implementada.

Desventajas de la Arquitectura de Microservicios

Más que desventajas, se puede hablar de retos a la hora de adoptar una Arquitectura de Microservicios, y entre los principales tenemos:

Versionamiento Un Microservicio, al ser autónomo, suele evolucionar independientemente del producto o de los productos de Software a los cuales provee funcionalidad. Esto significa que su interfaz API y la validación del esquema de datos varía continuamente, sin embargo para no afectar la estabilidad de sus clientes antiguos debe mantener un versionamiento de los mismos y obviamente mantenerlos operando. Esto tanto para áreas de operaciones y de desarrollo implica una tarea adicional en su implementación.	Pruebas Si bien un Microservicio por sí solo es más simple de probar, su orquestación con otros servicios (test de integración) y las pruebas integrales (pruebas end to end) son mucho más complejas. Esto resulta a menudo en una cobertura incompleta de escenarios de pruebas y un esfuerzo redoblado en su desarrollo.
Rollback y Sistemas Distribuidos El reto más grande, para mí, es el diseño de sistemas distribuidos, puesto que hay que definir qué sucede en caso de fallos esperados o inesperados en la orquestación de los servicios, analizar patrones de resiliencia y recuperación de transacciones, mirar la atomicidad de operaciones y consistencia de datos, entre otros. Claro está, que para esto nos podemos apoyar en conceptos como “Patrones de Integración Empresarial”, “Mallas de servicios” o similares, pero sin duda estas decisiones son extremadamente relevantes no solo para el desarrollo sino para el soporte post-producción.	Coordinación de equipos Si bien, al desarrollar un Microservicio, paradigmas como la Agilidad y un equipo responsable puede representar una gran ventaja para generar valor e innovación constante en su implementación, al tener decenas o centenas de microservicios con decenas o centenas de equipos responsables, la cooperación y comunicación de estos equipos es un reto, pues el TODO de un Sistema y su evolución se puede poner en riesgo cuando se carece de una acción combinada.
Sobrecarga de infraestructura En la Arquitectura Monolítica un operador a menudo mira un servidor y un Software correspondiente con su archivo log; en un paradigma de Arquitectura de Microservicios puede enfrentarse a escenarios donde un Software tiene 100 servicios y centenas de servidores, con uno o varios balanceadores, muchos archivos de logs y decenas de formatos. Aunque hoy existen esquemas de contenerización como Docker y Kubernetes, la administración sigue siendo un reto y se necesita varias tecnologías complementarias para enfrentarlo.	Tiempo y esfuerzo 1x A este punto del artículo ya hemos descrito muchas actividades adicionales en el diseño, implementación, operación y mantenimiento de la Arquitectura de Microservicios, por su característica de Sistema Distribuido. Por este motivo es importante sopesar el beneficio de este paradigma en contraste con el caso de negocio y los resultados esperados a corto, medio y largo plazo; del mismo modo debemos pensar en el soporte post implementación, en relación al equipo, sus capacidades.
Despliegue ¡Si!, desplegar un solo microservicio es simple, sin embargo desplegar cientos de ellos de forma manual se vuelve imposible. El orden de despliegue, los cambios de base de datos que implica, la estratégia de entrega (Blue-Green, Canary, etc.), entre otros, son cosas a planificar y deben estar automatizadas, con prácticas DevOps entre otras como Integración Continua (CI) y entrega Continua (CD).	Logs y Monitoreo De la misma manera, un producto de Software Monolítico deja un solo log de operación y se puede medir su performance centralizadamente. En una Arquitectura de Microservicios, vamos a tener tantos logs como servicios implementados para el producto de Software y además si estos son redundantes, tendremos logs multiplicados por cada servicio. Debemos planificar una estratégia para rastrear errores, identificar la salud de cada servicio y del sistema como tal.
Debug Encontrar un problema no siempre va a ser posible revisando logs (que al ser tantos ya nos agrega una complejidad), a veces vamos a tener que depurar la implementación y esto en un sistema distribuido no va a ser factible, por lo que se requerirá de otras técnicas y patrones que permitan repetir ciertas ciclos de transacciones.

Pensamientos Finales

A este punto del artículo, puede sonar complejo decidir por microservicios, y la verdad lo es; sin embargo, esta complejidad no se evidencia desde el momento cero de una implementación, sino que irá apareciendo gradualmente mientras vamos creando más microservicios y escalándolos.

Son muchas sus ventajas, y aunque hay retos, en una estratégia digital a largo plazo es sin duda el camino a adoptar, y así mismo, debe venir acompañada de un soporte directivo dado que la estructura organizacional, técnica y de costos va a tener que evolucionar también.

¿Debo usar Microservicios? La realidad es que muchos desarrollos de Software nacen con este enfoque, sin abordar en un primer momento las soluciones a estos desafíos, pero eventualmente lo harán. Les invito a ver una interesante conversación entre Martin Fowler y Sam NewMan sobre cuando usar microservicios y cuando no.

El soporte de este tipo de aplicaciones es complejo, pues detectar un fallo en una Arquitectura de Microservicios requiere de un entrenamiento en el flujo de negocio, en los puntos de integración y en la interpretación de los logs de información. En muchos casos al soporte de primera línea le faltan insumos para responder y el escalamiento de las incidencias es muy rápido al equipo técnico, resultando en una sobrecarga de operación y costo.

The post Arquitectura de Microservicios: qué es, ventajas y desventajas appeared first on Software Evolutivo.

[:es]Microservicios en aplicaciones empresariales[:]

Fernando Paz — Mon, 18 Jul 2016 14:40:00 +0000

[: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
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.

Escalamiento Horizontal Aplicaciones Monolíticas, Copyleft www.softwareevolutivo.com.ec

Escalamiento Vertical Microservicios, Copyleft www.softwareevolutivo.com.ec

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]
A Microscope on Microservices[5]

Referencias:

[:]

The post [:es]Microservicios en aplicaciones empresariales[:] appeared first on Software Evolutivo.