Scalability of update calls in a common scenario

[pie-silo]

@4johnny

I believe the whole point of the IC is that developers (writing apps against it) should not need to care about any of it, aside from the SLA on specific calls. Indeed, the dev should be able to reasonably rely upon such “guarantees”, which can be composed in the dev’s architecture to ensure its own NFRs.

I think I agree with you: as a developer looking at an application platform, I want some indication of what performance I can expect to attain, and how I have to structure my app to get adequate performance – and some gut feel for how hard it will be for me to get good performance.

Since it’s at such an early stage I don’t expect SLAs or hard numbers, but I think I’m not alone in wanting at least some indication of what to expect, and a bit of background color about why the performance promises are realistic.

Mentioning SLAs raises another really interesting question: with major cloud platforms, you can get a credit if they significantly breach the SLA. They have money on the table for their performance and availability promises. Is such a thing even possible in a distributed system? It would be neat if DC providers had to pay me if my apps missed their availability/latency/throughput benchmarks. Although, then, I would worry about a vicious cycle that chases away DCs.

[4johnny]

Indeed, a related bigger question is: Does the Network Nervous System have its own legal fund?

Dominic talks a lot about the “platform risk” of existing cloud providers. But the IC has its own platform risk. Anyone can be sued up and down a supply chain.

First-time devs and startups of the future might not be thinking of such things when they are just getting going. But established enterprises definitely do. They can be sued; and they will want to know who they can sue. (This is a primary argument made by the Hedera folks in favour of their governance model.)