blog
Understanding the DBaaS Architecture
What is a DBaaS?
The current trend for DBaaS or Database-as-a-Service and its terminology have grown so much that even its nomenclature also are termed as a cloud database or a managed-service database service. Technically speaking, DBaaS was initiated primarily as a consolidated exercise to reduce capital expenditures (CaPex). This initiative has brought into a quest which resulted in a number of great innovations that helps SMBs to large organizations and cut a huge amount of costs from spending maintenance of the underlying physical servers and costs for keeping the people and its expertise to be always on top for administering and performance monitoring.
DBaaS is a way of delivering database functionality as a service to one or more consumers. A DBaaS platform would provide automated procedures for database deployment, monitoring, backups, recovery/repair, scaling, security/multi-tenancy, etc. This type of automation is especially useful where agility is needed, e.g. for systems that require elasticity by scaling out or scaling back at short notice, or for temporary deployments associated with dev/test/QA. Now that you’ve automated the repetitive stuff, you can start using your time and skills to optimize your schemas and configurations, help developers write better queries that scale, and work on system architecture or strategic database initiatives.
Benefits of Deploying via DBaaS
The DBaaS environment has evolved throughout the years. DBaaS is a PaaS (Platform-as-a-Service) component and figuratively you can take AWS RDS as the common example of this type of service. Over the years, database providers and companies such as MongoDB, MariaDB, Aiven, ElephantSQL, and etc. were sprouting and offering a hybrid type of multi-cloud setup using cloud offerings from other available providers such as Google Cloud, AWS, Azure, Digital Ocean, and others. They are also showcasing their own setup and bundled software included as an alternative in the competitive global database market for using the DBaaS. From backup and restore offering, rich and granular monitoring with observability, configuration management, in-depth query analysis which might not be available from the pioneers in DBaaS. This evolution helps the competition more alluring yet a healthy alternative as it provides advantages and benefits for SMBs to large organizations.
DBaaS delivers focus and provides granular services based on a service catalog during deployment. Hence, there are great benefits when deploying DBaaS:
- Eliminate cost of buying expensive hardware and software
- Self-service portal for agility and speed. Provides for outsourcing the administration and monitoring of databases and operational activities such as backup, recovery, tuning, optimization, and patch management. Administration tasks can be automated such that it can be scheduled or proactively initiated to support various database activities.
- Ability to scale-up and scale-out easily
- It is a self-service database provisioning and can be done on demand. The end-users can create or tear down database services based on their needs.
- Ability to measure database usage and chargeback users. IT staff do not have to manage the database environment. All tasks are offloaded to the DBaaS provider.
- Speeds up application development and testing through faster provisioning of new databases and automation of the administration process.
- Remove the requirements of racking and stacking hardware to improve productivity. No need to include long discussions as part of the Capacity Planning process as it is already stacked up by the provider.
- A move from CapEx to OpEx for the database service. Capacity can be obtained as and when needed without having to procure capacity in advance.
DBaaS Architectural Models
There are different consolidation models that are tested and can be utilized to provide DBaaS architecture. Most simple and common approach to deliver this setup is through virtualization. Implementing your DBaaS with server virtualization allows you to spawn instances on the fly and on demand, and at the same time can be run on different tenants or providers through cloud APIs. Virtualization also allows you to run multiple OS on the same hardware sharing physical resources such as CPU, memory, or storage devices such as other VMs.
Another model is using a platform consolidation. It consolidates multiple databases on the same operating system, or a cluster. However, having this type of setup faces database sprawl as it continuously increases and invariable leads to larger administrative overheads. It also adds complexity with granular monitoring against the host resources consumed for a specific database. An even better consolidation model is the capability to host multiple schemas from different tenants within the same database. A good example of this is orchestrating with Kubernetes and has a bunch of container nodes in a form of pods. I’m borrowing these concepts from a book called Building Database Clouds in Oracle 12c which is in fact common approaches when designing a DBaaS architecture infrastructure. See the image below:
Certain organizations who are investing in DBaaS offering rely on a hybrid setup. For example, Aiven uses AWS, GCP, Azure, Digital Ocean, and UpCloud. While MariaDB SkySQL also uses GCP and is heavily dependent also into Kubernetes for orchestrating its services and also its database self-healing process inherits the process of how Kubernetes functions when it comes to resiliency.
On the other hand, VMWare’s approach for DBaaS relies heavily on their ESXi as a virtualization platform and uses vSphere to run business-critical applications to meet your most demanding service level agreements (SLAs) at the lowest total cost of ownership (TCO). With their vSphere, this solution gives you operational insight into the virtual environment for improved availability, performance, and capacity utilization. So it’s comparable to its counterpart, AWS Console. They have also vRealize Orchestrator which is a development- and process-automation platform that provides a library of workflows.
With all of these types of models, approaches for implementing a DBaaS can lead from a simple yet complex type of architecture and even to a more higher degree of abstraction and complexity.
DBaaS Security and Isolation
Implementing your DBaaS service can be a pure challenge when dealing with security and isolation of your database servers. It’s one of the primary concerns of SMBs and large organizations especially compliance and regulations to specific laws adhering based on the type of business that the end-users are offering for their vast number of clients. Data has to be expressively isolated from each other especially the type of compute instance and resources the end-user has provisioned during the workflow in your service catalog. Once the provisioned database is spawned, it is expected that monitoring the performance and also the database health has to be isolated and only be dedicated to each resource consumed so it’s easy to utilize the managed-service offering. Take note that it’s not only the end-users are monitoring the database health and server or compute instance but also the usage is aligned to its usage as cost and price has to be based per usage.
Of course, this section has a lot to cover as networking, VPC peering, tenancy, zones and regions are part of this section aside from consolidating the requirements governing compliance to laws and regulations. Basically, this has to be taken into account for DBaaS architecture.
DBaaS Scalability and High Availability
One of the primary reasons why it’s enticing to switch from on-prem to a managed database service is that it eases all the worries and concerns especially on dealing and improving your RPO (Recovery Point Objective). Aside from cutting the cost, your software engineers, DBAs, and solution architects can focus on the business side of things and not spend optimizing and scaling your database infrastructure to avoid large downtime and lower RTO (Recovery Time Objective). For a DBaaS infrastructure, it has always been equipped to be able to scale-up or even on demand tear-down if needed. While having these features available in your infrastructure, resiliency is always a key especially when a database goes down, a new and fresh database is re-built and able to join again the database cluster that the end-user has launched or provisioned.
For example, MariaDB SkySQL uses MaxScale to constantly monitor the status of its database clusters. Once a primary database fails, MaxScale promotes the most-up-to-date replica to be the new primary and all existing replicas will be redirected to the new assigned primary to function back again. As it adapts self-healing behavior just like how Kubernetes works, in case a replica fails, a new node will be built in the background so that each time a cluster is degraded it will always try to fix itself and back to a normal state of the database cluster.
Using Multi-zones is also involved in this section as it’s very important that in case a hybrid type of DBaaS infrastructure is set up, such a datacenter in a specific zone has a possibility to fail. In that case, with multi-zones, it helps avoid huge downtime in case your database fails or encounters a datacenter outage.
The Existence of DBaaS APIs
A developer-friendly DBaaS always provides APIs or a series of command lines that are available for developer utilization especially for automation. For example, using AWS RDS provides APIs to use and avoid using web UIs to follow the workflow available in the service catalog. Providing APIs allows your end-users to manage their desired outcome and management of their database compute usage provisioned into the DBaaS as a fully-managed service database.
e.g. Creating a Database User using MongoDB Atlas API
curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest
--header "Accept: application/json"
--header "Content-Type: application/json"
--include
--request POST "https://cloud.mongodb.com/api/atlas/v1.0/groups/{PROJECT-ID}/databaseUsers"
--data '
{
"databaseName": "admin",
"password": "changeme123",
"roles": [{
"databaseName": "sales",
"roleName": "readWrite"
}, {
"databaseName": "marketing",
"roleName": "read"
}],
"username": "david"
}'Aside from management of databases in the managed service offering, your end-users would also like to retrieve alerts, metrics, invoices, teams, projects, and many more to allow their company to have more management in terms of RBAC (Role-Based Access Control). Your DBaaS shall have the presence of RBAC but in a certain scenario that there are cases that a specific end-user (SMBs or certain organization) would like to manage and provide more filters only in their organizations. So using API’s to manage this efficiently inside their organization would help simplify the approach of OpEx and capacity management.
Conclusion
DBaaS is just one of the generic architectural concepts that exist in the world of cloud computing. It is an offering which is a type of paid service to manage databases, which can be from various vendors, to offer unique services that provide efficiency and productivity to the end-users. It can be inevitable to shop and find such available DBaaS in the market that offers fully-managed type of database management. It is up to the end-users to choose the right DBaaS infrastructure that promises customer satisfaction, higher SLAs, package services, and appeal (expertise and professional engagements) to their clients.
