The (True) Cost of a Cloud Database

Hello and welcome everybody. My name is Andrew Marshall, and I work at Cockroach Labs. I am joining you from Portland, Oregon, by way of this small circular portal on your screen, and I am very excited to join you all today to speak about the true costs of cloud databases.

Before I jump into that, maybe a little bit about me. One of the reasons I am excited to be speaking to you today is I have spent the last several years, prior to joining Cockroach Labs, working very closely with DevOps teams such as yourselves at companies like PagerDuty and New Relic, where I helped launch our observability tool for infrastructure monitoring. Before that, I was at AWS, also working with developers and DevOps teams. So I am very happy to be here speaking with all you all today.

When I consider the cost of a database, the first thing that pops in your head, the very simplified view, is of course that you are paying for something along the lines of a software license and the underpinning hardware that is needed to stand it up. Obviously, in the world we live in, that is no longer a reality. There are a lot of other considerations that you need to factor in, and some of them go beyond just the baseline of what it takes to stand up a database and move into what you need to do and think about to be very successful with your applications and the data that underpins them.

These are things like: what are the cloud costs per production and per usage? What do you do when the system goes down and you plan for disaster recovery? Are you enabled for scale, or does that cost more money? And of course, what is the tech ecosystem that you plan to support, and what will it integrate with both now and in the future? A number of different areas definitely go well beyond the baseline and need to be considered.

Going further, there are also some unplanned, or what I would call soft costs, that people need to think about as you use the database. There are DBAs who will need to interface with it, and a tool that is familiar to them obviously saves everybody a lot of time and saves them from manually doing a lot of tasks. Same thing with developers: is your database system conducive to the way that they develop, in a CI/CD world and the DevOps sphere we are all in? Does this tool accommodate the DevOps philosophy and help us connect the developer world with the infrastructure world on an ongoing basis?

Then you have things like planned downtime. Upgrading databases and any software is always going to happen, and then there is the unplanned that also will definitely happen. All of these are wrapped up with: are you utilizing the cloud resources that you have provisioned appropriately with your database, or does that change based off of scale?

Going even further, there are some what I would call business opportunities and/or risks that you need to factor in, that absolutely need to be thought through when you are planning for your application and the database that supports it. Things like the way you deliver applications philosophically: is this database in line with that? Are you going to be supporting multiple regions, and does that require multi-cloud? Do you need to hire new people to support this database? Are you tied into it? Then, of course, the risk factor: privacy, compliance. These are all major, major factors for applications that sometimes are not as visible at the very beginning, but as your application becomes more successful, those issues come to the front as well.

This is a lot. It is a little overwhelming, and that is not my intention for today, to make everyone feel a little depressed about this. Quite the opposite. Given all these considerations, the process I would like to go through is to set up a rubric that will allow us to set these areas into buckets, as a colleague of mine, Jim Walker, thought through, and basically break them down into what you need to think about: the baseline, more advanced topics, the management layer, and then some of those hidden considerations I mentioned as well.

Let us start at the baseline. Software, the software license, has a couple different ways to look at it. I came from a more traditional enterprise software world years back at Microsoft. That model is fairly easy: you provision the license and then use it. There is a pretty easy-to-estimate software support and maintenance cost on top of that, generally. When a new version comes out, you upgrade. That is a pretty standard model.

Moving on to commercial open source, it is a little different. It is free to get started, but as you grow and your application becomes more successful, there are more features that you probably need to scale it into enterprise readiness. Of course, support and maintenance then becomes a factor as well, and that is separate.

Finally, you have the pure open source software world that I know many of you live in. The thing I like to think about here is: is this free beer, something somebody will give me and I will immediately enjoy and it truly is free, or is this a free puppy, which I need to take home, put newspaper down in my house, and learn how to take care of before I can enjoy the companionship? Yes, there is free and then there is free, and of course, what is the support model for that type of software? That is something we need to factor in as well.

The other thing to think about is that a lot of the public cloud service providers have a shared responsibility model, so that support only goes so far with them.

Under hardware, there was a basic old equation: if you have a project budget, you subtract the software licensing costs, and then the amount of money you have left over is what you use to scale your hardware. Pretty simple equation.

Not today. Things have absolutely changed. If you are now hosting your application on-prem in your own data center, basically setting up your own cloud, it is a little bit more complex. You are negotiating prices, purchasing hardware as required, obviously scaling as you need to support your application, and you are responsible for everything there, soup to nuts. As you all know, that data center is your responsibility to keep up and running at all times.

If you choose a public cloud provider, some of those considerations are abstracted out a little bit, but then you still need to plan for how you configure things like load balancers and plan for different instance types. The management of that, again, under the shared responsibility model, falls back on you.

I will not spend too much time on the slide, since I think you are all very familiar with the value proposition of the OpEx versus CapEx model. But given the economic climate we are in, this is moving to the forefront a little bit more than it has been in recent years, and the value of paying for your technology on an operational basis, a predictable monthly cost, versus that big upfront capital expenditure, becomes more appealing. This dichotomy is going to be interesting again, if it never was for some of you. To me, it is.

Moving on to cloud costs: cloud services are very easy to provision, but then what? Do you have the right storage connected to it? Are your IOPS configured correctly for the right data load that you are actually using with your application? What about scale? If you are moving into multiple regions, are you prepared to support customers in those different regions with different workloads and consistency considerations? And of course, the cloud backup: you need to plan for that as well. That is not a given at all times.

Disaster recovery downtime will happen. We know this for a fact. It will absolutely require you, at times, to deal with a disaster situation. Things like the active/passive setup that people have used to deal with this inevitable issue are very complex. You have not just the backup systems, but the synchronization between the two, and then the egress costs depending on which regions you are in. Those are all things that need to be planned into a standard backup recovery system.

Scale is very non-trivial. Others would assume that to scale, you buy bigger machines, you add more hardware, it is a linear thing. Obviously, that is absolutely not the case. When you get into things like sharding, nobody ever said sharding was easy. It is very difficult. Manual sharding is time-consuming. It possibly changes your application, which is something that needs to be factored in. All this needs to happen without disrupting your business, so business continuity while you are scaling needs to be baked into the overall process.

The tool stack that you use now and in the future could always be changing. The integrations, the tools that you need to connect your systems, need to be factored in. Are you out-of-the-box ready to go with the various developer tools that you need to support things like data lakes, et cetera, or will that require some engineering work? That is another factor.

For the DBAs working closely with the database, this is where we get into management-layer stuff that we need to think about. Is this easy for them to use, or does it require a new skill set? Can DBA teams optimize for cost on the fly, or is that something they will have to do quite a bit of analysis and fine tuning on? All things need to be considered when considering that function.

Another area that I think is near and dear to everyone’s heart is the tax that could be placed on your development or engineering teams when standing up these applications with various databases. Is this something they can use out of the box? Is it using familiar SQL, for example? If it is, developers are going to have a much easier time prototyping and getting an application built into production, because they are not having to learn a new system. That is an incredibly important, yet sometimes underrepresented, issue with how you choose a database for your application.

Moving into your function, on the DevOps and SRE utilization or integration points: as you all know, the way software is built now has built in quite a few efficiencies. Applications now are not merely code thrown over a wall. It is code and the infrastructure that underpins it, and how it performs, and DevOps teams such as yourselves are responsible for that package. Does the database add stress to that situation? Does it help break some of the connection points between developers and the DevOps philosophy you are trying to implement in your company? These are all things we need to think about as well.

Also, the database should not be hard to use. It should be very simple. You have enough on your plate. I am thinking of the iceberg analogy, where what many people think DevOps teams are doing is here at the top, and then underwater are massive other considerations. The database, as much as possible, should not be one of those.

The database will need to be updated like any other system. You are going to want to upgrade your schema from time to time. You need to do this without any loss of business continuity. Is the process of upgrading your database and your systems seamless to customers, and does it happen in a time where your team can support it without a lot of extra time? There is some risk to planned downtime. Obviously these days, there is lots of data on what downtime of any type costs your company by way of lost revenue, loss of reputation, things like that. It is very non-trivial to understand what the tax is on planned downtime.

The aforementioned disaster scenario: as all of us know, everything fails eventually, every time. Are you prepared for that with business continuity, as I mentioned before? Are your databases going to be out of sync after that? Rebuilding after this type of failure could have massive technical debt implications, things that you need to factor in, which plays a big tax on your teams.

The other aspect of downtime that we need to consider is whether you have a strategy on recovery time objective and recovery point objective. These are things you will want to have a plan in place for, an SLA in place. Is that something you want to manage, or is that better off being embedded in a managed database system, for example?

The final thing I wanted to talk about on that management layer is cloud utilization. Yes, provisioning services is very easy, but how you use them is still very much up to you. It is a shared responsibility model for this. You need to keep close tabs on cloud utilization. We have all seen scenarios where there was an instance you spun up and forgot about, and then that is a recurring bill you were surprised about, quite frankly. You still need to configure these cloud instances to support your application needs and performance needs, and that does require some fine tuning. It is not simply out-of-the-box ready to go in that situation.

Now I am going to get into some of the hidden costs, or lesser-visible considerations, for your database concerns.

Performance: is the speed of your database exactly what the application needs, both in the primary region that you started in and other regions around the world? Theoretically, that type of fine tuning is going to need to happen. You need to make sure there are not pockets of customers or users having declining performance issues. When things like a schema change occur, how much can you do in your database layer versus having to do that in the application layer? Reducing the complexity of your application is a very big consideration for teams these days.

I think you are all familiar with the hundred-millisecond rule, but I like to put this out here as well: multi-region and multi-cloud are not trivial. This is a reality based on the speed of light, which is fun to think about, but from your database perspective, is the database built to understand those realities out of the box to allow you to plan accordingly, or is that something you need to factor into the actual configuration of your application?

Another one that is front and center these days: it is difficult to hire people. A lot of the technical teams that we are working with, and I think the managers among you realize this, know it is very hard to find great talent. When you get them, getting them onboarded and up to speed takes some time. Is your system requiring added people because that scale is not linear? You do have to hire new people, get them onboarded, and make them experts. The amount of automation you can do on the front end to keep you working with the existing team you have is definitely behooving most teams.

We all want to be able to make architecture changes, to change our application, to shift the way we deliver our software whenever we need. Vendor lock-in is a major issue people need to think about. Are you building with such freedom that you can make changes on the fly, or are you locked into something? That is something a lot of teams are thinking more about. I believe there is even some regulation happening in EMEA, possibly in the US as well, that requires things like architecting for multi-cloud compliance. I think that is going to increase. Making sure you are building something where you do not have a gun to your head in the near future makes sense for all of us.

Getting into a couple of the more legal compliance issues people need to think about: data privacy. Are you using a service that factors that in and helps you become more compliant or achieve your compliance goals, or is that completely up to you to do? There is a big hidden time, resource, and money cost there when that falls squarely on your plate. Ultimately, of course, it does, but the extent to which you are getting support from your systems definitely shortens that amount of time, so the business risk there is massive.

Compliance is the last item I wanted to touch on. There are ever-changing rules in the US and EMEA, and the ability to help you become compliant in the regions where you are actually serving customers is a big value-add from the user perspective. These laws are no joke. They oftentimes carry major fines and, frankly, have business bottom-line impact. The more you are working with a system that is an expert in dealing with this multi-region, especially compliance, the better.

That was a lot, broken down into a couple buckets to help us understand it. Ultimately, there is a cost to all of these things. It is a lot to think about, versus the alternative, and probably not the most desirable thing for you all to spend your time on.

This is where I introduce CockroachDB. We are very proud to offer our database to customers in a self-hosted model, but also as a database-as-a-service, a purely managed service database offering where we take care of a lot of the things that we mentioned earlier today. CockroachDB Dedicated has full live support. Our team of SREs support the database, so you do not have to. The pricing models with Dedicated are very predictable and connected to scale, so no surprises there. We are delivering distributed SQL for your application, so it is very dependable, very known by your developer teams, and built to accommodate scale in the future and resilience. For those who do not know, the name Cockroach comes from our ability to deliver very highly resilient, very hard-to-kill databases.

We are wire-compatible with Postgres, and we use familiar SQL, so for your developers it is very easy to use. The issues with configuring databases on the fly are built into our product. We offer things like helping you observe inefficiencies in your system, then make changes to your database, including schema changes, without any downtime or any customer-impacting downtime whatsoever. These types of rolling changes happen behind the scenes. We do it for you: one less thing to think about, or 12 less things to think about.

All of our nodes are read-and-write nodes. That helps you scale, versus some of the public cloud-provider-based databases that do not offer write nodes across your systems. That is a major factor, and it really helps with scale and data locality. Geopartitioning, the ability to keep the rows of data that you want in a specific location, really helps with performance and regulatory compliance for these multi-region scenarios as well. All of those are things that we have factored in, and our product was architected from the ground up to do. Being cloud-agnostic is built into the CockroachDB offering, so you are not locked into any one vendor.

Just to wrap things up, our solution, in my opinion, encapsulates the best of three different areas. The best of the traditional relational database: being durable, consistent, and very familiar with SQL. The best of NoSQL databases: highly scalable, incredibly resilient, and very flexible based off your needs. Finally, the cloud value proposition that we all know well: pay for what you use, be highly elastic, and support a modern distributed system. Legacy databases do not do this. They quite frankly were never built 30 years ago to accommodate microservices, Kubernetes, or any of the modern CI/CD processes that we build software with.

CockroachDB is a distributed database that allows you to offload the management aspect of the database to us, guarantee transactions, use familiar SQL, and scale wherever you want to go, including data locality.

That is my talk. Thank you all very much for joining us today. I hope you have a fantastic rest of the show. I know some folks from Cockroach Labs are here that you can speak to, and I have also added a resource page for DevOps Enterprise teams. You can go check out and find out a little bit more about what we spoke about today, and my contact information is below as well. Again, thank you very much, and have a great day.