I live near the South Downs, a beautiful part of England – all fields, chalk pits, cottages, country pubs – apart from the parts that are motorways, factories, and airports. But this isn’t San Francisco or even Silicon Roundabout, and sometimes I crave some of this nerdy action.

So I Skyped a few people to talk about their products – products I’ve used in production or just played with. This time, instead of telling you how to install it, I thought I’d find out how these guys solved the problem that matters in the cloud: keeping something running all the time and at scale.

Cloud means so many things, it’s almost meaningless. Stuff-as-a-service is so overused it’s become almost a dead phrase. We have milk-delivery-as-a-service and I went to beer-as-a-service this afternoon.

What’s really interesting is how the -as-a-service people build what they build. How they turn machines, operating systems, scripts, and applications into a service that’s better than simply installing the thing and how they bundle a mix of doing-it-at-scale with doing it differently.

Anyone can install something with apt-get and friends, so what makes using someone else’s installation and configuration on the cloud better than installing it yourself?

I’m going to go beyond the press release and beyond the tutorial to find out a little bit about what makes some of these services go. After I looked at Xeround, a cloud database-as-a-service (DBaaS), a couple of months ago, I looked into more DBaaS providers. However, before I get to that, I want to introduce a new concept that was sent my way.

In my kitchen, with laptop perched and Skype running, I talked to David Jilk, CEO of Standing Cloud, which I wrote about recently.

Jilk got in touch with the idea of “Model-Driven Deployment.” His whitepaper peddles the idea that, rather than think of operating at scale as spinning up instances that are configured by someone automating what would normally be done by a human, think of it as a model.

Cloud management systems like Scalr and RightScale and the tools in AWS or Rackspace allow you to automate much of the OS setup with scripts, and this is often missed by firms moving into the cloud. Thinking of an instance as a model – as in OOP – gives you a more structured way of describing and communicating it.

I asked Jilk whether this doesn’t just boil down to scripts. Before his direct answer, “Of course it is just scripting,” he provides a little insight into model-driven deployment:

It is precisely a lot of scripting; however, scripts can be written well or poorly, and they can be designed as software or as hacks. We think the right way to do this is to start to think about the process of deployment not as simply automating something that you would type, but as something that you would build with levels of abstraction, just as you would with models in software.

And, you know, there are various companies doing things with MDD and DevOps that think in similar ways. If you look at Chef and their concept of recipes, where you can combine existing recipes together into larger ones – the idea of modules. You don’t necessarily have to think about what’s inside every time.

Chef, Puppet, RightScale, Scalr, and all the other cloud management tools encourage you to distill your configuration down to scripts. But, as Jilk says, scripts can be done well or badly, and that’s what makes the difference.

“We’ve been moving … away from pure base and PowerShell scripts to Python,” he says, “although there are no particular constraints on which language you use, … so long as it can perform systems operations.”

The problem with the field – automating operating systems and getting OSs to do automated stuff at scale – is that it’s new.

“It’s a toddler,” Jilk says. “I don’t think there are tools that help very much with the building of the actual model.” So whereas tools like Chef and Puppet help deploy the same thing millions of times, nothing exists to help design and build up the model – the abstraction.

So, what does the future hold for deploying “models” of servers or services? The future of encapsulating the behavior of a service? Are modern OSs up to it, or will a native cloud OS emerge?

“What you describe is exactly where things are going to be headed,” Jilk responds, “but it’s very far off. We’ve got a long way to go. We’re still fighting the battle of model-driven deployment vs. virtual appliances, and you’re talking about a pure software view of what a system is. Of course, it is software. We can provision virtual machines via an API call. What shall we call it now? A server allocation? But it’s all software. The whole Internet – including the infrastructure – is software.”

But we’re not there yet. We’re still left running regular expressions on config files on the server’s disk. How old fashioned will this sound in 15 years?

If It Looks Like a Duck, It Isn’t a Duck: It’s NoSQL

There are two ways of offering a low-level cloud service – even a hosting service. Either you wrap up an existing piece of software in the comfort of someone else dealing with the problems for you, or it’s a completely new way of providing the old service. Instead of giving you pages, queries, etc. in the old way, someone finds a way to give you the old stuff in a new and magic way that scales, is more resilient, and is just better than before.

This leads to the next interesting question. What should the server contain? There are two ways of providing a cloud service: a scaled-up, optimized, and supported version of the existing software or a completely new piece of software that looks and behaves like the old one.

Suppose you want to solve the problem of MySQL in the cloud. Services like RDS from Amazon can spin up managed MySQL instances in minutes and provide you with fully hosted MySQL, but maybe a MySQL server isn’t the answer to the MySQL scaling problem. Maybe something that looks like MySQL and behaves like MySQL doesn’t need to be MySQL.

That’s what Xeround gives you, whereas, if you fire up RDS, it is MySQL, Oracle, or Microsoft SQL Server. However, Xeround manages to sell MySQL behavior without running any services.

Xeround doesn’t run MySQL servers behind an API. No MySQL admin is sitting there making sure it’s scaled properly. There’s a heap of NoSQL.

Xeround provides you with a MySQL interface backed by a completely custom driver. But that’s not how it started, as Razi Sharir from Xeround explained:

Xeround was founded back in 2005 with a different premise. Looking to becoming a world leader in telco internal operations and services, it hit the road in 2005, and it was going fairly well along these lines. Running live in a telco is probably the highest recognition you can get for robustness and around a piece of software, oftentimes referred to as telco “grade” or “certification.”

But that wasn’t enough for Xeround:

Around late 2009, the company decided that time to market in a telco environment was too long for a small startup to handle and [we decided] to see what else can be done with [the technology]. Not surprisingly, the cloud came up.

By repurposing the technology, Xeround is about to offer something that MySQL admins have spent years trying to simplify. Instead of working in terms of masters, slaves, and replication, they solve it in a “super simplistic manner” with a NoSQL database that is able to run the required queries at scale. Their DBaaS runs any queries and scales elastically and at high availability.

This is how we ended up from telco guys to cloud guys. The core of the technology is the same that was used in telco … but we’ve upgraded on the front end to extend the SQL coverage, as well as the service side to enable us to run in the wider public cloud across multiple providers.

So, the trick, in a nutshell, from a product perspective: Underneath the hood is no simple database. The closest thing you can think of could be Hadoop. Hadoop, the filesystem, and some algorithms on top of it so we can support any NoSQL beyond that.

According to Sharir, MySQL and other relational DB engines wouldn’t be able to handle the same kind of scale. So, with NoSQL use growing, why wouldn’t developers just switch to NoSQL, such as CouchDB, Mongo, or one of the other large-scale databases designed to solve exactly this system: Internet-level database traffic?

You can see the problems by considering the scenario of a firm that has to solve the problem of scale in their MySQL-driven app. Problems of scaling in databases come down to bottlenecks in the queries, inefficient SQL, and bad indexes, among other things. Some problems can be replaced by simply moving from one database to another – swapping out MySQL for Mongo for session data can be done quickly because the data is self-contained, compared with highly structured data about accounts, transaction history, and the like.

In the past, I’ve seen a project’s performance turned around in an afternoon by using NoSQL for one problem; however, this isn’t replacing MySQL or the relational database, it’s supplementing it. The project of fully replacing MySQL in an existing, in-production product with NoSQL isn’t something many development teams are going to take on.

But, Sharir continues, there’s something else:

CouchDB and other NoSQL DBs are good solutions and do a great job for what they were designed for, but what they were designed for doesn’t support any transactional nor any relational capability, which means most of the commercial applications won’t be able to use them as a core engine. If you’re running any application that does basic credit card or other basic transactions and you want make sure your two- and/or three-phase commit went through, there’s no real way to do it with a simple DB, is there?

All of the NoSQL guys are very good for simple, basic operations on large data sets that scale and are highly available, but when it comes to real applications in the cloud, I don’t quite see it happening.

Do It Yourself?

Moving to cloud isn’t the issue anymore, but how you do it matters.

“So typically,” said Sharir, “when users move to the cloud, the first thing they get hit on is the availability thing because their machines disappear and they don’t have the slightest idea how to bring them back, how to scale them, or how to build them … multiple replicas … this and that.”

This is a huge challenge. I’ve written about some of the tools that can help you, but the mindset is different, and if you don’t have the time to invest in those skills, what do you do?

You can spin things up, but too often this is only to watch them crash later on. What companies like Xeround are doing is building up that skill and management for you.

“The other thing, when they’re on the cloud, is when the first time a major campaign comes in, the traffic comes, and the instance’s aren’t strong enough to handle the load,” said Sharir.

Doing database architecture these days has become more like a patchwork. You don’t chose one big solution, but bring together many.

The paradox that Xeround presents is: You have something that looks like MySQL, but under the hood it’s NoSQL. Why, then, don’t they expose the NoSQL API so you have the relational, traditional perspective on your data and have the cool new NoSQL view as well? Maybe one day.

Reinvent Everything?

Xeround is a really cool answer to an old problem, but reinvention isn’t the only way to solve these problems.

Next time, I’ll cover a service that gives you Postgres at scale and with management, taking more hours away from systems administration, and I’ll look at what you can learn from the choice of big-architecture cloud providers.