Desarrollar un software es un proceso complejo que demanda tiempo y requiere de una metodología determinada. Son tantos los pasos a seguir durante semanas, o incluso meses, que una correcta organización desde el comienzo del proyecto resulta crucial para su éxito. Sin embargo, no existe solo un modelo a seguir y elegir cuál de ellos seguir también es una elección que debe hacerse con cuidado. Hace ya tiempo que el mecanismo de microservicios gana terreno en la industria y quienes decidan embarcarse en él deben conocer tanto sus ventajas como sus desventajas.
Pero antes de comenzar, es importante entender que el modelo de microservicios no es mejor ni peor que otras formas de desarrollar un software, como puede ser la arquitectura basada en el estilo monolítico. Solo es otra metodología de trabajo que sirve para darle una organización al sistema y que, según las características de la iniciativa, puede resultar beneficiosa. Por lo tanto, más allá de los consejos que se puedan obtener, lo primordial es tomarse el tiempo necesario para analizar si esta elección resultará valiosa para el proyecto o no.
Índice de temas
Qué es un microservicio: definición
En la industria del desarrollo de software, se conoce al microservicio como un estilo de arquitectura nativo de la nube. Es decir, como una manera de programar el sistema que se quiere construir en una red de servidores remotos que se conectan a Internet y permiten llevar a cabo varias acciones, como almacenar, administrar y procesar datos, servidores y bases de datos, entre otros.
A diferencia de otras opciones, lo que se busca es que una aplicación, plataforma o programa esté dividida en un conjunto de pequeños servicios que son independientes entre ellos. Si bien todos trabajan en conjunto para llevar a cabo las tareas deseadas, no son una sola pieza que interactúa de forma dependiente.
En esa línea, cada elemento que forma parte del software es un microservicio particular. “Este enfoque en el ciclo de vida del desarrollo de software valora el nivel de detalle, la sencillez y la capacidad para compartir un proceso similar en varias aplicaciones. Es un elemento fundamental de la optimización del desarrollo de aplicaciones hacia un modelo nativo de la nube”, explican desde una importante empresa proveedora de software con código abierto.
En conclusión, lo que se busca con esta metodología es la distribución de los componentes del sistema con la meta de tener una funcionalidad con mayor calidad y rapidez. “Si bien esto se puede lograr con los microservicios, se deben considerar otras cuestiones. Dividir las aplicaciones en microservicios no es suficiente; es necesario administrarlos, coordinarlos y gestionar los datos que crean y modifican”, advierten.
Origen del microservicio
Desde que el desarrollo de software se estableció como un trabajo y posteriormente como una industria, el enfoque tradicional que predominó fue el estilo de arquitectura monolítica. El mismo plantea que todos los elementos necesarios para construir una aplicación deben estar contenidos en un solo sistema que funciona de forma dependiente.
Sin embargo, esta modalidad plantea una problemática difícil de resolver. Cuando surge un inconveniente, sobre todo en una aplicación de gran escala, es más difícil encontrar el lugar donde se originó el error y, por lo tanto, lleva más tiempo obtener una respuesta. Algo similar sucede cuando se quiere sumar una nueva función y debe realizarse un análisis para determinar dónde debe agregarse.
Para obtener una alternativa a este sistema, el experto en desarrollo de software Martin Fowler acuñó el término “Microservicio” en 2014. Según este enfoque técnico, una aplicación debe ser desarrollada a partir de “unidades funcionales independientes” que al momento de ser ejecutadas tienen una autonomía de las demás y que la comunicación entre ellas se produce a través de una Interfaz de Programación de Aplicaciones (API).
Hace ya casi una década que este paradigma se instaló en la industria y cada vez son más los programadores y desarrolladores que lo eligen. Esto se debe, sobre todo, a que posibilita a los equipos de desarrollo involucrados trabajar de forma simultánea porque cada uno se encarga de uno o varios microservicios. Al finalizar, todos estos componentes se conectan entre sí y se otorga al cliente un producto de alta calidad y que llevó menos tiempo de creación en comparación a otros sistemas.
“No afirmamos que el estilo de microservicio sea novedoso o innovador, sus raíces se remontan al menos a los principios de diseño de Unix. Pero sí creemos que no hay suficientes personas que consideren una arquitectura basada en microservicios, y que muchos desarrollos de software estarían mejor si la usaran”, asegura Fowler en un artículo sobre este tema que escribió junto a James Lewis, consultor en tecnología y creador de aplicaciones a partir de los microservicios.
Qué es la arquitectura de microservicio
Hasta los creadores de este término admiten que no existe una única definición sobre la arquitectura de microservicio que abarque todos los conceptos que rodean a este modelo. Esto se debe a que dentro del sistema también existen variaciones que cuentan con sus propias características. Sin embargo, con el objetivo de dar claridad al respecto, se puede llegar a algunas conclusiones generales.
Lo primero a tener en cuenta es que un software es creado a partir de varios componentes. Un componente es una unidad de software que opera de forma independiente a las demás y, por lo tanto, puede ser actualizada o reemplazada sin la necesidad de intervenir en el resto de la aplicación.
Es cierto que la arquitectura de microservicios utiliza bibliotecas, componentes vinculados a un programa que se llaman entre sí mediante funciones en la memoria. De todas formas, esta no es la forma en la que un software desarrollado con microservicio permite dividir sus componentes. Estos últimos realizan un proceso distinto en el cual los servicios son componentes fuera de proceso que se comunican con un mecanismo como una solicitud de servicio web o una llamada a procedimiento remoto.
Ventajas del microservicio
Quienes trabajan con esta modalidad destacan algunas de las principales ventajas que otorga a los proyectos. La primera de ellas es la facilidad de despliegue. Como los componentes son independientes entre sí, se despliega uno de ellos del resto de forma rápida y segura. Así, se puede analizar, modificar o sumar extensiones y luego volver a integrarlo a la aplicación sin correr el riesgo de generar inconvenientes a gran escala.
Otro beneficio que se suele considerar es la libertad del lenguaje de programación. Nuevamente, como los componentes son independientes entre sí y la comunicación entre ellos se da a través de una API, cada uno puede ser programado en el lenguaje que el creador considere más eficiente. Y, por otro lado, esta modalidad también permite una escalabilidad mucho más ágil porque no es necesario escalar horizontalmente toda la aplicación, sino solamente aquellos componentes que lo requieran.
Finalmente, también se observa como positivo el hecho de tener una alineación organizativa. Es decir, la cantidad de personas que están a cargo del mismo código es menor y eso lleva a que el trabajo esté mejor distribuido, se reduzcan los costos y se logren las metas en menos tiempo.
Desventajas del microservicio
Hasta el momento se mencionaron los beneficios que genera el modelo de microservicios. Sin embargo, también hay desventajas que pueden provocarse durante el proceso de aplicación de este formato. Es importante tenerlas en cuenta para evitar caer en ciertas problemáticas o buscar soluciones en caso de ser necesario.
Lo primero a remarcar es que no todos los programadores tienen la misma forma de trabajo. Incluso existen diferencias filosóficas sobre cómo abordar el desarrollo de un software que pueden ser totalmente opuestas entre sí. No tener en cuenta esto antes de iniciar un proyecto con múltiples equipos de desarrollo puede desembocar en un caos que lleve al fracaso del proyecto.
Otro aspecto que debe ser tenido en cuenta es que la modalidad de microservicio genera mucha “carga” durante su creación e implementación. Por ese motivo, es recomendable contar con un equipo de DevOps que sepan implementar la integración, entrega y despliegue en forma continua. Además, cada servicio requiere de su propio almacenamiento, monitoreo y mantenimiento, por lo que los costos finales pueden ser más elevados de lo esperado.
“Un argumento razonable que hemos escuchado a modo de desventaja es que no se debe comenzar con una arquitectura de microservicios”, revelan los autores de este término. Y agregan: “En su lugar, puede comenzar con un monolito, mantenerlo modular y dividirlo en microservicios una vez que el monolito se convierta en un problema. Aunque este consejo no es ideal, ya que una buena interfaz en proceso no suele ser una buena interfaz de servicio”.
Por qué y cuándo usar microservicios
Son varias las empresas que realizan el desarrollo de aplicaciones o plataformas a partir de los microservicios. Algunas de las más reconocidas a nivel internacional son Netflix, Amazon y Gilt. Para quienes defienden esta modalidad de desarrollo de software, esto es tomado como un impulso. Que compañías globales de gran tamaño lo utilicen, provoca una legitimación de la modalidad y un efecto réplica para que otras organizaciones hagan lo mismo
En el caso de Netflix, por ejemplo, hace ya varios años que migró de una arquitectura monolítica a microservicios. Se estima que la plataforma recibe alrededor de mil millones de llamadas diarias y mediante su API es capaz de adaptarse a más de 800 tipos de dispositivos diferentes. En todo momento, el servicio es estable y esto demuestra que la modalidad de compartimientos independientes funciona correctamente. Algo similar ocurre con Amazon o con Ebay, que emplean sistemas construidos con el mismo abordaje.
En cuanto al por qué utilizar los microservicios, hay varios argumentos que suelen darse. Por un lado, la app es más fácil de entender para los programadores que se suman al proyecto y, por ende, también es más sencilla de modificar. Además, provoca que los integrantes del equipo deban adaptarse al sistema de trabajo de forma ágil y veloz.
En esa línea, otra razón para utilizar los microservicios es la posibilidad de escalar el sistema de una manera más eficiente. Por el diseño propio del modelo, para lograr eso se requiere ejecutar copias de la aplicación en máquinas distintas. Esto resulta beneficioso porque la información no se encuentra en un solo lugar y en caso de tener dificultades se puede recurrir a uno de los backups.
Microservicios y contenedores
Los microservicios son un tipo de arquitectura de software originado en la nube. Por sus propias características, uno de los desafíos más importantes a los que se enfrenta una aplicación desarrollada con esta modalidad es el empaquetado, despliegue y distribución de la app. Por ese motivo es que el modelo está unido al concepto de contenedores.
Los contenedores tienen la capacidad de empaquetar toda la información para que un servicio sea ejecutado de forma encapsulada. Por lo tanto, resultan cruciales para el funcionamiento, ya que aseguran la disponibilidad del servicio más allá del sistema operativo que se elija para alojarlo. Por otro lado, de esta manera se garantiza la ligereza y portabilidad del proyecto y se logra que los servicios se transfieran entre diferentes entornos o máquinas casi instantáneamente y sin interrumpir su funcionamiento.
Microservicios vs. arquitectura monolítica
La diferencia entre la arquitectura monolítica y los microservicios radica en la dependencia entre los componentes que forman parte de la aplicación. Mientras en la primera todos los procesos están unidos entre sí y se ejecutan a través de un solo servicio, en la segunda hay decenas o cientos de conjuntos de pequeños servicios que operan de forma independiente y se comunican a partir de APIs.
Microservicios vs API
Muchas personas suelen confundir los términos microservicios y API y los interpretan como conceptos opuestos. Sin embargo, esta concepción es errónea. Los microservicios permiten un tipo de arquitectura para el ciclo de vida de desarrollo de software en el cual hay varios servicios pequeños operando de forma independiente. En ese contexto, las APIs son un elemento clave de esta modalidad porque posibilitan la comunicación entre los componentes. Además, gracias a las pasarelas de APIs es que un usuario puede llevar a cabo una tarea dentro del sistema en alguno de los servicios disponibles.
Microservicios y SOA
Otra modalidad de arquitectura de software es la Arquitectura Orientada a Servicios, conocida en la industria como SOA. En pocas palabras, este estilo tiene como objetivo proporcionar servicios a distintos componentes a través de un protocolo de comunicaciones en la web. Este último puede tener distintas versiones, ya que existen modalidades de un solo paso de datos o de dos o más servicios que coordinen su conexión.
Otra característica de la arquitectura SOA es que también cumple la función de consumir servicios. En este caso, hay una interacción con la arquitectura donde los usuarios humanos u otros sistemas pertenecientes a sistemas distintos mantienen una relación y comunicación.
En cuanto a los microservicios, la principal diferencia que se observa con respecto a los SOA es su tamaño y alcance. Los primeros son más pequeños que los segundos y, a su vez, estos últimos pueden estar desarrollados a partir de una arquitectura de aplicación monolítica. Ambos modelos cuentan con ventajas y desventajas y su elección para desarrollar un software recae en la finalidad del proyecto y los recursos disponibles para llevarlo a cabo.
Microservicios y DevOps
En la industria del desarrollo de software, cuando se habla de DevOps se hace referencia al conjunto de prácticas que se llevan a cabo para poder concretar el proyecto. Por lo tanto, se aglomera tanto las técnicas de desarrollo como las operaciones de IT que se implementan. El objetivo de todo grupo de programadores es que los pasos necesarios para llegar a la meta sean dados de manera coordinada para aprovechar al máximo los recursos.
En esa línea, cuando se implementa un DevOps, es necesario que se cumplan con los requisitos funcionales y los no-funcionales. Al utilizar una arquitectura monolítica, los desarrolladores suelen concentrarse en en los funcionales, mientras que los no-funcionales son relegados para momentos posteriores a la finalización del proyecto. Esto no ocurre con los microservicios porque ambos requerimientos, que incluyen la escalabilidad, la autonomía y el mantenimiento, entre otros, se trabajan simultáneamente.
Durante los últimos años, los microservicios se han convertido en el estándar de calidad para los DevOps. Esto se debe a que permiten una mejor organización y procesamiento del conjunto de prácticas. El resultado es una mayor agilidad para el desarrollo del software y una mejor calidad del mismo. Ambos son aspectos claves a la hora de entregar un producto a un cliente.
Qué tipos existen
Cuando un usuario de una determinada aplicación quiere conectarse con ella, puede hacerlo a través de distintos canales. Por lo tanto, existen varios tipos de microservicios que son clasificados según estas características. Las diferencias más notorias en este sentido radican en la clase de protocolos que utilizan, cuántos receptores tienen y su tipo de estado.
Por clase de protocolo
Según el tipo de protocolo que utilice una aplicación desarrollada a partir de microservicios puede agruparse en protocolo sincrónico y protocolo asincrónico.
Protocolo sincrónico
En esta modalidad, lo que se busca es que cada microservicio esté aislado al máximo nivel posible. Para lograrlo, se procede a bloquear los subprocesos y, de esa manera, el usuario solo puede seguir con la tarea que realiza en el sistema cuando recibe la respuesta del servidor donde se aloja el componente. El HTTP/HTPS es el ejemplo más usual que se utiliza en estos casos.
Protocolo asincrónico
A diferencia del caso anterior, en este modelo los subprocesos no están bloqueados. Además, se implementan protocolos compatibles con múltiples sistemas operativos y entornos establecidos en la nube. Básicamente, se envía un mensaje o llamada a un agente de mensajes. Un caso de uso es el protocolo AMQP, que utiliza el código del cliente y no espera ninguna respuesta.
Por cantidad de receptores
Otra manera de clasificar los microservicios se relaciona con la cantidad de receptores que tenga la aplicación. En ese sentido, pueden ser de un único receptor o de varios receptores.
Receptor único
Como lo indica su nombre, en esta modalidad hay un solo receptor que recibe todas las solicitudes de los clientes. Este es el encargado de procesar el 100% de las llamadas que llegan al sistema.
Varios receptores
En este caso, hay un agente dedicado a la mensajería o interfaz de bus de eventos. Su tarea es propagar las actualizaciones de base de datos entre todos los microservicios a través de un bus o dispositivo con características similares. De esta manera, la distribución no depende de un solo receptor, sino de todos los sistemas establecidos para llevar a cabo estas acciones.
Según su estado
Según su estado, los microservicios pueden diferenciarse en “con estado” y “sin estado”.
Microservicios sin estado
En este caso, lo que se observa son bloques de construcción de los sistemas distribuidos. Cuando se trabaja con esta categoría, no hay almacenamiento ni se mantienen sesiones entre dos peticiones. Un beneficio es que al eliminar un servicio determinado dentro de la aplicación, no se afecta el procesamiento general del sistema.
Microservicio con estado
A diferencia del tipo anterior, en esta modalidad sí se mantienen o almacenan los estados de sesión. Por lo tanto, las peticiones de servicios que se llevan a cabo entre los microservicios siempre se mantienen disponibles.
Críticas o controversias a los microservicios
Quienes tienen sus reparos con respecto a los microservicios realizan ciertas críticas a este sistema. La primera de ellas se refiere al equipo necesario para poder implementar esta modalidad. Al existir patrones de diseño, la necesidad de crear soluciones de forma veloz, la implementación de balanceos de cargas y otras cuestiones técnicas asociadas, resulta primordial contar con un grupo de expertos con amplia trayectoria en el sector. Esto no resulta accesible porque este tipo de profesionales escasea en la industria y, por lo general, sus remuneraciones son elevadas.
Por otro lado, la propia segmentación de equipos genera barreras de información que pueden ser difíciles de superar. Si bien los componentes funcionan de manera independiente, hay cuestiones que todos los integrantes del proyecto deben conocer para poder llegar a los objetivos planteados con éxito. Muchas veces ocurre que los grupos viven en países diferentes y, por lo tanto, requieren de un sistema de comunicación que si no funciona correctamente puede ser perjudicial para la iniciativa.
Por último, se subraya que los costos de comunicación entre los servicios son mayores a un sistema monolítico. Esto se debe a la necesidad de implementar canales de comunicación entre todos los componentes, mientras que en un sistema dependiente esto no es necesario porque todos conforman la misma unidad. En ese sentido, lo que resulta una ventaja a la hora de desarrollar el software puede ser una desventaja en términos de inversión y de mantenimiento del mismo.
Tecnología de los microservicio
Como se mencionó, una de las ventajas de los microservicios es que cada componente que forma la aplicación puede ser desarrollado a partir de lenguajes de programación distintos. Por lo tanto, no hay un estándar definitivo para esta parte de la construcción. Sin embargo, hay varias tecnologías que son necesarias para llevar a cabo un proyecto con esta modalidad de forma ordenada y metódica.
Uno de los desarrollos que mejor se adapta a los microservicios es Docker. “Debido a que los contenedores no tienen la sobrecarga de su propio sistema operativo, son más pequeños y más ligeros que las tradicionales máquinas virtuales y pueden girar hacia arriba y hacia abajo más rápidamente, lo que los convierte en la opción perfecta para los servicios más pequeños y ligeros que se encuentran dentro de las arquitecturas de microservicios”, señalan expertos de IBM al respecto.
Por otro lado, debido a la cantidad de servicios que surgieron en los últimos años, la gestión de grandes grupos de contenedores y su respectiva orquestación, se volvió una actividad cada vez más compleja. “Kubernetes, una plataforma de código abierto de orquestación de contenedor, ha surgido como una de las soluciones de orquestación más populares porque hace ese trabajo muy bien”, agregan en IBM.
Para concluir, otra tecnología necesaria para optimizar e implementar la funcionalidad de los componentes que forman parte de una aplicación creada por este modelo son los getaway de API. Cada servicio opera de una forma independiente entre sí y se comunica con el resto a través de una API determinada. Por lo tanto, contar con getaways, capas intermedias que actúa como un proxy inverso para los clientes mediante solicitudes de direccionamiento, es una necesidad vital. Sobre todo porque distribuyen las llamadas por varios servicios y genera más protección del sistema al existir mayores procesos de seguridad y autenticación.
Prohibida su reproducción total o parcial.