Quando os Relacionamentos com Serviços de Tecnologia Não Funcionam

Tutoriais
AWS

Pense naqueles dias em que você conheceu o amor da sua vida. O sentimento era mútuo. O mundo parecia um lugar melhor, e você estava em uma jornada emocionante com seu parceiro. Vocês estavam ambos “totalmente envolvidos” enquanto faziam planos para uma vida juntos.

A vida era incrível… até que não era mais.

Quando as coisas não saem como planejado, é hora de fazer o trabalho difícil de desfazer o relacionamento. Comunicar-se um com o outro e com os outros. Resolver compras compartilhadas. Seguir em frente. Bleh.

Acredite ou não, nosso relacionamento com a tecnologia não é muito diferente.

Terminando com um Serviço

Houve um tempo em que você decidiu adotar um serviço — talvez fosse um SaaS, um PaaS, ou algo mais genérico. Naquela época, você tomou a decisão sem considerar o momento em que não planejava mais usar o serviço? Provavelmente não. Você estava pensando em todas as maravilhosas possibilidades para o futuro.

Mas o que acontece quando continuar com esse serviço não é mais do seu interesse? Agora, você enfrenta um desafio, chamado abdicação de serviço. Embora os serviços possam ser encerrados com um esforço razoável, obter os dados subjacentes pode ser problemático. Isso geralmente depende do tipo de serviço e do volume de dados pertencentes a esse provedor de serviços.

Às vezes, o ideal para desfazer parece assim: Pare de pagar pelo serviço, mas mantenha o acesso à fonte de dados por um período de tempo. Isso é realmente uma possibilidade? Sim, é!

O Poder do Peering VPC

Os principais provedores de nuvem adotaram a nuvem privada virtual (VPC) como a abordagem padrão para estabelecer conectividade entre recursos. Por exemplo, uma instância EC2 na AWS pode acessar uma fonte de dados usando VPCs e serviços de ponto final de VPC. Pense nisso como uma conexão ponto a ponto.

As VPCs nos permitem conceder acesso a outros recursos no mesmo provedor de nuvem, mas também podemos usá-las para conceder acesso a serviços externos. Considere um serviço que foi recentemente abandonado, mas com a fonte de dados original mantida. Aqui está como isso pode parecer:

Esse conceito é chamado de emparelhamento de VPC, e permite que uma conexão privada seja estabelecida a partir de outra rede.

Um Exemplo de Migração de Serviço

Vamos considerar um exemplo mais concreto. Em sua organização, foi tomada a decisão de otimizar como opera na nuvem. Enquanto continuava a aproveitar alguns serviços da AWS, sua organização queria otimizar como constrói, implementa e gerencia suas aplicações, encerrando um serviço baseado em nuvem de terceiros que estava rodando na AWS. Eles analisaram os números e concluíram que engenheiros de software internos poderiam criar e suportar um novo serviço auto-escalável na Heroku por uma fração do custo que estavam pagando ao provedor de terceiros.

No entanto, devido a um longo período com o provedor de serviços, migrar a fonte de dados não é uma opção em breve. Você não quer o serviço, e não pode mover os dados, mas ainda deseja ter acesso aos dados. Felizmente, o provedor concordou com um novo contrato para continuar hospedando os dados e fornecer acesso — via VPC peering.

Aqui está como o novo acordo seria:

VPC Peering com o Heroku

Para que seu novo serviço (um aplicativo Heroku) acesse a fonte de dados original na AWS, primeiro você precisará executar seu aplicativo dentro de um Espaço Privado. Para mais informações, você pode ler sobre adoção segura de nuvem e minha descoberta dos Espaços Privados do Heroku.

Em seguida, você precisará atender aos seguintes requisitos simples de rede:

  • A VPC deve usar um bloco CIDR IPv4 compatível em sua configuração de rede.
  • A VPC deve usar um bloco CIDR RFC1918 (10.0.0.0/8, 172.16.0.0/12, ou 192.168.0.0/16).
  • O bloco CIDR da VPC não deve se sobrepor com as faixas CIDR do seu Espaço Privado. As faixas padrão são 10.0.0.0/16, 10.1.0.0/16, e 172.17.0.0/16. 

Com seu Espaço Privado funcionando, você precisará recuperar as informações de peering:

Shell

 

Anote o ID da Conta AWS (647xxxxxx317) e o ID da VPC AWS (vpc-e285ab73). Você precisará fornecer essas informações ao provedor terceirizado que controla a fonte de dados da AWS. A partir daí, eles podem usar o Console da AWS ou CLI para criar uma conexão de peering. A operação deles seria algo parecido com isto:

Shell

 

Isto cria uma solicitação de peering. Depois que o provedor fizer isso, você poderá visualizar a solicitação pendente no lado do Heroku:

Shell

 

Na captura de tela abaixo, podemos ver o status de pendente de aceitação para a conexão de peering.

A partir daqui, você pode aceitar a solicitação de conexão de peering:

Shell

 

Verificamos o status da solicitação uma segunda vez:

Shell

 

Vemos que a conexão de peering está ativa.

Neste ponto, o aplicativo em execução em nosso Espaço Privado do Heroku poderá acessar a fonte de dados da AWS sem problemas.

Conclusão

Uma verdade infeliz na vida é que os relacionamentos podem ser malsucedidos com a mesma frequência com que duram muito tempo. Isso se aplica às pessoas e se aplica à tecnologia.

Quando se trata de decisões de tecnologia, às vezes situações e necessidades em mudança nos levam a seguir direções diferentes. Às vezes, as coisas simplesmente não funcionam. E nestas situações, o maior desafio frequentemente é desfazer uma implementação existente — sem perder o acesso aos dados persistentes.

Felizmente, o Heroku fornece uma solução para migrar lentamente de soluções baseadas em nuvem existentes, mantendo o acesso aos dados hospedados externamente. Sua fácil integração para interconexão de VPC com AWS permite acessar recursos que ainda precisam permanecer na implementação legada, mesmo que o restante já tenha migrado.

Ao adotar essa abordagem, seu novo serviço poderá prosperar sem interrupções no atendimento ao consumidor.

Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out