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).

Figure 1: A DBaaS environment with an EnterpriseDB cloud database. (© 2013 EnterpriseDB Corporation)

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.