Quando le relazioni (Servizio Tecnico) non funzionano

Tutorial
AWS

Ripensa a quei giorni in cui hai incontrato l’amore della tua vita. La sensazione era reciproca. Il mondo sembrava un posto migliore e stavi vivendo un viaggio emozionante con il tuo partner. Eravate entrambi “tutti dentro” mentre pianificavate una vita insieme.

La vita era straordinaria… finché non ha smesso di esserlo.

Quando le cose non vanno come previsto, devi affrontare il difficile compito di sciogliere la relazione. Comunicare tra di voi e con gli altri. Sistemare gli acquisti condivisi. Andare avanti. Bleh.

Credici o no, la nostra relazione con la tecnologia non è poi così diversa.

Interrompere un Servizio

C’è stato un momento in cui hai deciso di adottare un servizio — forse era un SaaS, o un PaaS, o qualcosa di più generico. All’epoca, hai preso la decisione pensando anche al momento in cui non avresti più pianificato di utilizzare il servizio? Probabilmente no. Stavi solo pensando a tutte le meravigliose possibilità per il futuro.

Ma cosa succede quando utilizzare quel servizio non è più nel tuo interesse? Ora, sei di fronte a una sfida, e si chiama abdicazione del servizio. Mentre i servizi possono essere interrotti con un ragionevole sforzo, ottenere i dati sottostanti può essere problematico. Questo dipende spesso dal tipo di servizio e dal volume di dati di proprietà di quel fornitore di servizi.

A volte, il modo ideale per sciogliere la relazione appare così: smettere di pagare per il servizio, ma mantenere l’accesso alla fonte dei dati per un certo periodo di tempo. È anche una possibilità? Sì, lo è!

Il Potere del VPC Peering

I principali fornitori di cloud hanno adottato la cloud privata virtuale (VPC) come approccio de facto per stabilire connettività tra le risorse. Ad esempio, un’istanza EC2 su AWS può accedere a una fonte di dati utilizzando VPC e servizi di endpoint VPC. Pensala come una connessione punto a punto.

Le VPC ci permettono di concedere accesso ad altre risorse nello stesso fornitore di cloud, ma possiamo anche utilizzarle per concedere accesso a servizi esterni. Considera un servizio che è stato recentemente abbandonato, ma con la fonte di dati originale rimasta in loco. Ecco come potrebbe apparire:

Questo concetto è chiamato peering VPC, e consente di stabilire una connessione privata da un’altra rete.

Un Esempio di Migrazione del Servizio

Consideriamo un esempio più concreto. Nella tua organizzazione, è stata presa una decisione aziendale per semplificare il modo in cui opera nel cloud. Continuando a sfruttare alcuni servizi AWS, la tua organizzazione voleva ottimizzare il modo in cui costruisce, distribuisce e gestisce le sue applicazioni, terminando un servizio cloud di terze parti in esecuzione su AWS. Hanno fatto i calcoli e hanno concluso che gli ingegneri software interni potevano creare e supportare un nuovo servizio auto-scalato su Heroku per una frazione del costo che stavano pagando al fornitore di terze parti.

Tuttavia, a causa di una lunga collaborazione con il fornitore di servizi, migrare la fonte dei dati non è un’opzione a breve termine. Non vuoi il servizio, e non puoi spostare i dati, ma desideri comunque avere accesso ai dati. Fortunatamente, il fornitore ha accettato un nuovo contratto per continuare a ospitare i dati e fornire accesso — tramite VPC peering.

Ecco come apparirà il nuovo accordo:

VPC Peering con Heroku

Affinché il tuo nuovo servizio (un’app Heroku) possa accedere alla fonte originale dei dati in AWS, dovrai prima eseguire la tua app all’interno di uno Spazio Privato. Per ulteriori informazioni, puoi leggere riguardo l’adozione sicura del cloud e la mia scoperta degli Spazi Privati di Heroku.

Successivamente, dovrai soddisfare i seguenti semplici requisiti di rete:

  • Il VPC deve utilizzare un blocco CIDR IPv4 compatibile nella sua configurazione di rete.
  • Il VPC deve utilizzare un blocco CIDR RFC1918 (10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16).
  • Il blocco CIDR del VPC non deve sovrapporsi con gli intervalli CIDR per il tuo Spazio Privato. Gli intervalli predefiniti sono 10.0.0.0/16, 10.1.0.0/16 e 172.17.0.0/16.

Con il tuo Spazio Privato attivo e funzionante, dovrai recuperare le informazioni di peering:

Shell

 

Annota il ID dell’Account AWS (647xxxxxx317) e il ID VPC AWS (vpc-e285ab73). Dovrai fornire queste informazioni al fornitore terzo che controlla la fonte dati AWS. Da lì, possono utilizzare sia la Console AWS che la CLI per creare una connessione di peering. La loro operazione apparirebbe più o meno così:

Shell

 

Questo crea una richiesta di peering. Una volta che il fornitore ha fatto questo, puoi visualizzare la richiesta in sospeso dal lato di Heroku:

Shell

 

Nello screenshot qui sotto, possiamo vedere lo stato di accettazione in sospeso per la connessione di peering.

Da qui, puoi accettare la richiesta di connessione di peering:

Shell

 

Controlliamo lo stato della richiesta un’altra volta:

Shell

 

Vediamo che la connessione di peering è attiva.

A questo punto, l’app in esecuzione nel nostro Heroku Private Space sarà in grado di accedere alla fonte dati AWS senza alcun problema.

Conclusione

Una verità sfortunata nella vita è che le relazioni possono essere inefficaci tanto quanto possono essere durature. Questo si applica alle persone e si applica alla tecnologia.

Quando si tratta di decisioni tecnologiche, a volte le situazioni e le esigenze in cambiamento ci spingono a muoverci in direzioni diverse. A volte, le cose semplicemente non funzionano. E in queste situazioni, la sfida più grande è spesso disfare un’implementazione esistente — senza perdere l’accesso ai dati persistenti.

Fortunatamente, Heroku fornisce una soluzione per migrare lentamente da soluzioni basate su cloud esistenti mantenendo l’accesso ai dati ospitati esternamente. La sua facile integrazione per peering VPC con AWS ti consente di accedere alle risorse che devono ancora risiedere nell’implementazione legacy, anche se il resto è stato aggiornato.

Seguire questo approccio permetterà al tuo nuovo servizio di prosperare senza interruzioni nel servizio al consumatore.

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