Idea principale

Quando il cliente paga direttamente il proprio Azure SQL, il ragionamento spontaneo è che dovrebbe pagare meno l'abbonamento: una voce di costo è appena uscita dal perimetro del produttore.

Ne è uscita, sì, ma se n'è aperta un'altra. Supportare database installati presso i clienti obbliga a gestire versioni diverse, vincoli di rete diversi, meccanismi di replica, backup, snapshot, ripristini, permessi, monitoraggio, configurazioni specifiche — e soprattutto molti più scenari da capire quando qualcosa smette di funzionare.

Il costo di infrastruttura scende, il costo di servizio sale. Non sono le stesse voci, e niente garantisce che la seconda sia più piccola della prima.

Perché è importante

Il ragionamento spontaneo porta a concedere uno sconto proprio nel momento in cui il costo reale aumenta. L'errore è strutturale: si confronta ciò che è facile da quantificare — il prezzo di una risorsa — con ciò che non lo è — la varietà da supportare.

Ne viene anche una regola per gli impegni collegati. Garantire il ripristino di un database ospitato presso il cliente richiede tecnologia, test, monitoraggio, procedure di ripristino: è una responsabilità in più, quindi una voce da fatturare. Se il cliente preferisce tenerla per sé, la retention, la qualità dei backup e le conseguenze di un backup inutilizzabile devono ricadere esplicitamente su di lui.

Sfumature e limiti

L'aumento dipende dalla varietà che si accetta davvero. Una sola versione supportata, una sola configurazione, e il sovraccosto resta contenuto.

E una parte del costo è di apprendimento: i primi deployment costano più dei successivi, il che falsa qualsiasi proiezione fatta troppo presto.

Domande aperte

• Come quantificare in anticipo un costo di servizio, quando dipende dalla varietà che si sarà accettata?