Técnicas

Embora o mapeamento do caminho para produção tenha sido uma prática quase universal na Thoughtworks desde a programação da Entrega Contínua, muitas vezes encontramos organizações que não estão familiarizadas com a prática. A atividade é mais frequentemente realizada em um workshop com um grupo multifuncional – que inclui todas as pessoas envolvidas no projeto, no desenvolvimento, no lançamento e na operação do software – em torno de um quadro branco compartilhado (ou ferramenta virtual equivalente). Primeiro, as etapas do processo são listadas e ordenadas, desde a estação de trabalho da pessoa desenvolvedora até a produção. Em seguida, uma sessão facilitada é usada para capturar mais informações e pontos problemáticos. A técnica mais comum que vemos é baseada em mapeamento de fluxo de valor, embora muitos mapas de processo sejam igualmente valiosos. A atividade é muitas vezes reveladora para muitas das pessoas que participam, pois elas identificam atrasos, riscos e inconsistências e continuam a usar a representação visual para a melhoria contínua do processo de compilação e implantação. Consideramos essa técnica tão fundamental que nos surpreendemos ao descobrir que não a havíamos incluído no Radar antes.

A interação do time é um conceito-chave ao redesenhar uma organização para agilidade e velocidade nos negócios. Essas interações serão refletidas no software que está sendo construído (consulte a Lei de Conway) e indicarão o quão eficientemente os times podem entregar valor de forma autônoma a clientes. Nosso conselho é ser intencional sobre como os times são projetados e como interagem. Por acreditarmos que o design organizacional e as interações do time evoluem com o tempo, achamos que é particularmente importante medir e acompanhar a carga cognitiva do time , que indica a facilidade ou a dificuldade dos times para construir, testar e manter seus serviços. Estamos usando um modelo para avaliar a carga cognitiva do time com base nas ideias dos autores do Team Topologies.

O impacto positivo da aplicação dos conceitos deste livro na comunicação com clientes e no redesenho das organizações continua nos impressionando. Os autores recomendam uma abordagem simples, mas poderosa para o design organizacional, identificando apenas quatro tipos de times e três modos de interação. Isso ajuda a reduzir a ambiguidade dentro da organização e fornece um glossário comum para que times, partes interessadas e liderança descrevam e desenhem o trabalho de uma equipe. Para implementar uma mudança no design da organização, projetamos a estrutura de topologias de time ideal, aplicamos quaisquer restrições técnicas/equipe (por exemplo, profissionais insuficientes) e, em seguida, concluímos com a estrutura final. Isso nos permite aconselhar melhor clientes e antecipar se estamos de fato melhorando a carga cognitiva ao comparar as estruturas de time nos estágios como estão/como devem estar.

Continuamos recomendando que os times executem modelagem de ameaças — um conjunto de técnicas para ajudar a identificar e classificar ameaças potenciais durante o processo de desenvolvimento — mas queremos enfatizar que esta não é uma atividade pontual realizada apenas no início dos projetos; as equipes precisam evitar o sanduíche de segurança. Isso ocorre porque ao longo da vida útil de qualquer software, novas ameaças surgirão e as existentes continuarão a evoluir graças a eventos externos e mudanças contínuas nos requisitos e na arquitetura. Isso significa que a modelagem de ameaças precisa ser repetida periodicamente — a frequência de repetição dependerá das circunstâncias e precisará considerar fatores como o custo de execução do exercício e o risco potencial para o negócio. Quando usada em conjunto com outras técnicas, como estabelecer requisitos de segurança multifuncionais para lidar com riscos comuns nas tecnologias do projeto e usar verificadores de segurança automatizados, a modelagem de ameaças pode ser um ativo poderoso.

Desde a última vez que falamos sobre BERT (Representações de Codificador Bidirecional de Transformadores, ou Bidirectional Encoder Representations from Transformers em inglês) no Radar, nossos times o usaram com sucesso em alguns projetos de processamento de linguagem natural (PLN). Em uma de nossas clientes, observamos melhorias significativas quando mudamos do tokenizador BERT padrão para um tokenizador de pedaços de palavras treinado por domínio para consultas que contêm substantivos como nomes de marcas ou dimensões. Embora o PLN tenha vários novos modelos de transformadores, o BERT é bem compreendido, conta com boa documentação e uma comunidade vibrante, e continuamos a considerá-lo eficiente em um contexto de PLN empresarial.

Testes de regressão visual são recursos úteis e poderosos para ter em sua caixa de ferramentas, mas têm um custo significativo, pois são feitos para páginas inteiras. Com o surgimento de frameworks baseados em componentes como React e Vue, também observamos a ascensão dos testes de regressão visual de componentes. Essa técnica atinge um bom equilíbrio entre valor e custo para garantir que nenhum elemento visual indesejado seja adicionado à aplicação. Em nossa experiência, o teste de regressão visual de componentes apresenta menos falsos positivos e promove um bom estilo de arquitetura. Em conjunto com ferramentas como Vite e o recurso Hot Module Replacement (HMR) do webpack, seu uso pode ser visto como uma mudança de paradigma para aplicar o desenvolvimento orientado a testes ao desenvolvimento front-end.

Ao ser confrontada com o desafio de usar um sistema de design de forma consistente em uma variedade de formatos e plataformas, a equipe da Salesforce criou o conceito de tokens de design. Os tokens armazenam valores, como cores e fontes, em um local centralizado. Isso possibilita separar opções de decisões e melhora significativamente a colaboração entre times. Os tokens de design não são novos, mas com a introdução de ferramentas como Tailwind CSS e Style Dictionary, temos visto tokens de design sendo usados com mais frequência.

Usar contas de e-mail de testes ou servidores SMTP (Single Mail Transfer Protocol) de testes completos continua sendo uma prática comum de teste de software. No entanto, usar um servidor real traz o risco de que e-mails de teste sejam enviados para pessoas reais e muitas vezes complica o teste de integração automatizado. Tivemos sucesso ao usar um servidor SMTP falso para testar o envio de e-mails , que registra uma solicitação para enviar um e-mail sem realmente enviá-lo. Existem várias ferramentas de código aberto neste espaço, incluindo fake-smtp-server, que renderiza e-mails em uma interface de usuário web para testes visuais e mountebank, que expõe os e-mails enviados por meio de uma API REST para testes de integração. Recomendamos explorar essa técnica para reduzir o risco e melhorar a eficiência dos testes.

Estamos observando atualmente projetos de clientes que usam aprendizado de máquina federado. Tradicionalmente, o treinamento de modelos de aprendizado de máquina (ML) exigia que os dados fossem colocados em um local centralizado onde o algoritmo de treinamento relevante pudesse ser executado. Do ponto de vista de privacidade, isso é problemático, especialmente quando os dados de treinamento contêm informações confidenciais ou de identificação pessoal. As pessoas usuárias podem relutar em compartilhar dados ou a legislação local de proteção de dados pode nos impedir de mover os dados para um local central. O ML federado é uma técnica descentralizada para treinamento em um grande conjunto diversificado de dados que permite que os dados permaneçam remotos, por exemplo, no dispositivo de uma pessoa usuária. A largura de banda da rede e as limitações computacionais dos dispositivos ainda apresentam desafios técnicos significativos, mas gostamos da maneira como o aprendizado de máquina federado deixa os usuários no controle de suas próprias informações pessoais.

Temos abordado plataformas de desenvolvimento e como construí-las em quase todas as edições do Radar desde 2017. Enquanto isso, o livro Team Topologies também fez um ótimo trabalho ao descrever uma plataforma ideal que oferece suporte a pessoas desenvolvedoras com "APIs de autoatendimento, ferramentas, serviços e conhecimento". No entanto, muitas vezes vemos times buscando adotar muito dessa visão de plataforma muito rápido. Em vez disso, construir uma plataforma de desenvolvimento incremental é a chave.

O Team Topologies recomenda sempre buscar o que chamam de "plataforma mais enxuta viável" necessária em qualquer estágio, na qual a primeira versão pode até ser apenas um conjunto de documentação em um wiki. O próximo incremento pode aumentar o nível de serviço fornecendo modelos ou permitindo que os times criem pull requests. Incrementos adicionais poderiam então introduzir APIs de autoatendimento, mas somente se valiosas. Em suma, embora tenhamos alertado contra modelos operacionais de plataforma totalmente orientados por tickets, passar de zero ao autoatendimento é o outro extremo. Siga seu ritmo, trate sua plataforma como um produto e construa-a de forma incremental.

Desde sua introdução no Radar em 2016, vimos uma ampla adoção de micro frontends para interfaces de usuário web. Recentemente, no entanto, observamos projetos estendendo esse estilo de arquitetura para incluir também micro frontends para aplicativos móveis. Quando um aplicativo se torna suficientemente grande e complexo, torna-se necessário distribuir o desenvolvimento entre vários times. Isso apresenta uma série de desafios em torno da autonomia do time, estruturas de repositório e frameworks de integração. No passado, mencionamos Atlas e BeeHive, mas esses frameworks não conseguiram ganhar força e não estão mais em desenvolvimento ativo. Abordagens mais recentes incluem Tuist ou Swift Package Manager para integrar o trabalho de vários times em um único aplicativo. Mas, em nossa experiência, os times geralmente acabam implementando seu próprio framework de integração. Embora definitivamente vejamos a necessidade de modularidade na ampliação dos times de desenvolvimento móvel, o caso dos micro frontends é menos certo. Isso porque enquanto os micro frontends implicam uma correspondência direta entre times e páginas ou componentes, essa estrutura pode acabar confundindo responsabilidades por contextos de domínio de negócio, aumentando assim a carga cognitiva do time. Nosso conselho é seguir o básico de um design de aplicativo bom e limpo, adotar a modularidade ao escalar para vários times e adotar uma arquitetura de micro frontend somente quando os módulos e o domínio de negócio estiverem fortemente alinhados.

As práticas de observabilidade mudaram o foco da conversa de monitoramento de problemas bem compreendidos para apoio na solução de problemas desconhecidos em sistemas distribuídos. Tivemos sucesso ao tirar essa perspectiva do ambiente de produção tradicional, aplicando observabilidade para pipelines de CI/CD para ajudar a otimizar os gargalos de teste e implantação. Pipelines complexos criam atrito para pessoas desenvolvedoras quando são executados muito lentamente ou sofrem de não determinismo, reduzindo importantes ciclos de feedback e prejudicando a eficiência da pessoa desenvolvedora. Além disso, seu papel como infraestrutura de implantação crítica cria pontos de estresse durante os períodos de deployment rápidos, como aconteceu com várias organizações que responderam à recente vulnerabilidade do log4shell. O conceito de rastreamentos se traduz muito bem em pipelines: em vez de capturar a cascata de chamadas de serviço, os child spans capturam informações sobre cada estágio da compilação. Os mesmos gráficos em cascata usados ​​para analisar um fluxo de chamadas em uma arquitetura distribuída também podem ser eficazes para nos ajudar a identificar gargalos em pipelines, mesmo que sejam complexos com fan-in e fan-out. Isso permite esforços de otimização com foco muito melhor definido. Embora a técnica deva funcionar com qualquer ferramenta de rastreamento, o Honeycomb suporta uma ferramenta chamada buildevents que ajuda a capturar informações sobre o rastreamento de pipelines. Uma abordagem alternativa de captura de informações já expostas por plataformas CI/CD, feita pela ferramenta de código aberto buildviz (desenvolvida e mantida por um Thoughtworker), permite uma investigação semelhante sem alterar as próprias configurações da etapa.

À medida que a complexidade do software continua a crescer, proteger-se do vetor de ameaças de dependências de software torna-se cada vez mais desafiador. Níveis de Cadeia de Fornecimento para Artefatos de Software (Supply chain Levels for Software Artifacts, em inglês), ou SLSA (pronuncia-se "salsa"), é uma curadoria de orientações para ajudar as organizações a se protegerem de ataques à cadeia de fornecimento, e uma evolução do conjunto de orientações interno que o Google vem usando há anos. Apreciamos que SLSA não promete uma abordagem "bala de prata" baseada apenas em ferramentas para proteger a cadeia de fornecimento, mas provê uma lista de verificação de ameaças e práticas concretas junto a um modelo de maturidade. O modelo de ameaças é fácil de seguir com exemplos reais de ataques e os requisitos fornecem orientações para ajudar as organizações a priorizar ações com base em níveis de robustez crescentes para melhorar sua postura de segurança na cadeia de fornecimento. Desde que incluímos pela primeira vez no Radar, SLSA adicionou mais detalhes sobre atestados de software com exemplos para rastrear preocupações como proveniência de compilação. Nossos times concluíram que SLSA consegue um bom equilíbrio entre a orientação para implementação e a conscientização de alto nível sobre as ameaças da cadeia de fornecimento.

Com a pressão contínua para manter os sistemas seguros e nenhum sinal de recuo no cenário geral de ameaças, uma lista de materiais de software (Software Bill of Materials ou SBOM) legível por máquina pode ajudar os times a se manterem atualizados sobre os problemas de segurança nas bibliotecas das quais dependem. Desde que a Ordem Executiva original foi publicada, a indústria compreendeu o que é uma SBOM e como criá-la. O National Institute of Standards and Technology (NIST), por exemplo, agora tem mais recomendações específicas sobre como cumprir a ordem. Temos experiência de produção usando SBOMs em projetos que vão de pequenas empresas a grandes multinacionais e até departamentos governamentais, e temos convicção de que trazem benefícios. Mais organizações e governos devem considerar exigir SBOMs para software em uso. A técnica será fortalecida por novas ferramentas que continuam surgindo, como Firebase Android BOM que alinha automaticamente as dependências da biblioteca de uma aplicação àquelas listadas na SBOM.

A sustentabilidade é um tema que demanda a atenção das empresas. No espaço de desenvolvimento de software, sua importância aumentou, e agora estamos vendo diferentes maneiras para abordar este tema. Observando a pegada de carbono do desenvolvimento de software, por exemplo, recomendamos avaliar a eficiência de carbono como uma característica arquitetural. Uma arquitetura que leva em consideração a eficiência de carbono é aquela em que as escolhas de design e infraestrutura são feitas para minimizar o consumo de energia e, portanto, as emissões de carbono. As ferramentas de medição e recomendações neste espaço estão amadurecendo, tornando viável que os times considerem a eficiência de carbono juntamente com outros fatores como desempenho, escalabilidade, custo financeiro e segurança. Como quase tudo na arquitetura de software, isso deve ser considerado como uma compensação. Nosso conselho é pensar nisso como uma característica adicional em todo um conjunto de atributos de qualidade relevantes que são orientados e priorizados por objetivos organizacionais, e não relegados a um pequeno grupo de especialistas para refletir de forma isolada.

Como você aborda a escrita de um bom código? Como você avalia se escreveu um bom código? Como pessoas desenvolvedoras de software, estamos sempre buscando regras, princípios e padrões interessantes que possamos usar para compartilhar linguagem e valores ao escrever código simples e fácil de alterar.

Daniel Terhorst-North recentemente executou uma nova tentativa de criar uma lista de verificação para um bom código. Ele argumenta que, em vez de se ater a um conjunto de regras como SOLID, usar um conjunto de propriedades para visar é mais aplicável. Ele criou o que chama de propriedades CUPID para descrever o que devemos nos esforçar para alcançar um código "joyful": o código deve ser composable, seguir a filosofia Unix e ser previsível, idiomático e baseado em domínio.

A publicação acidental de segredos parece ser um problema perene, à medida que ferramentas como Talisman surgem para ajudar a resolver o problema. Até agora, os usuários do GitHub Enterprise Cloud com uma licença de segurança avançada podiam habilitar a verificação de segurança em suas contas, e quaisquer segredos (chaves de API, tokens de acesso, credenciais etc.) que fossem acidentalmente enviados acionariam um alerta. GitHub push protection dá um passo adiante, e traz isso para uma etapa anterior no fluxo de trabalho de desenvolvimento, impedindo que as alterações sejam enviadas se segredos forem detectados. Isso precisa ser configurado para a organização e se aplica evidentemente apenas aos detentores de licenças, mas a proteção adicional contra a publicação de segredos é bem-vinda.

Em uma aplicação centralizada, os dados no servidor são a única fonte de verdade — qualquer modificação nos dados deve passar pelo servidor. Os dados locais são subordinados à versão do servidor. Esta parece ser uma escolha natural e inevitável para permitir a colaboração entre vários usuários do software. Aplicação local-first , ou software local-first, é um conjunto de princípios que permite tanto colaboração quanto propriedade de dados locais. A abordagem prioriza o uso de armazenamento local e redes locais em relação a servidores em data centers remotos ou na nuvem. Técnicas como tipos de dados replicados sem conflito (CRDTs) e redes peer-to-peer (P2P) têm o potencial de ser uma tecnologia fundamental para a realização de software local-first.

Um repositório de métricas, às vezes chamado de headless business intelligence (BI), é uma camada que desacopla as definições de métricas a partir de seu uso em relatórios e visualizações. Tradicionalmente, métricas são definidas dentro do contexto das ferramentas de BI, mas essa abordagem leva a duplicações e inconsistências, pois diferentes times as utilizam em diferentes contextos. Ao desacoplar a definição no repositório de métricas, obtemos uma reutilização nítida e consistente em relatórios de BI, visualizações e até análises incorporadas. Esta técnica não é nova. Por exemplo, o Airbnb introduziu o Minerva um ano atrás. No entanto, agora estamos vendo uma tração considerável no ecossistema de dados e análises com mais ferramentas que suportam repositórios de métricas prontas para uso.

A interface de usuário orientada a servidor continua a ser um assunto polêmico nos círculos de discussão sobre dispositivos móveis, porque oferece às pessoas desenvolvedoras o potencial de aproveitar os ciclos de mudança mais rápidos sem entrar em conflito com as políticas das lojas de aplicativos sobre a revalidação do próprio aplicativo para dispositivos móveis. A interface de usuário orientada ao servidor separa a renderização em um contêiner genérico no aplicativo móvel, enquanto a estrutura e os dados de cada visualização são fornecidos pelo servidor. Isso significa que as alterações que antes exigiam um percurso de ida e volta a uma loja de aplicativos agora podem ser realizadas por meio de alterações simples nas respostas que o servidor envia. Embora alguns times de aplicativos móveis muito grandes tenham obtido bastante sucesso com essa técnica, isso também exige um investimento substancial na construção e manutenção de um framework proprietário complexo. Tal investimento requer um caso de negócio convincente. Até que haja bons argumentos, talvez seja melhor proceder com cautela. Na verdade, nós tivemos algumas experiências com bagunças terríveis e excessivamente configuráveis ​​que não entregaram os benefícios prometidos. Mas com o apoio de gigantes como Airbnb e Lyft, podemos verdadeiramente ver surgir alguns frameworks úteis capazes de ajudar a domar a complexidade. Fique de olho nesse espaço.

Desde que o Google popularizou indicadores de nível de serviço (SLIs) e objetivos de nível de serviço (SLOs) como parte de sua prática de engenharia de confiabilidade do site (SRE), ferramentas de observabilidade como Datadog, Honeycomb e Dynatrace começaram a incorporar o monitoramento de SLOs em seu conjunto de ferramentas. OpenSLO é um padrão emergente que permite definir SLIs e SLOs como código , usando uma linguagem de especificação declarativa e independente de fornecedor com base no formato YAML usado por Kubernetes. Embora o padrão ainda seja bastante novo, estamos vendo uma conjuntura positiva, como é o caso da contribuição da ferramenta slogen, da Sumo Logic, para gerar monitoramento e painéis. Estamos otimistas com a promessa de versionar as definições de SLI e SLO no código e atualizar as ferramentas de observabilidade como parte do pipeline de CI/CD do serviço que está sendo implantado.

Durante nossas discussões para esta edição do Radar, surgiram várias ferramentas e aplicações para geração de dados sintéticos. À medida que as ferramentas amadurecem, descobrimos que usar dados sintéticos para testes de modelos é uma técnica poderosa e amplamente útil. Embora não pretenda substituir os dados reais na validação do poder de discriminação dos modelos de aprendizado de máquina, os dados sintéticos podem ser usados ​​em diversas situações. Por exemplo, podem ser usados para proteção contra falhas catastróficas do modelo em resposta a eventos que ocorrem raramente ou para testar pipelines de dados sem expor informações de identificação pessoal. Dados sintéticos também são úteis para explorar casos extremos que não possuem dados reais ou para identificar vieses de modelo. Algumas ferramentas úteis para gerar dados incluem Faker ou Synth, que geram dados de acordo com as propriedades estatísticas desejadas, e ferramentas como Synthetic Data Vault, que podem gerar dados que imitam as propriedades de um conjunto de dados de entrada.

Continua nos entusiasmando a técnica de TinyML e a capacidade de criar modelos de aprendizado de máquina (ML) projetados para serem executados em dispositivos móveis e de baixa potência. Até recentemente, a execução de um modelo de ML era vista como computacionalmente cara e, em alguns casos, exigia hardware para fins especiais. Embora a criação dos modelos ainda esteja amplamente dentro dessa classificação, os modelos agora podem ser criados de uma maneira que permita sua execução em dispositivos pequenos, de baixo custo e baixo consumo de energia. Se você está pensando em usar ML mas considerava inviável devido a restrições de computação ou rede, vale a pena avaliar essa técnica.

Quando as incluímos pela primeira vez no Radar, há dois anos, as credenciais verificáveis eram um padrão intrigante com algumas aplicações promissoras em potencial, mas não eram amplamente conhecidas ou entendidas fora da comunidade de entusiastas. Isso era particularmente verdadeiro quando se tratava de instituições de concessão de credenciais, como governos de estado, que seriam responsáveis ​​pela implementação dos padrões. Dois anos e uma pandemia depois, a demanda por credenciais eletrônicas criptograficamente seguras, que respeitam a privacidade e são verificáveis ​​por máquina cresceu e, como resultado, os governos estão começando a despertar para o potencial das credenciais verificáveis. Agora estamos começando a ver as credenciais verificáveis surgirem em nossos trabalhos para clientes do setor público. O padrão W3C coloca titulares de credenciais no centro, o que é semelhante à nossa experiência ao usar credenciais físicas: as pessoas usuárias podem colocar suas credenciais verificáveis ​​em suas próprias carteiras digitais e mostrá-las a qualquer pessoa a qualquer momento sem a permissão da entidade emissora das credenciais. Essa abordagem descentralizada também permite que os usuários gerenciem melhor e divulguem seletivamente suas próprias informações, o que melhora muito a proteção da privacidade dos dados. Por exemplo, com tecnologia de prova de conhecimento zero, você pode construir uma credencial verificável para provar que é uma pessoa adulta sem revelar seu aniversário. É importante notar que, embora muitas soluções de identidade descentralizada baseadas em credenciais verificáveis dependam da tecnologia de blockchain, blockchain não é um pré-requisito para todas as implementações de credenciais verificáveis.

O termo "configuração de times remotos" não descreve apenas uma configuração, mas abrange vários padrões e nuances. E muitos times vêm mudando os padrões recentemente. Estão saindo do modo "todo mundo sempre remoto" que foi imposto pela pandemia e mudando para um padrão de profissionais satélite (muitas em rotatividade), no qual parte do time está colocalizado enquanto outra parte fica remota. Vemos muitos times falhando ao não considerar adequadamente o que isso significa para suas formas de trabalho. Profissionais satélite sem formas de trabalho "nativamente remotas" são um retrocesso no sentido de privilegiar práticas colocalizadas. Em uma configuração com profissionais satélite, é importante ainda usar processos e abordagens "nativamente remotos" por padrão. Por exemplo, se a parte colocalizada do time ingressar em uma reunião, todos os membros ainda devem estar em seus laptops individuais para participar da colaboração digital ou do bate-papo da reunião. Os times precisam estar cientes do risco de excluir profissionais satélites, criando silos e sentimentos de exclusão. Se você sabe que sempre terá pelo menos um membro satélite no time, as formas padrão de trabalho devem considerar a condição remota.

A prevalência de times que escolhem uma aplicação de página única (SPA) quando precisam de um site continua. Ainda nos preocupa que as pessoas não estejam reconhecendo adequadamente SPAs como um estilo arquitetural inicialmente; em vez disso, elas estão imediatamente pulando para a seleção do framework. SPAs incorrem em uma complexidade que simplesmente não existe em sites tradicionais baseados em servidor: questões como otimização de mecanismos de pesquisa, gerenciamento de histórico do navegador, web analytics e tempo de carregamento da primeira página precisam ser abordadas. A análise e a consideração adequadas das vantagens e desvantagens são necessárias para determinar se essa complexidade é justificada por motivos de negócios ou de experiência do usuário. Muitas vezes, as equipes ignoram essa análise, aceitando cegamente a complexidade de SPAs por padrão , mesmo quando as necessidades de negócio não justificam. Ainda vemos algumas pessoas desenvolvedoras que não conhecem uma abordagem alternativa porque passaram toda a sua carreira usando um framework como o React. Acreditamos que muitos sites se beneficiarão da simplicidade da lógica do lado do servidor e técnicas como Hotwire, que ajudam a resolver os problemas com a experiência do usuário, nos encorajam.

O termo "cloud native" foi originalmente usado para descrever arquiteturas com características que tiravam o máximo proveito da hospedagem em nuvem pública. Os exemplos incluem arquiteturas distribuídas compostas por muitos processos pequenos, sem estado e colaborativos, e sistemas com altos níveis de automação para construção, teste e implantação de aplicações. No entanto, notamos uma tendência crescente para design nativo de nuvem superficial , que simplesmente usa muitos serviços proprietários de um fornecedor de nuvem e para por aí, sem revisitar a natureza fundamentalmente monolítica, frágil ou com muitas tarefas manuais e repetitivas da aplicação. É importante lembrar que as funções sem servidor por si só não tornam uma aplicação mais resiliente ou mais fácil de manter, e que a nuvem nativa é realmente uma questão de design e não um conjunto de opções de implementação.