Business Tech: MultiValue in the Clouds

Sadly Turn Away From the Coffee

You know this scenario. You arrived at work, pour a hot cup of coffee, and get ready to tear into that project you keep getting pulled away from and suddenly you hear a co-worker or boss race in and say, "We need to implement <fill in the latest buzzword>. Without <same buzzword> we are just another hopelessly technologically backward company. Fire/Flood/Famine will surely follow if we don't get on the <same buzzword> bandwagon."

At this point one of two things happens: A) You sadly turn away from the coffee and spend the next fifteen minutes explaining the buzzword's real implications to an audience who is unprepared for any answer besides "right away!" B) You sadly turn away from the coffee and spend the next fifteen minutes Googling the buzzword and posting on message boards to figure out what this buzzword means in concept and in workload.

Clouds in My Coffee

Sometimes when we Google and post, it is not because someone else is excited. Occasionally, we allow ourselves to get excited about technology as well. Personally, I've been known wax poetic over certain hardware and software from time to time. We are technologists, after all. For some of us, the new twinkling bit of coolness is the Cloud.

We aren't alone. Amazon, Apple, Microsoft, and lots of other people are screaming, "Cloud!" from every rooftop. So, it wasn't a surprise when I saw a post on the LinkedIn Reality group about MultiValue on the Cloud. It wasn't a surprise that the post said, "Won't it be cool…"

I leapt in, as did several others, and said, "Can be done, has been done, could be done better." I thought I'd provide a larger version of my answer for the larger audience here.

Stratus? Cumulus? Cirrus? Cumulonimbus?

A definition is in order. From a delivery standpoint, Cloud is a synonym for Timeshare. I've been doing timeshare since the early 80s, and I got into the game late. In essence, Cloud computing is central server computing with shared resources. That sure meets the definition of Timeshare. The difference is in the execution.

From an execution standpoint, the cloud is cluster computing, but at a lower level. Clusters combine several computers to produce the effect of one, faster computer. Cloud deployment allows the combining of memory, disk, etc. to make one computer beefier, or leaner without reboot, reconfiguration, or migration. So, if the execution is done right, a Cloud server is, to the O/S and to the applications, exactly what a non-cloud server is — a collection of hardware.

Cloudy with a Chance…

If a Cloud server running Red Hat Enterprise Linux looks just like a non-cloud server with the same software, MultiValue can run on it. If it looks like Ubuntu and your MultiValue platform can run on that, then MultiValue is deployable on the Cloud.

Here's why we aren't really ready for the Cloud — deployment tools. See, we meet the technical definition of Cloud. But this is a business tech column, so we have to understand how business defines the cloud. Again, it's about deployment tools.

From my original post: "The limit isn't MultiValue, the limit is the 'missing' tools to allow nth number of databases to be hosted separately. Since we have the concept of discreet accounts, the missing part is just a webpage/wizard to deploy you and charge you for the service."

Business loves the Cloud because it offers the following:

1. Less down-time due to migration;
2. Less down-time due to upgrades;
3. Less down-time due to hardware maintenance;
4. Less down-time due to wrestling with software deployment.

Sense a theme here? Business hates down-time. I once had a customer, back in my first IT job, say, "Our system is too important for us to take it down for backups." They literally felt that having no backups was less of a problem than having a down-time event scheduled nightly. Less down-time is a core concept for every business that uses technology, which is to say nearly every business.

If we want to see MultiValue on the Cloud, we can make it happen. There's a lot of money in offering companies a managed system using this sort of technology.

As if by Chance

As it happens, I am doing a Cloud deployment right now. While it is MultiValue adjacent — the UniVerse system involved is on a separate server with the Cloud server depends on for content and some layout — the deployment won't require me to move MultiValue to the cloud. Since I know how to install databases to servers, and that hasn't changed, what few things I've learned in this deployment are enough to make me an expert on Cloud deployment for MultiValue. The learning curve is actually that small.

Chances Are

My post oversimplifies, because it only talks about making MultiValue deployable. We all know that MultiValue is a means, not an end. To make us really ready for the Cloud, we need deployment tools for our utilities (report writers, 4GLs, etc.) , our applications, and for our data.

So, the challenge is out there. In the cloud, people are more concerned with up-time and smooth operations than with brand names. We can stop selling MultiValue and just start selling the productivity that MultiValue produces. Being an embedded database has been a successful model for us, and the Cloud is just the next level of embedding.

Featured:

Sep/Oct 2011