Dobbiamo veramente preoccuparci del lock-in rispetto ai fornitori di public cloud?

Ultimamente, in diverse occasioni, mi è capitato di sentir sollevare la questione del lock-in come motivazione per non migrare applicazioni web da infrastrutture monolitiche verso servizi di public cloud come Amazon Web Services o Google Cloud Platform.

Quando ci si approccia a scelte di questo genere è normale porsi certi interrogativi, ma realmente dobbiamo essere spaventati da un eccessivo lock-in rispetto a questi fornitori?

Per provare a dare una risposta a questo quesito ho voluto raccogliere per punti alcune riflessioni che mi sono posto su come affrontare la questione.

1. Ogni scelta tecnologica comporta un lock-in

La scelta di un fornitore a prescindere dallo stesso è di per sè un lock-in come ogni scelta tecnologica che ci troviamo periodicamente a compiere (quale db engine? quale stack tecnologico?). In questo i servizi di public cloud non si differenziano da nessun altro servizio, tecnologia o fornitore. Quello che dobbiamo stare attenti ad evitare è che i costi per un eventuale piano di uscita siano eccessivi.

2. Abbiamo necessità di cambiare vendor così spesso?

Speriamo di no. Se stiamo valutando il fornitore di un servizio per una migrazione o l’inizio di un nuovo progetto partiamo certamente con la speranza di non trovarci a breve a compiere nuovamente questo tipo di scelta. Bisogna prestare più attenzione al processo di selezione per non commettere errori nell’ottica di non dover cambiare fornitore se non in un periodo medio lungo. Se ci ritroviamo a dover cambiare fornitore in un periodo breve allora il problema non è tanto il lock-in quanto forse il nostro processo di selezione del fornitore.

3. La vera scelta è sui servizi

Ogni volta che scegliamo un fornitore di public cloud in realtà ci si apre al ventaglio dei differenti servizi che ognuno di essi offre, ed è proprio nel scegliere questi che possiamo fare la differenza sul vincolarci o meno al singolo fornitore. Quindi il pericolo di lock-in sta più nella scelta del singolo servizio che nella scelta del fornitore. Ad esempio optare per un modello Infrastructure as a service (IaaS) ci porta a vincolarci meno ai singoli servizi come avverrebbe nel caso di una scelta di un servizio Platform as a service (PaaS) (es: AWS Elastic Beanstalk, Google App Engine). I core service che sfruttiamo in uno stack IAAS sono sicuramente comuni a tutti i principali vendor e sarà più facile poter effettuare una migrazione.

4. Serveless

Quando si parla di serverless è il terreno in cui abbiamo più possibilità di incappare in lock-in rispetto al servizio di singolo vendor e con cui ci scontreremmo maggiormente in caso di migrazione. C’è comunque da dire che i principali vendor stanno andando tutti verso la stessa direzione con offerte quasi equiparabili e si stanno definendo degli standard sempre maggiori. Vi segnalo il servizio serverless.com che in ottica di code as infrastructure promette di poter definire un ambiente serverless in maniera agnostica rispetto al vendor.

5. Standard open

Quando possiamo dovremmo scegliere standard open e pattern riproducibili. Recentemente ad un evento di Google sul loro cloud mi sono sentito ripetere fino all’esasperazione che con loro non c’è lock-in visto il loro utilizzo di standard open. Questo è vero fino ad un certo punto e apre anche all’altra grande domanda: chi li definisce gli standard? Avere comunque attenzione ed essere informati su quali sono gli standard che si stanno definendo e stanno prendendo più piede può solo essere di aiuto nelle scelte.

6. Avere sempre un piano di uscita

O almeno avere la percezione di quale impatto dobbiamo affrontare per un eventuale cambio di fornitore: quali sono i servizi a cui siamo legati maggiormente e con quali tecnologie o servizi corrispondenti di altri vendor potremmo sostituirli? Risulta comodo fare un mapping della nostra infrastruttura sui servizi analoghi degli altri vendor e mettere in evidenza quali problematiche dobbiamo affrontare per passare da un servizio ad un altro.

7. L’importante è la consapevolezza

La consapevolezza dei limiti della scelta, dei compromessi che si devono accettare e dei vantaggi o svantaggi che ne conseguono. Non dobbiamo limitarci e perdere l’opportunità di sfruttare certi servizi che migliorerebbero drasticamente la qualità del nostro prodotto o del nostro flusso di lavoro per paura di legarci ad un vendor. Quello che abbiamo da perdere è sicuramente superiore all’effort per svincolarci da un eventuale lock-in.