Quando as Relações de (Serviço Técnico) Não Funcionam

Tutoriais
AWS

Pense de volta àqueles 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 “totalmente dentro” 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, você precisa fazer o trabalho duro de desfazer o relacionamento. Comunicar-se um com o outro e com os outros. Organizar compras compartilhadas. Seguir em frente. Bleh.

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

Terminando com um Serviço

Houve um tempo em que você decidiu adotar um serviço — talvez fosse um SaaS, ou 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 apenas pensando em todas as maravilhosas possibilidades para o futuro.

Mas o que acontece quando optar por esse serviço não está mais nos seus melhores interesses? Agora, você enfrenta um desafio, e isso se chama abdicação de serviço. Enquanto os serviços podem ser encerrados com um esforço razoável, obter os dados subjacentes pode ser problemático. Isso muitas vezes depende do tipo de serviço e do volume de dados que pertencem a esse provedor de serviços.

Às vezes, o desfecho ideal se parece com isso: pare de pagar pelo serviço, mas mantenha o acesso à fonte de dados por um certo período de tempo. Isso é mesmo uma possibilidade? Sim, é!

O Poder do Peering VPC

Os principais provedores de nuvem adotaram a rede de 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 de extremidade da 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 deixada no lugar. Veja como isso poderia parecer:

Esse conceito é chamado de interligação de VPCs e permite estabelecer uma conexão privada a partir de outra rede.

Um Exemplo de Migração de Serviço

Vamos considerar um exemplo mais concreto. Em sua organização, uma decisão de negócios foi tomada para otimizar a forma como opera na nuvem. Continuando a aproveitar alguns serviços da AWS, sua organização quis otimizar como constrói, implanta e gerencia suas aplicações ao encerrar um serviço de terceiros baseado na nuvem em execução na AWS. Eles fizeram os cálculos e concluíram que os engenheiros de software internos poderiam implantar e dar suporte a um novo serviço autoescalável no Heroku por uma fração do custo que estavam pagando ao provedor de terceiros.

No entanto, devido a uma longa permanência com o provedor de serviços, migrar a fonte de dados não é uma opção tão cedo. Você não quer o serviço e não pode mover os dados, mas ainda quer 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 se pareceria:

VPC Peering Com Heroku

Para que seu novo serviço (um aplicativo Heroku) possa acessar a fonte de dados original na AWS, você primeiro 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 de rede simples:

  • O VPC deve usar um bloco CIDR IPv4 compatível em sua configuração de rede.
  • O 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 do VPC não deve se sobrepor com os intervalos CIDR para o seu Espaço Privado. Os intervalos 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 suas informações de peering:

Shell

 

Copie 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 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. Assim 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 pendência 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 mal sucedidos tão frequentemente quanto duradouros. Isso se aplica às pessoas e se aplica à tecnologia.

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

Felizmente, o Heroku oferece uma solução para migrar lentamente de soluções baseadas em nuvem existentes, mantendo o acesso a dados hospedados externamente. Sua fácil integração para peering VPC com a AWS permite que você acesse recursos que ainda precisam permanecer na implementação legada, mesmo que o restante de você já tenha avançado.

Adotar essa abordagem permitirá que seu novo serviço prospere sem interrupção no serviço ao consumidor.

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