Os componentes de arquitetura de um aplicativo podem ser categorizados como front-end ou back-end. Em alguns cenários, esses componentes podem ser hospedados para operar em diferentes ambientes de computação. Como parte do padrão de arquitetura híbrido em camadas, os ambientes de computação estão localizados em um ambiente de computação particular local e em Google Cloud.
Os componentes do aplicativo de front-end são expostos diretamente a usuários finais ou dispositivos. Como resultado, esses aplicativos geralmente são sensíveis ao desempenho. Para desenvolver novos recursos e melhorias, as atualizações de software podem ser frequentes. Como os aplicativos de front-end geralmente dependem de aplicativos de back-end para armazenar e gerenciar dados, além de lógica de negócios e processamento de entrada do usuário, eles geralmente são sem estado ou gerenciam apenas volumes limitados de dados.
Para que sejam acessíveis e utilizáveis, crie seus aplicativos de front-end com vários frameworks e tecnologias. Alguns fatores importantes para um aplicativo de front-end bem-sucedido incluem a performance do aplicativo, a velocidade de resposta e a compatibilidade do navegador.
Os componentes de aplicativos de back-end geralmente se concentram no armazenamento e no gerenciamento de dados. Em algumas arquiteturas, a lógica de negócios pode ser incorporada ao componente de back-end. Novas versões de aplicativos de back-end tendem a ser menos frequentes do que versões para aplicativos de front-end. Os aplicativos de back-end têm os seguintes desafios a serem gerenciados:
- Como processar um grande volume de solicitações
- Como lidar com um grande volume de dados
- Como proteger dados
- Manter dados atuais e atualizados em todas as réplicas do sistema
A arquitetura de aplicativos de três camadas é uma das implementações mais usadas para criar aplicativos da Web de negócios, como sites de e-commerce que contêm diferentes componentes de aplicativos. Essa arquitetura contém os seguintes níveis. Cada nível opera de forma independente, mas eles estão intimamente vinculados e funcionam juntos.
- Front-end da Web e camada de apresentação
- Nível do aplicativo
- Camada de back-end ou de acesso a dados
Colocar essas camadas em contêineres separa as necessidades técnicas, como requisitos de escalonamento, e ajuda a migrar em etapas. Além disso, é possível implantá-los em serviços de nuvem independentes de plataforma que podem ser portáteis em vários ambientes, usar gerenciamento automatizado e dimensionar com plataformas gerenciadas por nuvem, como o Cloud Run ou o Google Kubernetes Engine (GKE) Enterprise Edition. Além disso, bancos de dados gerenciados porGoogle Cloud, como o Cloud SQL, ajudam a fornecer o back-end como a camada de banco de dados.
O padrão de arquitetura híbrida em camadas se concentra na implantação de componentes de aplicativos de front-end na nuvem pública. Nesse padrão, você mantém todos os componentes de aplicativos de back-end no ambiente de computação particular. Dependendo da escala e do design específico do aplicativo, é possível migrar componentes de aplicativos front-end caso a caso. Para mais informações, consulte Migrar para Google Cloud.
Se você já tem um aplicativo com componentes de back-end e front-end hospedados no ambiente local, considere os limites da sua arquitetura atual. Por exemplo, à medida que o aplicativo é dimensionado e as demandas de desempenho e confiabilidade aumentam, é necessário avaliar se partes do aplicativo precisam ser refatoradas ou movidas para uma arquitetura diferente e otimizada. O padrão de arquitetura híbrido em camadas permite transferir algumas cargas de trabalho e componentes de aplicativos 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.
O diagrama a seguir mostra um padrão de arquitetura híbrido em camadas típico.
No diagrama anterior, as solicitações do cliente são enviadas para o front-end do aplicativo hospedado em Google Cloud. Por sua vez, o front-end do aplicativo envia dados de volta ao ambiente local em que o back-end do aplicativo está hospedado (de preferência por um gateway de API).
Com o padrão de arquitetura híbrido em camadas, é possível aproveitar a infraestruturaGoogle Cloud e os serviços globais, conforme mostrado no exemplo de arquitetura no diagrama a seguir. O front-end do aplicativo pode ser acessado por Google Cloud. Ele também pode adicionar elasticidade ao front-end usando o escalonamento automático para responder de forma dinâmica e eficiente à demanda de escalonamento sem sobrecarregar a infraestrutura. Existem diferentes arquiteturas que podem ser usadas para criar e executar apps da Web escalonáveis no Google Cloud. Cada arquitetura tem vantagens e desvantagens para requisitos diferentes.
Para mais informações, assista o vídeo Três formas de executar apps da Web escalonáveis no Google Cloud no YouTube. Para saber mais sobre as diferentes maneiras de modernizar sua plataforma de e-commerce no Google Cloud, consulte Como criar uma plataforma de comércio digital no Google Cloud.
No diagrama anterior, o front-end do aplicativo é hospedado em Google Cloud para fornecer uma experiência do usuário multirregional e otimizada globalmente que usa o balanceamento de carga global, o dimensionamento automático e a proteção contra DDoS pelo Google Cloud Armor.
Com o tempo, o número de aplicativos implantados na nuvem pública pode aumentar a ponto de você considerar mover componentes de aplicativos de back-end para a nuvem pública. Se você espera oferecer tráfego intenso, optar por serviços gerenciados em nuvem pode ajudar a economizar esforços de engenharia ao gerenciar sua própria infraestrutura. Considere essa opção, a menos que restrições ou requisitos exijam a hospedagem de componentes de aplicativos de back-end no local. Por exemplo, se os dados do back-end estiverem sujeitos a restrições regulamentares, provavelmente será necessário manter esses dados no local. No entanto, quando aplicável e em conformidade, o uso de recursos de Proteção de dados sensíveis, como técnicas de desidentificação, pode ajudar a transferir esses dados quando necessário.
No padrão de arquitetura híbrida em camadas, também é possível usar o Google Distributed Cloud em alguns cenários. Com o Distributed Cloud, você pode executar clusters do Google Kubernetes Engine em hardware dedicado fornecido e mantido pelo Google, que é separado do data center Google Cloud . Para garantir que a Distributed Cloud atenda aos seus requisitos atuais e futuros, conheça as limitações da Distributed Cloud em comparação com uma zona GKE convencional baseada na nuvem.
Vantagens
Concentrar-se em aplicativos de front-end primeiro tem várias vantagens, incluindo as seguintes:
- Os componentes de front-end dependem de recursos de back-end e, às vezes, de outros componentes de front-end.
- Os componentes de back-end não dependem dos componentes de front-end. Portanto, isolar e migrar aplicativos de front-end tende a ser menos complexo do que migrar aplicativos de back-end.
- Como os aplicativos de front-end geralmente são sem estado ou não gerenciam dados
por si, eles tendem a ser menos difíceis de migrar do que os back-ends.
- Os componentes de front-end podem ser otimizados como parte da migração para usar arquitetura sem estado. Para mais informações, assista ao vídeo Como portar apps da Web com estado para o Cloud Run no YouTube.
A implantação na nuvem de aplicativos de front-end atuais ou recém-desenvolvidos tem várias vantagens:
- Muitas aplicações de front-end estão sujeitas a alterações frequentes. A execução desses aplicativos na nuvem pública simplifica a configuração de um processo de integração contínua/implantação contínua (CI/CD). Você pode usar a CI/CD para enviar atualizações de maneira eficiente e automatizada. Para mais informações, consulte CI/CD no Google Cloud.
- Front-ends sensíveis ao desempenho com carga de tráfego variável podem se beneficiar substancialmente do balanceamento de carga, das implantações multirregionais, do armazenamento em cache do Cloud CDN, sem servidor e dos recursos de escalonamento automático que uma implantação baseada na nuvem permite (de preferência com uma arquitetura sem estado).
A adoção de microsserviços com contêineres usando uma plataforma gerenciada pela nuvem, como o GKE, permite usar arquiteturas modernas, como o microfront-end, que estendem microsserviços para os componentes de front-end.
A extensão de microsserviços é comumente usada com front-ends que envolvem várias equipes colaborando no mesmo aplicativo. Esse tipo de estrutura de equipe exige uma abordagem iterativa e manutenção contínua. Confira a seguir algumas das vantagens do uso de microfront-ends:
- Ele pode ser transformado em módulos de microsserviços independentes para desenvolvimento, teste e implantação.
- Ele oferece separação em que equipes de desenvolvimento individuais podem selecionar as tecnologias e o código preferidos.
- Ele pode estimular ciclos rápidos de desenvolvimento e implantação sem afetar o restante dos componentes de front-end que podem ser gerenciados por outras equipes.
Seja implementando interfaces de usuário ou APIs ou lidando com o processamento de dados da Internet das Coisas (IoT), os aplicativos de front-end podem se beneficiar dos recursos oferecidos por serviços em nuvem, como o Firebase, o Pub/Sub, o Apigee, o Cloud CDN, o App Engine ou o Cloud Run.
Os proxies de API gerenciados pela nuvem ajudam a:
- Desvincule a API voltada para o app dos seus serviços de back-end, como microsserviços.
- Protege apps contra mudanças no código de back-end.
- Ofereça suporte a arquiteturas de front-end orientadas a API, como back-end para front-end (BFF), microfront-end e outras.
- Exponha suas APIs no Google Cloud ou em outros ambientes implementando proxies de API no Apigee.
Também é possível aplicar o padrão híbrido em camadas ao contrário, implantando back-ends na nuvem e mantendo front-ends em ambientes de computação particulares. Embora seja menos comum, essa abordagem é melhor aplicada quando você está lidando com um front-end pesado e monolítico. Nesses casos, pode ser mais fácil extrair iterativamente a funcionalidade de back-end e implantar esses novos back-ends na nuvem.
A terceira parte desta série discute possíveis padrões de rede para permitir essa arquitetura. A Apigee híbrida ajuda como uma plataforma para criar e gerenciar proxies de API em um modelo de implantação híbrida. Para mais informações, consulte Arquitetura com acoplamento frouxo, incluindo arquiteturas monolíticas e de microsserviços em camadas.
Práticas recomendadas
Use as informações desta seção ao planejar sua arquitetura híbrida em camadas.
Práticas recomendadas para reduzir a complexidade
Ao aplicar o padrão de arquitetura híbrida em camadas, considere as práticas recomendadas a seguir, que podem ajudar a reduzir a complexidade operacional e de implantação geral:
- Com base na avaliação dos modelos de comunicação dos aplicativos identificados, selecione a solução de comunicação mais eficiente e eficaz para esses aplicativos.
Como a maior parte da interação do usuário envolve sistemas que se conectam a vários ambientes de computação, é importante ter conectividade rápida e de baixa latência entre esses sistemas. Para atender às expectativas de disponibilidade e desempenho, projete para alta disponibilidade, baixa latência e níveis de capacidade de processamento adequados. Do ponto de vista da segurança, a comunicação precisa ser refinada e controlada. O ideal é expor componentes do aplicativo usando APIs seguras. Para mais informações, consulte Saída controlada.
- Para minimizar a latência de comunicação entre os ambientes, selecione uma regiãoGoogle Cloud que esteja geograficamente próxima ao ambiente de computação particular em que os componentes de back-end do aplicativo são hospedados. Saiba mais em Práticas recomendadas para a seleção de regiões do Compute Engine.
- Minimize dependências altas entre sistemas que estão sendo executados em diferentes ambientes, principalmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem diminuir o desempenho, diminuir a disponibilidade geral e possivelmente gerar cobranças adicionais de transferência de dados de saída.
- Com o padrão de arquitetura híbrido em camadas, é possível ter volumes maiores de tráfego de entrada de ambientes locais para aGoogle Cloud em comparação com o tráfego de saída que sai da Google Cloud. No entanto, você precisa saber o volume esperado de transferência de dados de saída que sai do Google Cloud. Se você planeja usar essa arquitetura a longo prazo com grandes volumes de transferência de dados de saída, considere usar o Cloud Interconnect. O Cloud Interconnect ajuda a otimizar o desempenho da conectividade e pode reduzir as cobranças da transferência de dados de saída para o tráfego que atenda a determinadas condições. Para saber mais, consulte Preços do Cloud Interconnect.
- Para proteger informações sensíveis, recomendamos criptografar todas as comunicações em trânsito. Se a criptografia for necessária na camada de conectividade, você poderá usar túneis de VPN, VPN de alta disponibilidade pelo Cloud Interconnect e MACsec para Cloud Interconnect.
Para superar inconsistências em protocolos, APIs e mecanismos de autenticação em vários serviços de back-end, recomendamos, quando aplicável, implantar um gateway de API ou proxy como uma fachada unificadora. Esse gateway ou proxy atua como um ponto de controle centralizado e faz o seguinte:
- Implementa medidas de segurança adicionais.
- Protege apps clientes e outros serviços contra mudanças no código de back-end.
- Facilita trilhas de auditoria para comunicação entre todos aplicativos entre ambientes e seus componentes dissociados.
- Atua como
camada de comunicação intermediária
entre serviços legados e modernizados.
- A Apigee e a Apigee híbrida permitem hospedar e gerenciar gateways híbridos e corporativos em ambientes locais, de borda, em outras nuvens e Google Cloud .
Para facilitar o estabelecimento de configurações híbridas, use o Cloud Load Balancing com conectividade híbrida. Isso significa que você pode estender os benefícios do balanceamento de carga da nuvem para serviços hospedados no seu ambiente de computação local. Essa abordagem permite migrações de carga de trabalho em fases para Google Cloud com interrupção mínima ou nenhuma interrupção do serviço, garantindo uma transição tranquila para os serviços distribuídos. Para mais informações, consulte Visão geral dos grupos de endpoints da rede de conectividade híbrida.
Às vezes, usar um gateway de API ou um proxy e um Application Load Balancer juntos pode oferecer uma solução mais robusta para gerenciar, proteger e distribuir o tráfego de API em grande escala. Usar o Cloud Load Balancing com gateways de API permite realizar o seguinte:
- Ofereça APIs de alto desempenho com a Apigee e o Cloud CDN, para reduzir a latência, hospedar APIs globalmente e aumentar a disponibilidade para tempos de pico de tráfego. Para mais informações, assista Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN no YouTube.
- Implementar o gerenciamento de tráfego avançado.
- Use o Google Cloud Armor como um serviço de proteção contra DDoS e segurança de rede para proteger suas APIs.
- Gerenciar eficientemente o balanceamento de carga entre gateways em várias regiões. Para mais informações, assista Como proteger as APIs e implementar o failover multirregional com o Private Service Connect e a Apigee no YouTube.
Use o gerenciamento de API e a malha de serviço para proteger e controlar a comunicação e a exposição do serviço com a arquitetura de microsserviços.
- Use o Cloud Service Mesh para permitir a comunicação entre serviços que mantém a qualidade em um sistema composto de serviços distribuídos, em que é possível gerenciar a autenticação, a autorização e a criptografia entre serviços.
- Use uma plataforma de gerenciamento de APIs como a Apigee, que permite que sua organização e entidades externas consumam esses serviços exibindo-os como APIs.
Estabeleça uma identidade comum entre os ambientes, para que a autenticação dos sistemas possa ser feita com segurança nos limites do ambiente.
Implante sistemas de CI/CD e gerenciamento de configuração na nuvem pública. Para mais informações, consulte Padrão de arquitetura de rede espelhada.
Para aumentar a eficiência operacional, use ferramentas consistentes e pipelines de CI/CD em todos os ambientes.
Práticas recomendadas para arquiteturas de aplicativos e cargas de trabalho individuais
- Embora o foco esteja nos aplicativos de front-end nesse padrão, fique atento à necessidade de modernizar os aplicativos de back-end. Se o ritmo de desenvolvimento de aplicativos de back-end for substancialmente mais lento do que para aplicativos de front-end, a diferença pode causar complexidade extra.
- Tratar as APIs como interfaces de back-end simplifica as integrações, o desenvolvimento do front-end, as interações de serviço e oculta as complexidades do sistema de back-end. Para resolver esses desafios, a Apigee facilita o desenvolvimento e o gerenciamento de gateway/proxy de API para implantações híbridas e multicloud.
- Escolha a abordagem de renderização para seu aplicativo da Web de front-end com base no conteúdo (estático ou dinâmico), no desempenho de otimização de mecanismos de pesquisa e nas expectativas sobre as velocidades de carregamento da página.
- Ao selecionar uma arquitetura para aplicativos da Web orientados a conteúdo, várias opções estão disponíveis, incluindo arquiteturas monolíticas, sem servidor, orientadas a eventos e de microsserviços. Para selecionar a arquitetura mais adequada, avalie essas opções em relação aos requisitos atuais e futuros do aplicativo. Para ajudar você a tomar uma decisão arquitetônica que esteja alinhada aos seus objetivos comerciais e técnicos, consulte Comparação de diferentes arquiteturas para back-ends de aplicativos da Web orientados a conteúdo e Considerações importantes para back-ends da Web.
Com uma arquitetura de microsserviços, é possível usar aplicativos conteinerizados com o Kubernetes como a camada de execução comum. Com o padrão de arquitetura híbrida em camadas, é possível executá-lo em um dos seguintes cenários:
Em ambos os ambientes (Google Cloud e seus ambientes locais).
- Ao usar contêineres e o Kubernetes em ambientes, você tem a flexibilidade de modernizar cargas de trabalho e migrar para Google Cloud em momentos diferentes. Isso ajuda quando uma carga de trabalho depende muito de outra e não pode ser migrada individualmente ou para usar a portabilidade híbrida de carga de trabalho e aproveitar os melhores recursos disponíveis em cada ambiente. Em todos os casos, o GKE Enterprise pode ser uma tecnologia capacitadora fundamental. Para mais informações, consulte Ambiente híbrido do GKE Enterprise.
Em um ambiente Google Cloud para os componentes do aplicativo migrados e modernizados.
- Use essa abordagem quando você tiver back-ends legados no local que não têm suporte para contêineres ou que exigem tempo e recursos significativos para serem modernizados em curto prazo.
Para mais informações sobre como projetar e refatorar um app monolítico para uma arquitetura de microsserviços para modernizar a arquitetura do seu aplicativo da Web, consulte Introdução aos microsserviços.
É possível combinar tecnologias de armazenamento de dados de acordo com as necessidades dos aplicativos da Web. O uso do Cloud SQL para dados estruturados e do Cloud Storage para arquivos de mídia é uma abordagem comum para atender a diversas necessidades de armazenamento de dados. No entanto, a escolha depende muito do seu caso de uso. Para mais informações sobre as opções de armazenamento de dados para back-ends de aplicativos orientados a conteúdo e modalidades eficazes, consulte Opções de armazenamento de dados para apps da Web orientados a conteúdo. Consulte também Suas opções de banco de dados Google Cloud , explicadas.