Qualquer linguagem, qualquer nuvem: por que continuamos agnósticos

Uma das primeiras perguntas que ouvimos é qual tecnologia usamos. É uma pergunta justa, e a nossa resposta pode soar evasiva à primeira vista: usamos a que se encaixa. Trabalhamos nas linguagens e nos frameworks em que uma organização já se apoia, implantamos na nuvem que ela escolheu ou em uma hospedagem que nós mesmos gerenciamos, e continuamos operando o que construímos.

Não é um slogan. É uma posição de projeto, e ela tem consequências na forma como as aplicações são moldadas, governadas e mantidas. Este artigo explica o raciocínio.

Definir as restrições antes de escolher a plataforma

Para uma aplicação que conecta pedidos, estoque e atendimento no Brasil, primeiro se definem os acessos, os idiomas dos usuários e quem vai operar o sistema. Os locais de hospedagem aceitáveis, a retenção e as condições de saída são definidos com o cliente. O país do leitor não determina, por si só, onde os dados devem ficar.

Agnóstico não quer dizer indiferente

Ser agnóstico não quer dizer não ter opinião. Nossos arquitetos têm convicções fortes sobre o que torna um sistema sustentável, seguro e agradável de mudar. O que evitamos é partir de uma tecnologia favorita e encaixar a organização nela.

Cada escolha tecnológica troca um conjunto de restrições por outro. O equilíbrio certo depende da organização, não do fornecedor. Uma escolha excelente para um cliente pode ser um problema para o próximo, porque as pessoas, os sistemas e as obrigações em torno da aplicação são diferentes.

As restrições que decidem

Quando moldamos uma aplicação, a tecnologia decorre de um punhado de perguntas específicas da organização.

• Quem vai conviver com ela? Se uma equipe interna vai manter partes do sistema, as linguagens que ela conhece importam mais do que as que nós preferimos.
• Com o que ela precisa conversar? Uma aplicação raramente fica sozinha. O ERP, o CRM, o provedor de identidade e as ferramentas de relatórios já existentes determinam o que se integra de forma limpa.
• Onde os dados podem ficar? Leis de privacidade, contratos e políticas internas podem decidir quais regiões e quais fornecedores são aceitáveis antes que qualquer preferência técnica entre na conversa.
• Como ela vai ser operada? Monitoramento, backups, atualizações e resposta a incidentes precisam se encaixar nas pessoas e nos processos que vão cuidar deles, de dia e de noite.
• Como você sairia? Todo sistema deveria ter uma saída crível: para outro fornecedor, para outra equipe ou de volta para dentro de casa.

Essas perguntas são feitas cedo, e as respostas são registradas com o restante do projeto. Elas não ficam para o fim, quando mudá-las sai caro.

Onde ela roda é uma decisão de projeto

A hospedagem costuma ser tratada como um detalhe operacional, resolvido depois que a aplicação está pronta. Nós a tratamos como parte do projeto. Uma aplicação pode rodar na nuvem da própria organização, no seu próprio data center ou em uma infraestrutura que a Croo gerencia. Cada opção traz responsabilidades diferentes de segurança, disponibilidade e custo, e a escolha é da organização.

Para que essa escolha seja real, o ambiente de destino é descrito na configuração, em vez de ficar entranhado no código. Um registro simplificado, apenas ilustrativo, fica assim:

# Onde o portal de compras roda fica registrado com o seu projeto.
application: purchasing-portal
packaging: container
environments:
  - name: acceptance
    hosting: client-cloud
    data-residency: client-approved-region
  - name: production
    hosting: client-cloud
    data-residency: client-approved-region
fallback:
  hosting: croo-managed
  reason: continua disponível se a equipe de plataforma mudar de rumo

O valor não está no formato do arquivo. Está na disciplina: a aplicação não pressupõe onde vive, então movê-la é um projeto deliberado, e não uma reescrita.

Manter a porta de saída aberta

A dependência de um fornecedor raramente vem de uma única decisão. Ela se acumula em pequenas conveniências: um serviço proprietário aqui, um script sem documentação ali. Ser agnóstico significa resistir a esse acúmulo em nome do cliente.

Na prática, isso significa alguns hábitos.

• Empacotamento portável. As aplicações são empacotadas para funcionar do mesmo jeito em qualquer ambiente que suporte contêineres padrão, para que a organização não fique presa ao ambiente de execução de um único fornecedor.
• Infraestrutura descrita como código. Os ambientes são criados a partir de definições revisadas, e não montados à mão, para poderem ser recriados em outro lugar.
• Dados abertos. A organização pode exportar seus dados em formatos documentados, a qualquer momento, sem a nossa ajuda.
• Documentação que viaja. Decisões, arquitetura e procedimentos de operação vivem no registro compartilhado, para que outra equipe possa assumir.

Nada disso impede o uso do melhor serviço que um fornecedor oferece. Significa saber, e deixar por escrito, quanto essa escolha custaria se as circunstâncias mudassem.

O que ser agnóstico exige de nós

Trabalhar com várias linguagens e nuvens é mais difícil do que se especializar em uma. Exige amplitude na equipe e disciplina na forma de guardar o conhecimento.

Duas coisas tornam isso sustentável. A primeira é a memória compartilhada da Factory: padrões, decisões e lições de uma tecnologia ficam registrados de um jeito que o próximo trabalho pode aproveitar. A segunda é a produção assistida por IA, que reduz o esforço de trabalhar com um framework menos conhecido ou de ler um código desconhecido. O discernimento sobre arquitetura, segurança e concessões continua com pessoas seniores que respondem por ele.

Governança desde a concepção

Escolher onde uma aplicação roda também é uma decisão de governança. Residência de dados, controle de acesso, criptografia, backups e o tratamento de dados pessoais são definidos na mesma conversa que a tecnologia, e registrados com ela.

É por isso que colocamos este tema sob a governança desde a concepção. Uma organização deveria poder dizer, a qualquer momento, onde suas aplicações rodam, quem pode acessá-las, por que essas escolhas foram feitas e como poderia mudá-las. Ser agnóstico é a nossa forma de manter essas respostas nas mãos da organização.

Em resumo

Não vendemos um conjunto fechado de tecnologias. Construímos aplicações corporativas nas linguagens e nas nuvens que servem à organização, ou nós mesmos as operamos quando essa é a melhor resposta. As restrições decidem, as escolhas ficam registradas e a porta de saída continua aberta.