Padrão híbrido em camadas

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 de aplicativos de front-end estão diretamente expostos 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, e possivelmente 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 desempenho, velocidade de resposta e compatibilidade com navegadores.

Os componentes de aplicativos de back-end geralmente se concentram no armazenamento e 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 as de aplicativos de front-end. Os aplicativos de back-end têm os seguintes desafios para gerenciar:

• 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 solução de app da Web de três camadas é uma das implementações mais usadas para criar aplicativos da Web comerciais, como sites de e-commerce que contêm diferentes componentes de aplicativos. Essa arquitetura contém as seguintes camadas. Cada nível opera de forma independente, mas eles estão intimamente ligados e funcionam juntos.

• Front-end da Web e camada de apresentação
• Nível do aplicativo
• Acesso a dados ou camada de back-end

Colocar essas camadas em contêineres separa as necessidades técnicas delas, como requisitos de escalonamento, e ajuda a migrá-las em uma abordagem gradual. 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 escalonar com plataformas gerenciadas pela nuvem, como o Cloud Run ou a edição Enterprise do Google Kubernetes Engine (GKE). Além disso, os bancos de dados gerenciados peloGoogle 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 atuais na nuvem pública. Nesse padrão, você mantém todos os componentes de aplicativo de back-end atuais no ambiente de computação particular. Dependendo da escala e do design específico do aplicativo, é possível migrar os componentes do aplicativo front-end caso a caso. Para mais informações, consulte Migrar para Google Cloud.

Se você tiver um aplicativo com componentes de back-end e front-end hospedados no seu ambiente local, considere os limites da arquitetura atual. Por exemplo, à medida que seu aplicativo é escalonado e as demandas de desempenho e confiabilidade aumentam, comece a avaliar se partes do aplicativo precisam ser refatoradas ou movidas para uma arquitetura diferente e mais otimizada. O padrão de arquitetura híbrida 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 em uma migração desse tipo.

O diagrama a seguir mostra um padrão típico de arquitetura híbrida em camadas.

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 para o ambiente local onde o back-end do aplicativo está hospedado (idealmente por um gateway de API).

Com o padrão de arquitetura híbrida em camadas, é possível aproveitar a infraestrutura Google Cloud e os serviços globais, conforme mostrado no exemplo de arquitetura no diagrama a seguir. O front-end do aplicativo pode ser acessado pelo 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 provisionar demais a infraestrutura. Há diferentes arquiteturas que você pode usar para criar e executar apps da Web escalonáveis no Google Cloud. Cada uma tem vantagens e desvantagens para diferentes requisitos.

Para mais informações, assista Três maneiras de executar apps da Web escalonáveis no Google Cloud no YouTube. Para saber mais sobre 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 oferecer uma experiência do usuário multirregional e otimizada globalmente que usa balanceamento de carga, escalonamento automático e proteção contra DDoS globais pelo Google Cloud Armor.

Com o tempo, o número de aplicativos que você implanta na nuvem pública pode aumentar a ponto de considerar a movimentação de componentes de aplicativos de back-end para a nuvem pública. Se você espera atender a um tráfego intenso, optar por serviços gerenciados na nuvem pode ajudar a economizar esforço de engenharia ao gerenciar sua própria infraestrutura. Considere essa opção, a menos que restrições ou requisitos exijam hospedar componentes de aplicativos de back-end no local. Por exemplo, se os dados de back-end estiverem sujeitos a restrições regulatórias, provavelmente será necessário mantê-los no local. No entanto, quando aplicável e em conformidade, o uso de recursos da Proteção de dados sensíveis, como técnicas de desidentificação, pode ajudar você a mover 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, é possível executar clusters do Google Kubernetes Engine em hardware dedicado fornecido e mantido pelo Google e separado do data center Google Cloud . Para garantir que o Distributed Cloud atenda aos seus requisitos atuais e futuros, conheça as limitações dele em comparação com uma zona do GKE convencional baseada na nuvem.

Vantagens

Concentrar-se em aplicativos de front-end primeiro tem várias vantagens, incluindo o seguinte:

• 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 mesmos, 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 a arquitetura sem estado. Para mais informações, assista Como migrar 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.
• Os 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, dos recursos sem servidor e de escalonamento automático que uma implantação baseada em nuvem permite (idealmente com uma arquitetura sem estado).

• Adotar microsserviços com contêineres usando uma plataforma gerenciada na nuvem, como o GKE, permite usar arquiteturas modernas, como microfrontend, que estendem os microsserviços aos componentes de front-end.

  A extensão de microsserviços é usada com frequência em 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 algumas das vantagens de usar microfrontends:

  • Ele pode ser transformado em módulos de microsserviços independentes para desenvolvimento, teste e implantação.
  • Ele oferece separação para que equipes de desenvolvimento individuais possam selecionar as tecnologias e o código preferidos.
  • Isso pode promover 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 processando a ingestão de dados da Internet das Coisas (IoT), os aplicativos de front-end podem se beneficiar dos recursos de serviços em nuvem como Firebase, Pub/Sub, Apigee, Cloud CDN, App Engine ou Cloud Run.

• Os proxies de API gerenciados na nuvem ajudam a:

  • Dissocie a API voltada ao app dos serviços de back-end, como microsserviços.
  • Proteja os apps contra mudanças no código de back-end.
  • Suporte às arquiteturas de front-end atuais orientadas por 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 é mais adequada 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 ativar 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 fraco, incluindo arquiteturas monolíticas em camadas e de microsserviços.

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 implantação geral e a complexidade operacional:

• 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 eles.

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, crie um projeto com 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 de aplicativos 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ão doGoogle Cloud geograficamente próxima ao ambiente de computação particular em que os componentes de back-end do aplicativo estão hospedados. Para mais informações, consulte Práticas recomendadas para a seleção de regiões do Compute Engine.
• Minimize dependências entre sistemas que estão sendo executados em ambientes diferentes, especialmente quando a comunicação é tratada de maneira síncrona. Essas dependências podem retardar o desempenho, diminuir a disponibilidade e gerar cobranças adicionais de transferência de dados de saída.
• Com o padrão de arquitetura híbrida em camadas, você pode ter volumes maiores de tráfego de entrada de ambientes locais chegando aoGoogle Cloud em comparação com o tráfego de saída do Google Cloud. No entanto, é importante saber o volume previsto de transferência de dados de saída de Google Cloud. Se você planeja usar essa arquitetura a longo prazo com altos 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 de transferência de dados de saída para o tráfego que atenda a determinadas condições. Para mais informações, 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, use 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 em ambientes doGoogle 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 do Cloud 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 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 balanceador de carga de aplicativo juntos pode fornecer uma solução mais robusta para gerenciar, proteger e distribuir o tráfego de APIs em grande escala. Usar o Cloud Load Balancing com gateways de API permite realizar o seguinte:

  • Forneç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 temporadas de pico de tráfego. Para mais informações, assista no YouTube: Como entregar APIs de alto desempenho com a Apigee e o Cloud CDN.
  • 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 de serviços 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 autenticação, autorização e criptografia entre serviços.
  • Use uma plataforma de gerenciamento de APIs, como o Apigee, que permite que sua organização e entidades externas consumam esses serviços expondo-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

• O foco está nos aplicativos de front-end nesse padrão, mas 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 de front-end, a diferença pode causar complexidade extra.
• Tratar as APIs como interfaces de back-end simplifica as integrações, o desenvolvimento de front-end, as interações de serviço e oculta as complexidades do sistema de back-end. Para enfrentar esses desafios, a Apigee facilita o desenvolvimento e o gerenciamento de gateways/proxies 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 x dinâmico), na performance de otimização de mecanismos de pesquisa e nas expectativas sobre a velocidade de carregamento da página.
• Ao selecionar uma arquitetura para aplicativos da Web orientados a conteúdo, há várias opções disponíveis, incluindo arquiteturas monolíticas, sem servidor, baseadas em eventos e de microsserviços. Para selecionar a arquitetura mais adequada, avalie essas opções de acordo com os requisitos atuais e futuros do aplicativo. Para ajudar você a tomar uma decisão arquitetônica 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 Principais considerações para back-ends da Web.

• Com uma arquitetura de microsserviços, é possível usar aplicativos conteinerizados com o Kubernetes como a camada de tempo de execução comum. Com o padrão de arquitetura híbrida em camadas, é possível executar 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 o 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 cargas 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 de aplicativo migrados e modernizados.

    • Use essa abordagem quando tiver back-ends legados no local que não têm suporte à contêinerização ou exigem tempo e recursos significativos para modernização no curto prazo.

    Para mais informações sobre como projetar e refatorar um app monolítico para uma arquitetura de microsserviços e modernizar sua arquitetura de aplicativos da Web, consulte Introdução aos microsserviços.

• É possível combinar tecnologias de armazenamento de dados dependendo das necessidades dos seus aplicativos da Web. Usar o Cloud SQL para dados estruturados e o 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 opções de armazenamento de dados para back-ends de aplicativos baseados em conteúdo e modalidades eficazes, consulte Opções de armazenamento de dados para apps da Web baseados em conteúdo. Consulte também Suas opções de banco de dados do Google Cloud , explicadas.