Microservicios

  • Por
Breve descripción del concepto de microservicios, su procedencia y los motivos por los que es una arquitectura interesante para el estado actual de la tecnología.

Microservicios es un término acuñado por Martin Fowler para denominar un tipo de arquitectura de aplicación que nos ofrece diversas ventajas muy representativas en la actualidad.

Si buscas un poco por microservicios o microservices encontrarás fácilmente un documento de James Lewis y Martin Fowler que explica con detalle este tipo de arquitectura. Los propios autores la definen como un "estilo de arquitectura en el que el desarrollo de una única aplicación se realiza mediante un conjunto de pequeños servicios, cada uno de ellos ejecutándose en su propio proceso y comunicando mediante mecanismos ligeros, habitualmente como un recurso API accedido mediante HTTP.

Muy probablemente si has formado parte del equipo de desarrollo de algún proyecto avanzado ya estés familiarizado con esta arquitectura, aunque quizás aún no le hayas puesto nombre. En este artículo resumiremos, no ya la implementación de una arquitectura de microservicios, que es algo abierto que puedes resolver de muchas maneras y usando un stack de tecnologías muy diverso, sino más bien los motivos por los que grandes proyectos y profesionales están decantándose por este tipo de arquitectura.

Monolíticas Vs Microservicios

Como venimos apuntando anteriormente, en la actualidad existen unas necesidades marcantes en el mundo del desarrollo, definidas por empresas, startups y el mercado en general: Desarrollos ligeros, con poco coste, rápidos de producir y capaces de salir al mercado para crecer en la medida de las necesidades de los usuarios.

Esas necesidades se pueden resolver con diversas filosofías, metodologías etc. pero en cuanto a arquitectura de aplicaciones ahora se está apuntando hacia los "microservicios".

Los microservicios se contraponen a la filosofía tradicional de arquitectura de aplicación. Hasta hace poco lo habitual era tener una aplicación con un gran núcleo, capaz de hacer todo tipo de cosas que fueran necesarias para la operativa de una empresa, negocio o perfil profesional. Ese tipo de aplicaciones se conocen generalmente con el término "monolíticas". Básicamente son aplicaciones grandes, con desarrollos pesados y costosos, donde no existen facilidades de adaptación a las necesidades cambiantes de los proyectos actuales.

Como las aplicaciones monolíticas no se adaptan bien a las demandas del mercado, estamos pasando a una etapa en la que, en lugar de construir una aplicación capaz de hacer muchas cosas, estamos comenzando a construir diversas pequeñas aplicaciones capaces de desarrollar únicamente tareas más concretas, que colaboran entre sí para realizar un propósito común.

Al final la solución alcanzada es la misma, pero en lugar de hacer una única aplicación, la tendencia actual es la de realizar una suite de pequeñas aplicaciones capaces de trabajar en conjunto para resolver pequeños problemas.

Libertad para la elección de tecnologías

En el anterior marco de las aplicaciones monolíticas no había mucha posibilidad de elección de tecnologías, ya que éstas vienen marcadas por el stack actual. Es decir, si se deseaba realizar una nueva funcionalidad en una aplicación, simplemente existe la obligación de respetar aquellas tecnologías con las que se está trabajando.

Lo normal en estos casos es crear una nueva versión de la gran aplicación que ahora tenga una nueva funcionalidad requerida, obviamente usando los mismos lenguajes y recursos que ya se usaban. Sin embargo, la realidad es que las tecnologías cambian, aparecen otras nuevas capaces de aportar diversas mejoras. Tampoco existe una única tecnología que sea la mejor para resolver todo tipo de problemas.

En los microservicios tienes la libertad deescoger la tecnología que vas a usar en cada uno de los pequeños servicios que forma una aplicación. Esto no solamente beneficia al proyecto en si, capaz de tomar lo mejor de cada tecnología en cada servicio, sino también a los equipos de desarrollo, que son capaces de usar aquellas tecnologías con las que se sienten cómodos y no aquellas que les imponen, o simplemente escoger aquella que se adapta mejor a las necesidades que tienen que resolver.

Escalabilidad y desacoplamiento

Dos de las características más importantes de cualquier software de calidad también tienen maximizada su presencia en arquitecturas de microservicios, por varios motivos.

En aplicaciones monolíticas, donde tenemos un único núcleo, de manera natural se produce un acoplamiento mayor entre sus distintas partes, es decir, dependen más entre sí, de modo que los cambios en una parte suelen repercutir más en otras partes que en Microservicios.

Si tenemos varios servicios pequeños más independientes, podemos desmontar cualquier servicio, cambiarlo y volverlo a montar sin que esto afecte a otros servicios. En realidad los servicios comunican entre ellos para realizar tareas mayores, pero con que se respete los términos de esas comunicaciones es suficiente para que sigan colaborando a pesar de sus cambios.

En cuanto a escalabilidad la mejora es fundamental. En aplicaciones monolíticas se escala generalmente replicando el servidor de aplicaciones completo. Pero no siempre ocurre que todas las partes de la aplicación están saturadas y necesitando la replicación. En microservicios si un servicio se satura, simplemente se necesita replicar ese pequeño servicio que estaba dando problemas. O si se levanta un nuevo servidor de aplicaciones se puede elegir qué servicios replicar porque sean los que lo estén necesitando.

Otra cosa interesante en microservicios es que el mantenimiento en la aplicación se puede realizar de manera individual por servicios. Si una parte de tu aplicación cambia, necesitas una nueva funcionalidad o reparar un bug, no necesitas hacer un despliegue de toda una macro-aplicación, sino simplemente del servicio en cuestión que había que actualizar.

Conclusión

Los microservicios son una alternativa útil y ágil para el desarrollo de una aplicación. Tiene diversas ventajas, la principal es que es capaz de adaptarse mejor a todo tipo de situaciones y sacar lo mejor de la tecnología en cada caso.

A partir de aquí entrarían en consideración diversos puntos, como las características de arquitecturas microservicio, capas, modelos de comunicación, etc. Seguro que encontrarás mucho material en el mencionado post de Microservicios de Martin Fowler.

Autor

Miguel Angel Alvarez

Miguel es fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Comenzó en el mundo del desarrollo web en el año 1997, transformando su hobby en su trabajo.

Compartir

Comentarios

jhons_rawson

27/1/2016
Diferencias con los webservices y ejemplo prácticos recomendables.
Que diferencian a los Microservicios de los Webservices ?
A modo de ejemplo, los webservices de tipo restfull son consideradores microservicios ?
y las Api provistas por las redes sociales también ?

Por lo que he visto, se pueden implementar los microservicios
mediante múltiples lenguages de programación, para iniciarse en el tema,
con que lenguage recomendarían hacerlo ?

Yeray

13/2/2016
Re: Diferencias entre Microservicios y Webservices
Hola jhons_rawson,
creo que soy uno de esos desarrolladores que ya usaba estos "Microservicios" pero sin ponerle nombre y voy a contestar a tu pregunta desde mi experiencia:
Un "microservicio" puede ser un webservice. Como decían en el artículo es independiente de la tecnología. El webservice sería una forma de implementarlo, pero también podría ser simplemente una aplicación corriendo en segundo plano que está en local con la base de datos "principal" y se conecta para realizar ciertas operaciones. También puedes encontrarte con webservices que sean demasiado amplios y complejos y no encajen en la definición de microservicio. Al final el webservice es la tecnología y el microservicio la arquitectura.