What is a native cloud database?

Before this series is finished, I plan to define in detail what the different levels of cloud nativity might be to allow readers to classify products based on architecture, not marketing. In this article, I will introduce some general concepts. First, let’s talk about a lot of things in the cloud that aren’t cloud-native.

Any database that runs on physical hardware can run on virtual machines and, therefore, can run on virtual machines in the cloud. Databases without cloud capacity other than the ability to run on a virtual machine on a cloud provider are not cloud native. Worse, many anecdotes suggest that there are no significant savings to be made by moving a database from an on-premises server or virtual machine to a cloud virtual machine with no other changes to take advantage of. elasticity of the cloud.

Here are two general definitions for your consideration:

1) A native cloud database will have one or more features that use capabilities found only on a cloud computing platform, and

2) A native cloud database will demonstrate the economic benefits derived from these cloud-specific features.

Note that the way you pay for services via capital expenditure (CapEx) or operating expenditure (OpEx) does not bring any economic advantage. If the monetary costs of a subscription are more or less equal to the financial costs of a license, the savings are linked to the tax law and not to the economy. Beware of cloud subscriptions that change the way you pay without clearly adding beneficial cloud features. These subscriptions are often the source of the anecdotes without savings mentioned above.

This next point concerns the separation of storage and computation. Businesses have long disconnected their databases from a simple heap of disks (JBOD) to shared storage such as SAN or S3. Today, any database can use shared storage. Needless to say, any database that can use shared storage has separated storage from computation. By using the idea that there must be functionalities, and not marketing, which allow computation to evolve separately and more or less dynamically from storage as definition, we will be able to advance in this area.

3) For the storage to be appropriately separated from the calculation, it must be possible to dynamically evolve the calculation from top to bottom.

Then, when calculating the scales, it evolves to a different granularity. An application or database that automatically adds and subtracts virtual machines offers different economic benefits than a database that evolves using containers. Applications that add and subtract containers have different savings than applications that use so-called serverless containers at scale. In this dimension, we will try to characterize the granularity to take into account the associated cloud economy. This topic will be covered in more detail later, so I will save the rule for this post.

Note that it is possible for database providers to develop a granular architecture and use the economic advantages associated with their advantage. They may charge you for the time that part of your database is running, but be charged by their supplier for smaller pieces. This is not a problem unless their overall costs become uncompetitive.

Finally, and in some respects the least, different products may charge for time in smaller or larger chunks. You may be billed by the hour, minute, second, or in small increments. Think of the economy of scale that I suggested in the first articles of this thread. If you are billed by the hour, there is no financial incentive to scale up to complete the job to the minute. You will be billed the same way for ten minutes or fifty minutes when you are billed by the hour. Rule:

4) Cloud databases that charge in smaller time increments are more economical than those that charge in larger increments.

The rationale here is probably obvious, but I will cover it in detail in a later post.

Once these concepts are in place, we can discuss how architectural changes affect every aspect of the cloud economy.

Note that this last sentence was written assuming that a British computer scientist with an erudite accent would speak it when they create the PBS series from these posts. Not.