I read this nice piece on CosmosDB and setting performance levels. It covers how you set some level of performance for Request Units (RU) and CosmosDB handles the rest. Great, right? Set the level of performance you need and that gets handled. The question I have is how do you know what level of performance you need?

This is one of the issues with the Cloud services that I see. It doesn't matter if you use PaaS or IaaS, most of us really don't know what level of performance works. We tend to guess, and far too many of us don't use regular monitoring to decide if we are over or under powered. I find many DBAs and sysadmins would prefer to be over-provisioned and then let the server trundle along at a lower resource usage so that no one complains. 

When we move to a cloud type service, we tend to be more cost conscious, which makes sense when we're paying by the minute. We want to minimum level of hardware we can get, but we don't want to cause unnecessary complaints, either from customers because the system is slow, or from the CFO because costs are high. Using your old method of over-provisioning hardware (or DTUs) usually causes complaints from the CFO.

The piece goes into some ways that you can start to evaluate your performance level for CosmosDB, and how to deal with throttling while you tune your RUs with a new application. This works great if you're in a (more) greenfield area of development. Not so great if you're lifting and shifting some application from another platform. Then we might need to ensure that we are responding quickly to issues, or better yet, have scripted responses that scale up or down.

The same thing should be done for our relational systems. The Ops part of DevOps needs to be using monitoring and instrumentation to measure performance, adding capacity as appropriate, which should be before users realize there's an issue. With today's virtual systems, adding CPU and RAM usually is fairly easy, and it's easy in the cloud as well.

Of course, all this monitoring isn't just to add capacity. Having a better sense of what's going on can help you pinpoint poor code. Getting someone to fix that code becomes a lot easier if you can show that better code would cost less for our systems. It can be amazing how much more developers care about their code when the CFO gets involved.