Es probable que los microservicios sean al menos tan conocidos entre los ejecutivos y los líderes de proyectos como entre los desarrolladores. Esta es una de las características más inusuales de los microservicios, porque el entusiasmo por la arquitectura se reserva normalmente para los equipos de desarrollo de software. La razón es que los microservicios reflejan mejor la forma en que muchos líderes empresariales desean estructurar y ejecutar sus equipos y procesos de desarrollo.

Dicho de otro modo, los microservicios son un modelo de arquitectura que facilita un modelo operativo deseado. En una encuesta reciente de IBM realizada a más de 1200 desarrolladores y ejecutivos de TI, el 87 % de los usuarios de microservicios afirmó que el gasto y el esfuerzo necesarios para adoptar los microservicios valen la pena. 

Estos son solo algunos de los beneficios empresariales de los microservicios.

Desplegables de forma independiente

Tal vez la característica más importante de los microservicios es que como los servicios son más pequeños y desplegables de manera independiente, ya no requieren una legislación para cambiar una línea de código o añadir una nueva característica en una aplicación.

Los microservicios prometen a las organizaciones un antídoto contra la frustración que provoca que la aplicación de pequeños cambios requiera grandes cantidades de tiempo. No se necesita un doctorado en informática para ver o entender el valor de un enfoque que aumenta la velocidad y la agilidad.

No obstante, la velocidad no es la única ventaja que tiene diseñar servicios de esta manera. Un modelo organizativo emergente común es reunir equipos multifuncionales en torno a un problema de negocio, servicio o producto. El modelo de microservicios encaja perfectamente con esta tendencia, ya que permite a una organización crear equipos pequeños y multifuncionales en torno a un servicio o una colección de servicios, y hacer que operen de forma ágil.

El acoplamiento ligero de los microservicios también crea un grado de aislamiento de errores y ofrece una mejor resiliencia en las aplicaciones. Asimismo, el pequeño tamaño de los servicios, combinado con sus claros límites y patrones de comunicación, permite a los nuevos miembros del equipo entender la base de código y modificarla rápidamente, lo que supone una clara ventaja en términos de velocidad y moral de los empleados.

La herramienta adecuada para el trabajo

En los patrones de arquitectura tradicionales de n niveles, una aplicación normalmente comparte una pila común, con una gran base de datos relacional que da soporte a toda la aplicación. Este enfoque tiene varios inconvenientes obvios: el más importante es que cada componente de una aplicación debe compartir una pila común, un modelo de datos y una base de datos, aunque haya una herramienta mejor para el trabajo para determinados elementos. Esto perjudica a la arquitectura y es frustrante para los desarrolladores, que son conscientes en todo momento de que hay una forma mejor y más eficaz de crear estos componentes.

Por el contrario, en un modelo de microservicios, los componentes se despliegan de forma independiente y se comunican a través de una combinación de REST, transmisión de sucesos e intermediarios de mensajes, lo que permite optimizar la pila de cada servicio individual en ese servicio. La tecnología cambia todo el tiempo, y es mucho más fácil y menos costoso que una aplicación formada por múltiples servicios más pequeños evolucione con la tecnología a medida que esta avance.

Escalado preciso

Con los microservicios, los servicios individuales se pueden desplegar uno a uno, pero también se pueden escalar individualmente. Si se hace correctamente, los microservicios requieren menos infraestructura que las aplicaciones monolíticas, ya que permiten un escalado preciso solo de los componentes que lo requieran, en lugar de toda la aplicación, como ocurre con las aplicaciones monolíticas.

También existen algunos retos

Las importantes ventajas de los microservicios también llevan asociadas algunos retos significativos. Cambiar de una aplicación monolítica a los microservicios implica una mayor complejidad de gestión: muchos más servicios, creados por muchos más equipos, desplegados en muchos más lugares. Los problemas en un servicio pueden provocar o deberse a problemas en otros servicios. Los datos de registro (utilizados para la supervisión y la resolución de problemas) son más voluminosos y pueden ser incoherentes entre los distintos servicios. Las nuevas versiones pueden generar problemas de compatibilidad con las versiones anteriores. Las aplicaciones requieren más conexiones de red, lo que significa más oportunidades de problemas de latencia y conectividad. Un enfoque de DevOps (como se describe a continuación) puede solucionar muchos de estos problemas, pero la adopción de DevOps tiene sus propios retos.

No obstante, estos retos no impiden que los no usuarios adopten el uso de microservicios, o que los usuarios aumenten sus compromisos de microservicios. Los datos de una reciente encuesta de IBM revelan que el 56 % de los no usuarios actuales probablemente o muy probablemente adoptarán microservicios en los próximos dos años, y que el 78 % de los usuarios actuales de microservicios es muy probable que aumenten el tiempo, el dinero y el esfuerzo que han invertido en los microservicios.

Aunque casi cualquier herramienta o lenguaje moderno puede utilizarse en una arquitectura de microservicios, hay varias herramientas básicas que se han convertido en esenciales y que definen los límites de los microservicios:

Contenedores, Docker y Kubernetes

Uno de los elementos clave de un microservicio es que, por lo general, es bastante pequeño (no hay una cantidad arbitraria de código que determine si algo es o no es un microservicio, pero "micro" está incluido por algo en el nombre).

Cuando Docker dio inicio a la era moderna de los contenedores en 2013, también introdujo el modelo de cálculo que se asociaría más estrechamente con los microservicios. Como los contenedores individuales no tienen la sobrecarga de su propio sistema operativo, son más pequeños y más ligeros que las máquinas virtuales tradicionales, además pueden activarse y desactivarse más rápidamente, lo que les convierte en la solución perfecta para los servicios de peso más ligero y pequeños que se encuentran en las arquitecturas de microservicios.

Con la proliferación de servicios y contenedores, la orquestación y la gestión de grandes grupos de contenedores se convirtió rápidamente en uno de los retos clave. Kubernetes, una plataforma de orquestación de contenedores de código abierto, ha surgido como una de las soluciones de orquestación más populares porque hace su trabajo muy bien.

Pasarelas de API

Los microservicios a menudo se comunican a través de una API, especialmente cuando se establece el estado por primera vez. Si bien es cierto que los clientes y los servicios pueden comunicarse entre sí directamente, las pasarelas de API suelen ser una capa intermedia útil, especialmente a medida que el número de servicios crece con el tiempo en una aplicación. Una pasarela de API actúa como proxy inverso para los clientes ya que direcciona las solicitudes, distribuye en abanico las solicitudes en varios servicios y proporciona seguridad y autenticación adicionales.

Existen varias tecnologías que pueden utilizarse para implementar pasarelas de API, por ejemplo, las plataformas de gestión de API, pero si la arquitectura de microservicios se está implementando mediante contenedores y Kubernetes, la pasarela se suele implementar con Ingress o, más recientemente, Istio.

Mensajería y transmisión de sucesos

Aunque la práctica recomendada sería el diseño de servicios sin estado, el estado existe y los servicios deben tenerlo en cuenta. Asimismo, aunque una llamada de API es a menudo una forma eficaz de establecer inicialmente el estado de un determinado servicio, no es una manera particularmente eficaz de mantenerse al día. El enfoque "¿Hemos llegado ya?" de sondeo constante para mantener los servicios actualizados no resulta práctico.

En su lugar, es necesario acoplar las llamadas de API de establecimiento de estado con la mensajería o la transmisión de sucesos, para que los servicios puedan emitir cambios de estado y otras partes interesadas puedan escuchar esos cambios y realizar ajustes en consecuencia. Es probable que este trabajo sea más adecuado para un intermediario de mensajes de uso general, pero hay casos en los que una plataforma de transmisión de sucesos como, por ejemplo, Apache Kafka, puede ser una buena solución. Asimismo, la combinación de microservicios con desarrolladores de arquitectura basada en sucesos puede crear sistemas distribuidos, altamente escalables, tolerantes a errores y ampliables que pueden consumir y procesar grandes cantidades de sucesos o información en tiempo real.

Sin servidor

Las arquitecturas sin servidor llevan algunos de los patrones básicos de cloud y microservicios a su conclusión lógica. En el caso de las arquitecturas sin servidor, la unidad de ejecución no es solo un pequeño servicio, sino una función, que a menudo puede estar formada por unas pocas líneas de código. La línea que separa una función sin servidor de un microservicio es difusa, pero normalmente se entiende que las funciones son incluso más pequeñas que un microservicio.

El punto en común de las arquitecturas sin servidor y las plataformas de funciones como servicio (FaaS) con los microservicios es que ambas están interesadas en crear unidades más pequeñas de despliegue y un escalado preciso según demanda.

Los microservicios no son necesariamente relevantes para cloud computing de manera exclusiva, pero hay varias razones importantes por las que suelen ir juntos, razones que van más allá de que los microservicios sean un estilo de arquitectura popular para las nuevas aplicaciones y que el cloud sea un destino popular de alojamiento para nuevas aplicaciones.

Entre los principales beneficios de la arquitectura de microservicios se encuentran las ventajas económicas y de uso asociadas con el despliegue y escalado individual de componentes. Aunque estos beneficios también están presentes en cierta medida en la infraestructura local, la combinación de componentes pequeños y escalables de manera independiente con una infraestructura de pago por uso según demanda es donde reside la verdadera optimización de costes.

En segundo lugar, otro de los principales beneficios, y quizás más importante, es que cada componente individual puede adoptar la pila más adecuada para su trabajo específico. La proliferación de pilas puede aumentar significativamente la complejidad y generar una sobrecarga cuando gestiona su propia infraestructura, pero el consumo de la pila de soporte como servicios en cloud puede minimizar drásticamente los retos de gestión. Dicho de otra manera, aunque no es imposible desplegar su propia infraestructura de microservicios, no se recomienda, especialmente si está empezando.

En las arquitecturas de microservicios, hay muchos patrones de diseño, comunicación e integración comunes y útiles, que permiten abordar algunos de los retos y oportunidades más comunes, por ejemplo:

Patrón de Backend-for-frontend (BFF). Este patrón inserta una capa entre la experiencia del usuario y los recursos que invoca dicha experiencia. Por ejemplo, una aplicación utilizada en un escritorio tendrá diferentes límites de tamaño de pantalla, visualización y rendimiento que un dispositivo móvil. El patrón BFF permite a los desarrolladores crear y dar soporte a un tipo de programa de fondo por interfaz de usuario utilizando las mejores opciones para esa interfaz, en lugar de intentar dar soporte a un programa de fondo genérico que funcione con cualquier interfaz, pero que pueda afectar negativamente al rendimiento de frontend.

Patrones de entidad y agregados. Una entidad es un objeto distinguido por su identidad. Por ejemplo, en un sitio de comercio electrónico, un objeto de producto puede distinguirse por nombre de producto, tipo y precio. Un agregado es una colección de entidades relacionadas que deben tratarse como una unidad. Por lo tanto, para el sitio de comercio electrónico, un pedido será una colección (un agregado) de productos (entidades) ordenados por comprador. Estos patrones se utilizan para clasificar los datos de forma significativa.

Patrones de descubrimiento de servicios. Estas aplicaciones y servicios de ayuda se encuentran entre sí. En una arquitectura de microservicios, las instancias de servicio cambian dinámicamente debido al escalado, las actualizaciones, la anomalía de servicio e incluso la terminación del servicio. Estos patrones proporcionan mecanismos de descubrimiento para gestionar esta transitoriedad. El equilibrio de carga puede utilizar patrones de descubrimiento de servicios utilizando comprobaciones de estado y anomalías de servicio como desencadenantes para reequilibrar el tráfico.

Patrones de microservicios de adaptador. Piense en los patrones de adaptador como en los adaptadores de enchufes que utiliza al viajar a otro país. La finalidad de los patrones de adaptador es ayudar a convertir relaciones entre clases u objetos que de otro modo son incompatibles. Una aplicación que se basa en API de terceros puede necesitar utilizar un patrón de adaptador para garantizar que la aplicación y las API puedan comunicarse.

Patrón de aplicación Strangler. Estos patrones permiten gestionar la refactorización de una aplicación monolítica en aplicaciones de microservicios. El nombre Strangler (estrangulador) hace referencia a cómo una vid (microservicios) estrangula lentamente y con el tiempo un árbol (una aplicación monolítica).

Puede obtener más información sobre estos patrones en "Cómo utilizar patrones de desarrollo con los microservicios (parte 4)". IBM Developer también proporciona mucha información si desea aprender otros patrones de código de microservicios.

Aunque hay muchos patrones para aplicar bien los microservicios, hay un número igualmente grande de patrones que pueden crear problemas rápidamente para cualquier equipo de desarrollo. Algunos de ellos, reformulados como "noes", son los siguientes:

La primera regla de los microservicios es "no crear microservicios". O, más precisamente, no empezar con los microservicios. Los microservicios son una forma de gestionar la complejidad una vez que las aplicaciones se han vuelto demasiado grandes y difíciles de actualizar y mantener. Solo cuando sienta que la dificultad y la complejidad de las aplicaciones monolíticas son relevantes será recomendable considerar cómo puede refactorizar esa aplicación en servicios más pequeños. Hasta que no sienta esa dificultad, ni siquiera tiene realmente un monolito que necesite refactorización.

No haga microservicios sin DevOps o servicios de cloud. La creación de microservicios significa construir sistemas distribuidos, y los sistemas distribuidos son complejos (y especialmente complejos si se toman decisiones que aumentan su complejidad). Si intenta aplicar microservicios sin un a) despliegue adecuado y una automatización de la supervisión, o b) servicios cloud gestionados para dar soporte a su infraestructura heterogénea en constante expansión, está buscando problemas innecesarios. Ahórrese esos problemas y dedique su tiempo a preocuparse por el estado. 

No aplique demasiados microservicios creándolos demasiado pequeños. si se excede con el "micro" de microservicios, podría generar fácilmente una sobrecarga y una complejidad que no compensen los beneficios generales de una arquitectura de microservicios. Es mejor inclinarse por servicios más grandes y solo dividirlos cuando comiencen a desarrollar características que los microservicios puedan resolver, es decir, que cada vez sea más difícil y lento desplegar cambios, que un modelo de datos común se esté volviendo demasiado complejo o que diferentes partes del servicio tengan diferentes requisitos de carga/escala.

No convierta los microservicios en SOA. Los microservicios y la arquitectura orientada a servicios (SOA) a menudo se confunden entre sí, dado que en su nivel más básico ambos están interesados en crear componentes individuales reutilizables que puedan consumir otras aplicaciones. La diferencia entre los microservicios y SOA es que los proyectos de microservicios suelen implicar la refactorización de una aplicación para que sea más fácil de gestionar, mientras que SOA cambia la forma en la que los servicios de TI trabajan en toda la empresa. Un proyecto de microservicios que se transforme en un proyecto SOA probablemente cederá bajo su propio peso.

No intente ser Netflix. Netflix fue uno de los pioneros de la arquitectura de microservicios al crear y gestionar una aplicación que englobaba un tercio de todo el tráfico de Internet, una especie de tormenta perfecta que les obligaba a crear una gran cantidad de código personalizado y servicios que son innecesarios para la aplicación media. Se recomienda empezar a un ritmo que pueda manejar, evitar la complejidad y utilizar tantas herramientas predefinidas como sea posible.

Si está preparado para obtener más información sobre cómo utilizar microservicios, o si necesita desarrollar sus conocimientos sobre microservicios, pruebe uno de estos tutoriales:

• Introducción a los microservicios
  
  
• Laboratorio rápido: Crear microservicios de aplicaciones web altamente escalables con Node.js
  
  
• Cómo empezar con los microservicios Java utilizando Spring Boot y Cloudant
  
  
• Crear, ejecutar y desplegar microservicios Spring en cinco minutos
  
  
• Microservicios, SOA y API: ¿amigos o enemigos?