A Developer’s Guide to Database as a Service

It can be confusing navigating the plethora of services that big cloud providers now offer. It may seem that the likes of Amazon AWS, Google Cloud and Microsoft Azure and others offer an inexhaustible selection, but when it comes to database services it boils down to three options. The first is installing your own database in a cloud instance, as an example, this could be Percona Server for MySQL on an AWS instance. The second option is to choose a Database as a Service (DBaaS) based on an open source project that’s offered by a cloud provider. An example of this is AWS RDS for MySQL. Your third option is to run a commercially supported, proprietary DBaaS, which is fully managed by a cloud provider, with AWS Aurora MySQL being a good example of this.

Running your chosen database on a cloud-based server is an ideal option if you have strong database administration skills yourself, or within your team. It’s likely to have cost benefits, assuming dedicated staff isn’t required for the project, and it will enable you to get up and running quickly while leaving the management of the infrastructure to your cloud provider.

SEE ALSO: Intelligent edge or cloud computing: Which is the killer app for IoT?

But when is DBaaS your best way forward? The obvious answer, when contrasted with running your own database in a cloud instance, is where you have a lack of expertise. However, although it may be a tempting solution to a common problem, it should not be the only consideration.

Before covering the reasons for when and when not to use DBaaS, we, first, need to make a distinction between a DBaaS that’s based on an open source project and a commercially supported DBaaS. The pros and cons generally apply to both but while an open source project based DBaaS is an excellent route if you and your team have less database administration and management experience, it is less likely to be suitable for more specific requirements. Additionally, this type of DBaaS is more likely to need extra support and services for important workloads. In contrast, a commercially supported DBaaS will likely support additional customisations and optimisation for workloads while also eliminating the need for you and your team to maintain server operations expertise in-house.

A commercially supported DBaaS manages the entire environment – physical and virtual hardware, operating system, networking, replication configuration, etc – so you can stay focused on software development. With the click of a button you can set up the database and then connect your application with a simple API call. And you’re ready to go.

DBaaS: The pros

The speed of development and cost advantages of DBaaS can be great for you and your team and these are three main reasons for using DBaaS:

Skills gap

As we have mentioned previously, a team of software developers are not necessarily going to have the experience to deal with, or want to wrestle with, the complexities of provisioning a database, when they will want to focus on optimising the software. In addition, many DBaaS providers offer complementary services, such as automatic backups of your data. This will enable you to do what you do best and not worry whether the database you are using is functioning properly.

Short-lived data

DBaaS is a good choice for continuous integration testing. DBaaS will enable you to rapidly provision the databases, pipe test data into the databases and delete the databases when they are no longer required. The DBaaS approach allows for faster and simpler automation of the testing environment.

Microservices design friendly

Where your project is using a microservices approach, DBaaS can be particularly helpful, even in a production environment, where a very large number of databases is being utilised. DBaaS can get you into production significantly faster.

DBaaS: The cons

There are two main reasons that DBaaS may be less suitable for your next project:

Complex Topologies

DBaaS focuses on ease of deployment. With the click of a button, DBaaS is designed to enable you to set up the database and connect your application with a simple API call, but to do so DBaaS providers limit the ability to deploy complex environment topologies and limit flexibility. For example, a relatively complex topology disaster recovery involving a primary synchronous replication cluster in one region and a secondary synchronous replication cluster in a different region, with an asynchronous relationship between the two would be outside the scope of most DBaaS offerings.

SEE ALSO: Cloud Native Communication: Using Ambassador and Consul Connect with Java Apps

IO-Bound Workloads

If your database has IO-bound workloads, you may not be able to find a DBaaS provider that offers a high enough hardware configuration specification to match your requirements. IO-bound workloads often need very powerful hardware, including high-end CPUs, terabytes of RAM and very fast storage.

As you can see, choosing to use a DBaaS isn’t simply down to whether it solves a lack of expertise on your dev team. Making sure that your project’s database requirements match the capabilities of DBaaS will remove significant operational complexity from the task and enable you to develop, test and deliver your applications faster and at a lower total cost. However, careful investigation of today’s DBaaS offerings, including Amazon RDS, Google Cloud SQL and Azure SQL Database, is going to be a necessary research job. It’s worth mentioning that If you are considering MongoDB as your commercially supported DBaaS your options are limited, based on the company’s recent change in licensing. Generally, though, you will find that each DBaaS offers different features and focus, including deployment models, performance trade-offs, instance types and more.

After analysis, you may find that DBaaS isn’t suitable and in which case, you’ll need to provision your databases yourself. If you don’t have the expertise in-house, a database consultant may be a cost-effective strategy, if you can’t afford new hires, and enable you to get the support you need.

The post A Developer’s Guide to Database as a Service appeared first on JAXenter.