Durante quase todo o tempo em que a web existe, o desenvolvimento web tem lutado fortemente para encontrar a maneira certa de conectar componentes pela rede. Esta é a questão da API remota. Ele influencia todos os aspectos do software que construímos. Chegamos a um compromisso tolerável com APIs JSON. Embora estes tenham suas limitações, você deve apreciar sua simplicidade subjacente.
Mas o advento de endpoints habilitados para IA que podem mediar intenções está mudando o funcionamento básico da Internet. Essa mudança está despertando gradativamente um sonho antigo, a arquitetura orientada a serviços (SOA). Desta vez, com sorte, finalmente obteremos a descoberta de serviço automatizada flexível, detectável e sustentável que tanto desejamos. Dedos cruzados.
Por que o SOA da velha escola falhou
Vamos chamar essa crescente influência da IA na arquitetura web de SOA 2.0.
Para entender por que o SOA 2.0 é diferente do SOA 1.0, temos que lembrar o trauma dos anos 2000. (Isso pode ser doloroso, mas também catártico.) O sonho original da SOA era lindo: um mundo onde serviços de negócios díspares – estoque, faturamento, remessa, entre outros – pudessem descobrir-se automaticamente, compreender capacidades e orquestrar tarefas complexas sem intervenção humana.
Para conseguir isso, construímos um monumento à complexidade. Tínhamos SOAP (Simple Object Access Protocol) para mensagens, WSDL (Web Services Description Language) para definir contratos e registros UDDI para descoberta de serviços. No centro de tudo estava o Enterprise Service Bus (ESB), uma enorme peça de middleware que deveria rotear tudo de maneira elegante e contínua. Caso vocês, jovens, estejam confusos, tudo isso é baseado em XML.
Quando você terminou de entender a infraestrutura bem o suficiente para saber como fazer algo, você já havia esquecido o que pretendia fazer.
Ele falhou. Foi extremamente pesado. Apenas para fazer algo simples, como criar um ponto final de “Novo Item”, você imediatamente precisava começar a escalar uma parede de definições rígidas.
Como os computadores historicamente exigiam perfeição absoluta e determinística, se faltasse uma única tag XML em um envelope SOAP ou se um serviço atualizasse seu WSDL sem que cada cliente gerasse novamente seus stubs, todo o pipeline multimilionário se desfaria violentamente. Alguns de nós podem estar familiarizados com um desafio semelhante em microsserviços conteinerizados (como Kubernates), onde tentar determinar onde um problema se originou na malha é… estranho.
SOA clássico era um castelo de cartas, frágil demais para sobreviver à realidade confusa da Internet.
A API JSON típica de hoje é uma reação contra SOA. (Pode ser uma reação exagerada.) Abandonamos a SOA pela relativa simplicidade do REST, desistindo do sonho da orquestração autônoma de serviços em troca de integrações manuais que apenas trabalhe.
O novo middleware de intenção de execução
Uma mudança radical já está acontecendo com a arquitetura em nível de aplicativo.
O efeito dos endpoints de IA no perfil de serviço de um aplicativo vai além de apenas um novo recurso. Isso muda a forma como o restante dos serviços funcionam juntos. O efeito geral é algo como o aplicativo ganhando uma compreensão de si mesmo e do que pode fazer. Isto não é diferente do que o WSDL deveria realizar. Mas em vez de um descritor codificado, onde alguém tinha que manter o que estava disponível e o que foi descrito em sincronia, agora você tem uma camada que pode aceitar descritores produzidos dinamicamente e uni-los à intenção difusa do usuário e produzir ações significativas.
Você vincula endpoints de IA para fazer a ponte entre o que o usuário está tentando realizar, com os vários recursos estritos disponíveis. Esses recursos podem existir no aplicativo no back-end, no front-end ou em outra camada de serviço. O principal é que existe uma camada de IA flexível que mitiga a necessidade de codificar os links entre os serviços.
Na SOA clássica, o contrato era um documento WSDL rígido e implacável. Na prática comum moderna, o contrato é um endpoint RESTful fortemente acoplado. Na SOA 2.0, o contrato tem um grau de flexibilidade até então desconhecido, graças às capacidades de linguagem natural de um LLM.
Quando um usuário ou sistema expressa uma intenção — digamos, “Provisionar um novo ambiente de preparação para o serviço de cobrança” — o middleware de IA não procura uma integração ponto a ponto codificada. Em vez disso, ele digere a intenção e realiza o roteamento semântico, consultando um registro e selecionando as ferramentas apropriadas. Esse registro, em vez de um UDDI pesado, pode ser um banco de dados vetorial de terminais de API internos disponíveis ou uma coleção de funções disponíveis.
LLMs modernos equipados com recursos de chamada de função atuam como os orquestradores dinâmicos definitivos. Eles leem o esquema JSON de uma API REST de destino, entendem seus parâmetros e mapeiam dinamicamente a intenção difusa e não estruturada do usuário em uma carga JSON perfeitamente formatada. Se um campo estiver faltando, o LLM pode inferi-lo a partir do contexto ou pausar a execução para pedir esclarecimentos ao usuário.
A fragilidade do SOA 1.0 é substituída por um amortecedor. Se a API de destino alterar o nome de um parâmetro de customerID para clientIdo middleware de IA pode ler o esquema atualizado e ajustar seu mapeamento instantaneamente. Nenhum código do cliente precisa ser recompilado. Nenhum stub precisa ser regenerado. O pipeline multimilionário sobrevive.
Quando o software se torna inteligente
Estas não são apenas ideias abstratas. Recentemente fiz meus impostos, usando um serviço popular e popular que não vou citar. Tive de lidar com várias áreas incomuns e mal-humoradas, incluindo as novas regulamentações de criptografia. Não foi bonito.
Mas o que mais me impressionou foi o quão burro o software era, em comparação com o chatbot de IA que eu estava usando para me ajudar a me orientar. Eu queria poder contar ao (estúpido) software o que estava tentando fazer. Como “Carregue meu NOL do ano passado!” Ou “Não sei se preciso de um cronograma K, diga-me você!”
Não quero outro chatbot. Quer dizer, já tenho um bom chatbot. Quero que o aplicativo esteja bem integrado com serviços de IA que entendam o aplicativo, entendam minha situação atual dentro do aplicativo e me encontrem no nível de intenção, aplicando as lições aprendidas por outras pessoas que usaram as mesmas ferramentas.
Esse tipo de nivelamento de intenção direcionado e inteligente é, pelo que posso ver, o próximo estágio do desenvolvimento de software, e será massivo.
Latência, não determinismo e outros desafios
Estamos trocando a fragilidade determinística da SOA clássica pela imprecisão probabilística da SOA 2.0. E esse comércio será exigido com cada vez mais insistência pelos usuários. Mas isso vem com um novo conjunto de compensações.
Primeiro, existe o imposto de latência. O antigo barramento de serviço corporativo era pesado para configurar, mas em tempo de execução, as mensagens eram apenas roteadas em XML. Injetar um LLM no caminho crítico de um aplicativo adiciona centenas de milissegundos, senão segundos, de latência. Para tarefas assíncronas ou orquestrações complexas, esta é uma compensação bem-vinda. Para microsserviços de alto rendimento e em tempo real, é um fator decisivo.
Em segundo lugar, existe o problema do não-determinismo. Passamos décadas treinando a nós mesmos (e aos nossos sistemas) para esperar que, dada a entrada A, um sistema sempre produzirá a saída B. Essa equação determinística era nossa fé final. A camada de intenção não funciona dessa maneira. Um LLM pode encaminhar uma solicitação lindamente 99 vezes e, na centésima, alucinar um parâmetro. Ou pode escolher um caminho de execução totalmente diferente com base em uma mudança sutil na frase do usuário.
Um terceiro problema são os chamados requisitos não funcionais, ou NFRs. Esses são os problemas incômodos da barra lateral que se recusam a ser ignorados, como segurança e confiabilidade.
As preocupações de segurança são ampliadas pelos recursos do modelo, como chamada de função (ou “passagem de função”). Se você combinar os desejos de um usuário com o que a IA pode fazer, e então deixar a IA decidir, o que acontece a seguir é claramente um ato de fé, a menos que proteções sejam implementadas. Essas proteções devem ir além da segurança típica da web (ou seja, garantir que chamadas de funções importantes sejam protegidas no servidor e não expostas no cliente) e devem ser internalizadas pela IA ou (mais provavelmente) impostas por uma camada fora da IA. Existem várias maneiras de fazer isso, variando em grau de poder e complexidade.
Certamente continuaremos a usar práticas padrão (como RBAC e SSO) para impor a autenticação. Continuaremos a implementar técnicas de autorização padrão (como OAUTH e JWT). Mas iremos aplicá-los no contexto dessa camada de intenção e de suas capacidades.
A confiabilidade é outro desafio. Por exemplo, recentemente encontrei um obstáculo com a API Imagen do Google. Tudo estava funcionando perfeitamente e, de repente, algumas imagens pararam de ser geradas. Não houve erros nos logs do cliente ou do servidor; no entanto, ocorreram 500 erros na rede. Após um exame mais aprofundado, o prompt se transformou (entre o contexto do aplicativo e o conteúdo do usuário) para incluir o que as regras da API Imagen consideravam conteúdo perigoso. Isso não foi obviamente sinalizado. Foi uma escrita criativa bastante prosaica, nos moldes de “Uma paisagem cyberpunk sombria, surreal e problemática com figuras ameaçadoras…”. Esse tipo de coisa.
Estas são algumas das maneiras pelas quais até mesmo o uso simples e direto de APIs LLM pode surpreendê-lo. A questão que estou pensando é: quais serão os resultados inesperados no software em grande escala?
Amanhecer de uma teia probabilística
Desde a sua criação, a natureza imprevisível e probabilística da Internet veio principalmente dos humanos que a utilizam (e dos transístores que invertem a radiação de fundo, das falhas de rede, dos efeitos geopolíticos no terreno, e assim por diante). Mas as APIs mediadas por IA introduzem uma forma de probabilidade intencional e semanticamente controlada.
Como desenvolvedores, descobriremos naturalmente as técnicas que tornam o consumo de endpoints de IA mais eficaz. Aqui estou pensando em práticas como respostas estruturadas e chamadas de funções. Mas a questão maior é: qual será a natureza do software?
Em um mundo de estados binários, protocolos rígidos e URIs rígidos, se você enviar um GET solicitação para um endpoint específico, você espera uma resposta exata e previsível. Passamos os últimos 40 anos tratando a web como uma máquina de estado vasta e inimaginavelmente complexa.
Mas à medida que as APIs mediadas pelo LLM permeiam a nossa arquitetura com estocástica, a própria estrutura da Internet começa a mudar. Ao injetar IA nas camadas de roteamento e descoberta, estamos introduzindo uma enorme dose de probabilidade na base de nossas redes. Quando uma solicitação não é mais uma chamada de URI codificada, mas uma intenção de linguagem natural analisada por um LLM, a conexão entre o nó A e o nó B deixa de ser um fio rígido. Torna-se uma probabilidade ponderada.
Em essência, estamos refazendo a Internet para espelhar a arquitetura dos modelos de IA que estamos implantando. Assim como uma rede neural depende do disparo probabilístico de sinapses, em vez de declarações determinísticas se/então, a próxima iteração da web dependerá de descobertas semânticas fluidas. Os serviços não se “ligarão” apenas uns aos outros; eles gravitarão um em direção ao outro com base na proximidade conceitual de suas capacidades dentro de um espaço latente compartilhado.
Isso altera o caráter da engenharia de software. Perdemos (a ilusão) de estar totalmente no controle. O seu estranho paradoxo é que a engenharia que utiliza componentes explicitamente probabilísticas pode resultar num sistema mais resiliente. Há um debate de longa data sobre a melhor metáfora para o desenvolvimento de software. Durante muito tempo, a construção de um edifício sempre pareceu ser uma analogia adequada, ou talvez a mecânica de um veículo. Mas hoje em dia, a metáfora da jardinagem ou do cultivo parece cada vez mais relevante.
Apesar dos desafios colocados pela inserção da IA na pilha, estamos finalmente voltando à promessa original do início dos anos 2000. Desta vez, com os dedos cruzados, estamos equipados com as ferramentas certas para o trabalho.
Tentamos construir uma descoberta autônoma de serviços usando lógica rígida e XML determinístico, mas ela ruiu sob seu próprio peso. Agora, estamos construindo isso com redes neurais que entendem a “intenção” por trás da integração. Ainda estamos construindo middleware, mas em vez de um barramento de serviço empresarial, estamos construindo um barramento de raciocínio empresarial.
A era da codificação manual de cada integração entre cada microsserviço pode estar chegando ao fim.
