Considera una situazione di sviluppo greenfield in cui vengono considerati gli strumenti cloud rispetto alle soluzioni interne, nella vena di AWS SQS rispetto a Kafka self-hosted, ECS vs Mesos-Marathon, Lambda / Azure Functions vs Whisk vs an array di API / servizi personalizzati.
A parità di tutti (costi finanziari, esperienza tecnica, ecc.), come si può valutare il costo del lock-in del fornitore quando si decide se utilizzare o meno i servizi cloud oltre la VM di base e i prodotti di storage? Ho visto in diversi casi, dove i timori di lock-in del fornitore hanno chiuso l'argomento sull'utilizzo di servizi cloud di livello superiore senza nemmeno consentire una valutazione tecnica o finanziaria del loro valore per il progetto.
Naturalmente c'è un costo a nell'utilizzo di servizi specifici del fornitore, ma tale costo non può essere così grande da eclissare tutti gli altri costi di sviluppo del software. Per evitare che i servizi cloud di alto livello sembrino, IMO, essere un argomento simile a "costruiamo un ORM completamente astratto nel caso in cui avessimo bisogno di scambiare i prodotti del database." ... alias YAGNI .
L'autosufficienza è spesso la strada verso la povertà e tutto il software dipende da molti altri livelli per avere successo: Docker, Linux, npm, gcc, e dozzine e dozzine di altri, ma questi sono raramente considerati come "blocco" ins". I costi per eseguire qualsiasi internamente, possono essere significativi, tra cui:
- Perdita di tempo sul mercato
- Risorse dedicate al mantenimento di servizi interni e non generatori di entrate
- Maggiori costi operativi
Quindi, qual è il modo giusto per valutare equamente i servizi cloud, riconoscendo il costo del lock-in del fornitore come un componente nella strategia di prodotto, senza consentirgli di dominare altri problemi?