¿Se puede ignorar la resiliencia al crear aplicaciones nativas en la nube?

Samar Abbas de Temporal cree que los desarrolladores no deberían tener que pensar siquiera en perder el estado. Solo hay estas ejecuciones duraderas que nunca fallan.

Si ha usado herramientas de procesamiento de textos durante mucho tiempo, recordará la acción refleja de presionar el atajo de teclado "guardar": el miedo de perder su trabajo, maldecir en voz alta y lamentarse por el increíble trabajo que acaba de perder.

Con las herramientas modernas (piense en Google Docs), esta preocupación ni siquiera surge. ¿En medio de una palabra y se va la luz? Ningún problema. Todo se guarda en el estado en que lo dejaste y puedes seguir adelante.

Samar Abbas y su equipo en el motor de orquestación de flujo de trabajo Temporal quieren llevar este concepto al flujo de trabajo de su empresa. Usted proporciona la lógica comercial y ellos manejan todas las partes que requieren experiencia especializada, como la persistencia y la resiliencia.

Temporal fue fundada en 2019 por Abbas y su colega Maxim Fateev mientras estaban en Uber. Habían creado una plataforma de desarrollo para la empresa de aplicaciones de transporte de vehículos llamada "Cadence". Es una evolución de la plataforma AWS Simple Workflow Service que el dúo ayudó a desarrollar cuando eran colegas en Amazon a mediados de la década de 2000. Docenas de servicios y aplicaciones de Uber adoptaron Cadence .

Abbas y Fateev se fueron para cofundar Temporal y construir el proyecto sucesor de Cadence del motor de flujo de trabajo tolerante a fallas. En los tres años transcurridos desde entonces, la empresa ha disfrutado de un sólido éxito, con empresas como Netflix, Instacart y otras que utilizan el código de software de fuente abierta de Temporal. A principios de este año, la compañía aseguró una ronda Serie B de $ 103 millones que colocó su valoración en $ 1.5 mil millones.

Hace poco tuve una conversación con Abbas (puedes verlo completo ) sobre cómo él y Fateev construyeron su exitosa empresa. (Sus palabras a continuación están editadas para mayor claridad y extensión).

De Uber a Temporal

En 2015, Uber abrió una oficina en Seattle y me uní a su equipo de ingeniería. Max [cofundador temporal, Maxim Fateev] y yo terminamos en Uber con un mes de diferencia. El proyecto clave en el que trabajamos juntos fue Cadence.

En Uber, los ingenieros dedicaron mucho tiempo a unir colas de bajo nivel, bases de datos y temporizadores duraderos para generar resiliencia en sus aplicaciones.

Esto es lo que tratábamos de resolver con un sistema como Cadence, en el que brindamos abstracción de alto nivel que todavía estaba basada en código, pero eliminamos ciertas clases de fallas de las placas de los ingenieros y las resolvimos debajo de la plataforma para permitir que los ingenieros para centrarse en la lógica empresarial de la aplicación, en lugar de crear resiliencia.

Eso tuvo éxito dentro de Uber y, como era de código abierto, comenzamos a ver mucha adopción externa de la tecnología. Entonces, en 2019, Max y yo decidimos dar el salto y comenzamos Temporal, porque realmente queríamos centrarnos en la adopción externa de la tecnología.

La experiencia del desarrollador temporal

Las personas a veces describen a Temporal como un motor de flujo de trabajo o describen sus funciones, pero la propuesta de valor clave para nosotros es la productividad de los desarrolladores: qué tan rápido pueden los desarrolladores crear aplicaciones y hacer que se ejecuten en producción sin pasar semanas o meses probando todo tipo de situaciones de falla que pueden suceder en un entorno nativo de la nube.

Entonces, la forma en que pensamos sobre las experiencias de los desarrolladores no es solo los aspectos centrales de lo que la tecnología tiene para ofrecer; Cubrimos todo el ciclo de vida del desarrollo de software desde el principio, cómo los desarrolladores construyen su aplicación. Por ejemplo, muchos motores de flujo de trabajo suelen seguir la ruta del lenguaje específico del dominio (DSL). Todos estamos basados en código. Sabemos que a los desarrolladores les gusta escribir código, y queremos que escriban código, pero simplemente elimine una cierta clase de preocupaciones, como cómo hacer que ese código sea resistente si alguna infraestructura subyacente falla, o cómo hacer que el código sea resistente cuando ocurre una falla en la red. .

¿Cuándo y cómo marca la diferencia lo temporal?

Las transferencias de dinero son uno de los casos de uso clave en los que Temporal se usa con bastante frecuencia. Si está moviendo dinero de una cuenta a otra, generalmente desde la perspectiva del usuario, sí, cargo de la cuenta A y luego abono a la cuenta B. Pero la mayor parte del tiempo de desarrollo de software se dedica a fallas del sistema entre esas dos llamadas. Y aquí es donde básicamente los ingenieros pasan todo tipo de tiempo.

Este es un ejemplo de cuando un sistema como Temporal puede ayudar mucho, incluso se siente mágico. Escuchamos mucho esta pregunta: ¿Qué sucede si mi aplicación falla en este punto?

Nuestra respuesta a esa pregunta es: los flujos de trabajo nunca fallan (en Temporal, llamamos a la primitiva que estamos construyendo "flujo de trabajo"). Entonces es uno de esos momentos en los que se enciende una luz. Hemos comenzado a llamar a esto "ejecución duradera", donde en un nivel alto lo que ofrecemos es esto: sus ejecuciones son completamente duraderas. Nunca fallan.

El impacto comercial de un flujo de trabajo con estado 'falta de atención'

En los años 90, cuando estaba en la escuela, solíamos escribir todas nuestras tareas en Microsoft Word. Tienes el hábito de guardar tu documento cada vez que escribes algunas ediciones. Sin embargo, había una cierta clase de fallas, como que el disco duro fallara, donde perdía todo su trabajo.

Ahora, con Google Docs, los niños ni siquiera pueden relacionarse con esto. Ya ni siquiera hay un botón de "guardar". Creemos que hay una clase de aplicaciones con estado que aún se encuentran en esta era de la década de 1990, en la que más del 80 % del código trata sobre el manejo de fallas de la infraestructura para generar resiliencia para las aplicaciones con estado. Cada vez que ocurre un evento, carga ese estado, aplica ese evento, realiza un montón de acciones y luego vuelve a almacenar ese estado. Aquí es donde se dirige la mayoría de la ingeniería: cómo hacer que sea confiable, rápido y eficaz y protegerlo contra todo tipo de fallas y corrupciones.

Los desarrolladores ni siquiera deberían tener que pensar que alguna vez pueden perder su estado. Solo hay estas ejecuciones duraderas que nunca fallan. Y creo que va a cambiar por completo la forma en que los ingenieros piensan sobre los sistemas nativos de la nube.

¿Por qué administrar Apache Cassandra?

Mi cofundador Max y yo venimos de la creación de sistemas de mensajería y middleware. Ejecutar sistemas de almacenamiento no es nuestro punto fuerte. Entonces, cuando comenzamos la empresa como solo dos personas, un objetivo clave para nosotros era capitalizar nuestras fortalezas para brindar la mejor experiencia de desarrollador para los usuarios de Temporal. Temporal tiene un componente de servidor y SDK de cliente, que la mayoría de los desarrolladores utilizan para crear aplicaciones. Pero, ¿cómo pueden las personas ejecutar esos servidores con una sobrecarga operativa mínima? Aquí es donde está la mayor parte de los gastos generales para ejecutar Temporal.

Tenemos un modelo de persistencia conectable; Admitimos Apache Cassandra , MySQL y Postgres como adaptadores enchufables. Cassandra es uno de los adaptadores que tiene muy buenas características de escalabilidad. Una propuesta de valor clave para nuestros usuarios es el hecho de que ejecutan aplicaciones de misión crítica , y la confiabilidad es lo principal que buscan. Así que no lo tomamos a la ligera cuando traemos una nueva dependencia al redil Temporal. Realizamos más de un mes de evaluación para todo tipo de opciones de persistencia. Era DataStax Astra DB sin duda alguna.

Algunas bases de datos ganan en algunas características, otras ganan en otras características. Pero ni siquiera se trataba de la tecnología en este caso; se trata de la gente. Creemos que los errores y las fallas son parte de la vida. Se trata de cómo responde cuando ocurre una interrupción. Y aquí es donde creemos que Astra DB gana. Hay tantas similitudes con la forma en que DataStax trata a sus clientes y los tipos de relaciones que construyen cuando se trata de poner en funcionamiento sus bases de datos. Y eso nos dio la confianza de que esta es una dependencia en la que queremos invertir para una parte central del sistema.

No creo que estaríamos en el lugar donde estamos hoy si una tecnología como Astra no estuviera allí para que podamos capitalizar y construir sobre ella. Cosas como simplemente poner en funcionamiento a Cassandra y hacer que las cosas "se hagan" por sí solas sería un proyecto de al menos un año, y eso ni siquiera es parte de nuestra fuerza principal. Para una empresa como la nuestra, donde la propuesta de valor clave es la confiabilidad, si no podemos encontrar una manera de ejecutar y poner en funcionamiento su almacenamiento de manera confiable, no tenemos un negocio.

Regístrese ahora para Cassandra Forward, un evento virtual gratuito de dos horas que tendrá lugar el 14 de marzo y se sumergirá en todo lo relacionado con Apache Cassandra.

Por Patrick McFadin, DataStax

Patrick McFadin es coautor del libro de O'Reilly 'Managing Cloud Native Data on Kubernetes'. Actualmente trabaja en DataStax en relaciones con desarrolladores y como colaborador del proyecto Apache Cassandra. Patrick ha trabajado como jefe de evangelización de Apache Cassandra (¡también es un committer recién nombrado de Cassandra!) y como consultor de DataStax, donde se divirtió mucho creando algunas de las implementaciones más grandes en producción.