Apesar das vantagens da simplicidade, infelizmente a complexidade vende melhor (2022)
(eugeneyan.com)- Por trás da avaliação mais baixa de métodos simples em revisões de artigos ou avaliações para promoção está o viés da complexidade, pois resultados complexos parecem conter mais esforço, habilidade e inovação
- Sistemas com muitas opções e componentes parecem flexíveis, mas na operação real podem se tornar difíceis de explicar, testar e solucionar, aumentando erros e ineficiências
- Ideias e sistemas simples são fáceis de entender, usar, receber feedback e expandir; quando foi adquirida em 2012, a Instagram atendia dezenas de milhões de usuários com uma equipe de 13 pessoas, mantendo tecnologias comprovadas como PostgreSQL e Redis
- Em machine learning, técnicas complexas também nem sempre são superiores: em 45 datasets tabulares de médio porte, modelos baseados em árvores foram melhores que redes neurais profundas, e há casos em recomendação e busca em que o produto interno (dot product) supera neural collaborative filtering
- Recompensar a complexidade em si incentiva complexificação desnecessária e a tendência de not invented here; portanto, quanto mais complexo o problema, mais é preciso primeiro avaliar se há uma solução simples possível e se o custo da complexidade é justificado
Por que a complexidade parece mais atraente
- A complexidade tende a ser recebida como sinal de esforço
- Artigos com muitas ideias difíceis e detalhes técnicos parecem ter exigido muito tempo e esforço
- Sistemas com muitos componentes e funcionalidades tendem a ser avaliados como entregas mais trabalhadas do que sistemas menores
- A impressão de que algo é difícil de construir acaba funcionando como sinal de valor e qualidade
- Também é interpretada como sinal de habilidade
- Um sistema com muitas partes móveis dá a impressão de que o projetista tem capacidade de entender e integrar cada uma delas
- Artigos com muitos termos técnicos e provas são difíceis de acessar, mas parecem demonstrar mais especialização no tema
- A prática de perguntar em entrevistas sobre algoritmos e estruturas de dados quase nunca usados no trabalho também está ligada a esse tipo de sinalização
- Há também a percepção de que é sinal de inovação
- Um artigo que cria uma arquitetura de modelo totalmente nova tende a ser avaliado como mais novo do que um artigo que modifica uma rede existente
- Sistemas com muitos componentes feitos do zero parecem mais originais do que sistemas que reutilizam peças existentes
- A avaliação de que “só muda uma coisa e o restante é igual a trabalhos anteriores” pode reduzir o valor de uma ideia simples
- Quanto mais funcionalidades, mais surge a ilusão de que algo é abrangente
- Sistemas que suportam tanto armazenamentos de dados SQL quanto NoSQL, ou que permitem pipelines tanto em batch quanto em streaming, parecem cobrir todos os casos
- Quanto mais blocos de Lego, maior a impressão de que será possível lidar melhor com mudanças
- Esse julgamento leva ao complexity bias, uma preferência excessiva por coisas complexas em relação a ideias e sistemas simples
Onde a simplicidade se torna uma vantagem real
- Ideias e funcionalidades simples são fáceis de entender e usar
- Aumentam as chances de adoção e o impacto real
- Também são mais fáceis de comunicar e de receber feedback
- Sistemas complexos são difíceis de explicar e gerenciar, tornando complicado para o usuário entender o que fazer e como fazer
- Quando há itens demais para ajustar, os erros aumentam; quando há etapas demais, surgem ineficiências
- Sistemas simples são mais fáceis de construir e escalar
- Menos componentes tornam a implementação mais fácil
- Usar tecnologias padronizadas e prontas facilita encontrar pessoas para implementar e manter
- Com menos código e menos interações internas, também diminui o peso de entender e testar
- Sistemas desnecessariamente complexos desperdiçam tempo e recursos na construção
- O caso da Instagram mostra as vantagens de escolhas tecnológicas simples
- Quando foi adquirida em 2012, a Instagram atendia dezenas de milhões de usuários com uma equipe de 13 pessoas
- Em vez de novas tecnologias da moda, manteve tecnologias comprovadas, reduzindo a carga operacional por engenheiro
- Enquanto outras startups adotavam armazenamentos de dados NoSQL em alta e enfrentavam dificuldades, a Instagram usava PostgreSQL e Redis, fáceis de entender
Custos operacionais e manutenibilidade
- O deploy de um sistema não é o fim, mas o ponto de partida
- A maior parte do esforço acontece depois da entrada em produção
- É muito provável que a operação fique com pessoas que não fazem parte da equipe que o criou originalmente
- Sistemas simples podem reduzir custos de manutenção e aumentar sua vida útil
- Quanto menos partes móveis, mais confiável e fácil de corrigir
- Há menos pontos que podem falhar
- Com menos interações internas, fica mais fácil atualizar ou substituir componentes individuais
- Sistemas complexos aumentam o custo de manutenção, pois uma equipe limitada precisa entender muitos componentes
- Quando há muitas partes interdependentes, a resolução de problemas também fica mais difícil
- Thomas Paine disse em Common Sense: “quanto mais simples qualquer coisa é, menos sujeita está a se desordenar e mais fácil é consertá-la quando isso acontece”
Casos em que técnicas simples não ficam para trás nem em machine learning
- Técnicas mais sofisticadas nem sempre entregam melhor desempenho
- Modelos baseados em árvores > redes neurais profundas: em 45 datasets tabulares de médio porte, modelos baseados em árvores são melhores que redes neurais profundas
- Algoritmos gulosos > graph neural networks: em problemas combinatórios em grafos, algoritmos gulosos são melhores que graph neural networks
- Média simples ≥ otimizadores complexos: em problemas de aprendizado multitarefa, a média simples é igual ou superior a otimizadores complexos
- Métodos simples > métodos complexos: em precisão preditiva ao longo de 32 artigos, métodos simples são melhores que métodos complexos
- Produto interno > neural collaborative filtering: em recomendação e busca de itens, o produto interno é melhor que neural collaborative filtering
Problemas que surgem ao recompensar a complexidade
- Recompensar a complexidade cria incentivos para as pessoas construírem coisas desnecessariamente complexas
- Métodos ou sistemas simples podem ser avaliados como menos valiosos por parecerem fáceis
- Quando se complexifica um sistema para obter recompensa, a solução mais simples deixa de ser uma escolha óbvia
- Complexidade gera mais complexidade e, no fim, pode levar o trabalho a um nível impraticável
- A tendência de not invented here também é reforçada
- Mesmo que reutilizar componentes existentes economize tempo e esforço, surge a inclinação de construir tudo do zero
- Isso pode desperdiçar tempo e recursos e levar a resultados piores
- Processos de promoção e revisão de artigos de machine learning também podem enfatizar a complexidade em excesso
- Bryan Liles observa que soluções simples são mais fáceis de implementar e escalar do que soluções complexas, mas muitas vezes a promoção vai para quem criou a solução complexa
- Micah Goldblum diz que, em revisões de ML, é comum apontarem que o método é simples demais ou composto por peças existentes, mas simplicidade não é fraqueza; é força
- Inovações como Kalman Filters, PageRank, SVM, LSTM, Word2Vec e Dropout também já foram rejeitadas
Uma forma melhor de lidar com a complexidade
- O objetivo é resolver problemas complexos com soluções tão simples quanto possível
- É preciso focar na complexidade do problema, não na complexidade da solução
- Uma solução simples mostra uma compreensão profunda do problema e a capacidade de evitar soluções mais tortuosas e custosas
- Isso se conecta à frase de Albert Einstein: “Tudo deve ser feito da forma mais simples possível, mas não mais simples que isso”
- É possível considerar várias soluções focadas em vez de uma solução complexa que abranja tudo
- Soluções universais (one-size-fits-all) podem ser menos flexíveis e menos reutilizáveis do que o esperado
- Dar suporte simultâneo a vários casos de uso e stakeholders cria forte acoplamento e exige mais coordenação para planejamento e migração
- Sistemas de propósito único são fáceis de operar e também fáceis de descartar quando necessário
- Para reduzir o viés da complexidade, é possível aplicar a Occam’s razor
- É o princípio de que a solução ou explicação mais simples costuma estar correta
- Não se deve rejeitar ideias simples cedo demais nem adicionar complexidade desnecessária para justificar valor
- É preciso considerar o custo da complexidade e perguntar: “vale a pena?”
O viés oposto de reutilizar a complexidade familiar
- No lado oposto de “not invented here”, também existe o viés de preferir automaticamente componentes existentes
- Isso acontece porque já são conhecidos, parecem mais fáceis pela experiência pessoal e reduzem o próprio tempo e esforço
- Mas, se o componente existente for muito complexo, ele pode desperdiçar mais tempo e recursos e levar a resultados piores do que criar algo mais simples do zero
- Quando não há uma opção simples, pode ser necessário construir algo novo
- Também há casos em que o que foi recém-criado não se torna realmente simples e vira apenas outro objeto tão complexo quanto o existente
- Alguns problemas são intrinsecamente complexos e possuem essential complexity que não pode ser realmente removida
- ORM é tratado como um mau exemplo
- ORMs continuam sendo recriados e começam simples, mas no fim a complexidade explode
- O object/relational impedance mismatch é bem conhecido, e a própria ideia de ORM é intrinsecamente complexa
- O que parece ter preservado a simplicidade provavelmente não é um ORM, mas um query builder ou data mapper
- A API de cache PSR é um exemplo de complexidade removível
- Depois da API de cache PSR-6, surgiu a API de cache PSR-16, mais simples
- A PSR-16 reduz a complexidade e o número de conceitos, tornando a API menor e menos opinativa
- O fato de ser possível criar um adaptador PSR-6 para implementação PSR-16 e um adaptador no sentido oposto mostra que a complexidade removida da PSR-16 não era essencial
- Algumas bibliotecas e frameworks podem crescer além da complexidade essencial em nome da experiência do desenvolvedor
- A simplicidade real tem uma natureza mensurável por indicadores como número de linhas de código, número de métodos públicos e acoplamento
- Há casos em que uma biblioteca cresce para 10 vezes seu tamanho original em poucos anos e lança grandes breaking changes a cada 6 a 12 meses
- A motivação de considerar “morta” uma biblioteca sem crescimento e migrar para um pacote mais “ativo” também pode ser sintoma do viés da complexidade
- Para evitar a complexidade que se espalha, às vezes é necessário optar por criar algo novo
- Se for possível fixar os requisitos e evitar crescimento com expansão de escopo, uma nova implementação pode ser a escolha mais simples
- É preciso tomar cuidado para não reforçar nenhum dos dois vieses
1 comentários
Opiniões do Hacker News
Trabalhei em uma empresa FAANG numa época em que resolver problemas complexos era usado como critério para promoção; quanto mais complexo era o problema resolvido, mais subiam nível, remuneração e status.
Naturalmente, as pessoas passaram a procurar problemas complexos que pudessem resolver, e, à medida que outras empresas copiavam as ideias dessa companhia, parece que até empresas pequenas que não precisavam de soluções complexas acabaram adotando stacks tecnológicas parecidas.
Tenho pensado algo parecido ao ver as UIs de carros de hoje, especialmente as UIs complexas e difíceis de usar dos elétricos, a ponto de isso me impedir de comprar um carro que eu preciso.
Minha conclusão é que consumidores sofisticados e consumidores aspiracionais são muito diferentes, e há muito mais consumidores aspiracionais.
Por isso, faz sentido econômico sacrificar o consumidor sofisticado para atender ao aspiracional.
O consumidor aspiracional aceita defeitos e truques porque os vê como símbolos de conquista no consumo.
Falando de forma grosseira, ele fica tão feliz por dirigir um carro “de luxo” que não enxerga o lixo que veio junto; já eu, como alguém que compra carros de luxo há décadas, só queria que a alavanca de câmbio fosse fácil de entender.
Os alvos de toque ficaram pequenos demais sem motivo, e parece que os desenvolvedores criaram e testaram a UI em um monitor parado sobre uma mesa, ou em um carro que não estava em movimento.
Dentro de um carro em movimento, tudo desanda.
Os modelos mais recentes, sem alavanca de câmbio, setas, limpadores ou alavanca de luzes, são um caos.
Sentado ao volante, você precisa acertar alvos minúsculos numa tela onde nem há um lugar para apoiar a mão; por causa da operação indireta, da confusão, da imprecisão e da distração, tudo isso faz com que todo mundo dirija pior.
Ela automatiza tarefas chatas como travar e destravar, fechar janelas, pré-aquecer ou pré-resfriar, configurar automaticamente a navegação para o trabalho de manhã e para casa à noite, e ajustar bancos e configurações conforme a chave de celular usada.
Graças à conectividade gratuita, a navegação também funciona de verdade; todos os GPS embarcados que usei antes eram inúteis.
A tela de seleção e reprodução de música também é boa, e os comandos de voz funcionam razoavelmente bem para escolher músicas.
Não é perfeito, mas considero melhor do que todos os carros a combustão que já dirigi.
De manhã, sair para o trabalho leva só dois passos: abrir a porta e colocar no modo de condução.
Num carro a combustão no inverno, eram mais de 10 passos: procurar a chave, destrancar o carro, abrir a porta, ajustar o banco depois que minha esposa dirigiu, apertar o botão de partida, desembaçar o para-brisa, ligar o desembaçador do vidro traseiro, raspar o gelo do para-brisa, escolher o trabalho no GPS, soltar o freio de estacionamento, acionar a embreagem e engatar a marcha.
Pessoas que não têm um vivem lamentando a tela sensível ao toque na internet, mas os donos de Tesla continuam com a marca porque, com ou sem touchscreen, o carro é excelente em comparação com outros.
A Technology Connections comentou em um vídeo recente que, para trocar o limpador, era preciso segurar por 4 segundos uma alavanca feia, estilo anos 90, e que teve de ler o manual para descobrir isso.
Em carros feitos com peças encaixadas separadamente, esse tipo de comportamento lixo é muito comum.
Já o meu carro envia alertas de vídeo de vigilância em tempo real para o celular, dirige no trajeto para o trabalho, e a troca de marcha normalmente chega ao ponto de o carro escolher a direção sozinho quando você coloca o cinto e pisa no freio.
Funções importantes ficam acessíveis contextualmente pelo volante, não por 50 botões.
É simples e poderoso; o problema é que a execução nos tais carros de luxo mencionados antes é péssima.
Às vezes assisto a um YouTuber chamado Theo Browne, que é principalmente desenvolvedor front-end
Quando vejo ele explicar uma solução, parece que levei uma tacada de beisebol na cabeça, e a quantidade de elementos que entram na demo é de dar vontade de chorar
Também me impressiona a quantidade de termos obscuros relacionados a React que ele menciona em um único vídeo
Não quero atacar uma pessoa específica, mas me preocupo que essa complexidade seja justamente o que mantém sua popularidade
Por outro lado, Pieter Levels coloca PHP puro direto em produção sem falar de Suspense, renderização no servidor, Hydration e coisas do tipo
Os dois acabam chegando ao mesmo objetivo, mas acho que Pieter Levels deve ganhar muito mais dinheiro, e a diferença de complexidade é enorme
Na prática, coisas como o Nomad List me parecem muito mais ricas em recursos do que o que vejo no Theo
Depois vi outra pessoa reconhecê-lo e eles entrarem em uma discussão amigável, aos gritos, sobre um tema em que o Theo tinha se posicionado fortemente no canal
A personalidade dele parecia perfeitamente ajustada a maximizar o engajamento de mídia por meio de complexidade desnecessária
Quanto mais complexo, mais pontos de debate existem, e isso pode parecer mais inteligente para quem não está familiarizado com opções obscuras
A quantidade de bibliotecas e código usados em exemplos de brinquedo é muito maior do que o que vejo em produção, e olha que já vi sistemas bem monstruosos
Não sei por quanto tempo isso vai durar
Vem junto um monte de coisas variadas que você não vai usar, e elas atrapalham justamente as partes que você vai usar
Quando surge um problema, agora você precisa entender não só a linguagem de programação e o seu próprio código, mas também o código do caminho que você percorre dentro do framework
Esse caminho pode facilmente descer 10 a 20 funções de profundidade, e é extremamente raro que o que acontece em diversos casos de borda esteja documentado de forma suficientemente concreta
A quantidade de ferramentas usadas para criar algo relativamente simples é enorme, e tenho a sensação de que algo parecido acontece em DevOps
Acho que esse problema foi criado pelos “desenvolvedores front-end” das empresas
Parece que uma espécie de complexo de inferioridade em relação à “engenharia de verdade” feita por desenvolvedores full-stack ou back-end fez o front-end também querer criar problemas de “engenharia de verdade”
Depois de décadas desenvolvendo sistemas legados, às vezes com projetos da nossa própria empresa e às vezes em trabalhos contratados para clientes, vi muita coisa me levar a acreditar que certos clientes preferem softwares complexos e cheios de bugs
O motivo é que podem se esconder atrás deles
Algo como “não terminei a tempo porque o software tinha bugs”, “não consegui fazer X porque o software não dava suporte a Y”, “o cachorro comeu meu dever de casa”
Em muitos casos, teria sido possível projetar uma solução simples, fácil e com muito menos bugs, mas aí ficaria mais difícil para os usuários esconderem que uma determinada falha talvez não fosse problema do software, e sim incompetência própria
Por isso, especialmente em empresas com muita pressão de cima, os gestores na prática preferem trabalhar com softwares que não entendem completamente e que são conhecidos por ter bugs e problemas
Aos 27 anos, quando saí do meu primeiro emprego, onde fiquei 5 anos, substituí um programa GUI supercomplexo por uma pequena GUI envolvendo dois programas CLI
Ele funcionava sempre, mesmo com entradas incorretas, e, nas raras vezes em que falhava, dava mensagens de erro úteis
As três mulheres que usavam aquilo me odiavam de verdade
Só fui entender o motivo cerca de um ano depois de sair da empresa, e naquela época eu não era muito esperto
Com o tempo, passei a achar que as pessoas querem coisas como Microsoft Teams porque, quando precisam, podem usá-las para encobrir seus próprios atrasos
Em UI física, nosso grupo chama isso de problema do micro-ondas
Ninguém usa os 20 botões extras do micro-ondas, e a maioria usa só um ou dois botões, mas ninguém compra um micro-ondas com poucos botões
Gosto do Samsung ME82V há 10 anos, e dois seletores resolvem tudo
Então fazer um lanchinho escondido às 2 da manhã vira ficar vigiando o micro-ondas como se fosse 1999
Tudo o que você quer é um seletor de velocidade, um botão de pulsar e um interruptor de energia, e todo mundo quer isso, mas por algum motivo, a cada geração, eles vêm cheios de recursos que ninguém usa
Você não necessariamente usa sempre os mesmos dois botões, então gosta de ter a opção de usar outros
E, quando há muitos botões, com bastante frequência vêm junto especificações melhores
Tinham menos controles e menos funções, mas a experiência do usuário era excelente
Lembro da elegância do iPod em comparação com produtos concorrentes excessivamente cheios de recursos e complexos
Esse tipo de lamentação irrita porque é cheio de máximas batidas
É fácil parecer inteligente citando Einstein e Dijkstra, e também é fácil generalizar soluções complexas e apontar o dedo quando se tem o benefício da retrospectiva e ignorância sobre os requisitos reais
“Tão simples quanto possível, mas não mais simples” está sempre certo
Se a solução ficou bagunçada, é porque deveria ter sido simplificada; se uma solução primitiva causa problemas, é porque não deveria ter sido simplificada demais
É como perguntar por que simplesmente não pensaram em fazer perfeito
Na prática, quando há várias concessões em uma solução, até chegar a um acordo sobre o que é simples é muito difícil
Manter um banco de dados complexo pode ser mais fácil do que ter três bancos de dados “simples”, triplicar o trabalho de administração e, no fim, implementar sincronização ou transações distribuídas
O que é fácil de implementar agora pode criar problemas complexos depois, e uma solução pronta que não resolve totalmente o problema gera workarounds complexos para os casos que não suporta, até acabar acrescentando também a complexidade de migrar para algo adequado
O conselho de “basta fazer simples” muitas vezes não entende que essa solução não é uma panaceia, nem a realidade em que raramente existem opções claras entre complexo e simples
Projetos têm restrições como sistemas legados bagunçados, exigências legais inconsistentes e necessidades de negócio mutáveis, e também podem priorizar velocidade de lançamento ou as competências disponíveis para contratação
A economia também é implacável: mesmo que exportar o relatório anual pareça uma máquina de Rube Goldberg, ele é usado só uma vez por ano, e reescrevê-lo talvez não recupere o custo em 50 anos
Discussões sobre complexidade quase nunca reconhecem que projetos e requisitos crescem
Algo perfeitamente simples hoje pode ficar complexo depois de uma forma totalmente racional, não por incompetência nem má-fé
No começo, armazenar dados em um arquivo de texto puro é lindamente simples, mas depois pode virar um péssimo banco de dados NIH
Por outro lado, usar um banco de dados desde o início para três linhas de dados também é overengineering
Refatorar tem custo; portanto, usar sempre a solução ideal também não é algo tão simples assim
Muito menos coisas são de fato óbvias do que se imagina
Interpretar “tão simples quanto possível, mas não mais simples” como uma exigência de perfeição não decorre logicamente
Na prática, sabemos que iteração vence planejamento
Se for difícil chegar a um acordo sobre o que é simples, peça perdão em vez de pedir permissão
É uma regra que funciona neste setor, e talvez em muitos outros
Há certamente um tipo específico de complexidade acidental que aparece em sonhadores e desenvolvedores front-end
Complexidade é complicada
Sistemas mais complexos também têm o efeito secundário de gerar muitos materiais periféricos, como tutoriais e vídeos
Além disso, para quem aprende aquilo, isso dá estabilidade no emprego, pois a pessoa passa a ter as habilidades e responsabilidades necessárias na empresa, em vez de tudo simplesmente funcionar bem e dispensar essa pessoa
Há empregos demais em TI que não existiriam se software fosse feito para ser simples e simplesmente funcionar
Nos casos simples, ele “simplesmente funciona”, mas tudo bem desde que você não tente olhar por dentro nem fazer algo minimamente não trivial
Talvez a analogia seja bem adequada
Se estamos falando de revisão de artigos, como revisor, o que procuro em um artigo não é simplicidade, nem complexidade, nem “novidade”
O que procuro é uma análise empírica minuciosa e instigante do problema
Entre as submissões, há muitas que 1) propõem um sistema Frankenstein costurado a partir de uma dúzia de ideias existentes e conseguem obter “números vistosos” usando o máximo possível dos brinquedos mais recentes à mão, sem analisar em profundidade os modos de falha de cada parte; 2) apenas modificam um pouco um método existente e, por acaso, obtêm melhor desempenho, mas sem uma justificativa empírica ou teórica adequada de por que isso ajuda
O segundo tipo pode ter um valor muito pequeno para a comunidade ou para os leitores, mas, na maioria das vezes, considero inútil
O que tem valor para o leitor é quando um doutorando olha para um problema por muito tempo, conecta sua intuição a uma confirmação quantitativa e verificável e obtém uma observação reprodutível com poder preditivo
Por exemplo: “verificamos experimentalmente, em todos os casos, que X afeta Y por meio do mecanismo Z descrito neste artigo, e por isso melhoramos a métrica A em B%, o que é consistente com Z”
Independentemente da complexidade, algo do tipo “fizemos X e A subiu B%” é insuficiente
Infelizmente, nem todos os revisores concordam
Meu professor de história no ensino médio passou uma redação sobre os eventos que levaram à Segunda Guerra Mundial
A primeira pergunta foi qual deveria ser o tamanho do texto, e o professor respondeu que daria nota máxima se alguém conseguisse tratar desse tema complexo em uma folha A4, mas que duvidava sinceramente que fosse possível abordá-lo em um texto tão curto
Todo mundo ficou chocado com essa lógica
Ninguém jamais tinha ouvido um professor dizer algo assim, o que mostra que desde pequenos aprendemos que mais é sempre melhor
Uma explicação sempre pode ser tornada longa ou curta escolhendo o nível de abstração, e as pessoas normalmente escolhem esse nível conforme o contexto e as convenções sociais
Por exemplo, “como um pressionamento de tecla vira uma letra na tela” pode ser explicado em uma frase, ou em vários livros longos se entrarmos em firmware, pilha de software, eletrônica, ciência dos materiais e processos de fabricação
Também dá para dizer que a Segunda Guerra Mundial começou quando Hitler invadiu a Poland e a France, ou voltar ao Tratado de Versailles, ou até falar da evolução da vida na Terra
O último caso é pedante, mas tecnicamente foi um evento que levou à Segunda Guerra Mundial
Recomendo fortemente a palestra Simple Made Easy, de Rich Hickey
A complexidade não vende bem de jeito nenhum, mas o que é fácil vende bem
Se uma empresa consegue contratar muitas pessoas que sabem usar “foo” e o setor continua falando sobre “foo”, ela vai escolher foo mesmo que seja uma bagunça completa
Basta olhar para a arquitetura Lambda, a maioria dos projetos Apache, contêineres etc.