What to Consider When Using DBaaS Around the World

Ariel Maislos is CEO of Stratoscale.

It’s been a few years since “anything as a service” started gaining popularity. Since then, providers have improved the performance and reliability of these services, and the largest companies in the world have begun to adopt them. When it comes to Database as a Service (DBaaS), the reason is simple: Instead of setting up and taking care of the whole system by yourself, you can delegate the setup and ongoing care to someone else. If you decide to go with a cloud provider like AWS or Azure, you’re delegating tasks to some of the top experts in the world.

Although reallocating your data is always a sensitive process, the fact is that out-of-the-box DBaaS solutions are more secure than out-of-the-box on-premises installations. With DBaaS, the OS is all set up, the firewall is up and running and the database has the latest patches.

Types of Databases

There are two major database camps: relational databases and NoSQL databases. Relational databases are most frequently relied upon because the technology is a mature and proven concept with most database managers. NoSQL databases have gained in popularity over the past decade. The benefit of using NoSQL databases is that you can easily store unstructured data to avoid creating tables at the beginning. Although this can be extremely useful, it is also a tempting way for developers to simply store data that they'll index at a later date. While NoSQL databases are not at fault for that per se, they do enable developers to quickly accumulate a lot of technical debt.

Almost every cloud provider has its own set of relational and NoSQL databases as a service. When choosing which one to use, you should not only decide between relational, NoSQL or a combined approach, but also investigate which database model best suits current and future needs.

Benefits of DBaaS vs. Hosted Solutions

Before DBaaS became a viable alternative, hosted solutions were a must. Hosted solutions shouldn’t be thought of only as on-premises servers. Think of them instead as at least one small virtual machine running MySQL to complex systems, combined with your own infrastructure and rented infrastructure all over the world. The biggest difference between DBaaS and hosted solutions isn't that one has an infrastructure and the other doesn't, but who takes care of that infrastructure.

With hosted solutions, you are responsible for OS updates, DB updates, security, network power outages and software crashes, among other things. With DBaaS, on the other hand, these problems are delegated to IT professionals that work for your cloud provider. DBaaS does have a premium in price, but only if you ignore the maintenance, upgrade and setup costs of hosted solutions. Calculating those costs, DBaaS should end up being cheaper, in addition to being more reliable. Another benefit of using DBaaS over hosted solutions is that you don't have to take care of complex licensing — everything is included in the price.

Hybrid Solutions

There are scenarios when you want to combine your hosted databases with DBaaS. Some of the most common are:

When considering hybrid solutions, you need a certain amount of bandwidth for some of these scenarios, security precautions for both the hosted database and DBaaS, and a DBaaS that can support this kind of hybrid scenario.

With a DBaaS using DB engines from Oracle or Microsoft, you'll get all the support you need for hybrid connections, replication, and other enterprise grade benefits, though the price will be higher. There are some cheaper DBaaS solutions that are good enough for various cases and are much cheaper, but they won't necessarily provide you with the flexibility you need.

Scaling Possibilities and Problems

Scaling is one of the most important reasons to migrate from a hosted solution to a DBaaS. It is relatively easy to implement and use scaling, up to a point. The problem is that you can easily scale up and scale down. That means that you can increase and decrease the performance of your database with a click of the mouse, or on an automatic trigger or rule. Another possible problem with this type of scaling is that you can't scale up infinitely. There will come a time when your DBaaS will be running on the best possible machine available from your cloud provider and you won’t be able to scale any higher.

At that point, it’s time to consider scaling out and scaling in. For stateless web apps, this is an easy process because they don't need to remember any data, but for databases, it requires a restructuring of the whole database — something that can’t be done in a couple of minutes. If your system requires you to scale, be sure to first scale up as much as possible and anticipate the moment when you'll need to scale out so that you can engage your DB experts to restructure the database and scale it over more than one database. After restructuring everything, you still won't be able to scale out as you want, but you'll be able to scale those instances up and down.

Multi-tenant Applications

 If you're developing a multi-tenant application, you should take extra care in scaling and partitioning of your data.

Common design practices for placing tenant data follow three distinct models:

Designing a multi-tenant application is a process that takes time and warrants careful consideration. Some DBaaS solutions can help you with this process.

To provide every tenant with a database that meets your performance requirements, you need to either rent each database with a specific amount of resources or you need to scale it on demand. Of course, as mentioned earlier, it takes time to scale.

A nice approach to addressing this problem is to use “elastic pools” of databases. The idea is to rent a certain amount of resources and add a number of databases to that pool. Since the resources are already provisioned to you, databases can scale inside the pool's resources almost instantaneously. A multi-instance architecture will help you to develop a more fluent solution and save money.

Minimizing Vendor Lock-in

Every cloud provider is trying to solve a problem for their clients and each one has a different idea of the ideal solution. As a result, you may end up using some services and features that are specific to only one cloud provider.

Cloud services rarely fail, but it happens and it's up to you to assess how much risk you can take. If it's okay with you to have your data stored at only one cloud provider, regardless of whether you're keeping it in only one region or spread all over the world, that's fine. On the other hand, if you need to continue operating no matter what, you should distribute your services over different regions and over different cloud providers, and perhaps even keep a backup hosted solution on-premises. To make this work, you'll need to do a lot of planning and testing, and it will cost considerably more than using just one cloud provider – but you'll have great redundancy.

Next Steps

DBaaS solutions are becoming more popular, secure and useful every day. If used properly, they can help you to save money on infrastructure and maintenance, while spreading your resources all over the world.

Nonetheless, there are some considerations, especially with respect to security that you should carefully consider before jumping on board this train. A nice approach would be to start small and undertake the migration in phases using hybrid solutions; then decide if you want to go all- in to DBaaS or keep the hybrid solution.

All major cloud providers have extensive documentation, tutorials, and tools to help you migrate your databases; still, it also makes sense to employ a company that resells the cloud through a partnership so they can assist you with the process and provide better insight.

Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Penton.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.