
O que eu mais gosto é como discretamente elimina a dor de cabeça de "onde eu sequer alcanço esse serviço?".
No meu dia a dia, eu simplesmente dou a cada micro-serviço um nome—algo simples como "perfil-de-usuário" ou "validador-de-pedido"—e o Cloud Map mantém o IP/porta mais recente, status de saúde, e até alguns atributos personalizados em um pequeno registro. Depois disso, não importa quantas vezes o auto-escalonamento adicione ou remova nós, o resto da frota os encontra automaticamente. Parei de codificar IPs manualmente em arquivos de configuração, parei de gerenciar entradas do Route 53 manualmente, e nunca mais precisei dizer à equipe de front-end "esperem, o endpoint mudou de novo". Parece que o diretório de serviços se cuida sozinho, então posso continuar no código em vez de ficar cuidando do DNS. Análise coletada por e hospedada no G2.com.
O que ainda me confunde é como o Cloud Map parece "dividido" dentro do console da AWS. Metade dos controles estão no próprio Cloud Map, mas no momento em que quero anexar um namespace a um serviço ECS ou a um ingresso EKS, de repente estou clicando em três outros serviços (ECS, EKS, App Mesh, até mesmo Route 53) apenas para visualizar o que são essencialmente os mesmos registros.
Depurar é a pior parte. Vou notar uma instância que parece não estar saudável no Cloud Map, mas para descobrir o porquê, tenho que pular para as tarefas do ECS, depois para os logs do CloudWatch, e então voltar ao Cloud Map para desregistrar o nó ruim. Acaba parecendo que o diretório de serviços deveria ser a única fonte de verdade—exceto quando não é, e ainda estou preso caçando entre abas para juntar tudo. Análise coletada por e hospedada no G2.com.



