Databases as a service, DaaS, is fast becoming the preferred way of running databases. The advantages are obvious: scalability, fast deployments, less need for a DBA, no need to buy servers, global access, low cost, and so on.
Multi-cloud strategy for databases is on the topic right now! We will cover the subject in this article. Let’s take a look at the different reasons to go multi-cloud, starting with risk mitigation;
Risk mitigation
This really is a no-brainer and is probably the number one reason to use several cloud providers. To put it simply, if you run your database only on one service, for example AWS and AWS go down, you’re out of luck. This may mean anything from an annoyance to total financial disaster for the company you’re working for. With a multi-cloud strategy, you’re not dependent on a single cloud provider.
Cost structure
The different cloud companies not only charge different prices for the same functionality. The different services may also handle changes in volumes in different ways when it comes to pricing. The characteristics of the workloads may lead to different costs too.
And also, reductions in prices tend to come at different times from different cloud providers. Having access to several providers means better opportunities to take advantage of lower prices. Furthermore, with a multi-cloud database service like ElephantSQL you pay the same price independent of which cloud platform is being used. That means it’s easier to predict costs.
Local availability
Let's say for a certain service AWS provides the best performance for users in the US and Azure for users in Europe. The reason for the differences is a question of where the different providers have built data centers, and how big the data centers are, performance of servers and connections to and from the data centers also matter.
Performance
Just like there are differences in cost structure between cloud providers, there are differences in performance characteristics. Depending on the actual need at any given point in time, different providers provide the optimal solutions.
Innovation
You may not want to use a new feature from one cloud provider that’s not available from others. That would, in fact, make it hard to adopt a multi-cloud strategy. But, you may want to familiarize yourself with new capabilities. In due time all important providers will have the new features if they’re any good. And there may actually be situations where you want to use a new feature even if it’s only available from one provider if such a feature is a game-changer.
What about compatibility?
The database manager used in ElephantSQL is PostgreSQL. What if PostgreSQL isn’t your cup of tea? Of course, that can be the case, but it doesn’t have to be a problem. PostgreSQL maintains a high level of Oracle compatibility. The Oracle database is more or less the industry standard for relational databases, which makes PostgreSQL an option for many, probably most, database users, because of its Oracle compatibility. In fact, that is one important reason for many to choose PostgreSQL in the first place.
Also, modern application design tends to require less in terms of features in relational databases that are incompatible between different suppliers. This is partly because of performance requirements that come from large-scale web applications, partly because of inspiration from nosql databases. Which, when you think about it, can be described as two sides of the same coin.
Since the SQL language is highly standardized, chances are that database solutions actually are pretty easy to move. If you avoid stored procedures and stick to standard SQL statements database code should be possible to migrate to PostgreSQL without to much hassle.
And even if you’re dependent on stored procedures in Oracle databases, it’s possible to move them fairly easily to PostgreSQL.
Mastering challenges with a multi-cloud strategy
Many good things in life come with a price. That goes for multi-cloud database services too. A service like ElephantSQL helps to minimize the challenges with a multi-cloud strategy. Let’s take a look at how:
Differences in code
This is an obstacle that can be avoided. It’s relevant if you’re using really different database services on different cloud platforms. That may not be a good idea, in fact why would you consider it at all? One reason would be to really take advantage of the capabilities on different database services. But that strategy is probably not very smart in most cases.
The way to avoid this problem is simply to use the same database, on different cloud platforms. For example, ElephantSQL provides the database manager PostgreSQL on AWS, Microsoft Azure, Google Cloud Platform, and Softlayer, among others.
When using the same database manager on different cloud platforms, the differences in the required code, both SQL and application code, should be minimal, if any.
Difficult administration
It would be unfeasible to continually administrate three or four different cloud platforms, just for running database services. Some kind of umbrella service is needed. ElephantSQL is precisely that, it hides the differences between different cloud platforms from the user.
The control panel in ElephantSQL shows server metrics to measure performance and view slow queries. There’s also the ability to use log handling services like Papertrail, Splunk, Loggly, and Logentries. And the built-in PostgreSQL browser in ElephantSQL makes it possible to handle databases on different cloud platforms like one environment.
Moving workloads and data
One way to simplify moving data is to continually replicate data between different cloud platforms. That means that when the need to move workloads on a short notice arises, the data is already at the desired location. This applies both to situations originating from technical problems on a certain cloud platform, and to situations that arises from the desire to take advantage of differences in cost, performance or availability between different cloud platforms.
Replication in ElephantSQL works between different regions and even between different cloud providers.
Failovers
What to do when a cloud platform goes down? Move everything to another cloud platform, of course. The problem is, that may be easier said than done.
A follower is a feature in ElephantSQL that truly simplifies this process. Follower means that a stand-in environment can always be available. The stand-in environment can be located in another region or even with a different cloud provider.
More about follower solutions at the end of this post.
Backup
It’s sure difficult enough to handle backups for one cloud database service. How about backups for two, three or four cloud services? And how about restoring backups?
ElephantSQL provides automated backups and the data is stored in a cloud file storage. That means data are always accessible to restore. There’s even the possibility of point-in-time-recovery to restore your database.
Use cases
So, when is a service like ElephantSQL appropriate? Are there a threshold when it comes to data volumes, performance requirements, business importance, and so on?
A simple answer to that question is that when data, and as extensions operations and business, are important a service that provides flexibility and availability makes sense. If downtime means disaster, it makes sense to take a look at a service like ElephantSQL.
When does it not makes sense? Well, if you’re content to run your databases on a server in a closet at the office, ElephantSQL is not for you. But on the other hand, in that case you’re probably not interested in cloud services at all, at least not for databases.
Independence
Another reason to adopt a multi-cloud database strategy is both principal and practical: The desire to avoid lock-in, in this case from cloud providers. We at ElephanSQL makes it possible to be cloud provider agnostic. The reasons to avoid cloud provider lock-in are obvious. Just to mention one, what if your only cloud provider chooses to close down the database service that your company is absolutely dependent on?
Follower
Follower means automatic failover between different high availability (HA) cloud platforms. The follower, the environment that operations move to, can be located in another region or even at a different cloud provider.
This is a solution for companies that are serious about availability. In one sense, on an abstract level, a follower may not seem that different from other solutions for failover and replication. But there are two significant differences compared to more traditional failover solutions:
Followers in ElephantSQL are highly automated. That means fewer error-prone script, and less dependency of even more error-prone human operators. Not to mention a lower number of administrators.
Followers in ElephantSQL is cloud provider independent. Failovers are possible between different cloud providers. Failovers can, of course, also be performed between different geographical regions.
Solutions like these will most probably be mandatory for cloud-based businesses in the not too distant future. Large cloud-based companies probably have solutions in place already. But existing solutions are probably less automated, and more demanding when it comes to resource requirements, than a solution like Follower in ElephantSQL.
What about the future?
It’s a sure prediction that more cloud customers will use a multi-cloud strategy in the coming years, than today. The question is, how will they do it?
Is it reasonable to assume that big cloud providers like AWS, Microsoft and Google will provide multi-cloud features? Maybe, maybe not. Probably not so much. And if they do, their main objective will still be for you to use their services. Also, in a meta kind of way, there’s always the risk that a certain cloud provider’s solutions for multi-cloud operations have a lock-in effect to that provider’s cloud platform. How about that for a lock-in strategy?
It makes sense to choose multi-cloud functionality from a company that is independent of cloud providers. That makes the risk of vendor lock-in less likely. 84codes is just that, independent from cloud providers.
ElephanSQL
We offers highly sophisticated multi cloud capabilities for PostgreSQL.
There’s an FAQ available and if you want to dig deeper, here’s the documentation for ElephantSQL.
This guide will help you achieve a quick start with PostgreSQL.