“The move to autonomous databases is taking place already – from a technology perspective, a lot of the required tools already exist. What still needs to change is how teams manage their approach”
Whenever you have an application, you have data. Aside from the result of your carefully crafted application, the application will also tell you what it has done, how long it took, and what happened to that resulting information. All this data has to be stored somewhere, it has to be easily accessible, and it has to be useful.
Databases exist to look after this information, writes Matt Yonkovit, Chief Experience Officer, Percona. They provide you with a way of storing, accessing and then analysing that data. However, modern application designs and working practices are changing how databases work as part of applications.
Today, databases hold more data than ever from a variety of different application components and for more reasons.
Alongside providing a record of activities for record-keeping and analysis, enterprises can create ever-more useful ways to take their data and combine it in new and different ways. Traditional database management skills remain important, but the speed at which companies want to develop and release new software and services means that these processes are at risk.
Automation can help, but even this may not be enough to keep up. Instead, we are seeing the development of autonomous databases.
Autonomy for You and Me
Autonomous databases take the precepts of automation further. Rather than relying on individual database administrators to run scripts and tend instances, why can’t the database implementations take care of that themselves, automatically? Why can’t security, backup, and other management processes be handled in the background, letting developers concentrate on what the application does? And why can’t issues of scale be handled in the same way?
These three points – management, automation, and scale – are all essential to running new applications. The growth of containers and container orchestration in new application development is a good indication of this. According to Gartner, less than 20% of companies are currently running more than two applications on containers. However, 70% of companies will have more than two containerised applications in place by 2023. This increase in container adoption will force more systems to work in the same way, including databases.
Container-based applications can scale up or down rapidly in response to demand. If you get ten times the customers you expect, then adding the required number of containers to run at the right demand level is simple – and can be automated with container orchestration tools like Kubernetes. However, unless your database instances are prepared for this ebb and flow in traffic, performance can suffer.
Kubernetes Operators solve this problem. Operators help you build a cloud-native application to run on containers, easily balance resources against demand, and provide an avenue for consistent and reliable deployment of new services. With Kubernetes Operators, you can ensure that your new environments are consistent across cloud providers and on-premises environments. These Operators can also help automate and remove human interaction from the process over time, making instances like databases autonomous.
In practice, what does this mean for database management? Using Operators, you should be able to deploy additional cluster environments when required. This allows you to support applications, scale up the number of nodes within a cluster to meet the rate of data being created, and then automate the backup and monitoring processes so that the right steps are being taken to manage that cluster instance. Alongside this, autonomous database instances have automatic node recovery to provide self-healing should any individual node fail.
These processes are essential to keep the database running efficiently and remove some of the common hurdles. By taking care of elements such as encryption, security, data backups, and replica data set-ups in the background, autonomous database instances promise better service levels for the applications that run on top of them.
No ‘One Size Fits All’ Approach
The move to autonomous databases is taking place already – from a technology perspective, a lot of the required tools already exist. What still needs to change is how teams manage their approach. When it comes to data, are you comfortable handing over all responsibility to an automated system? Is it wise to completely trust the system that you have designed? Or do you prefer to let an autonomous database implementation augment your approach to solving problems instead?
One challenge for autonomous database implementations is that there are two groups of issues that have to be managed: those that apply to everyone, and those that are specific to your business. Everyone needs to keep their data secure, ensure their database nodes are backed up properly, and update their instances efficiently. Autonomous processes around these steps would, therefore, make a lot of sense.
There are also elements that may be specific only to your application deployment and setup. For example, application tuning and performance should involve understanding your specific requirements and implementation decisions. The choices you make may mean that you need a larger replica set for your data compared to another company running the same database. Providing autonomous database recommendations on that instance has to be tailored to your needs, rather than being a single rule applicable to everyone.
When moving towards more autonomous database designs, vendors promise to help you remove mistakes and improve performance. These implementations provide data on how they are operating, which allows you to make informed future decisions regarding which steps are automated and when decisions should be made.
Rather than relying on people to carry out standard management tasks, automation should reduce workloads and allow your skilled people to focus on creating and adding more value to the business. Connecting multiple steps makes greater autonomy possible and frees up more time to concentrate on other issues. Autonomous databases should improve application performance; in turn, improving your business performance.