Exemplos de ambiente

Nos exemplos desta página, você verá alguns cenários hipotéticos com Environs que ilustram alguns dos conceitos e práticas recomendadas dos nossos guias. Antes de ler este guia, você precisa conhecer os conceitos de Introdução aos Environs e Requisitos e práticas recomendadas do Environ.

Exemplo 1: Environs com recursos de produção, preparação e desenvolvimento

Neste primeiro exemplo, há quatro clusters. Dois clusters são para produção (em duas regiões para redundância), um para preparo e teste e o último para desenvolvimento. Todos os clusters pertencem e são administrados centralmente pela equipe da plataforma. Neste exemplo simples, há dois serviços: frontend e backend. No entanto, cenários mais complexos podem ter um número maior de serviços e clusters.

Diagrama ilustrando um sistema com recursos de produção, preparação e desenvolvimento
Um sistema com recursos de produção, preparação e desenvolvimento

Abordagem 1: Environs separados para produção, preparação e desenvolvimento

Uma abordagem possível para aproveitar Environs é criar Environs separados para os recursos de produção, preparação e desenvolvimento.

Para fazer isso, criamos três projetos de host de Environ diferentes e colocamos recursos neles ou, no caso do nosso cluster de desenvolvimento local, registramos o cluster no projeto example-dev. Não foi preciso resolver muitos dos problemas de igualdade de namespace e de serviço devido à granularidade no exemplo, mas garantimos que os namespaces dos clusters prod-east e prod-west foram normalizados.

A vantagem dessa abordagem é que temos um isolamento muito forte entre cada um dos Environs. A principal desvantagem dessa abordagem é que precisamos administrar três Environs diferentes, o que dificulta a consistência entre produção, preparo e desenvolvimento. Para equipes de desenvolvimento, também é mais difícil desenvolver com serviços preparados.

Diagrama ilustrando Environs separados para recursos de produção, preparação e desenvolvimento
Environs separados para recursos de produção, preparo e desenvolvimento

Abordagem 2: um Environ para todos os recursos

Nessa abordagem, criamos um único Environ para todos os recursos.

Para fazer isso, podemos deixar os recursos no projeto example e criar o Environ nesse projeto. Poderíamos separar nossos recursos de produção e preparo colocando-os em outros projetos de host de Environ e aproveitando a VPC compartilhada, mas optamos por não fazer isso para simplificar este exemplo.

Nessa abordagem, precisamos garantir que nossos namespaces e serviços sejam normalizados em todo o Environ. Por exemplo, renomeamos nosso frontend genérico como frontend-prod e frontend-staging nos clusters de produção e preparo, respectivamente. Por fim, embora possamos manter os nomes originais dos nossos namespaces de desenvolvimento, fornecemos nomes mais claros (como frontend-dev-alice) para indicar que eles são namespaces de desenvolvimento.

Com essa abordagem, estamos trocando o isolamento por uma maior facilidade de gerenciamento. Contamos com a autorização da malha de serviço para evitar comunicações indesejadas entre serviços, mas podemos administrar facilmente o sistema geral com um único Environ. Isso nos permite aplicar políticas em todos os recursos, o que nos dá a certeza de que o desenvolvimento parece muito próximo à produção.

Diagrama ilustrando um único Environ com recursos de produção, preparação e desenvolvimento
Um único Environ com recursos de produção, preparo e desenvolvimento

Abordagem 3: Environs separados para produção e não produção

Nessa abordagem, usamos uma configuração intermediária que combina os recursos de preparo e desenvolvimento em um Environ de não produção e coloca a produção em um Environ separado.

Para isso, criamos dois projetos de host de Environ, um para produção e outro para não produção. Também colocaremos nossos recursos diretamente nesses projetos, com o cluster dev no local registrado no nosso Environ de não produção. Precisamos normalizar os namespaces e serviços entre nossos recursos de preparo e desenvolvimento para oferecer mais clareza. Por exemplo, renomeamos frontend como frontend-staging no cluster de preparo.

A vantagem é que a produção é bem isolada da não produção. Por exemplo, podemos permitir que os serviços de desenvolvimento conversem com os serviços de preparo para que o frontend da desenvolvedora Alice possa se comunicar com um backend de preparo, enquanto ela estiver desenvolvendo o serviço.

Diagrama ilustrando Environs de produção e não produção
Environs de produção e não produção

Resumo

Cada uma das abordagens descritas no exemplo 1 é válida. A escolha da sua organização depende do isolamento em relação à consistência (e facilidade de gerenciamento). Em outras palavras, é preciso definir o isolamento necessário entre diferentes tipos de recursos em relação à consistência necessária entre eles. É mais fácil conseguir uma consistência maior com menos ambientes. A terceira abordagem é oferecida como um possível meio-termo, mantendo a produção completamente isolada e, ao mesmo tempo, oferecendo aos desenvolvedores a capacidade de trabalhar com serviços preparados.

Exemplo 2: Environs com diferentes proprietários de recursos

Para este exemplo, temos duas equipes: team-a e team-b. Essas equipes têm e administram os próprios clusters, e ambas usaram namespaces frontend e backend para os serviços que produzem. No entanto, frontend e backend da equipe team-a não são iguais aos da equipe team-b. As duas equipes querem criar uma malha de serviço para que os serviços possam interagir.

Diagrama ilustrando um sistema com os recursos de duas equipes
Um sistema com os recursos de duas equipes

Sem intervenção, não há como tornar esses clusters parte da mesma malha. Um bom ponto de partida é transferir a propriedade dos clusters para uma equipe centralizada de plataforma para estabelecer a confiança entre eles. Como alternativa, se as equipes team-a e team-b confiarem uma na outra, elas também podem se coordenar para estabelecer essa confiança. A próxima etapa é normalizar o uso do namespace para que frontend e backend não fiquem mais sobrecarregados nos clusters dessas duas equipes. Depois disso, elas podem estabelecer um único Environ para todos os recursos e criar a malha de serviço deles.

Diagrama ilustrando os recursos de duas equipes em um único Environ
Recursos de duas equipes em um único Environ

Se esse nível de confiança não puder ser estabelecido, team-a e team-b precisam formar dois Environs separados que usam dois projetos de host de Environ diferentes. A desvantagem dessa abordagem é que agora elas precisam usar a federação de malha, que é mais difícil de administrar do que uma única malha. A vantagem é que nenhuma equipe precisa normalizar os namespaces e serviços implantados, e somente a comunicação explícita e especificamente autorizada é possível.

Diagrama ilustrando os recursos de duas equipes em Environs separados
Recursos de duas equipes em Environs separados