Provider lock-in
Piuttosto che rimanere imbrigliati nel cercare di non imbrigliarvi in un provider specifico, fate una scelta e disegnate una architettura che non sia statica ma che possa evolvere all'interno della scelta fatta.
I giochi di parole sono voluti.
Provo a spiegarmi usando come esempio la scelta di un cloud provider…
Se costruite un prodotto che funziona su qualsiasi cloud, qual è il rischio di adottare una tecnologia che si basa sul minimo comun denominatore a tutte le piattaforme possibili e che quindi si evolve più lentamente?
Sei sicuro che in futuro dovrai cambiare cloud provider?
Perché pagare ora in termini di flessibilità e velocità per una mossa che potresti non fare mai?
Anche a voler solamente considerare i costi (che sono, purtroppo, il criterio più utilizzato), sei sicuro che il costo di implementare ora soluzioni al di fuori del minimo comun denominatore non sia maggiore del costo di migrare in un ipotetico futuro ad un altro cloud provider?
Costruisci quindi per il tuo cloud attuale, ma costruiscilo in modo da non aver mai paura di cambiarlo: il costo del trasferimento a quel punto sarà più basso perché hai adottato un’architettura evolutiva, e sarà pagato solo quando devi effettivamente effettuare la mossa, il tutto senza rinunciare alla velocità che guadagni usando le abilità uniche del tuo attuale fornitore.

Commenti
Posta un commento