Ideia principal

Quando o próprio cliente paga o Azure SQL dele, o raciocínio espontâneo é que ele deveria pagar menos pela assinatura: uma linha de custo acabou de sair do perímetro do fornecedor.

Ela saiu, e outra se abriu. Dar suporte a bancos instalados nos clientes obriga a lidar com versões diferentes, restrições de rede diferentes, mecanismos de replicação, backups, snapshots, restaurações, permissões, supervisão, configurações particulares — e, sobretudo, muito mais cenários a entender quando algo para de funcionar.

O custo de infraestrutura cai, o custo de serviço sobe. Não são as mesmas linhas, e nada garante que a segunda seja menor que a primeira.

Por que isso importa

O raciocínio espontâneo leva você a conceder um desconto exatamente no momento em que o custo real aumenta. O erro é estrutural: a gente compara o que é fácil de precificar — o preço de um recurso — com o que não é — a variedade a suportar.

Isso também dá uma regra para os compromissos associados. Garantir a restauração de um banco hospedado no cliente exige tecnologia, testes, supervisão, procedimentos de retomada: é uma responsabilidade a mais, portanto uma linha a faturar. Se o cliente preferir ficar com ela, a retenção, a qualidade dos backups e as consequências de um backup inutilizável precisam ser explicitamente atribuídas a ele.

Nuances e limites

O aumento depende da variedade realmente aceita. Uma única versão suportada, uma única configuração, e o custo extra fica modesto.

E parte do custo é de aprendizado: as primeiras implantações custam mais que as seguintes, o que distorce qualquer extrapolação feita cedo demais.

Questões em aberto

• Como precificar um custo de serviço com antecedência, se ele depende da variedade que você terá aceitado?