One of the most common patterns we see with new customers is a desire to shift from a legacy single-datacenter application deployment to a multi-datacenter, “active everywhere” deployment. This is not an easy transition to make, especially with applications that haven’t been designed with multiple datacenters in mind from inception.
In the abstract, there are really two key questions to answer when solving the multi-datacenter puzzle:
- How do you get your traffic to the “right” datacenter?
- How do you get your data where it needs to be?
Unless you can answer both these questions, you won’t be able to deliver your application from multiple datacenters. The two questions are interrelated to some extent: you can design your traffic management strategy to help enable your data strategy, or vice versa. But they are fundamentally different questions with different technologies in play.
At NSONE, we spend a lot of time thinking about question #1: how you get your traffic where it needs to go. DNS is a great way to shift large swaths of traffic around between different facilities. Many of our customers come to us because we do traffic management powerfully, flexibly, and — just as important — understandably. But often customers focus on solving the traffic management problem, and forget about the “data plane” problem: it doesn’t do much good to shift traffic around if you’re unable to get your data — whether it’s records in a database, rich media, or anything else — to the right datacenter at the right time.
For some kinds of applications and data, this is not a very hard problem to solve. Delivering a static website from your own simple CDN? Just make sure your assets are synchronized to every node. (Never discount the usefulness of rsync!)
But as soon as you have a dynamic application, with an ongoing combination of reads and writes in your data plane, things get more complicated. Most database technologies can only handle writes in a “primary” facility (conflict resolution is hard). Replication strategies are many and varied. Failover is complex if the primary goes down — usually requiring specific smarts in your application itself. If you are doing huge amounts of reads or writes, you may need to think about memory caching or other mechanisms for protecting your database nodes from overload.
One of the most interesting technologies in the data plane today is Aerospike, a high volume NoSQL database with killer multi-datacenter capabilities. A number of our biggest ad tech customers use Aerospike to handle hundreds of thousands of transactions per second spanning several datacenter facilities. Aerospike has built in conflict resolution enabling true active-active (write anywhere) setups, making it a true solution to the data plane side of a multi-datacenter strategy.
NSONE is excited to announce a technology partnership with Aerospike — it’s a great product that is often a perfect fit for our customers as they move to distributed deployments, so Aerospike is a natural fit alongside NSONE in your multi-datacenter strategy. Going forward, we will be working more deeply with Aerospike and our customers to tighten the interaction between NSONE’s traffic management and Aerospike’s data plane solutions. For now, we encourage you to take a look at Aerospike, tinker a bit, and see if it can help you as you shift your application into multiple facilities.