Monolítico vs. Arquitectura de microservicios: Los microservicios están de moda, los monolitos están de vuelta.

Para aquellos de ustedes que sienten que están sufriendo un grave caso de déjà vu técnico, no están equivocados. Esta es la misma situación en la que se encontraba la arquitectura orientada a servicios (SOA) alrededor de 2009, cuando Anne Thomas Manes declaró su muerte . El enlace lleva a un comentario de David Linthicum sobre la publicación de Manes porque el original parece haber sido devorado por Internet.

Ahora bien, Manes estaba siendo hiperbólico y algo sarcástico porque, como bien sabemos, la arquitectura orientada a servicios no murió. Resucitó con bastante rapidez como microservicios y, a juzgar por las lamentaciones de Internet, los diseñadores aún no han aprendido el importante papel que desempeña “la red” en el rendimiento.

La SOA “murió” por dos razones:

1. Estándares basados en XML, complejos y competitivos, que hicieron que las arquitecturas fueran excesivamente complejas. Nadie recuerda con cariño WSDL, SOAP y UDDI. Nadie.
2. Las leyes de la física y los estándares de interoperabilidad restringen el intercambio de paquetes de red a la velocidad de la luz y a 1500 bytes.

Quizá hayamos superado el primer desafío, pero ¿el segundo? La única respuesta a la segunda pregunta ha sido y sigue siendo un delicado equilibrio entre la granularidad del diseño del servicio y una buena comprensión del tiempo que lleva transferir datos entre servicios.

La transferencia de datos no es gratuita. Toma tiempo No existe tal cosa como “costo cero” cuando se trata de comunicaciones entre servicios. Está el tiempo que lleva colocar un paquete en el cable, luego transferirlo, luego sacarlo del paquete y, finalmente, procesarlo. Y no olvidemos que las comunicaciones de transporte también llevan tiempo. Abrir sockets y aceptar solicitudes tampoco es gratuito, como tampoco lo es el tiempo que lleva serializar y deserializar cargas útiles en algo que el servicio pueda procesar.

Ahora, multiplica ese costo total por la cantidad de servicios que intentas utilizar.

Cuanto más granular sea el diseño de su sistema, más tiempo llevará procesar una solicitud. En otras palabras, el tiempo total para procesar una solicitud depende de la cantidad de servicios por los que debe pasar esa solicitud.

¿Mayor granularidad? Mayor tiempo de procesamiento. ¿Más servicios? Mayor congestión en la red, lo que en última instancia aumenta el tiempo de procesamiento ya que las tarjetas y los dispositivos de red intentan ordenar los paquetes y exigen retransmisión.

Por lo tanto, al igual que SOA, los microservicios pueden verse y sufrirán por patrones de diseño que dependen de demasiada granularidad.

Amazon eligió un monolito para reemplazar sus microservicios. Eso significa que para su caso de uso, una arquitectura monolítica era la mejor opción. ¿Significa eso que los microservicios están muertos?

No. En lugar de ello, deberíamos extraer dos puntos clave:

• En primer lugar, deberíamos seguir el ejemplo de Amazon y ser más deliberados y reflexivos sobre cómo diseñamos sistemas que dependen de servicios y asegurarnos de entender las implicaciones que tiene para el rendimiento dividir las tareas entre demasiados servicios pequeños.
• En segundo lugar, debemos recordar que los monolitos son una opción viable para la arquitectura de aplicação . Hay una razón por la que el 60% de la cartera de aplicaciones empresariales está compuesta por aplicações basadas en una arquitectura “tradicional” , y el 16% de las organizaciones no tienen planes de retirarlas.

Las arquitecturas de aplicação no son buenas ni malas y tampoco son apropiadas para todos los casos de uso. Las organizaciones necesitan dar un paso atrás y considerar cuidadosamente qué es lo que están tratando de lograr y qué arquitectura podría satisfacer mejor esa necesidad en lugar de elegir la arquitectura más “moderna” porque, bueno, está de moda.

Cuando decimos que el futuro es TI híbrida, nos referimos a más que solo una combinación de implementaciones locales y de múltiples nubes. También queremos decir que la cartera de aplicaciones empresariales seguirá siendo híbrida (una mezcla de tradicionales y modernas) en el futuro previsible. Es por eso que el portafolio de F5 continúa brindando soporte a todas las aplicações, ya sea en instalaciones locales o en la nube pública, o en ambas.