¿Qué son los microservicios?

Una pequeña introducción

Desde hace tiempo «microservicios» es una palabra de moda en el mundo de la informática, frecuente en ofertas de empleo para consultoras o medianas/grandes empresas. Por tanto, vamos a explicar aquí que son y porque son importantes en el mundo actual.

Como toda historia, debemos entender los orígenes, el pasado, para comprender mejor el presente. Para empezar podemos decir que la historia de la informática es la continua evolución hacia una mayor abstracción y una mayor reutilización del software de tal forma que no perdamos el tiempo reinventando la rueda continuamente.

Al principio fue el bit, la codificación en binario, que pronto se elevó de nivel para tener el ensamblador que ya era un lenguaje más humano, y como esto seguía siendo poco, se inventaron los primeros lenguajes de alto nivel (COBOL, FORTRAN, ALGOL) y el código espagueti que generaba el ensamblador fue evolucionando hacia la programación estructurada (PASCAL, C, MODULA-2), que a su vez en una nueva vuelta de tuerca evoluciono hacia la programación orientada a objetos (C++, Objetive C, Java, Object Pascal).

El tema no quedó la programación orientada a objetos sino que fue paralelo a la así llamada «ingeniería del software» que cubría todo el ciclo de desarrollo, desde la toma de requisitos hasta la implementación final. Nació el modelo de «cascada» (waterfall en inglés) que parecía en su momento muy apropiado pero que poco a poco se demostró ser demasiado rígido cuando los proyectos se volvían grandes, era necesario revisar o adaptar con frecuencia los requisitos y el código que se generaba solía ser muy monolitico e interdependiente.

Nacieron así las metodologías ágiles que pretendían resolver la necesidad de tener gran flexibilidad de adaptación en el cambio de requisitos, validar que el código sea correcto, tener rápidamente versiones en producción.

Al mismo tiempo, la web iba revolucionando todo, dando cada día más importancia a que los servicios estuvieran en internet y los clientes en nuestros ordenadores, tablets, móviles, etc

El nacimiento

Una gran empresa, en este caso Amazon, empezó a darse cuenta de su necesidad creciente de distribuir y poder escalar sus servicios software, asi como poder dividir en módulos (APIs) esos servicios que podían ser implementados con diferentes tecnologías y diferentes equipos de programadores, usando todos un protocolo común para comunicarse.

En 2002 el CTO de Amazon (en aquel momento Allan Vermeulen), envió una circular interna a todos los desarrolladores de la compañía, y asi fue como nacieron los microservicios. Esto era una nueva vuelta de tuerca en el objetivo de abstraer y no reinventar la rueda, pudiendo cada vez reutilizar más componentes software. En la circular, conocida como API Mandate’ (‘Orden API’), decía lo siguiente:

1. Todos los equipos expondrán a partir de ahora sus datos y funcionalidad a través de interfaces de servicio.
2. Los equipos deben comunicarse entre sí a través de estas interfaces.
3. No se permitirá ninguna otra forma de comunicación entre procesos: nada de vinculación directa, ni lecturas directas del depósito de datos de otro equipo, ni modelo de memoria compartida, ni ninguna clase de puertas traseras: la única comunicación permitida será mediante llamadas a la interfaz de servicio a través de la red.
4. No importa qué tecnología utilicéis: HTTP, Corba, Pubsub, protocolos personalizados? da igual.
5. Todas las interfaces de servicio, sin excepción, deberán diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. Sin excepciones.
6. Cualquiera que no haga esto será despedido.

Así fue como Amazon cambio su estilo, su forma de desarrollo interno, sino que fue el germen que origino AWS (Amazon Web Services) un año más tarde, popularizando al resto de grandes empresas con necesidades similares esta forma de resolver los problemas. Otros siguieron su estela (Microsoft con Azure, Google).

Definición de microservicios

Según la definición de James Lewis y Martin Fowler, los microservicios son:

“Una Arquitectura de Microservicios ofrece un enfoque de desarrollar una aplicación como un conjunto de pequeños servicios, mediante un enfoque políglota de programación y con diferente sistemas de almacenamiento, que se ejecutan en su propio proceso y que se comunican entre sí mediante mecanismos ligeros http/api, sin necesitar tener una gestión centralizada de los mismos. Los servicios representan capacidades de negocio y son desplegados de forma independiente.”

Tras haber visto como nacieron y que son los microservicios, voy a poner ahora en los 2 últimos apartados de este artículo, los pros y contras de los dos modelos mencionados, o sea, monolítico frente a microservicios.

Pros y contras del modelo monolítico

Este modelo también tiene sus ventajas, sobre todo en pequeños proyectos, porque como dice la filosofía budista, la virtud está en el medio, es decir, que no tiene sentido dividir en microservicios una pequeña aplicación siendo extremistas e intentando reemplazar totalmente un modelo por otro.

Los contras son:

1. El tiempo invertido en hacer un pequeño cambio y desplegarlo en producción es mayor (y volver a rearrancar),
2. Mayor dificultad de adaptación a nuevos requisitos/necesidades.
3. Mayor complejidad en los pasos de desarrollo, pruebas (probar toda la aplicación), despliegue complicando el control de versiones.
4. Al ser un solo proceso el escalado se dificulta obligando a tener un balanceador y varias instancias.

Pros y contras de los microservicios

Las ventajas que proporcionan son las siguientes:

1. Mejor adaptados a las metodologías ágiles, en un proceso iterativo adaptado a cambios rápidos, asi como facilitando CI/CD (integración continua/despliegue continuo).
2. Bien adaptados para el desarrollo en la nube (cloud).
3. Facilitan el Big Data y el Machine Learning precisamente por su capacidad de «divide y vencerás».
4. Agnósticos del software (distintos equipos pueden implementar sus APIs de microservicios con distintas tecnologías).
5. Mayor facilidad para escalar las necesidades de proceso y por tanto muy apropiados para medianas y grandes empresas.
6. Consolidación de protocolos ligeros como RESTful.
7. Aplicación del «divide y vencerás» dividiendo la aplicación en una serie de servicios independientes entre si y que puede ser mantenidos por distintos equipos de trabajo y distintas tecnológicas (usado lo más conveniente en cada servicio).

El principal inconveniente es que pequeños proyectos pueden dificultar innecesariamente el desarrollo y mantenimiento (si el equipo es pequeño y debe hacerse cargo de servicios hechos con tecnologías que los miembros actuales del equipo no dominan origina un problema añadido).