Exemplos de frota

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

Exemplo 1: frotas com recursos de produção, preparo 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: frotas separadas para produção, preparo e desenvolvimento

Uma abordagem possível para aproveitar frotas é criar frotas separadas para recursos de produção, preparo e desenvolvimento.

Para fazer isso, criamos três projetos de host de frota separada 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 semelhança 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 uma das frotas. A principal desvantagem dessa abordagem é que precisamos administrar três frotas 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 rotas separadas para recursos de produção, preparo e desenvolvimento
Frotas separadas para recursos de produção, preparo e desenvolvimento

Abordagem 2: uma frota para todos os recursos

Nessa abordagem, criamos uma única rota para todos os recursos.

Para fazer isso, podemos deixar os recursos no projeto example e criar a frota nesse projeto. Poderíamos ter separado nossos recursos de produção e preparo colocando-os em outros projetos de host de frota 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 estejam normalizados em todo a frota. 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 uma única frota. 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 uma única frota com recursos de produção, preparo e desenvolvimento
Uma única frota com recursos de produção, preparo e desenvolvimento

Abordagem 3: frotas separadas 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 uma frota de não produção e coloca a produção em uma frota separada.

Para isso, criamos dois projetos de host de frota, 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 na nossa frota 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 frotas de produção e não produção
Frotas 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 frotas. 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: frotas 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 o frontend e backend não fiquem mais sobrecarregados nos clusters dessas duas equipes. Depois disso, elas podem estabelecer uma única frota para todos os recursos e criar a malha de serviço deles.

Diagrama ilustrando os recursos de duas equipes em uma única frota
Recursos de duas equipes em uma única frota

Se esse nível de confiança não puder ser estabelecido, team-a e team-b precisam formar duas frotas separadas que usam dois projetos de host de frotas 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 frotas separadas
Recursos de duas equipes em frotas separadas