Saltar al contenido

Arquitectura de microservicios

Compartir en:

Las arquitecturas de software son una disciplina en constante cambio y que requieren un profundo conocimiento del código, de los problemas con este, y sobre todo de como debe plantearse de manera óptima la construcción de la estructura de una pieza de software que resuelve una serie de necesidades.

Durante muchos años los monolitos de software estructurados de diferente manera (por capas, por norma general) han predominado (y predominan) en el panorama actual, pero dada la cantidad de software existente, la competencia en el sector y la necesidad de escalabilidad, agilidad y modularidad, resurgen con fuerza las arquitecturas basadas en microservicios.

Monolito de Software

Estas arquitecturas se estructuran en pequeñas piezas de software especializado en resolver un número pequeño de problemas, de manera aislada y concreta, frente al tradicional bloque monolítico organizado por capas donde la lógica de empresa gestiona de manera global dentro del bloque.

Arquitectura basada en microservicios

¿Cómo Funciona exactamente los microservicios?

La visión de un aplicativo basado en microservicios es un enfoque arquitectónico de software que aboga por hacer una separación de las responsabilidades de la aplicación en pequeños servicios. Estos servicios se encargan de resolver un problema concreto del global del sistema, de manera independiente, además, generalmente se comunican con otros servicios que completan la funcionalidad total.

Estos servicios no están ligados a ninguna atadura más allá de la comunicación, es decir, son independientes de lenguajes, bases de datos, infraestructura, localización, etc. Nos dan la libertad de seleccionar para cada problema las soluciones óptimas. Además, el sistema adquiere un carácter muy modular donde el intervenir en uno de los servicios focaliza mucho el mantenimiento, facilitando los ciclos de vida del software, y evitando problemas con las demás partes.

El despliegue también es más sencillo, ya que no se debe alterar los microservicios no afectados por los cambios, y se puede adaptar cada servicio a la mejor infraestructura para su cometido, al contrario que los monolitos donde una actualización supone un despliegue completo.

Aunque no todo son ventajas, la coordinación de la funcionalidad de los microservicios puede ser fácil al principio, pero conforme un software crece, también crecen los problemas. El tratar con cientos de servicios enviándose mensajes puede llegar a ser bastante complejo.

La trazabilidad también es un punto negativo, ya que es más complicado atajar problemas o encontrar bugs en una amalgama de pequeños servicios a pleno rendimiento.

Ventajas de los microservicios

  • Dominio especializado: En mi opinión, la modularidad de cada microservicio y la especialización del programa es la gran ventaja de este tipo de arquitecturas. Programas pequeños con dominios controlados son tremendamente fáciles de corregir, probar, testear y mantener.
  • Escalabilidad horizontal y vertical: Cuando no se tiene muy claro el volumen que un software puede llegar a alcanzar, o este tiene picos de trabajo muy variable, los microservicios son tu arquitectura. De manera independiente pueden crecer tanto en número del mismo servicio, tratando los datos, como en potencia de los mismos, de manera casi instantánea gracias a tecnologías de contenedores, orquestadores y los servicios en la nube, algo realmente potente.
  • Crecimiento modular: dado que las funcionalidades están acotadas, el crecimiento del software suele ser más ágil y rápido, además los equipos pueden centrar los esfuerzos en piezas separadas reduciendo los problemas en el desarrollo.
  • Facilidad de pruebas: Como todos sabemos ya, las pruebas son básicas en la calidad de un software, un servicio aislado es muy fácil de testear, y muy fácil de detectar mal funcionamiento en fases tempranas.

Desventajas

  • Complejidad: Esta es en mi opinión el principal hándicap. Un sistema de este tipo requiere programadores experimentados y mucha coordinación.
  • Mayores recursos de computación: al dividir las tareas, también se utilizan más recursos, la versatilidad y el aislamiento tiene un precio, y este se paga en memoria y en tiempo de CPU.
  • Disparidad en tecnologías: esto puede ser una ventaja o un verdadero infierno, desde luego el optar por soluciones especializadas está bien, pero el tener una amalgama de diferentes lenguajes, bases de datos y buses de mensajes no es la mejor solución.
  • Precio de la infraestructura: derivado de la segunda desventaja, la infraestructura es más costosa, y quizás el despliegue inicial algo más complejo.

Conclusión

Bien, entonces ¿esta arquitectura es mejor o peor que los monolitos?, los monolitos funcionan, eso es innegable, ¿Por qué cambiar? Como todo en esta vida todo depende. Las arquitecturas monolíticas son excelentes en ciertos escenarios, y en otros muchos dejan mucho que desear, el análisis del problema es fundamental.

Temas como la cantidad de información, sistema distribuido, usuarios, datos, presupuestos, experiencia y un sinfín de factores influyen en la decisión de implementar o no los microservicios. La profesión del diseño del software siempre alberga muchas más preguntas que respuestas y posiblemente a muchas de estas no se tenga la solución hasta avanzar en el diseño.

En mi opinión, la adaptabilidad de los microservicios y la tremenda escalabilidad las hace perfectas para aplicativos con mucha incertidumbre en el diseño; sin embargo, para diseños clásicos de sistemas más simples y con ideas claras obtenidas en las fases previas quizás un monolito sea más que suficiente y nos ahorre dinero y dolores de cabeza.


Juan Ibero

Inmerso en la Evolución Tecnológica. Ingeniero Informático especializado en la gestión segura de entornos TI e industriales, con un profundo énfasis en seguridad, arquitectura y programación. Siempre aprendiendo, siempre explorando.

Compartir en:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *