Pouvez-vous ignorer la résilience lors de la création d'applications cloud natives ?

Samar Abbas de Temporal pense que les développeurs ne devraient même pas avoir à penser à perdre leur état. Il n'y a que ces exécutions durables qui n'échouent jamais.

Si vous utilisez des outils de traitement de texte depuis longtemps, vous vous souvenez de l'action réflexive d'appuyer sur le raccourci clavier "enregistrer" - la peur de perdre votre travail, de jurer à haute voix et de déplorer le travail incroyable que vous venez de perdre.

Avec les outils modernes (pensez à Google Docs), cette inquiétude ne se pose même pas. Au milieu d'un mot et le courant s'éteint ? Aucun problème. Tout est sauvegardé dans l'état où vous l'avez laissé et vous pouvez passer à autre chose.

Samar Abbas et son équipe du moteur d'orchestration de flux de travail Temporal souhaitent intégrer ce concept au flux de travail de votre entreprise. Vous fournissez la logique métier et ils gèrent toutes les parties qui nécessitent une expertise spécialisée comme la persistance et la résilience.

Temporal a été fondé en 2019 par Abbas et son collègue Maxim Fateev alors qu'ils étaient chez Uber. Ils avaient créé une plate-forme de développement pour la société d'applications d'appel de voitures appelée "Cadence". Il s'agit d'une évolution de la plate-forme AWS Simple Workflow Service que le duo a aidé à développer lorsqu'ils étaient collègues chez Amazon au milieu des années 2000. Des dizaines de services et d'applications Uber ont adopté Cadence .

Abbas et Fateev sont partis pour co-fonder Temporal et construire le projet de successeur du moteur de workflow tolérant aux pannes de Cadence. Au cours des trois années qui ont suivi, la société a connu un solide succès, avec des sociétés comme Netflix, Instacart et d'autres utilisant le code logiciel open source de Temporal. Plus tôt cette année, la société a obtenu un tour de table de série B de 103 millions de dollars qui a porté sa valorisation à 1,5 milliard de dollars.

J'ai récemment eu une conversation avec Abbas (vous pouvez tout regarder ) sur la façon dont lui et Fateev ont construit leur entreprise extrêmement réussie. (Ses mots ci-dessous sont édités pour plus de clarté et de longueur).

D'Uber à Temporel

En 2015, Uber a ouvert un bureau à Seattle, et j'ai rejoint leur équipe d'ingénieurs. Moi et Max [le co-fondateur de Temporal Maxim Fateev] nous sommes retrouvés chez Uber à un mois d'intervalle. Le projet clé sur lequel nous avons travaillé ensemble était Cadence.

Chez Uber, les ingénieurs ont passé beaucoup de temps à assembler des files d'attente de bas niveau, des bases de données et des minuteurs durables pour renforcer la résilience de leurs applications.

C'est ce que nous essayions de résoudre avec un système comme Cadence, où nous fournissions une abstraction de haut niveau qui était toujours basée sur du code, mais nous avons retiré certaines classes de pannes des plaques des ingénieurs et les avons résolues sous la plate-forme pour permettre aux ingénieurs pour se concentrer sur la logique métier de l'application, plutôt que sur le renforcement de la résilience.

Cela a été un succès au sein d'Uber et, comme c'était open source, nous avons commencé à voir beaucoup d'adoptions externes pour la technologie. Donc en 2019, Max et moi avons décidé de sauter le pas et de lancer Temporal, car nous voulions vraiment nous concentrer sur l'adoption externe de la technologie.

L'expérience temporelle du développeur

Les gens décrivent parfois Temporal comme un moteur de flux de travail ou décrivent ses fonctionnalités, mais la principale proposition de valeur pour nous est la productivité des développeurs : la rapidité avec laquelle les développeurs peuvent créer des applications et les faire fonctionner en production sans passer des semaines ou des mois à tester toutes sortes de situations de défaillance qui peuvent se produire dans un environnement cloud natif.

Ainsi, la façon dont nous pensons aux expériences des développeurs ne se limite pas aux aspects essentiels de ce que la technologie a à offrir ; nous couvrons l'ensemble du cycle de vie du développement logiciel dès le départ, comment les développeurs construisent leur application. Par exemple, de nombreux moteurs de flux de travail utilisent généralement la voie du langage spécifique au domaine (DSL). Nous sommes tous basés sur le code. Nous savons que les développeurs aiment écrire du code, et nous voulons qu'ils écrivent du code, mais enlevez simplement une certaine classe de préoccupations, comme comment rendre ce code résilient si une infrastructure sous-jacente tombe en panne, ou comment rendre le code résilient lorsqu'un problème de réseau se produit .

Quand et comment le temporel fait-il la différence ?

Les transferts d'argent sont l'un des principaux cas d'utilisation où Temporal est utilisé assez fréquemment. Si vous transférez de l'argent d'un compte à un autre compte, généralement du point de vue de l'utilisateur, oui, je débite du compte A, puis je crédite le compte B. Mais la majorité du temps de développement logiciel est consacrée aux défaillances du système entre ces deux appels. Et c'est là que les ingénieurs passent essentiellement tout leur temps.

C'est un exemple de quand un système comme Temporal peut aider beaucoup - il semble même magique. Nous entendons souvent cette question : que se passe-t-il si ma candidature échoue à ce stade ?

Notre réponse à cette question est : Les flux de travail n'échouent jamais (Chez Temporal, nous appelons la primitive que nous construisons un « flux de travail ».) Ensuite, c'est l'un de ces moments où un interrupteur s'allume. Nous avons commencé à appeler cela une « exécution durable », où à un niveau élevé, ce que nous fournissons est ceci : vos exécutions sont complètement durables. Ils n'échouent jamais.

L'impact sur l'entreprise d'un flux de travail avec état « Fault Oblivious »

Dans les années 90, quand j'étais à l'école, nous avions l'habitude de taper tous nos devoirs dans Microsoft Word. Vous avez pris l'habitude d'enregistrer votre document chaque fois que vous écrivez quelques modifications. Pourtant, il y avait une certaine classe de pannes, comme le disque dur qui tombait en panne, où vous perdiez tout votre travail.

Maintenant, avec Google Docs, les enfants ne peuvent même plus s'y retrouver. Il n'y a même plus de bouton "enregistrer". Nous pensons qu'il existe une classe d'applications avec état qui sont encore dans cette ère des années 1990, où plus de 80 % du code concerne la gestion des défaillances de l'infrastructure pour renforcer la résilience des applications avec état. Chaque fois qu'un événement se produit, vous chargez cet état, appliquez cet événement, effectuez un ensemble d'actions, puis stockez cet état. C'est là que va la majorité de l'ingénierie : comment rendre cela fiable, rapide et performant et le protéger contre toutes sortes de pannes et de corruptions.

Les développeurs ne devraient même pas avoir à penser qu'ils peuvent un jour perdre leur état. Il n'y a que ces exécutions durables qui n'échouent jamais. Et je pense que cela va complètement changer la façon dont les ingénieurs perçoivent les systèmes natifs du cloud.

Pourquoi gérer Apache Cassandra ?

Mon co-fondateur Max et moi venons d'une formation dans la construction de systèmes de messagerie et d'intergiciels. Faire fonctionner des systèmes de stockage n'est pas notre force. Ainsi, lorsque nous avons démarré l'entreprise avec seulement deux personnes, un objectif clé pour nous était de capitaliser sur nos forces pour offrir la meilleure expérience de développement aux utilisateurs de Temporal. Temporal a un composant serveur et des SDK clients, que la plupart des développeurs utilisent pour créer des applications. Mais comment les gens peuvent-ils faire fonctionner ces serveurs avec un minimum de surcharge opérationnelle ? C'est là que se trouve la majorité des frais généraux liés à l'exécution de Temporal.

Nous avons un modèle de persistance enfichable ; nous prenons en charge Apache Cassandra , MySQL et Postgres en tant qu'adaptateurs enfichables. Cassandra est l'un des adaptateurs qui présente de très bonnes caractéristiques d'évolutivité. Une proposition de valeur clé pour nos utilisateurs est le fait qu'ils exécutent des applications critiques et que la fiabilité est l'élément clé qu'ils recherchent. Nous ne prenons donc pas cela à la légère lorsque nous introduisons une nouvelle dépendance dans le giron temporel. Nous avons effectué plus d'un mois d'évaluation pour toutes sortes d'options de persistance. C'était DataStax Astra DB haut la main.

Certaines bases de données gagnent sur certaines fonctionnalités, d'autres gagnent sur d'autres fonctionnalités. Mais il ne s'agissait même pas de technologie dans ce cas ; il s'agit des gens. Nous pensons que les bugs et les échecs font partie de la vie. Tout dépend de la façon dont vous réagissez en cas de panne. Et c'est là que nous pensons qu'Astra DB gagne. Il existe de nombreuses similitudes avec la manière dont DataStax traite ses clients et les types de relations qu'ils établissent lorsqu'il s'agit d'opérationnaliser leurs bases de données. Et cela nous a donné confiance qu'il s'agit d'une dépendance dans laquelle nous voulons investir pour une partie centrale du système.

Je ne pense pas que nous en serions là où nous en sommes aujourd'hui si une technologie comme Astra n'était pas là pour que nous puissions la capitaliser et la développer. Des choses comme simplement opérationnaliser Cassandra et faire des choses seules seraient un projet d'au moins un an, et cela ne fait même pas partie de notre force principale. Pour une entreprise comme la nôtre, où la proposition de valeur clé est la fiabilité, si nous ne pouvons pas trouver un moyen de gérer et d'opérationnaliser votre stockage de manière fiable, nous n'avons pas d'activité.

Inscrivez-vous maintenant à Cassandra Forward, un événement virtuel gratuit de deux heures qui se déroule le 14 mars et plonge dans tout ce qui concerne Apache Cassandra.

Par Patrick McFadin, DataStax

Patrick McFadin est co-auteur du livre d'O'Reilly "Managing Cloud Native Data on Kubernetes". Il travaille actuellement chez DataStax dans les relations avec les développeurs et en tant que contributeur au projet Apache Cassandra. Patrick a travaillé comme évangéliste en chef pour Apache Cassandra (il est également un nouveau committer Cassandra !) et comme consultant pour DataStax, où il a passé un bon moment à construire certains des plus grands déploiements en production.