Você pode ignorar a resiliência ao criar aplicativos nativos da nuvem?

Samar Abbas, da Temporal, acredita que os desenvolvedores não deveriam nem pensar em perder o estado. Existem apenas essas execuções duráveis que nunca falham.

Se você usa ferramentas de processamento de texto há muito tempo, lembra-se da ação reflexiva de pressionar o atalho de teclado "salvar" - o medo de perder seu trabalho, xingar em voz alta e lamentar o trabalho incrível que acabou de perder.

Com ferramentas modernas (pense no Google Docs), essa preocupação nem surge. No meio de uma palavra e a energia acaba? Sem problemas. Tudo é salvo no estado em que você deixou e você pode seguir em frente.

Samar Abbas e sua equipe no mecanismo de orquestração de fluxo de trabalho Temporal desejam trazer esse conceito para o fluxo de trabalho de sua empresa. Você fornece a lógica de negócios e eles lidam com todas as partes que exigem conhecimento especializado, como persistência e resiliência.

A Temporal foi fundada em 2019 por Abbas e seu colega Maxim Fateev enquanto eles estavam na Uber. Eles criaram uma plataforma de desenvolvimento para a empresa de aplicativos de transporte de carros apelidada de “Cadence”. É uma evolução da plataforma AWS Simple Workflow Service que a dupla ajudou a desenvolver quando eram colegas da Amazon em meados dos anos 2000. Dezenas de serviços e aplicativos da Uber adotaram o Cadence .

Abbas e Fateev saíram para co-fundar a Temporal e construir o projeto sucessor do mecanismo de fluxo de trabalho tolerante a falhas para a Cadence. Nos três anos seguintes, a empresa teve um sucesso sólido, com empresas como Netflix, Instacart e outras usando o código de software de código aberto da Temporal. No início deste ano, a empresa garantiu uma rodada da Série B de US$ 103 milhões, que colocou sua avaliação em US$ 1,5 bilhão.

Recentemente, conversei com Abbas (você pode assistir tudo ) sobre como ele e Fateev construíram seu empreendimento de grande sucesso. (Suas palavras abaixo são editadas para maior clareza e extensão).

De Uber para Temporal

Em 2015, a Uber abriu um escritório em Seattle e entrei para a equipe de engenharia. Eu e Max [co-fundador da Temporal, Maxim Fateev] acabamos no Uber com um mês de diferença. O principal projeto em que trabalhamos juntos foi o Cadence.

Na Uber, os engenheiros passaram muito tempo juntando filas de baixo nível, bancos de dados e cronômetros duráveis para criar resiliência em seus aplicativos.

Isso é o que estávamos tentando resolver com um sistema como o Cadence, onde fornecemos abstração de alto nível que ainda era baseada em código, mas tiramos certas classes de falhas das placas dos engenheiros e as resolvemos sob a plataforma para permitir que os engenheiros para se concentrar na lógica de negócios do aplicativo, em vez de criar resiliência.

Isso deu certo dentro do Uber e, como era de código aberto, começamos a ver muita adoção externa da tecnologia. Então, em 2019, eu e Max decidimos dar o salto e iniciar a Temporal, porque realmente queríamos focar na adoção externa da tecnologia.

A experiência do desenvolvedor temporal

As pessoas às vezes descrevem o Temporal como um mecanismo de fluxo de trabalho ou descrevem seus recursos, mas a principal proposta de valor para nós é a produtividade do desenvolvedor: a rapidez com que os desenvolvedores podem criar aplicativos e colocá-los em execução na produção sem passar semanas ou meses testando todos os tipos de situações de falha que podem acontecem em um ambiente nativo de nuvem.

Portanto, a maneira como pensamos sobre as experiências do desenvolvedor não é apenas os aspectos centrais do que a tecnologia tem a oferecer; cobrimos todo o ciclo de vida de desenvolvimento de software desde o início, como os desenvolvedores estão construindo seu aplicativo. Por exemplo, muitos mecanismos de fluxo de trabalho normalmente seguem a rota de linguagem específica de domínio (DSL). Somos todos baseados em código. Sabemos que os desenvolvedores gostam de escrever código e queremos que eles escrevam código, mas apenas elimine uma certa classe de preocupações, como como tornar esse código resiliente se alguma infraestrutura subjacente cair ou como tornar o código resiliente quando ocorrer um problema de rede .

Quando e como o temporal faz a diferença?

As transferências de dinheiro são um dos principais casos de uso em que o Temporal é usado com bastante frequência. Se você está transferindo dinheiro de uma conta para outra, normalmente do ponto de vista do usuário, sim, eu debito da conta A e depois credito na conta B. Mas a maior parte do tempo de desenvolvimento de software é gasto em falhas do sistema entre essas duas chamadas. E é aqui que basicamente os engenheiros estão gastando todo tipo de tempo.

Este é um exemplo de quando um sistema como o Temporal pode ajudar muito - até parece mágico. Ouvimos muito esta pergunta: O que acontece se meu aplicativo falhar neste ponto?

Nossa resposta a essa pergunta é: Fluxos de trabalho nunca falham (Na Temporal, chamamos o primitivo que estamos construindo de “fluxo de trabalho”.) Então é um daqueles momentos em que uma luz se acende. Começamos a chamar isso de “execução durável”, onde, em alto nível, o que fornecemos é o seguinte: Suas execuções são totalmente duráveis. Eles nunca falham.

O impacto nos negócios de um fluxo de trabalho com monitoramento de estado 'falha alheio'

Nos anos 90, quando eu estava na escola, costumávamos digitar todas as nossas tarefas no Microsoft Word. Você adquiriu o hábito de salvar seu documento toda vez que fazia algumas edições. No entanto, houve uma certa classe de falhas, como a falha do disco rígido, em que você perdeu todo o seu trabalho.

Agora, com o Google Docs, as crianças nem se identificam com isso. Não há nem mesmo um botão “salvar” mais. Acreditamos que existe uma classe de aplicativos com estado que ainda existe na década de 1990, em que mais de 80% do código trata de lidar com falhas de infraestrutura para criar resiliência para aplicativos com estado. Toda vez que um evento acontece, você carrega esse estado, aplica esse evento, executa várias ações e armazena esse estado de volta. É para onde a maior parte da engenharia se dirige: como tornar isso confiável, rápido e eficiente e protegê-lo contra todos os tipos de falhas e corrupções.

Os desenvolvedores nem deveriam pensar que podem perder seu estado. Existem apenas essas execuções duráveis que nunca falham. E acho que vai mudar completamente a forma como os engenheiros pensam sobre os sistemas nativos da nuvem.

Por que Apache Cassandra Gerenciado?

Meu cofundador Max e eu temos experiência na construção de sistemas de mensagens e middleware. Executar sistemas de armazenamento não é o nosso forte. Portanto, quando começamos a empresa com apenas duas pessoas, um objetivo importante para nós era capitalizar nossos pontos fortes para fornecer a melhor experiência de desenvolvedor para os usuários do Temporal. O Temporal tem um componente de servidor e SDKs de cliente, que a maioria dos desenvolvedores usa para criar aplicativos. Mas como as pessoas podem executar esses servidores com sobrecarga operacional mínima? É aqui que está a maior parte da sobrecarga para executar o Temporal.

Temos um modelo de persistência conectável; oferecemos suporte a Apache Cassandra , MySQL e Postgres como adaptadores conectáveis. Cassandra é um dos adaptadores que possui características de escalabilidade muito boas. Uma proposta de valor importante para nossos usuários é o fato de que eles estão executando aplicativos de missão crítica , e a confiabilidade é o principal que eles procuram. Portanto, não consideramos isso levianamente quando trazemos uma nova dependência para o redil temporal. Executamos mais de um mês de avaliação para todos os tipos de opções de persistência. Era o DataStax Astra DB .

Alguns bancos de dados ganham em alguns recursos, outros ganham em outros recursos. Mas nem era sobre a tecnologia neste caso; é sobre as pessoas. Acreditamos que erros e falhas fazem parte da vida. É tudo sobre como você responde quando uma interrupção está acontecendo. E é aqui que acreditamos que o Astra DB vence. Existem muitas semelhanças com a forma como a DataStax trata seus clientes e os tipos de relacionamento que eles constroem quando se trata de operacionalizar seus bancos de dados. E isso nos deu confiança de que essa é uma dependência na qual queremos investir para uma parte central do sistema.

Não acho que estaríamos onde estamos hoje se uma tecnologia como a Astra não existisse para capitalizarmos e construirmos sobre ela. Coisas como apenas operacionalizar Cassandra e fazer as coisas “feitas” sozinhas seriam um projeto de pelo menos um ano, e isso nem faz parte de nossa força principal. Para uma empresa como a nossa, em que a principal proposta de valor é a confiabilidade, se não conseguirmos descobrir uma maneira de executar e operacionalizar seu armazenamento de maneira confiável, não temos um negócio.

Registre-se agora para o Cassandra Forward, um evento virtual gratuito de duas horas que acontecerá em 14 de março e aborda tudo sobre o Apache Cassandra.

Por Patrick McFadin, DataStax

Patrick McFadin é coautor do livro da O'Reilly 'Managing Cloud Native Data on Kubernetes'. Ele atualmente trabalha na DataStax em relações com desenvolvedores e como colaborador do projeto Apache Cassandra. Patrick trabalhou como evangelista-chefe para Apache Cassandra (ele também é um committer de Cassandra recém-formado!) e como consultor para DataStax, onde se divertiu muito construindo algumas das maiores implantações em produção.