If you still haven’t found the time to learn how to install, configure, and maintain a database, you might be interested in a cloud solution that promises “zero management.”

Xeround sells itself as the “zero-management database.” Managing databases consumes thousands of hours every year, becoming yet another time sink to sys admins and developers alike. Management includes everything from installation through upgrades, checking on server health and disk space, and scaling and managing these things at scale – something that every one of us could learn, given a few books and the time if we could find it.

Fully Managed

Fully managed databases (DBs) aren’t new, and Xeround isn’t the first, but it has focused on the things that cause plenty of pain. Keeping a DB running and scaling it. After housing, powering, and securing the physical machines, configuring them is the next task that can distract from actually building an app. Although you might have edge case requirements that need specially honed and tweaked database servers, chances are … you don’t really.

In most cases, you can do a lot with a good standard config file and focus your efforts on the architecture of the app using these standard configs. Once you’ve given up your grip on the config files and the SSH into the box, you can focus on the app again. It’s okay to make apps and not be a slave to sys admin duties all the time.

Xeround

Xeround was introduced to me while talking to a prospective client. They reeled off a list of cloud services, and I nodded. Then, they mentioned using Xeround, and I quickly googled, scanned the Xeround homepage, and I thought, “Cool. Less to worry about.”

Xeround bills itself as “A ridiculously simple, seriously powerful cloud database.” In this blog, I want to look at how it does that. Xeround runs on AWS and Rackspace. You choose the size, launch the instance, and you get an instance to connect to.

After you have signed up and logged in, you are in the DB Instance Manager panel, where you can hit Create New to create a new database. The free account doesn’t come with scalable databases, but you will quickly get the idea: Xeround gives you a few end points to connect to, which are sent in an email after the launch of the database:

DNS Name = ec2-11-22-33-44.eu-west-1.compute.amazonaws.com, Port = 3158
DNS Name = ec2-22-33-44-55.eu-west-1.compute.amazonaws.com, Port = 3158
DNS Name = ec2-33-44-55-66.eu-west-1.compute.amazonaws.com, Port = 3158

Connect to these just like you would any other MySQL server,

mysql -u test -ptest -h ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -P 3158

and pipe in your data with:

mysql -u test -ptest -h ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -P 3158 < my-database.sql

If you need to move data from an existing DB to a Xeround DB, a simple trick is:

mysqldump my-database | mysql -u test -ptest -h ec2-11-22-33-44.eu-west-1.compute.amazonaws.com -P 3158

This makes switching to Xeround as a database for a live app, as a database in development, or just as an interim test simply a matter of changing the username, password, host, and port in your application.

Start Free

The free account runs on a shared environment and is limited to five connections. This isn’t going to be enough for most live environments but would certainly be enough for basic testing to see whether latency or connection issues arise. Larger packages start at US$ 17/month or US$ 75/month. When comparing this with something like EC2, in which one of the smallest services you could actually use in production starts at around US$ 70/month, it’s easy to see how the Xeround managed database makes sense. Before you have the cash or time to manage your own MySQL servers, this service can get you a long way.

Autoscaling is available in all supported providers. You can set monitoring and scaling thresholds based on CPU, memory, and number of transactions. These allow scaling on the basis of what’s going on in the DB at any time.

Start it GUI-Free

Provisioning is important. For me, the API is critical to anything having the title “cloud.” Provisioning databases dynamically can be really useful if you have an app that wants one database per instance (i.e., isn’t multitenant) or in development environments in which you’re creating, editing, and destroying databases frequently.

The API provides you with the ability to create DB instances and drop them. For any running instance, you can get its info and change the instance’s passwords.

These are fairly basic API calls, and I would liked to have seen others for changing the scaling rules and getting the health of an instance. It’s nice to manipulate the scaling behavior programatically rather than have to log in to the UI all the time.

Heruko, a service that I’ve talked about before, is supported via an addon. To spin up Xeround alongside Heruko, just enter

heroku addons:add xeround:free

and configure the DB URL with

heroku config:add ec2-11-22-33-44.eu-west-1.compute.amazonaws.com

which you’ll get by email after launching the instance.

You can find more information about Heruko integration with Xeround on their website.

In either guise, being able to spin up and delegate the running of the DB servers to someone else will save a heap of time.

Rackspace MySQL Server

Other cloud database options are available. Rackspace recently announced a database service based on the OpenStack framework. At first glance, this looks very similar to the Xeround system, providing the APIs to list and manage a database instance, manage users, and enable root access.

This private beta is by inviation only at present, and they say they’re working on “storage scaling, configuration management, backups/restores, and much more” – I’ll be nagging them for details, and I’ll post the details as soon as I hear.

RDS from Amazon

A service that’s been around for sometime is Amazon’s RDS (relational database service). As in launching EC2 instances, you spin up an RDS instance either via the AWS console or via the API. To spin up an RDS instance in the console, just log in, navigate to the RDS tab and click Launch Instance. After following instructions, you end up with a running MySQL server.

The RDS service is mature, supporting more options than most simple “managed MySQL” services. You can enable multi-AZ (multi-availability zone) by simply clicking the option, or you can use the Read Replica feature once your RDS instance is running.

The multi-AZ mode means you’re running two instances in two separate availability zones. If one zone dies, you can pick up from the second zone’s database. Beyond this, Read Replicas allow you to make a second, replica database that can be really useful for nightly reporting, back-office ordering systems, or just scaling up the hosting. To enable this in the AWS console, just log in and click Create Read Replica in the listing of RDS instances.

The options for replicas are, of course fewer than for the master. You can set the size, name, and AZ. With this, you could spread your read instances over all AZs within a geographical region, or you could create a reporting instance each week using the biggest instance to crunch through the week’s data.

Xeround vs. RDS

Xeround raises the point that RDS isn’t really elastic. In fairness, they don’t called it elastic, but if that’s what you’re looking for, RDS isn’t going to give it to you out of the box. Elastic means self-scaling: It’ll just provide you with the computing power you need. Scaling RDS works in increments, just as on EC2. You can have a micro, or a large, or an extra large. At each step you decide how many instances you need, rather than how much computing power.

Therefore, RDS is more like scaling old physical boxes than a pure service that hides the issues of scaling completely. In contrast, Xeround has focused on scaling transparently, keeping the matter of how it’s done in their corner rather than yours.

WhySQL Anyway?

Now that you’ve heard about the options for good old relational databases, what about the growing number of NoSQL options? If you’re trying to address the problem of scaling a database to huge levels, chances are it’s going to be scaling in two ways over the next few months and years: number of records and structure of data.

Relational databases like MySQL are great for structuring data, but NoSQL reverses the role of the database from dictating the structure to following it. Many NoSQL libraries hide the structure completely, so adding a new field can simply be done when you start using the database abstraction objects:

p = Person.find(123) p.is_special = true p.save

Libraries like MongoMapper in Ruby or Shanty in PHP connect to MongoDB, completely removing the need for maintaining the database’s structure in the traditional sense.

There’s a growing body of information on running NoSQL databases in the cloud including a recent whitepaper from Amazon, as well as plenty of other NoSQL systems. But what if you still don’t want to deal with the scaling problems yourself?

MongoHQ provides fully hosted MongoDB. As for every self-respecting service these days, there's a free tier called their sandbox tier that lets you launch a Mongo database. The interface allows you to create collections and manage database users and backups.

Two options come from Amazon. SimpleDB provides a similar key-value storage, and this has been around for some time. SimpleDB scales to internet-scale number of records, so for truly massive numbers of simple key-value data, this is a good option.

The newer DynamoDB requires a little more setup than the other services I’ve been looking at because “Amazon DynamoDB ... reserves sufficient hardware resources and appropriately partitions your data over multiple servers to meet your throughput requirements.” This means you have to define your throughput requirements – that’s the work.

After creating the DynamoDB table, which you can do using the SDK URL or via the AWS console, creating the table is a matter of naming it and setting the primary key and the read/write capacity units. The last option – the capacity units – allows AWS to guarantee your response times, so an additional option is required: the email that is alerted when there are more reads or writes than expected.

With these options created, you’ll need to hook up the SDK in your preferred language or use the AWS Explorer for Eclipse. This is one difference to the Xeround and MongoDB options: You have to speak via an SDK, so if you’re bound to your MySQL or Mongo terminal, this might upset you. If you’re dealing with Internet-scale data, you probably have other things to worry about, though.

More To Play With

Databases aren’t the domain of DB admins any more. They are services that you can buy and start using in minutes. Before you fire up another server or instance to run MySQL or your favorite database, consider the cloud database options. Give them a spin – it can take just minutes.

I started writing this post just playing with Xeround, but I have a feeling this one is going to evolve into its own little series, because who wouldn’t want to give up managing databases?