Que todo el mundo se calme. Respirad hondo y luego nos adentraremos poco a poco en plena guerra entre los microservicios y los monolitos que se libra en Internet.
Lo esencial:
Amazon publicó recientemente un estudio de caso en el que documentaba su decisión de abandonar los microservicios y adoptar una arquitectura monolítica, alegando una reducción de costes del 90 %. Ese estudio de caso desató en Internet una oleada de comentarios y tuits sarcásticos, enfrentando a los microservicios y a los monolitos en el cuadrilátero tecnológico.
La realidad:
Quienes tengáis la sensación de estar sufriendo un grave déjà vu tecnológico no os equivocáis. Es la misma situación en la que se encontró la arquitectura orientada a servicios (SOA) hacia 2009, cuando Anne Thomas Manes declaró su muerte. El enlace lleva a un comentario de David Linthicum sobre la publicación de Manes, porque parece que el original se lo tragó Internet.
Ahora bien, Manes estaba exagerando y siendo un tanto sarcástica porque, como bien sabemos, la arquitectura orientada a servicios no murió. Resucitó con bastante rapidez en forma de microservicios y, para lamento de Internet, los diseñadores aún no han aprendido hasta qué punto influye «la red» en el rendimiento.
La SOA «murió» por dos razones:
- Estándares rivales y sobrecargados basados en XML que hacían que las arquitecturas fueran excesivamente complejas. Nadie guarda un buen recuerdo de WSDL, SOAP y UDDI. Nadie.
- Las leyes de la física y los estándares de interoperabilidad limitan el intercambio de paquetes de red a la velocidad de la luz y a 1500 bytes.
Puede que hayamos superado el primer reto, pero ¿qué ocurre con el segundo? La única respuesta al segundo ha sido, y sigue siendo, mantener un delicado equilibrio entre la granularidad del diseño de los servicios y una buena comprensión del tiempo que se tarda en transferir datos entre ellos.
Transferir datos no sale gratis. Lleva tiempo. No existe el «coste cero» en las comunicaciones entre servicios. Se necesita tiempo para enviar un paquete por la red, transferirlo, extraer los datos del paquete y, finalmente, procesarlos. Y no hay que olvidar que las comunicaciones de transporte también llevan tiempo. Abrir sockets y aceptar solicitudes tampoco sale gratis, como tampoco el tiempo necesario para serializar y deserializar las cargas útiles en un formato que el servicio pueda procesar.
Ahora, multiplica ese coste total por el número de servicios que intentas utilizar.
Cuanto más granular sea el diseño del sistema, más tiempo se tardará en procesar una solicitud. En otras palabras, el tiempo total necesario para procesar una solicitud depende del número de servicios por los que esta deba pasar.
¿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 de red y los dispositivos intentan ordenar los paquetes y solicitan su retransmisión.
Así pues, al igual que la SOA, los microservicios pueden verse afectados, y de hecho se verán afectados, por patrones de diseño que dependen de una granularidad excesiva.
Amazon optó por un monolito para sustituir sus microservicios. Esto significa que, para su caso de uso, una arquitectura monolítica era la mejor opción. ¿Quiere decir esto que los microservicios han muerto?
No. En su lugar, debemos extraer dos conclusiones clave:
- En primer lugar, deberíamos seguir el ejemplo de Amazon y ser más meticulosos y reflexivos a la hora de diseñar sistemas que dependen de servicios, así como asegurarnos de comprender las repercusiones que tiene para el rendimiento repartir las responsabilidades entre demasiados servicios pequeños.
- En segundo lugar, debemos recordar que los monolitos son una opción viable de arquitectura de aplicaciones. Hay una razón por la que el 60 % de la cartera de aplicaciones de una empresa está compuesta por aplicaciones basadas en una arquitectura «tradicional», y el 16 % de las organizaciones no tiene previsto retirarlas.
Las arquitecturas de aplicaciones no son ni buenas ni malas, ni tampoco resultan adecuadas para todos los casos de uso. Las organizaciones deben tomar cierta distancia y analizar detenidamente qué pretenden conseguir y qué arquitectura podría responder mejor a esa necesidad, en lugar de elegir la arquitectura más «moderna» simplemente porque, bueno, está de moda.
Cuando decimos que el futuro pasa por una TI híbrida, nos referimos a algo más que una combinación de implementaciones multinube y locales. También queremos decir que la cartera de aplicaciones empresariales seguirá siendo híbrida —una combinación de aplicaciones tradicionales y modernas— en el futuro previsible. Por eso, la cartera de F5 sigue siendo compatible con todas las aplicaciones, tanto si se encuentran en las instalaciones como en la nube pública, o en ambas.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.