Denk terug aan die dagen waarop je de liefde van je leven ontmoette. Het gevoel was wederzijds. De wereld leek een betere plek, en je was op een spannende reis met je partner. Jullie waren allebei “totale inzet” terwijl jullie plannen maakten voor een leven samen.
Het leven was geweldig… totdat dat niet meer zo was.
Wanneer dingen niet lopen zoals gepland, moet je de moeilijke klus klaren van het ontrafelen van de relatie. Met elkaar en met anderen communiceren. Gezamenlijke aankopen sorteren. Verder gaan. Bah.
Geloof het of niet, onze relatie met technologie is niet zoveel anders.
Het Beëindigen van een Dienst
Er was een tijd dat je besloot een dienst te adopteren – misschien was het een SaaS, of een PaaS, of iets algemeners. Vroeger, heb je de beslissing genomen zonder ook maar na te denken over het moment waarop je de dienst niet meer zou willen gebruiken? Waarschijnlijk niet. Je dacht alleen aan alle geweldige mogelijkheden voor de toekomst.
Maar wat gebeurt er wanneer het gebruik van die dienst niet langer in jouw beste belang is? Nu staat je een uitdaging te wachten, en die heet dientabdicatie. Terwijl diensten met een redelijke inspanning kunnen worden stopgezet, kan het verkrijgen van de onderliggende data problematisch zijn. Dit hangt vaak af van het soort dienst en het volume aan data dat door die dienstverlener wordt beheerd.
Soms ziet de ideale afwikkeling er als volgt uit: Stop met betalen voor de dienst, maar behoud toegang tot de gegevensbron voor een bepaalde periode. Is dit zelfs een mogelijkheid? Ja, dat is het!
De Kracht van VPC Peering
Toonaangevende cloudproviders hebben het virtuele privécloud (VPC) netwerk omarmd als de facto aanpak voor het tot stand brengen van connectiviteit tussen middelen. Bijvoorbeeld, een EC2-instantie op AWS kan toegang krijgen tot een gegevensbron met behulp van VPC’s en VPC-eindpuntservices. Denk aan het als een punt-tot-punt verbinding.
VPC’s stellen ons in staat toegang te verlenen tot andere middelen in dezelfde cloudprovider, maar we kunnen ze ook gebruiken om toegang te verlenen tot externe services. Stel je een service voor die recentelijk is verlaten maar waarbij de oorspronkelijke gegevensbron nog steeds aanwezig is. Zo zou het eruit kunnen zien:
Dit concept wordt VPC-peering genoemd en het maakt het mogelijk om een privéverbinding tot stand te brengen vanuit een ander netwerk.
Een voorbeeld van service migratie
Laten we eens kijken naar een concreter voorbeeld. In uw organisatie is een zakelijke beslissing genomen om te stroomlijnen hoe het in de cloud opereert. Terwijl het blijft profiteren van sommige AWS-services, wilde uw organisatie optimaliseren hoe het zijn toepassingen bouwt, implementeert en beheert door een externe, cloudgebaseerde service die op AWS draait stop te zetten. Ze hebben de cijfers doorgerekend en geconcludeerd dat interne software-ingenieurs een nieuw automatisch geschaalde service op Heroku konden opzetten en ondersteunen voor een fractie van de kosten die ze aan de externe provider betaalden.
Echter, vanwege een lange dienstverband met de dienstverlener is het niet op korte termijn mogelijk om de gegevensbron te migreren. Je wilt de service niet en je kunt de gegevens niet verplaatsen, maar je wilt nog steeds toegang tot de gegevens. Gelukkig heeft de provider ingestemd met een nieuw contract om de gegevens te blijven hosten en toegang te verlenen — via VPC-koppeling.
Dit is hoe de nieuwe regeling eruit zou zien:
VPC-Koppeling Met Heroku
Om je nieuwe service (een Heroku-app) toegang te geven tot de originele gegevensbron in AWS, moet je eerst je app uitvoeren binnen een Privéruimte. Voor meer informatie kun je lezen over veilige cloudadoptie en mijn ontdekking van Heroku Privéruimtes.
Vervolgens moet je voldoen aan de volgende eenvoudige netwerkvereisten:
- De VPC moet een compatibel IPv4 CIDR-blok gebruiken in zijn netwerkconfiguratie.
- De VPC moet een RFC1918 CIDR-blok gebruiken (
10.0.0.0/8
,172.16.0.0/12
of192.168.0.0/16
). - Het CIDR-blok van de VPC mag niet overlappen met de CIDR-bereiken voor je Privéruimte. De standaardbereiken zijn
10.0.0.0
/16
,10.1.0.0/16
en172.17.0.0/16
.
Met je Privéruimte operationeel, moet je de koppelingsinformatie ophalen:
$ heroku spaces:peering:info our-new-app
=== our-new-app Peering Info
AWS Account ID: 647xxxxxx317
AWS Region: us-east-1
AWS VPC ID: vpc-e285ab73
AWS VPC CIDR: 10.0.0.0/16
Space CIDRs: 10.0.128.0/20, 10.0.144.0/20, 10.0.0.0/20, 10.0.16.0/20
Unavailable CIDRs: 10.1.0.0/16
Kopieer het AWS Account ID (647xxxxxx317) en AWS VPC ID (vpc-e285ab73). Je zult die informatie moeten doorgeven aan de externe provider die de AWS-gegevensbron beheert. Van daaruit kunnen ze ofwel de AWS Console of CLI gebruiken om een peeringverbinding te maken. Hun operatie zou er ongeveer zo uitzien:
$ aws ec2 create-vpc-peering-connection \
--vpc-id vpc-e527bb17 \
--peer-vpc-id vpc-e285ab73 \
--peer-owner-id 647xxxxxx317
{
"VpcPeeringConnection": {
"Status": {
"Message": "Initiating Request to 647xxxxxx317",
"Code": "initiating-request"
},
"Tags": [],
"RequesterVpcInfo": {
"OwnerId": "714xxxxxx214",
"VpcId": "vpc-e527bb17",
"CidrBlock": "10.100.0.0/16"
},
"VpcPeeringConnectionId": "pcx-123abc456",
"ExpirationTime": "2025-04-23T22:05:27.000Z",
"AccepterVpcInfo": {
"OwnerId": "647xxxxxx317",
"VpcId": "vpc-e285ab73"
}
}
}
Dit creëert een verzoek om te koppelen. Zodra de provider dit heeft gedaan, kun je het in behandeling zijnde verzoek aan de Heroku-kant bekijken:
$ heroku spaces:peerings our-new-app
Op de onderstaande schermafbeelding zien we de status in behandeling voor de peeringverbinding.
Vanaf hier kun je het verzoek voor de peeringverbinding accepteren:
$ heroku spaces:peerings:accept pcx-123abc456 --space our-new-app
Accepting and configuring peering connection pcx-123abc456
We controleren het verzoekstatus nog een keer:
$ heroku spaces:peerings our-new-app
We zien dat de peer-verbinding actief is.
Op dit punt zal de app die draait in onze Heroku Private Space in staat zijn om toegang te krijgen tot de AWS-gegevensbron zonder problemen.
Conclusie
Een jammerlijke waarheid in het leven is dat relaties net zo vaak onsuccesvol kunnen zijn als langdurig. Dit geldt voor mensen, en het geldt voor technologie.
Als het gaat om technologiebeslissingen, drijven veranderende situaties en behoeften ons soms om andere richtingen in te slaan. Soms werken dingen gewoon niet. En in deze situaties is de grootste uitdaging vaak het ongedaan maken van een bestaande implementatie — zonder de toegang tot persistente gegevens te verliezen.
Gelukkig biedt Heroku een oplossing voor het langzaam migreren van bestaande cloudoplossingen terwijl toegang tot extern gehoste gegevens behouden blijft. De eenvoudige integratie voor VPC-koppeling met AWS maakt het mogelijk om toegang te krijgen tot resources die nog steeds moeten blijven bestaan in de oude implementatie, zelfs als de rest van je bent overgestapt.
Door deze aanpak te volgen, kan je nieuwe service gedijen zonder onderbreking van de service aan de consument.
Source:
https://dzone.com/articles/when-tech-service-relationships-dont-work-out