For enterprises, the amount of data they have continues to expand, representing an increasing cost. While this data might be vital to business operations, it requires more and more resources to support. According to Gartner, companies will spend $203.6 billion on their database management systems (DBMS) by 2027. More than half of this will be in the cloud. The most interesting point in Gartner’s prediction is that more line of business teams will be responsible for making decisions on DBMS, taking on 75 percent of all deployment choices.
Alongside this, companies are now spending far more on cloud than they like as well. According to Forrester Consulting and Boomi, 72 percent of companies exceeded their cloud budgets in the past year. More than half (52 percent) said they over-spent on cloud storage. According to EY, 72 percent of organisations chose to move an application back on-premise due to their cloud costs. It should not be a surprise that the growth in data is leading to unsustainable and unpredicted costs in the cloud.
So, what can we do here? How can companies keep control over their spending when it comes to data? Secondly, are these lines of business teams fully equipped to take advantage of new DBMS systems for their applications?
Any decisions inevitably have a long term impact on how much it costs to run applications over time. Both line of business and application architecture teams have to look at their decisions and how much it costs to support data in the long term. These teams will have to collaborate, looking at how much it costs to run using DBaaS, and whether DBaaS offers the right approach compared to using Kubernetes and automation to manage data instead.
Applications, data and Kubernetes
Kubernetes is increasingly popular for deploying applications – according to the Cloud Native Computing Foundation Project Journey report, more than 90 percent of global organizations will be running containerized applications in production by 2027. It provides a convenient platform for managing and orchestrating cloud-native application components.
Developers love containers as they are easier to use for microservices architecture applications. The combination of containers and Kubernetes solves a host of problems. However, for databases, it has been a different story. At the start, it was not possible to run databases on Kubernetes, as Kubernetes did not support these stateful workloads. Instead, developers and DBAs had to connect their applications to their database instances and essentially run two distinct platforms as part of the infrastructure. This added complexity and management overheads, as these two systems had to be operated concurrently. In response, picking a Database as a Service (DBaaS) option was popular, as it handed over a lot of the operational workload to a third party.
Over time, Kubernetes has added more support for stateful workloads including data and databases, removing some of the existing headaches. Now, you can use databases in containers and manage them with Kubernetes, reducing the number of platforms that you have to support and getting the same cloud-native delivery benefits for your data as well as for your application. While DBaaS deployments have continued to demand a ‘cost of convenience’ for running these systems on your behalf, you can now achieve the same results using Kubernetes with base cloud instances yourself.
Using databases on Kubernetes has improved massively over the past couple of years. The growth of Kubernetes operators made it possible to automate many routine database operations. For example, developers and database administrators find setting up instances time consuming. Automating the workflow for deploying a database in a container as part of the software development process can make developers more productive. Yet, while individual automations help, the real challenge was making the whole data management process easier.
Kubernetes and databases – can you save on costs?
Automation alone is not enough to reduce your spend. Having unsuitable or poorly sized instances at the start will increase your spending over time. Even if you help your developers be more productive, that additional expense will quickly eat into any savings that automation alone might deliver. Automating the wrong things just lets you carry out mistakes more quickly.
Looking at DBaaS, you can easily find that making things easy leads to rising bills, especially when you over-specify instances or use cloud resources inefficiently. While you might be happy to pay for convenience, it’s now possible to achieve that same convenience on your own terms. Using Kubernetes and Kubernetes Operators for databases, you can now automate many of the steps that DBaaS services include and charge significant premiums for.
Above this, you can reduce your spending by looking at how your environments are sized correctly for what your team – and their applications – need across their life cycles. This is something that you can understand and control more effectively than an outside supplier. By understanding your needs, you can be more precise in what you decide to use and how you use it.
To get a true comparison, you can look at the cost for using a Kubernetes service, running Kubernetes on a standard Infrastructure-as-a-Service instance, or using a DBaaS instance. The cost for “vanilla” cloud services will typically be much less per instance compared to the same sized instance as part of a service. This differential can be substantial – for example, the cost of an AWS RDS install covering a large compute instance and 200GB of storage per instance. This would work out to around $168,000 per year for ten database instances. Pricing here may vary depending on which AWS zone you choose and how much you utilise the service, but databases tend to run continuously. Conversely, you can adopt your own approach by using vanilla Kubernetes to run the workloads instead. Looking at the cost of storage, compute and control plane services, the cost for ten instances would be around $92,000 in the same location. This is a significant reduction in costs, so being able to run your own processes using automation can deliver more efficient use of capital. At the same time, using Kubernetes Operators alone is not enough to deliver everything that you might need – there is a lot of value in how you set up those automated processes informed by database management best practices and experience around areas like security, backup and operational performance.
From the early days of Kubernetes Operators to today, running databases on Kubernetes can now effectively scale alongside application deployments. This runs data and application workloads in lock-step, so scaling can be managed in one way rather than needing to synchronise two different platforms. This helps your team deliver architecture more efficiently. It also helps to reduce the overall cost of delivering that infrastructure over time.
Obiidykhata is the Solutions Manager , Cloud Native Products and Services, Percona.