Lorsque les relations avec les services techniques ne fonctionnent pas

Tutoriels
AWS

Repensez à ces jours où vous avez rencontré l’amour de votre vie. Le sentiment était réciproque. Le monde semblait être un meilleur endroit, et vous étiez dans un voyage excitant avec votre partenaire. Vous étiez tous les deux « à fond » alors que vous faisiez des projets pour une vie ensemble.

La vie était incroyable… jusqu’à ce qu’elle ne le soit plus.

Quand les choses ne se passent pas comme prévu, il faut faire le travail difficile de défaire la relation. Communiquer l’un avec l’autre et avec les autres. Trier les achats communs. Passer à autre chose. Beurk.

Que vous le croyiez ou non, notre relation avec la technologie n’est pas si différente.

Mettre fin à un service

Il fut un temps où vous avez décidé d’adopter un service — peut-être un SaaS, un PaaS, ou quelque chose de plus générique. À l’époque, avez-vous pris la décision en tenant également compte du moment où vous n’auriez plus l’intention d’utiliser le service ? Probablement pas. Vous pensiez simplement à toutes les merveilleuses possibilités pour l’avenir.

Mais que se passe-t-il lorsque ce service n’est plus dans votre meilleur intérêt ? Maintenant, vous êtes confronté à un défi, et cela s’appelle abdication de service. Bien que les services puissent être arrêtés avec un effort raisonnable, obtenir les données sous-jacentes peut être problématique. Cela dépend souvent du type de service et du volume de données détenues par ce fournisseur de services.

Parfois, le désengagement idéal ressemble à ceci : Arrêter de payer pour le service, mais conserver l’accès à la source de données pendant un certain temps. Est-ce même une possibilité ? Oui, c’est possible !

Le pouvoir du VPC Peering

Les principaux fournisseurs de cloud ont adopté le cloud privé virtuel (VPC) comme approche de facto pour établir la connectivité entre les ressources. Par exemple, une instance EC2 sur AWS peut accéder à une source de données en utilisant des VPC et des services de point de terminaison VPC. Pensez-y comme à une connexion point à point.

Les VPC nous permettent d’accorder l’accès à d’autres ressources du même fournisseur de cloud, mais nous pouvons également les utiliser pour accorder l’accès à des services externes. Considérez un service qui a récemment été abandonné mais dont la source de données originale est restée en place. Voici à quoi cela pourrait ressembler :

Ce concept s’appelle le peering VPC, et il permet d’établir une connexion privée depuis un autre réseau.

Un exemple de migration de service

Considérons un exemple plus concret. Dans votre organisation, une décision commerciale a été prise pour rationaliser son fonctionnement dans le cloud. Tout en continuant à tirer parti de certains services AWS, votre organisation souhaitait optimiser la manière dont elle construit, déploie et gère ses applications en mettant fin à un service tiers basé sur le cloud fonctionnant sur AWS. Ils ont analysé les chiffres et ont conclu que les ingénieurs logiciels internes pouvaient mettre en place et soutenir un nouveau service à mise à l’échelle automatique sur Heroku pour une fraction du coût qu’ils avaient payé au fournisseur tiers.

Cependant, en raison d’une longue période de travail avec le fournisseur de services, la migration de la source de données n’est pas une option dans un avenir proche. Vous ne voulez pas du service, et vous ne pouvez pas déplacer les données, mais vous voulez toujours accéder aux données. Heureusement, le fournisseur a accepté de conclure un nouveau contrat pour continuer à héberger les données et fournir un accès — via VPC peering.

Voici à quoi ressemblerait le nouvel arrangement :

VPC Peering Avec Heroku

Pour que votre nouveau service (une application Heroku) puisse accéder à la source de données d’origine dans AWS, vous devrez d’abord exécuter votre application dans un Espace Privé. Pour plus d’informations, vous pouvez lire sur l’adoption sécurisée du cloud et ma découverte des Espaces Privés Heroku.

Ensuite, vous devrez répondre aux exigences réseau suivantes :

  • Le VPC doit utiliser un bloc CIDR IPv4 compatible dans sa configuration réseau.
  • Le VPC doit utiliser un bloc CIDR RFC1918 (10.0.0.0/8, 172.16.0.0/12, ou 192.168.0.0/16).
  • Le bloc CIDR du VPC ne doit pas se chevaucher avec les plages CIDR de votre Espace Privé. Les plages par défaut sont 10.0.0.0/16, 10.1.0.0/16, et 172.17.0.0/16. 

Avec votre Espace Privé opérationnel, vous devrez récupérer les informations de peering :

Shell

 

Copiez l’ID de compte AWS (647xxxxxx317) et l’ID VPC AWS (vpc-e285ab73). Vous devrez fournir ces informations au fournisseur tiers qui contrôle la source de données AWS. À partir de là, ils pourront utiliser soit la console AWS soit l’interface en ligne de commande (CLI) pour créer une connexion de peering. Leur opération ressemblerait à ceci :

Shell

 

Cela crée une demande de peering. Une fois que le fournisseur l’aura fait, vous pourrez consulter la demande en attente du côté de Heroku :

Shell

 

Sur la capture d’écran ci-dessous, nous pouvons voir le statut en attente d’acceptation pour la connexion de peering.

À partir de là, vous pouvez accepter la demande de connexion de peering :

Shell

 

Nous vérifions le statut de la demande une deuxième fois :

Shell

 

Nous voyons que la connexion entre pairs est active.

À ce stade, l’application s’exécutant dans notre Espace Privé Heroku pourra accéder à la source de données AWS sans aucun problème.

Conclusion

Une triste réalité de la vie est que les relations peuvent être aussi infructueuses aussi souvent qu’elles peuvent être durables. Cela s’applique aux personnes, et cela s’applique à la technologie.

En matière de décisions technologiques, parfois les situations changeantes et les besoins nous poussent à prendre des directions différentes. Parfois, les choses ne fonctionnent tout simplement pas. Et dans ces situations, le plus grand défi est souvent de démanteler une implémentation existante sans perdre l’accès aux données persistantes.

Heureusement, Heroku propose une solution pour migrer lentement des solutions basées sur le cloud existantes tout en conservant l’accès aux données hébergées à l’extérieur. Son intégration facile pour le peering VPC avec AWS vous permet d’accéder aux ressources qui doivent encore vivre dans l’implémentation héritée, même si le reste de votre système a évolué.

Adopter cette approche permettra à votre nouveau service de prospérer sans interruption de service pour le consommateur.

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