Os projetos de software baseados em nuvem utilizam diversos ambientes. Os nomes desses ambientes geralmente são dev, qa, staging e prod.
É fundamental que esses ambientes estejam totalmente isolados um do outro, e eles geralmente têm permissões de acesso ao operador bem diferentes.
Por exemplo, a equipe de desenvolvimento pode ter acesso total ao ambiente dev, mas acesso limitado ao ambiente prod, com toda a implantação de código orientada apenas por scripts automatizados. Além disso, é essencial que os dados nos diferentes ambientes permaneçam isolados.
O uso de vários projetos do Google Cloud atende a esses requisitos perfeitamente, já que os projetos fornecem isolamento completo de código e dados e as permissões do operador podem ser gerenciadas separadamente. Como o App Engine faz o escalonamento automático das instâncias de serviço, você só paga pelo que usar. Por exemplo, se o ambiente de preparo exigir apenas uma de cada quatro semanas, não haverá custo referente à veiculação de instâncias para as outras três semanas. No entanto, haverá cobrança pelos dados armazenados nesses projetos.
Como nomear ambientes
Se optar por criar seu aplicativo de microsserviços usando vários serviços, é possível criar um único projeto do Cloud para cada um dos seus ambientes e nomeá-los de acordo, como web-app-dev, web-app-qa e web-app-prod.
Ou, se preferir criar seu aplicativo de microsserviços usando vários projetos, separe os ambientes usando mais projetos, como web-app-dev, web-app-prod, user-service-dev e user-service-prod.
É necessário usar padrões de código para garantir que os projetos dev chamem apenas outros projetos dev e os projetos prod chamem apenas outros projetos prod.
A seguir
- Visão geral da arquitetura de microsserviços no App Engine.
- Conhecer as práticas recomendadas para projetar APIs para comunicação entre microsserviços.
- Conhecer as práticas recomendadas para o desempenho do microsserviço
- Aprenda a migrar de um aplicativo monolítico para um com microsserviços