Algo está te incomodando?

A jornada única de uma startup, contada pelo CEO

• É incomum uma startup operar em sigilo por 5 anos.
• Queríamos criar um produto surpreendente antes de nos apresentar ao público e, nesse processo, contratamos ótimos talentos, encontramos clientes iniciais e trabalhamos com investidores.
• Embora não seja um caminho natural para uma startup, isso nos permitiu construir muita coisa.

Por que criamos isso

• A Antithesis é uma continuação da história que começou na nossa empresa anterior, a FoundationDB.
• Queríamos criar um banco de dados distribuído escalável e resistente a falhas, mas o problema mais difícil era testá-lo e ter confiança na sua correção.
• O problema fundamental do desenvolvimento de software é que os desenvolvedores precisam lidar com situações que não previram.

O que construímos

• Antes de escrever o banco de dados, primeiro escrevemos uma simulação de rede baseada em eventos e totalmente determinística.
• Com esse sistema, quando um bug é encontrado, é possível reproduzi-lo repetidamente com a mesma semente aleatória para rastreá-lo.
• A FoundationDB era um banco de dados quase sem bugs, com pouquíssimos bugs relatados por clientes.

O que construímos

• Escrevemos um hipervisor para tornar softwares arbitrários determinísticos.
• Essa plataforma consegue encontrar bugs em software e reproduzi-los perfeitamente.
• Atualmente, estamos focados em testes de confiabilidade e tolerância a falhas em sistemas distribuídos.

Contato?

• Queremos conversar com organizações que valorizam a confiabilidade de sistemas distribuídos e a produtividade em engenharia.
• Se você tiver perguntas ou comentários, pode entrar em contato pelo TwitterX ou por [e-mail].

Opinião do GN⁺

• O ponto mais importante deste texto é que é possível criar software quase perfeito por meio de métodos de teste determinísticos. Isso ajuda muito a maximizar a produtividade das equipes de engenharia e a reduzir o tempo necessário para encontrar bugs.
• A plataforma oferecida pela Antithesis tem potencial para mudar o paradigma do desenvolvimento de software, o que pode causar um grande impacto na comunidade de engenharia.
• Este texto apresenta uma abordagem inovadora para superar os limites dos testes de software, oferecendo informações muito interessantes e úteis para quem trabalha na área de tecnologia.

[GN⁺]

Opinião no Hacker News

• A produtividade da equipe de engenharia aumentou 50 vezes

  • Parece que o conceito de "desenvolvedor 10x" se distorceu para significar alguém que trabalha 6,5 dias por semana, 15 horas por dia.
  • A produtividade real de 10x (ou 50x) vem de pessoas que tornam possível o que se considerava impossível e entregam software muito mais rápido.

• Esta é a melhor introdução que já li

  • Explica muito bem os fundamentos sobre as pessoas e o que elas construíram.
  • Explica que o que estão construindo agora é resultado do que construíram antes.
  • Também menciona equipes que já usaram isso (famosas e com sistemas complexos).
  • É apresentado com uma escrita boa e atraente para desenvolvedores/fundadores. A landing page também é excelente.

• Esta é uma proposta excelente, mas dizer "encontramos todos os bugs" só pode ser verdade se a definição de bug for muito estreita

  • Os bugs mais complicados estão relacionados à lógica de negócio da aplicação.
  • É um problema de descobrir desde o início o que é o "correto".
  • Construir software no mundo real e imaginar um estado sem bugs são coisas diferentes.

• Uma plataforma para encontrar bugs em software

  • Na prática, parece mais um serviço em nuvem que executa testes de integração.
  • É preciso descobrir como implantar em um ambiente especial e escrever testes de integração usando uma biblioteca especial.
  • Fico em dúvida sobre como isso ajudaria a encontrar bugs que já podem ser encontrados com o próprio ambiente e os testes de integração existentes.

• Dúvida sobre o nome

  • Fico curioso se é apenas uma variação da palavra 'Hypothesis' ou se há um significado inteligente de oposição a testes baseados em propriedades.

• Interesse nesta área

  • Passei a entender o que o FoundationDB faz por meio do guia de simulação sled.
  • Usando madsim, escreve-se um serviço no estilo async/await e, nos testes, todos os elementos não determinísticos são substituídos por um executor determinístico que os corrige.
  • Esses testes são ferramentas muito poderosas.

• A escrita é realmente agradável

  • Uma experiência de programação como se estivesse cercado por um escudo de força que impede todos os males.
  • Apaga todas as dependências e escreve sua própria implementação de Paxos muito rapidamente. Sem bugs.

• Isto não é praticamente o santo graal?

  • Usa a aplicação existente como está e apenas verifica propriedades.
  • CPUs e sistemas operacionais não determinísticos sempre foram um obstáculo.
  • Como reconstruir toda a stack vertical de computação é quase impossível, isso é contornado com a construção de um simulador determinístico de alta resolução.

• Conheci a Antithesis na Strangeloop

  • O produto está muito à frente do estado da arte em injeção automática de falhas que eu seguia quando trabalhava na Amazon.
  • Acompanhei o processo de rastreamento de um bug encontrado no streaming do Apache Spark.
  • Não dá nem para imaginar o quanto uma ferramenta como a Antithesis seria importante dentro de uma empresa que constrói sistemas distribuídos.

• Três pensamentos

  • Uma ótima ideia que chegou na hora certa.
  • Mira em um nicho de mercado.
  • Elogios à escrita e à documentação de alta qualidade.