Costo del blocco del fornitore cloud

2

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?

    
posta Dan1701 15.02.2017 - 23:43
fonte

1 risposta

2

Dipende dall'importanza del software che utilizza i servizi. In questo senso non è diverso da qualsiasi altro tipo di tecnologia "lock-in" (non necessariamente specifica del venditore). Se il software è estremamente importante per i proprietari, finanziariamente o meno, la mitigazione del rischio includerebbe livelli di isolamento, in particolare per i servizi di "livello superiore" che potrebbero non essere disponibili in tutte le situazioni.

YAGNI giustamente raccomanda di non scrivere codice aggiuntivo che potrebbe non essere mai usato. D'altra parte, se si vede la scelta del fornitore di servizi cloud come una fonte di rischio, dovrebbe essere affrontata, come qualsiasi altro rischio. Idealmente i tuoi test automatici funzionano con più di un fornitore e vengono regolarmente testati in questo modo.

    
risposta data 16.02.2017 - 00:11
fonte

Leggi altre domande sui tag