La idea de los microservicios no es nueva. Las personas mayores pueden haber trabajado con
EJB en su apogeo. De qué se trata, ya
Samuel Colt utilizó un enfoque modular para fabricar sus revólveres. Las piezas estándar y hechas con precisión de sus pistolas eran intercambiables, lo que simplificaba enormemente tanto la producción como el mantenimiento. Entonces, ¿por qué la infraestructura no debería ser modular?
No hay objeciones fundamentales a esto, y la idea misma yace en la superficie. Pero el tema de los microservicios se ha vuelto popular relativamente recientemente. Y hay una razón para esto.
Durante mucho tiempo, el mantenimiento de la infraestructura siguió siendo una tarea laboriosa y bastante especializada. Solo los administradores expertos pueden implementar cualquier caché o cola en la infraestructura. Que cada parte de la aplicación tenía su propia infraestructura, y no había dudas: ¿quién servirá a todo este zoológico?
Pero la tecnología de virtualización, los contenedores y las herramientas de administración de configuración de infraestructura han recorrido un largo camino. Y ahora desplegar una infraestructura independiente para un servicio de aplicaciones separado se ha vuelto aún más fácil y económico que impulsar todos los servicios en una infraestructura común. Progreso!
La aplicación se divide convenientemente en partes independientes, incluso por razones organizativas. En este caso, la interacción entre las partes se lleva a cabo a través de una u otra API. La conclusión es el servicio. A partir de aquí comienza el proceso de dividir la aplicación en macro servicios, metroservicios, microservicios, nanoservicios, picoservicios y funciones lambda de una sola línea en Amazon.
Parece que lo que podría salir mal aquí?
Por desgracia, dividir la aplicación en partes no es gratis. En primer lugar, el costo de soportar la API dentro de la infraestructura aumenta.
Supongamos que una aplicación necesita trabajar con archivos. Una tarea tipica. Se asigna un microservicio que implementa la infraestructura de almacenamiento de archivos; proporciona dos operaciones: lectura y escritura. Y sin cambios significativos en la API, dicho servicio puede crecer desde una interfaz a una carpeta en un disco local a una infraestructura de centro de datos distribuida geográficamente. El escenario perfecto.
Pero, ¿qué sucede si la aplicación se divide en servicios de tal manera que las líneas impares de la lógica de negocios terminan en un servicio y las líneas pares en otro? Esta separación no solo ralentizará significativamente la aplicación, ya que ahora, en lugar de llamar directamente al método, se producirá comunicación de red, por lo que la API entre servicios cambiará con tanta frecuencia que se ajustará a la versión larga para el número de versión de API.
Todo esto es, por supuesto, una exageración. Sin embargo, da una idea clara de las posibles consecuencias negativas. Una aplicación creada de esta manera es extremadamente costosa de desarrollar.
Antes de dividir la aplicación en partes, se deben considerar dos aspectos.
El primero ¿Con qué frecuencia interactuarán estos componentes en una sola operación? ¿Es posible que por cada acción tenga que realizar cientos, si no miles de llamadas de red? Esto puede matar el rendimiento de la aplicación.
Segunda. ¿Con qué frecuencia cambiará la API entre componentes? Si la historia de git muestra que la API cambiará todos los días, es probable que el costo de su soporte sea prohibitivo. Esto puede matar la productividad del desarrollo.
Sin embargo, con la división correcta de la aplicación en servicios, puede obtener beneficios significativos. Es solo que estos servicios no tienen que ser micro.