La aplicação de la paradoja de Teseo
El estudio de la filosofía, al menos en el pasado, ha implicado plantear preguntas que, a primera vista, parecen irrelevantes. Al fin y al cabo, ¿es realmente tan importante saber “si un barco que ha sido restaurado sustituyendo cada una de sus piezas de madera” sigue siendo el mismo barco? Ésa es la pregunta que Plutarco planteó en la Vida de Teseo. y posteriormente se conoció como la paradoja de Teseo. En términos más generales, pregunta si un objeto al que se le han reemplazado todos sus componentes sigue siendo fundamentalmente el mismo . ( Barco de Teseo, Wikipedia )
Podríamos preguntar lo mismo de los microservicios que, cuando se aplican a aplicações monolíticas existentes, buscan esencialmente restaurar la aplicação reemplazando funciones con servicios complementarios. Las funciones son pequeñas (o deberían serlo) por diseño, y por eso se aplica el término “micro” a los servicios desacoplados resultantes. Las diferencias entre ambos se pueden ver en términos de comunicación. En una aplicação monolítica, las funciones se invocan haciendo referencia a una dirección específica en la memoria. En una aplicação basada en microservicios, las funciones (servicios) se invocan haciendo referencia a una dirección IP específica en la red.
Conceptualmente, ambos son iguales, y solo difieren en el mecanismo de invocación de componentes funcionales individuales. Un diagrama resultante mostraría esencialmente poca diferencia, excepto que la “caja” del monolito es un solo servidor y la “caja” de los microservicios es todo el centro de datos. Uno utiliza direccionamiento localizado, el otro direccionamiento de red. El código para cada una de estas funciones podría ser exactamente el mismo, como la madera del barco de Teseo.
Pero sus funciones comerciales siguen siendo consistentes y, de hecho, si hemos descompuesto correctamente la aplicação, el usuario no debería ver ninguna diferencia perceptible entre los dos. Se podría argumentar que, desde la perspectiva del pasajero del barco de Teseo, no hay diferencia entre ambos. Ni debería haberlo.
Pero los filósofos tienden a profundizar más y, como ellos, también debemos hacerlo nosotros, porque la diferencia entre una aplicação monolítica y una basada en microservicios es, de hecho, bastante importante para las operaciones.
La complejización de las operaciones de red
Los microservicios simplifican muchos aspectos del proceso de desarrollo de aplicação , pero al hacerlo crean una gran complejidad operativa. La cantidad de conexiones de red entre las distintas partes de una aplicação basada en microservicios requiere necesariamente una sobrecarga asociada a la gestión de las distintas características de red requeridas: Direcciones IP, VLAN, tablas NAT y más. La escalabilidad también se convierte en un desafío que incluso Dijkstra podría encontrar frustrante, ya que la ubicación de los microservicios y el servicio de equilibrio de carga tienen un impacto muy real en el rendimiento en función de cuántos segmentos de la red se deben atravesar.
De repente se requieren políticas adicionales, ya que las políticas de seguridad aplicables a un servicio que accede directamente a una fuente de datos confidencial no son las que son necesarias para proteger otro servicio que administra preferencias o estados de sesión. La red resultante de políticas de microseguridad ciertamente proporciona muchos de los mismos beneficios que los propios microservicios, es decir, un control más detallado y una especie de simplicidad elegante, pero al mismo tiempo se convierte en una pesadilla operativa ya que las políticas deben moverse repentinamente con los servicios, donde sea que puedan aparecer en la arquitectura.
La implementación también se vuelve de repente exponencialmente más difícil, como pasar de un simple baile de pasos de caja al más complicado flamenco, con muchos más pasos y mucho más movimiento en la pista de baile (centro de datos). La orquestación y la automatización se convierten en un requisito para garantizar la consistencia y la previsibilidad necesarias para mover todas las piezas a su lugar en el momento adecuado.
Los responsables de proporcionar estos servicios de red y seguridad para las aplicações deben reconocer que el barco no es el mismo, sin importar cuál sea la vista desde cincuenta mil pies. Suena simple: una aplicação se reemplaza simplemente por diez servicios. ¡Listo! La aplicación ha sido recreada, igual que el barco de Teseo. Pero desde el punto de vista operativo este barco no es el mismo en absoluto. Las uniones (integración) en el nuevo barco son completamente diferentes, lo que puede cambiar la fricción creada contra el mar (red) y tender a hacer que el barco navegue más lentamente.
Los microservicios aún son emergentes. No están conquistando el mundo (todavía), pero es importante reconocer que no es tan simple como derribar el barco de Teseo y reconstruirlo. Los equipos de operaciones de servicios de red y seguridad deben adoptar la perspectiva del filósofo en lugar de la del pasajero (usuario) porque el impacto en la red y en la seguridad es muy, muy diferente.