Para el usuario final, se supone que los servicios nativos de la nube simplifican la vida y brindan más agilidad. Aún así, para el desarrollador, pueden hacer la vida mucho más compleja debido a su naturaleza distribuida. Entre los desafíos está la gestión del estado, algo que es algo natural para los profesionales de las bases de datos, pero no necesariamente para los desarrolladores de aplicaciones. Ese es el desafío que asumió Temporal Technologies, proporcionando la administración estatal detrás de la orquestación de microservicios, retomando donde terminan las mallas de servicio como Istio.
Es comprensible que probablemente nunca antes haya oído hablar de esta empresa de dos años, ya que su escaso sitio web hace que parezca que la empresa todavía está en sigilo. No está claro si Temporal tiene una gran base de clientes pagos; enumera una serie de logotipos como Datadog, Netflix, Instacart, Qualtrics, Box y otros, pero son usuarios de la tecnología de código abierto, no clientes que pagan. Si profundiza lo suficiente, puede encontrar documentación real. Pero en caso de que olvidemos mencionarlo, Temporal acaba de asegurar una ronda de Serie B de $ 103 millones.
Específicamente, Temporal señala una tarea limitada: administrar el estado de los microservicios. Dado que los microservicios generalmente se activan en entornos de nube altamente distribuidos, administrar el estado es similar a coreografiar transacciones en una base de datos sin maestro o con varios maestros. Ese es un desafío que, por ejemplo, los desarrolladores de Cassandra conocen muy bien. En las bases de datos, se trata de equilibrar la coherencia transaccional con la disponibilidad de escritura. En el nivel de aplicación o microservicios, se trata de disponibilidad, donde la cadena (en este caso, los nodos de cómputo que alojan microservicios específicos) solo será tan fuerte como su eslabón más débil.
Administrar el estado, que compromete las transacciones, es clave para garantizar que los resultados sean válidos y actuales y para evitar que el sistema, ya sea una base de datos o una aplicación, se bloquee. Por ejemplo, cuando retira efectivo de un cajero automático de un banco, la gestión del estado es esencial para garantizar que la transacción solo se complete cuando se haya realizado el cargo en la cuenta.
La necesidad de administrar el estado en entornos distribuidos es muy crítica porque, con múltiples partes móviles, existe una probabilidad decente de que una de ellas falle. Por lo tanto, cualquier cosa que se ejecute en Internet o en la nube requiere ingeniería para fallas, lo que implica conmutación por error y soluciones alternativas, de modo que la interrupción de un solo nodo no bloquee toda la aplicación o el servicio.
En el mundo de las bases de datos, los motores de estado normalmente estaban integrados; si inicia una base de datos, no tiene que escribir su propio motor de estado. En el mundo de AppDev, ese no es el caso; los desarrolladores normalmente tenían que escribir los suyos propios.
Para los microservicios, las organizaciones normalmente tendrían que escribir sus propias máquinas de estado además del código de aplicación. Para el usuario temporal Checkr, un servicio que proporciona verificaciones de antecedentes de empleados en línea, un flujo de trabajo típico a menudo implica una serie de 50 a 60 pasos automatizados y manuales (cada uno de ellos microservicios) que recuperan datos de una amplia variedad de fuentes externas. Había muchas colas de Kafka para hacer malabarismos, escribir datos en múltiples bases de datos de destino y luego escribir lógica para fusionar los resultados. Con un servidor temporal, podrían centrarse en la aplicación en lugar del motor de estado.
Temporal caracteriza su solución como «la plataforma de código abierto para orquestar aplicaciones de misión crítica altamente confiables a escala». Para los microservicios, a primera vista, eso se parece mucho a lo que hacen las mallas de servicios. Pero las mallas de servicio operan a nivel de infraestructura, haciendo conexiones y asegurando la conmutación por error si los nodos fallan. Por el contrario, Temporal se centra en el nivel de la aplicación y, más específicamente, en comprobar si se ejecuta el código o la lógica en el microservicio y, en caso contrario, en la gestión de soluciones temporales que se ocupan de las dependencias en cascada.
El problema que soluciona Temporal con los microservicios no es nada nuevo. Como se señaló anteriormente, en el mundo AppDev, los motores de estado deben escribirse como código externo o agruparse como parte de algún marco. Ese es exactamente el problema que las aplicaciones de Internet también tuvieron que resolver porque la web no tenía estado, y eso es lo que condujo a middleware dedicado, o servidores de aplicaciones, para manejar el proceso con aplicaciones web, donde el lenguaje popular como Java tenía sus propios mecanismos para administrar el estado. .
Con Temporal, la historia se repite en el nivel de microservicios. Su tecnología de servidor de administración estatal proviene de un proyecto de código abierto de cinco años que fue el resultado del trabajo desarrollado en Uber. Está construido alrededor de Temporal Server, una plataforma de orquestación de microservicios que se ubica entre los servidores de cómputo y el código fuente ejecutable.
Eso genera la pregunta obvia: si los microservicios son de naturaleza distribuida y se ejecutan en entornos informáticos distribuidos, ¿un servidor de orquestación central no frustrará el propósito al introducir un único punto de falla? La respuesta es una nueva función de replicación asincrónica de clústeres múltiples «experimental» que debería proporcionar las capacidades de conmutación por error necesarias. Cuando se trata de garantías transaccionales para microservicios, el futuro aún es un trabajo en progreso.
