Qué son Microservicios y ejemplos reales de uso

Microservicios , puede que a muchos no os suene, y por eso queremos que estéis preparados, por lo que vamos hoy con unos cuantos conceptos que os vendrán muy bien para ir entrando en materia.

¿Qué son los microservicios?

La arquitectura de microservicios o microservicios a secas, es un distintivo sistema de desarrollo de software que ha crecido en popularidad en los últimos años. De hecho, a pesar de que su extensión en uso no ha llegado tan allá donde sí lo ha hecho su teoría, muchos desarrolladores están descubriendo cómo esta forma de creación de software favorece el tiempo, rendimiento y estabilidad de sus proyectos.

Gracias a su sencilla escalabilidad , este método de arquitectura se considera especialmente adecuado cuando se tiene que procurar la compatibilidad con un amplio sector de diferentes plataformas (IoT, web, móvil, wearables…) o simplemente cuando no sabemos a ciencia cierta hacia qué tipo de dispositivos estamos orientando nuestro trabajo.

Si bien no existe un estándar o definición formal para los microservicios , hay ciertas características que nos ayudan a identificarlos. Básicamente el desarrollo de un proyecto que se base en este método conforma una aplicación o herramienta mediante la conjunción de diversos servicios independientes que se despliegan según se vayan necesitando . Por tanto, tendremos una aplicación modular a base de “pequeñas piezas”, que podremos ir ampliando o reduciendo a medida que se requiera.

Y la cuestión que muchos se harán es ¿Cómo comunico un servicio con otro? Y es como preguntar ¿Qué ordenador me compro? La respuesta será depende, tanto de nuestras habilidades, como de las preferencias o el sistema que mejor se adapte o nos soliciten… Muchos usan HTTP/REST con JSON o Protobuf, pero como los desarrolladores sois vosotros, usad aquello que mejor consideréis, aunque REST se posiciona en extensión de uso al ser uno de los métodos de integración cuya curva de aprendizaje y uso es increíblemente rápida respecto a otros protocolos.

Ejemplos de Microservicios

No hay mejor forma de conocer el alcance que ha tenido este método de desarrollo que ver quiénes lo han implementado. Multitud de webs que sirven aplicaciones a gran escala han decidido invertir en la evolución hacia los microservicios en vistas de un futuro donde el mantenimiento y escalabilidad de sus productos es mucho más simple, efectivo y rápido. Vamos a destacar algunas de estas compañías, que lo mismo hasta os suenan:

• Netflix : Esta plataforma tiene una arquitectura generalizada que desde hace ya un par de años (coincidiendo con su “boom” en U.S.A.) se pasó a los microservicios para el funcionamiento de sus productos. A diario recibe una media de mil millones de llamadas a sus diferentes servicios (se dice que es responsable del 30% del tráfico de Internet) y es capaz de adaptarse a más de 800 tipos de dispositivos mediante su API de streaming de vídeo, la cual para ofrecer un servicio más estable, por cada solicitud que le pedimos, ésta realiza cinco solicitudes a diferentes servidores para no perder nunca la continuidad de la transmisión.

• Amazon : No soporta tantos dispositivos como Netflix, pero tampoco es que sea fundamental para cubrir su sector. Migró hace tres años a la arquitectura de microservicios siendo una de las primeras grandes compañías que la implementaban en producción. No hay cifra aproximada de la cantidad de solicitudes que pueden recibir a diario, pero no son pocas. Entre éstas encontramos multitud de aplicaciones, las API del servicio web que ofrecen o la propia web de Amazon, cuyos ingenieros reconocen que habría sido imposible sobre la arquitectura monolítica con la que trabajaban previamente.

• Ebay : Cómo no, una de las empresas con mayor visión de futuro, siendo pionera en la adopción de tecnologías como Docker o ésta que nos ocupa. Su aplicación principal comprende varios servicios autónomos, y cada uno ejecutará la lógica propia de cada área funcional que se ofrece a los clientes.

Comprendiendo la Arquitectura de Microservicios

Pero para comprender la arquitectura basada en microservicios, lo mejor es considerar su opuesto, su némesis, la arquitectura monolítica . En ésta, la aplicación se desarrolla como una única unidad que no necesitará de ningún componente externo para funcionar . Por ejemplo, en una aplicación como la que desarrollamos hace unos días en Meteor que cuenta con un lado del cliente y un lado servidor, el “monolito” cliente se encargará de las peticiones HTTP, ejecutar la lógica y recibir/actualizar la información desde la base de datos.

El problema de las aplicaciones monolíticas es que todos los “ciclos de cambio” están vinculados unos a otros , por lo que la más mínima modificación en una remota sección de la app conllevaría a la creación y despliegue de una versión completamente nueva, con el gasto de recursos correspondiente. Por no hablar de si queremos escalar un apartado específico del proyecto o directamente la aplicación al completo; y aquí es donde los desarrolladores han visto el potencial de los microservicios.

Características del Software de microservicios

Como decía no hay un estándar en estas arquitecturas, pero sí que podemos destacar varias características comunes en mayor o menor medida:

1. El software construido en base a microservicios se podrá descomponer en varias partes funcionales independientes . Siendo así, cada uno de estos servicios podrá ser desplegado, modificado y re-desplegado sin comprometer los otros aspectos funcionales de la aplicación; y como resultado en caso de necesitarlo, sólo tendremos que modificar un par de servicios en lugar de redesplegar toda la aplicación al completo nuevamente.
    
2. La forma en la que se organizan los microservicios suele ser en torno a las necesidades, capacidades y prioridades del cliente o negocio en el que se implantará . A diferencia de un entorno monolítico donde cada equipo de trabajo tiene un enfoque específico sobre un apartado de la aplicación, en la arquitectura de microservicios se utilizan módulos multifuncionales, adaptando así un módulo común a todos para que ofrezca un servicio determinado. El ahorro en tiempo de desarrollo es inmenso, por no hablar de la comodidad a la hora de programar tareas de mantenimiento, donde podemos revisar un módulo mientras el resto del equipo de trabajo no ve interrumpida su jornada.
    
3. El funcionamiento del software de microservicios puede parecerse al sistema de trabajo clásico de UNIX (se recibe una petición, se procesa y se genera una respuesta consecuente. Al contrario que los entornos ESB (Enterprise Service Buses, o Bus de servicio empresarial) donde se utilizan equipos para enrutar mensajes, redireccionar tráfico, aplicar reglas de denegación de acceso etc… Se podría decir que la arquitectura de microservicios cuenta con puntos finales “inteligentes” que procesan la información en término y aplican la lógica establecida por el desarrollador.
    
4. La arquitectura de microservicios mantiene un sistema similar a un gobierno descentralizado , donde cada módulo contará por ejemplo con su propia base de datos, en lugar de acudir todos a la misma sobrecargándola así de solicitudes y arriesgándonos a que si falla ésta, todas la aplicación caiga.
    
5. Cuando varios servicios están comunicados entre sí, por lo general contarán con un sistema de aviso y actuación si alguno de éstos servicios llega a fallar (como mostrar una advertencia, enviar un mail a soporte, avisar a los usuarios de un fallo temporal, etc…), filtrando adecuadamente la información destinada a este módulo y favoreciendo la correcta gestión de los recursos entre los módulos funcionales restantes.

Pros / Contras

Conociendo ya qué son los microservicios, sus características principales y algunos ejemplos en los que se han implementado con éxito, os dejo algunos pros y contras de esta tecnología:

Pros:

• Otorga a los desarrolladores libertad de desarrollar y desplegar servicios de forma independiente.
  
• Un microservicio se puede desarrollar con un equipo de trabajo mínimo.
  
• Se pueden usar diferentes lenguajes de programación en diferentes módulos.
  
• Fácil integración y despliegue automático (por ejemplo con Jenkins…).
  
• Fácil de entender y modificar, por lo que la integración de nuevos miembros al equipo de desarrollo será muy rápida.
  
• Los desarrolladores podrán hacer uso de las tecnologías más actuales.
  
• El uso de contenedores hará el desarrollo y despliegue de la app mucho más rápido.
  
• Funcionalidad modular, con lo que la modificación de un módulo no afectará al funcionamiento del resto.
  
• Fácil de escalar e integrar con aplicaciones de terceros.

Contras:

• Las pruebas o testeos pueden resultar complicados debido al despliegue distribuido.
  
• Un gran número de servicios puede dar lugar a grandes bloques de información que gestionar.
  
• Será labor de los desarrolladores lidiar con aspectos como la latencia de la red, tolerancia a fallos, balanceo de carga, cantidad de formatos admitidos, etc…
  
• Sistema distribuido puede llegar a significar doble trabajo.
  
• Si se cuenta con un gran número de servicios, integrarlos y gestionarlos puede resultar muy complejo.
  
• Esta tecnología suele incurrir en un alto consumo de memoria.
  
• Fragmentar una aplicación en diferentes microservicios puede llevar muchas horas de planificación (y casi podría considerarse un arte).

Y si os ha convencido el software basado en microservicios, recordad echarle un vistazo al curso de Microservicios , así como suscribiros y seguirnos en las redes sociales. Un saludo!