Cloud Dreams

In my first story on database as a service (DBaaS) [1], I spoke to Xeround and Standing Cloud about how they implement and deliver their software as a service (SaaS). Although they come from different parts of the SaaS market, they had one thing in common: They're finding different ways of doing what's been done before in the hope it works better at the (cloud) Internet scale.

This is all part of an ongoing project to understand why it's worth bothering with SaaS at each level. Sure, there's hype, but is it actually worth it? This time, I look at EnterpriseDB [2], which is a slightly different case, as I'll describe. They've taken an existing product that they already support in the enterprise market, and they've deployed it to the cloud.

Their proposition: point-and-click simplicity running both on the premises and in the cloud. They differ because they're pitching to two separate markets. The traditional, highly expert database admin and the new cloud market, where ease of deployment and "it just works" matter.

The Beginning

With Skype fired up, I talked to Karen Padir from EnterpriseDB. EnterpriseDB was founded on the principle that Oracle database prices were too high. To combat this, EnterpriseDB built on PostgreSQL, an open source program with a reputation as a strong relational database preferred by many database admins. The thought was that they could go into the Fortune 500 market offering PostgreSQL with a few extras and added support to lure the blue chip firms away from their Oracle habit.

Although this worked, they then tweaked the recipe. A little more than three years ago, they had a change of CEO and decided that luring Oracle users might not be the only way. Maybe they could offer something more to the Postgres users of the world, which is where the new product line came in. They offer a series of products – from their solutions pack, Enterprise manager, to the new cloud product. The cloud product differs because it isn't simply a hosted version of their other products that run on-premises (Figure 1).

The cloud product supplies the "just works" aspect that on-premises products traditionally don't (although things are changing). Padir explains:

Developers are becoming sys admins. Developers are becoming database administrators. They're just assuming certain things are being taken care of for them, and they don't have to spend their time looking at and learning these tools to make it work right.

Those assumptions are a big part of running Anything-as-a-Service. It has to just work for two reasons:

1. In the cloud, it's more difficult to tweak and configure services. There's a limit to how far down the stack you can get, so tweaking some config file or running filesystem optimizations just aren't options. It's much better that the service works in a best-practice way out of the box. This is almost saying it should have the lowest common denominator config, but it's more accurate to say that it has to work for the majority of cases.

2. It's what people expect. If it's on the cloud and a service, then it should have solved the problems for you. That's why it's a service and not consultancy.

Reason 2 is a more powerful market force. Cloud services are expected to work straightaway, which hugely reduces the procurement process and time spent on contracts. Often, it's just filling in a form. All this puts pressure on the service to work. Just work. Straightaway.

The barriers haven't disappeared, but if you're frustrated with something that you spent four years of your budget on and is using up 4Us of space, you'll think twice about it compared with something you can shut down this afternoon or migrate next week. The biggest barrier to change for the user is rewriting their software, and that is less that four years of a budget. But EnterpriseDB doesn't see people using the cloud exclusively. The cloud product might be the choice for some people some of the time, but the on-premises solution will still be needed for a different set of people. Padir continued:

People will still download products. They'll download and play with them, but more and more people are doing their experimenting and their playing with things in a cloud environment. And, so what you expect to work in the cloud can be very different from when you download a piece of software onto your server and start running with it and playing with it from there.

Padir went on to explain that they have three audiences:

• The traditional band of install-configure-protect: They like to see their software running on their own metal.
• The cloud-native: They'll try it in the cloud and punch in their credit card details a couple of hours before the app goes into production. Think student, hacker, startup, and, increasingly, corporate people outside the IT department who just want to get the thing done.
• The experimenter: SaaS is still where people expect to try things out. Any product that can be used via an API or a web browser should have a trial I can use just by entering my email address. Ask any more than that, and you're pretending it's more complex than it is.

This ease of use is translating back to the on-premises world: "after the launch of our Postgres+ database  – we launched it at the end of January  – within the first days of our launch, we have customers looking and asking, 'I want the downloadable version of that'," said Padir.

The SaaS world is forcing the on-premises software world to rethink what "user friendly" means. It's more than just stamping it on the packaging. Padir continued:

People say, "… I'm not on the cloud but I love this and I want all these nice point-and-click setup buttons. All this add failover and adding disks. I want to be able to do all these things to my database without having to worry about it, but I'm not on a cloud."

On-Premises to Cloud Continuum

To understand how people choose where to deploy, Padir described a continuum. Starting (in no particular direction) from dedicated hardware, through virtualization of your on-premises hardware and then into the cloud in its various guises. The common thought is that you move from one end – the heavy hardware – to the other – the light cloud services. But, said Padir, "… I don't think people will move along the continuum that way. They won't necessarily start on traditional hardware and end up in the cloud."

People will be in more than one stage of the continuum, so as SaaS fits into their work, it'll fit differently, depending on what problem needs to be solved. The on-premises database may well stay there for years, but the short-run reporting projects require database server power that is best bought by the hour.

Choice Can Be Good

EnterpriseDB's Postgres Plus Cloud has a surprising number of options for a DBaaS. Compared with Xeround, RDS, Rackspace Cloud, and other products, you can tune it through the interface to a greater degree. Because the instances are launched on Amazon Web Service (AWS), you can ssh in and configure them there. Backup configuration comes standard.

"Cluster healing mode" is a simple checkbox option, meaning you have nothing to configure to determine whether you'll heal the master with a new master or existing replica. Autoscaling thresholds are built in to the interface.

A list of dozens of config options hide beneath the Configurations tab at the bottom of the page, including autovacuum times, checkpoint values, and other standard configuration choices. Other cloud databases do allow some control at this level but not often through the user interface.

What made EnterpriseDB decide to include configuration options rather than going with the "just works, don't fiddle" trend? The history of the product gives the background needed, as Padir explains:

We employ a number of commiters of the Postgres community. These are highly sophisticated database architects who are writing the database internals. So, there are certain things that they expect to tune and play with as they're using the database.

This sounds like more control than most platform-as-as-service (PaaS) products offer, but this is exactly why EnterpriseDB consciously made the choice to say, "You know what? That's OK because the way our product exists today you don't have to worry about it." Padir continued:

We have hundreds of users in our hosted service, and when we interview them … the common theme we get is that it seems too easy. They say, "I worry that I did something wrong because it just keeps running and I don't have any issues. I didn't have to do anything." So there's that, that it'll just work, but then also we do allow you the ability to ssh into the machine (your AWS instance); you can add additional components, do more things than just set it up and work away.

As someone who often prefers to start with a setup that just works, this sounds great. But the option of tweaking if the defaults don't work is a double-edged sword: I can tweak, but I can mess it up as well.

For the database admins this is built for, control sounds ideal. The contrast with other DBaaS products is striking: They pretty much give you any database, so long as it's black, to paraphrase Henry Ford.

MapReduce, NoSQL, andWhy Stick with SQL?

Suppose you have a heap of data and you want to plow through it with MapReduce at Hadoop speed. EnterpriseDB offers a MapReduce adaptor.

But, if you are going to implement NoSQL or processing of data on the scale that MapReduce and Hadoop offer and you need a rewrite, why not just migrate to Riak or any of the other NoSQL engines?

In answer, Padir said, "Most people aren't going to migrate their application to a database that has a completely different data store on the back end because that's a whole application rewrite."

Despite the number of new apps and startups appearing, there's a still a heap of legacy code out there. As I found talking to Xeround, the slowest moving part in many organizations is the codebase. Padir:

So, I think it has to do with: What is your application trying to do? What are the skills that you have? Because at the end of the day, most developers know how to write SQL, and if you're taking an application that already exists, it's just the flexibility you have to change the application.

I want to be able to take my data that's stored in Hadoop and put it in my relational database and be able to use some of my tools that I already have to run queries – more structured queries on that data – and vice versa. I have data that's in my relational database and I want to put it in my Hadoop cluster.

People are rewriting their applications in steps, but they want to start by having both worlds. So, again, database is a requirement rather than a technology. Instead of installing Oracle or MySQL, architects are choosing several database technologies to solve each of the problems they have. However, because other database technologies offer a few more features, you get a features race to satisfy developers that the database platform they're running on offers everything they need.

Future of PaaS

EnterpriseDB has made the move from a few products to a cloud service, which coexist. These products solve different problems and, unlike the other people I've spoken to (so far), DBaaS is just one way that the database problem can be solved.

Even though EnterpriseDB is clearly positioned at the database admin end of the market, with the configuration options and the ability to tweak, users do still expect it to work out of the box.

DBaaS has one strong argument in its favor: Chances are they have better database admins and better defaults than you because that's what the DBaaS provider does. For companies replacing their self-maintained database hardware or services, DBaaS removes a chunk of the admin. If you get to the tipping point at which the defaults just aren't good enough, bring it back in-house, but don't give yourself unnecessary pain by doing that from the beginning.

"Amazon and HP have lots of people who are completely dedicated to the security of their systems and keeping them up and running compared with a small company with a small data center that just happens to think they're secure because nobody knows about them," added Padir.

Most CTOs and developers have a lot of experience with database management, but many of them don't have a great deal of expertise when compared with the concentrated expertise used in the management of EnterpriseDB, Amazon's RDS, Rackspace's upcoming cloud database, and other DBaaS options. Even on security, Padir noted, "We have two additional products …. Both of these combined help protect you against SQL injection attacks and other bad things that can happen to your data."

Outsourcing the detail and management of your database sounds like a good idea. I for one am always in favor of paying someone else if they can do it better, so I concentrate on my product. But outsourcing can go wrong. Data is the most important part of your company, and if you are outsourcing control of it, you need to know what control is left to you, and you need to test the expertise of the platform or the support.

Anecdotally, the company I work for just migrated a lot of hosting to Rackspace-managed cloud to reduce the pointless sys admin tasks the developers were doing. Although they enjoyed the management and problem solving, and although this stuff was all essential to our service, they were spending their time doing something they didn't have to do.

"Pointless" sys admin tasks are very pointful tasks, but they are not what differentiates us from our competition. The ability to recover from backups is pretty basic and not what our devops team needs to spend its time on.

This move is no silver bullet. We had to learn Rackspace's support limits, and we tested at every stage. The most boring and menial tasks up to complex performance issues were sent their way so that, just like a new member of the dev team, we know how the service performs.

DBaaS is the same. It isn't a silver bullet, it's a new member of your stack, and it might do some stuff well, but you have to understand where its expertise ends.