Arquiteturas de back-end para back-ends de apps da Web orientados por conteúdo

A arquitetura de back-end se refere a como o back-end do seu aplicativo da Web é estruturado. A arquitetura de back-end determina como as partes do aplicativo se comunicam entre si para processar as solicitações recebidas e criar respostas. Ao criar um aplicativo da Web, selecione uma arquitetura de back-end com base em seus requisitos e fatores específicos, incluindo custo (contínuo e em escala), a complexidade do aplicativo, as metas de escalonamento e a experiência da sua equipe.

Especificamente para aplicativos da Web orientados a conteúdo, como e-commerce, jornais ou blogs, os requisitos críticos incluem a consistência dos dados e o desempenho, especialmente à medida que o aplicativo cresce em escala global e pode se tornar mais distribuído. Para aplicativos da Web voltados para conteúdo, o armazenamento de dados usado pelo aplicativo também é essencial e é discutido em mais detalhes no guia de armazenamento de dados. Ir além de arquiteturas de aplicativos típicas, hospedar seu conteúdo e torná-lo acessível é essencial ao otimizar o desempenho do seu app. Saiba mais sobre como selecionar a estratégia de hospedagem certa e otimizar seu app no guia de hospedagem.

Se você já tiver um back-end para um aplicativo da Web, considere os limites da sua arquitetura atual. Por exemplo, à medida que o aplicativo é escalonado e as demandas no desempenho e na confiabilidade aumentam, considere se partes do aplicativo precisam ser refatoradas ou movidas para uma arquitetura diferente mais adequada ao aumento da escala. Por exemplo, Arquiteturas híbridas (ou de várias cloud) permitem transferir algumas cargas de trabalho para a nuvem antes de fazer uma transição completa. Também é essencial considerar o custo, o tempo e o risco envolvidos nessa migração.

Arquiteturas monolíticos

Uma arquitetura monolítica tem uma estrutura unificada, com todos os componentes do aplicativo totalmente integrados em uma única base de código. O aplicativo inteiro é criado como uma unidade independente. A arquitetura monolítico tem várias camadas, em que diferentes camadas do aplicativo realizam tarefas específicas.

Camadas estruturais

• A interface do usuário (interface), que inclui componentes para apresentar os recursos do aplicativo, geralmente é um aplicativo baseado na Web ou para computadores que interage com os usuários.
• A lógica do aplicativo é onde reside o recurso principal.Essa parte da base do código contém as regras, os cálculos e as operações que definem como o aplicativo funciona.
• A camada de acesso a dados contém funções para ler e gravar dados, além de converter entre as estruturas de dados do aplicativo e o esquema do banco de dados. Essa camada é responsável por interagir com o banco de dados ou o armazenamento de dados do aplicativo.
• O banco de dados é onde o aplicativo armazena os dados. Geralmente, há um único banco de dados que armazena todos os dados do aplicativo, incluindo dados do usuário, configurações e outras informações.
• Os componentes de middleware processam tarefas como autenticação, roteamento de solicitações e validação de dados. Esses componentes ajudam a gerenciar o fluxo de dados e solicitações.
• Alguns aplicativos monolíticos têm pontos de integração com APIs ou serviços externos. Esses pontos permitem que o aplicativo interaja com serviços de terceiros, fontes de dados ou outros sistemas.

As camadas estruturais geralmente fazem parte de uma única base de código. Essa base de código contém todo o aplicativo e geralmente é organizada em diretórios, módulos e classes. Os desenvolvedores trabalham em várias partes da base do código para criar e manter o aplicativo. No entanto, o aplicativo inteiro é normalmente implantado como uma única unidade. Quando são feitas atualizações ou alterações, o aplicativo inteiro é reimplantado.

Possíveis desafios

• À medida que os aplicativos monolíticos crescem, a base de código tende a se tornar complexa e difícil de manter. Isso pode resultar em ciclos de desenvolvimento longos e dificuldade para entender toda a base de código.
• Implantar alterações em um aplicativo monolítico pode ser arriscado, porque as alterações feitas em uma parte do código podem afetar inadvertidamente outras partes do aplicativo. Isso pode criar um processo de implantação demorado e propenso a erros.
• Os aplicativos monolíticos podem ser difíceis de escalonar, porque são implantados como uma única unidade. É necessário escalonar todo o aplicativo, mesmo que apenas um componente tenha um aumento na demanda.
• Como os aplicativos monolíticos geralmente dependem de uma única pilha de tecnologia ou linguagem de programação, sua capacidade de usar a melhor ferramenta para uma tarefa específica no aplicativo pode ser limitada.
• Mesmo durante períodos de baixa demanda, os aplicativos monolíticos exigem recursos significativos para funcionar. Os custos de manutenção também aumentam à medida que o aplicativo envelhece, à medida que se torna mais difícil atualizar e corrigir o aplicativo sem causar regressões.
• As equipes de desenvolvimento que trabalham em aplicativos monolíticos geralmente são organizadas em torno do aplicativo inteiro, o que leva a equipes maiores e coordenação mais complexa entre os membros da equipe.

Uso sugerido

As arquiteturas monolíticos são adequadas quando um aplicativo tem requisitos modestos e a equipe de desenvolvimento é pequena. À medida que um aplicativo cresce em complexidade e escala, ou quando diferentes partes do aplicativo exigem diferentes tecnologias ou estratégias de implantação, as arquiteturas monolíticas podem se tornar menos flexíveis e mais desafiadoras de manter.

Você pode criar e gerenciar máquinas virtuais que podem executar aplicativos monolíticos no Compute Engine. Você tem controle total sobre os sistemas operacionais, o software e o gerenciamento dessas máquinas virtuais para executar seu aplicativo monolítico.

Com um serviço de plataforma como serviço, como o App Engine, é possível criar seu aplicativo e executá-lo em uma infraestrutura totalmente gerenciada que é escalonada automaticamente com as solicitações.

Se o aplicativo monolítico estiver em contêiner, é possível executá-lo usando o Google Kubernetes Engine (GKE) ou o Cloud Run. É possível usar serviços como o Cloud SQL ou o Cloud Spanner para armazenar dados de aplicativos monolíticos. Considere uma combinação de serviços e sistemas com base nos requisitos específicos do seu aplicativo.

Arquiteturas sem servidor

Com a arquitetura sem servidor, é possível criar e executar aplicativos sem gerenciar servidores físicos ou virtuais. O provedor de nuvem gerencia automaticamente a infraestrutura, o escalonamento e a alocação de recursos para que os desenvolvedores possam se concentrar em escrever o código dos aplicativos. As arquiteturas sem servidor podem simplificar o desenvolvimento, reduzir a sobrecarga operacional e otimizar os custos, eliminando a necessidade de manter servidores. Eles são adequados para microsserviços, processamento de dados em tempo real, aplicativos da Web com cargas de trabalho variáveis e processamento de eventos.

Arquiteturas sem servidor baseadas em eventos

As arquiteturas sem servidor baseadas em eventos são um tipo específico de arquitetura de computação sem servidor que depende de eventos ou gatilhos para iniciar a execução de funções ou microsserviços. Os componentes do sistema se comunicam por eventos, e as funções são invocadas em resposta a eles. Elas geralmente dependem da comunicação assíncrona, já que as funções são acionadas por eventos e, em seguida, processam-as de maneira independente e podem produzir eventos que acionam ações subsequentes. Esse tipo de arquitetura sem servidor é uma boa opção para criar sistemas escalonáveis, responsivos e acoplados com flexibilidade.

O Google Cloud Functions e o Cloud Functions para Firebase permitem criar e implantar funções orientadas a eventos em um ambiente totalmente gerenciado e sem servidor. Ele permite que você execute código em resposta a vários eventos e gatilhos, incluindo solicitações HTTP, mensagens do Cloud Pub/Sub, alterações no Google Cloud Storage e atualizações do Firebase Realtime Database, sem a necessidade de gerenciar a infraestrutura. Os principais recursos incluem suporte a várias linguagens, escalonabilidade, faturamento granular, integrações de terceiros, geração de registros e monitoramento robustos e integração com outros serviços do Google e do Firebase.

Arquiteturas sem servidor podem ser econômicas em muitos casos de uso, especialmente para aplicativos com cargas de trabalho variadas, necessidades de desenvolvimento rápido e tráfego imprevisível. A confiabilidade depende do provedor de nuvem, com contratos de nível de serviço (SLAs) em vigor para garantir metas específicas de desempenho e confiabilidade. Avalie seu caso de uso e requisitos específicos para determinar se a arquitetura sem servidor é a melhor opção.

Conteinerização

A conteinerização permite que aplicativos e as dependências deles sejam empacotados em contêineres leves e portáteis. Eles oferecem um ambiente de aplicativo consistente compatível com o desenvolvimento e a implantação em diferentes sistemas e plataformas. Algumas plataformas sem servidor oferecem a capacidade de executar cargas de trabalho em contêineres. A execução de contêineres em um ambiente sem servidor pode ser benéfico quando você tem cargas de trabalho complexas ou com estado que não podem ser expressas como funções básicas. Ele oferece flexibilidade em termos de suporte a linguagens e ambientes de execução.

O Cloud Run é uma plataforma de computação sem servidor que permite aos desenvolvedores implantar e executar aplicativos conteinerizados em um ambiente totalmente gerenciado. Ele fornece uma maneira simples de criar, implantar e escalonar aplicativos sem gerenciar a infraestrutura subjacente. Ele é adequado para uma ampla variedade de aplicativos da Web e de microsserviços, especialmente aqueles com cargas de trabalho variáveis, em que a conteinerização oferece benefícios em termos de empacotamento e consistência de aplicativos.

Arquiteturas de microsserviço

Os aplicativos são divididos em pequenas partes que são fracamente acopladas e implementam recursos ou capacidades distintos. Esses serviços podem se comunicar por mensagens assíncronas, canais com base em eventos ou diretamente expondo uma interface. Cada serviço é desenvolvido, testado e escalonado de maneira independente no próprio contêiner, que geralmente é gerenciado por um serviço de orquestração, como o Kubernetes, ou implantado usando uma plataforma gerenciada, como o Cloud Run.

As implantações de microsserviço geralmente também aproveitam o paradigma de aplicativo sem servidor ao não depender de um servidor centralizado.

Separar um aplicativo em serviços autônomos pode simplificar um sistema complexo. Limites e objetivos bem definidos podem acelerar o desenvolvimento e melhorar a manutenção. Cada microsserviço pode ser desenvolvido de forma independente usando os frameworks ou ferramentas mais eficazes. A comunicação entre serviços geralmente é processada usando eventos, comunicação de publicação/assinatura, pipelines de mensagens ou chamadas de procedimento remoto, como gRPC.

Para a orquestração de tarefas em uma arquitetura de microsserviço, use um framework que ofereça suporte às plataformas que você está segmentando, profundidade suficiente para as tarefas e os tipos de fluxos de trabalho que você está orquestrando, bem como o tratamento de erros e a telemetria para depurar problemas. As opções conhecidas incluem Conductor ou ofertas de um provedor de nuvem, como o Google Workflows.

Os aplicativos baseados em microsserviços podem ser complexos de desenvolver e manter devido à natureza distribuída e à necessidade de comunicação entre serviços. Portanto, gerenciar implantações, o monitoramento e a geração de registros são mais complexos do que outras opções de arquitetura. Como a confiabilidade depende da arquitetura dos serviços individuais, a natureza distribuída pode oferecer resiliência adicional, especialmente se o monitoramento e a telemetria forem implantados e ativados, se necessário.

Comparação de arquiteturas diferentes para back-ends de aplicativos da Web orientados por conteúdo

A tabela a seguir compara arquiteturas com os principais requisitos para o back-end de um aplicativo da Web orientado por conteúdo.

	Arquiteturas monolíticos	Arquiteturas sem servidor baseadas em eventos	Arquiteturas de microsserviços sem servidor
Complexidade e manutenção	A facilidade de implementação para projetos pequenos e independentes, mas a complexidade aumenta com a escala. Requer coordenação e manutenção manuais.	O escalonamento é compatível e integrado à plataforma. A solução de problemas e a depuração podem ser desafiadoras. Não é necessário gerenciar a infraestrutura.	Serviços independentes que são testados e implantados de maneira independente, facilitando a manutenção de cada unidade. Requer uma comunicação cuidadosa entre os serviços. Requer ferramentas de gerenciamento e orquestração para gerenciar em grande escala.
Escalonabilidade e desempenho	Eficiente em pequena escala, difícil de escalonar além de um tamanho específico. Necessidades específicas da infraestrutura, limitando as opções de escalonamento dinâmico. Escalonamento manual (ou uso de serviços manuais) na arquitetura, por exemplo, por meio do balanceamento de carga.	Escalonabilidade integrada com o uso de uma plataforma gerenciada. Escala em qualquer direção.	Cada serviço é personalizado para uma necessidade específica e pode ser escalonado e otimizado de maneira independente.
Estratégias de resiliência e alternativa	A implantação é complexa e pode levar a inatividade ("tudo ou nada").	Inerente ao provedor de nuvem. É possível tentar novamente cada função independente de forma independente.	Cada serviço é independente, tornando o sistema geral mais resiliente por meio de testes e desenvolvimento independentes.
Experiência em desenvolvimento	Desenvolvimento rápido em pequena escala por meio do acoplamento rígido da arquitetura (por exemplo, por meio de consultas eficientes). Tempos de compilação longos e difícil colaboração e testes à medida que a complexidade aumenta.	Não é necessário manter e gerenciar uma infraestrutura, o que acelera o desenvolvimento. Testar e depurar um aplicativo ativo depende dos serviços do provedor de nuvem.	Os serviços são independentes e podem ser desenvolvidos independentemente uns dos outros. Um grande número de serviços precisa ser coordenado e gerenciado.
Custo	Desenvolvimentos complexos podem aumentar os custos. Requer um investimento significativo em hardware ou infraestrutura, especialmente em uma escala maior. É difícil alcançar a eficiência de custo resultante do escalonamento vertical e horizontal.	Sem custos de hardware dedicado. Escalonamento vertical e horizontal para otimizar o uso e os custos de recursos (até zero).	Sem custos de hardware dedicado. Escalonamento vertical e horizontal para otimizar o uso de recursos e os custos dentro dos limites. Custos adicionais de monitoramento e gerenciamento de um grande conjunto de serviços independentes.

Saiba mais sobre arquiteturas de back-end para aplicativos da Web orientados por conteúdo

Aqui estão alguns recursos para saber mais sobre arquiteturas para aplicativos da Web orientados por conteúdo, incluindo como migrar seu app para uma arquitetura diferente:

• Saiba mais sobre arquiteturas de back-end de aplicativos da Web acopladas com flexibilidade, incluindo aplicativos da Web monolíticos e sem servidor em camadas.

• Como migrar um aplicativo monolítico para uma arquitetura de microsserviço.

• Casos de uso típicos do Cloud Functions sem servidor.