Cuando desarrollamos una aplicación, tenemos diferentes arquitecturas. En este caso, vamos a hablar sobre las diferencias entre un monolito y un micro servicio. ¡Comenzamos!

Toda aplicación nace con la finalidad de resolver un problema, es decir, para satisfacer una necesidad que tiene un cliente. Al principio, este problema suele ser sencillo y paulatinamente, empieza a aumentar en complejidad transformando nuestro problema inicial (la necesidad inicial) en la mayoría de casos a un conjunto de problemas.

Por ello, vamos a hablar de la manera en la que gestionamos este conjunto de problemas y que nos dará como resultante múltiples tipos de arquitecturas. Aunque nosotros hablaremos nos centraremos en dos. Que son:

  • Monolito: hace referencia al software que combina en una misma plataforma la capa IU (User Interface), la capa de Bussines (capa de negocio) y la capa de datos (BBDD, JSON…). Por tanto, podríamos imaginar un monolito como un contenedor que alberga toda la información de la aplicación. Este contendor puede ser grande o pequeño dependiendo de lo grande que sea el problema a resolver. Pero eso sí, será un único bloque (o cubo).
  • Microservicios: consiste en subdividir un monolito en múltiples partes, estas partes, son más conocidas microservicios y se comunican entre si para tener el mismo resultante que el monolito. Por tanto, podríamos imaginar estos contenedores (bloques o cubos), como unos contenedores de dimensiones más reducidas pero que se acoplan entre si y eso provoca que se convierta lo mismo que el monolito pero de una forma más organizada.

De una forma más gráfica, lo podríamos ver como:

¿Cuándo usar micro servicios? ¿Y cuándo usar monolitos?

Normalmente, en los inicios de un desarrollo de software comenzamos escogiendo un único lenguaje de programación y de BBDD. Pero a medida de que la aplicación va creciendo o coge un gran nivel de usuarios esto puede suponer un problema. En muchos de casos, hasta nos vemos en la obligación heredar funcionalidades ya desarrolladas. Ahora, a parte de mantener la aplicación, debemos de mantener también la funcionalidad que acabamos de heredar.

Hasta ahora, la mayoría de aplicaciones se creaban bajo el concepto que bautizo Martin Fowler como «MonolitFirst». Para una vez la aplicación aumentada en lo referente a la complejidad, partirla (desacoplarla) en micro servicios. Usualmente lo que se hacía es crear un monolito para dar valor a un cliente en un plazo corto y poco a poco ir desengranandolo que al pasarla a micro servicios. Esto nos supone que tendremos una experiencia previa del proyecto pero a su vez tiene la contra de que estamos retrabajando dos veces. Yo soy partidaria de escoger micro servicios de inicio. Bajo ese lema salió el famoso dicho que ya se ha vuelvo una filosofía en lo referente micro servicios, el: “Haz una cosa y hazla bien”

Uno de los principales motivos por los que decanto la lanza hacía el desarrollo de aplicaciones con arquitectura de microservicios y no hacía la de monolitos es el que al dividir la aplicación en múltiples partes, es mucho más fácil realizar desarrollos sobre partes más pequeñas. Esto facilita que varios desarrollados trabajen independientemente sobre partes del código de una manera más sencilla. Como decían los romanos, divide y vencerás. Estás partes (las subdivisiones del monolito) a partir de ahora para nosotros recibirán el nombre de servicios, que realmente proviene de la subdivisión del monolito (un servicio gigante) y de ahí su nombre de microservicios (ya que son algo más pequeños).

Los microservicios una arquitectura para gigantes

¿Os imagináis como sería el monolito de Google? Yo me imagino un contenedor muy similar al de la imagen (o más grande aún), En cambio, si utilizamos micro servicios, aunque la magnitud del conjunto de los contenedores no desaparece, me da la sensación de un mejor orden, de organización, de subdivisión. Si a veces nos cuesta encontrar un calcetín en un cajón, imaginaros en un monolito de tal envergadura…

Después de este ejemplo, ¿Cual creéis que es la más indicada para desarrollos de grandes magnitudes? Si habéis respuesto micro servicios, sin mucho pestañear es que habéis entendido, tenéis el 10. Y aprovecho para deciros que ¡A las compañías gigantes les encantan!

Los micro servicios a nivel de creación de APIS están obteniendo tanta fama, digo yo que por algo será. Algunos de los nombres de algunas de estas grandes compañías que implementan los micro servicios son Netflix, Amazon, Ebay, Paypal, Spotify…

Beneficios y desventajas de utilizar una arquitectura monolítica:

Algunas de las características de los monolitos aunque no todas son:

  • Son ideales para administrar aplicaciones pequeñas que tienen una escasa complejidad.
  • Cada vez que queremos desplegar de nuevo la aplicación debemos relanzar todo el sistema de nuevo.
  • Si una aplicación desarrollada con una arquitectura monolítica falla, aunque no tiene porque si se controla con excepciones, pero si pasase, caería toda la aplicación.
  • Al principio son fáciles de desarrollar pero conforme su código y su complejidad va aumentando se vuelven más enrevesadas de entender debido a la complejidad de su código, que en el mejor de los casos únicamente está dividido en funciones. 

Beneficios de utilizar una arquitectura de micro servicios:

Algunos de las características de los micro servicios aunque no todas son:

  • Cada micro servicio realiza una funcionalidad en específica.
  • Cada parte de un micro servicio se debe comunicar con el resto de partes de esta arquitectura.
  • Las comunicaciones en la arquitectura de micro servicios se realizan mediante al protocolo HTTP.
  • Podemos utilizar múltiples lenguajes de programación y de BBDD.
  • Son ideales para administrar aplicaciones medianas o gigantes que tienen una gran complejidad.
  • Si un micro servicio falla, solo fallará ese micro servicio el resto de la aplicación es independiente y no dejará de funcionar. Esto le otorga cierto grado de resistencia a fallos que trata de conservar la integridad del resto de la aplicación permitiendo a los otros micro servicios que sigan funcionando, si uno micro servicio falla,  nuestra aplicación sigue funcionando lo que se traduce en que nuestra aplicación es más segura ya que tiene un mejor aislamiento de fallos.

Espero que os hayáis familiarizado algo más con este mundo de los micro servicios. En próximas clases hablaremos más detalladamente de ellos. Saludos javer@s!