Original URL: https://www.theregister.co.uk/2013/05/15/cloud_architecture_strategy_avoiding_vendor_lock_in/

Ten years on: How did that cloud strategy pan out?

How to avoid vendor lock-in

By Timothy Prickett Morgan

Posted in Cloud, 15th May 2013 11:00 GMT

So the CEO is hearing all about clouds now and the financial director is looking at his pile of beans and as usual wants you to do more with less. And both think it is time for you to build or buy a cloud. Where do you start?

The answer is by being brutally honest with yourself and your bosses about everything around you.

A service provider building a greenfield cloud to peddle infrastructure or platform cloud services to augment your carrier and hosting services has it easy. It is simply a matter of examining what type of cloud it wants to supply to customers.

It picks a cloud controller fabric – VMware vCloud, the open source OpenStack or CloudStack, or maybe Windows Server 2012 and Hyper-V with System Center. This cloud doesn't have to integrate with anything but the provider’s billing systems: it just has to create a self-service portal for customers and a more sophisticated management console for the provider’s own admins.

Not so for you. You are sitting there with mission-critical systems – physical boxes running siloed workloads or at best virtualized machines that have a few workloads sharing capacity atop a hypervisor.

A fine mess

You probably have a mix of Risc/Unix boxes and maybe some proprietary mid-range and mainframe systems running legacy code.

You have Windows systems running Exchange Servers for email and groupware and any number of SQL Server databases and home-grown apps and third-party apps, and probably Linux systems running other infrastructure workloads such as data warehouses or analytics and maybe Java applications.

Exactly what the mess consists of hardly matters. You have a mix of apps and platforms and developers and admins with their own set of preferences and prejudices. And now the top brass wants you to turn this hodge-podge of hardware and software into a cloud.

It is understandable if you are jealous of Amazon Web Services and other clouds, says Bryan Che, general manager of the cloud business unit at Red Hat, the commercial Linux and Java platform distributor.

"The biggest motivation for CIOs is when they take a look at the complexity and inefficiencies of their own operations," he says.

"And then they take a look at the public cloud providers such as Amazon, Rackspace and IBM and on any measure they can think of – how quickly they can provision, how much it costs to get that infrastructure, how many administrators they need to manage it and so on – it is orders of magnitude different from what CIOs experience in their own data centers."


The odds are you have a lot of Windows systems in your shop, and therefore have VMware's ESXi hypervisor inside its vSphere server virtualization toolset in your shop virtualizing some of your Windows and Linux operating systems for x86 servers.

You could be dabbling with Red Hat's KVM-based Enterprise Virtualization hypervisor or Microsoft's Hyper-V, and where Oracle databases, middleware and applications are involved, you might even be virtualizing atop Oracle's own rendition of the open-source Xen hypervisor.

But again, based on market stats, you may have started out with VMware GSX Server and ESX Server a decade ago in your test and development environment when you first started virtualizing servers. Then you took five or six years to gradually start virtualizing more of your IT infrastructure.

It will come as no surprise that VMware wants you to do the same thing all over again with its vCloud Director tools.

"In the US five years ago, or in emerging countries such as Peru today, companies didn't start out with their first virtualized workload being Exchange Server," says Neela Jacques, director of product marketing for the cloud infrastructure suite at VMware.

"Not because Exchange Server couldn't be virtualized – it is by almost every VMware customer – but because if you start there, you need to think about how to tune storage and do backup and disaster recovery.

“By starting with test and dev with virtualization, you could ensure that you had a high degree of success, gain your skills and then move on to infrastructure and finally tier-two apps. Then maybe three years later you got to business-critical apps.

“Just as it was a big mistake to try to start virtualization with the most complex workloads, it is true for clouds too."

Jacques adds that if you have not built a cloud yet, you should start with the now-virtualized test and dev environment, adding vCloud Director and gaining experience with the self-service portal.

Then you move on to the more sophisticated cloud management tools and high-availability portions of the vCloud Suite, then maybe look at cloud-bursting and disaster-recovery features.

Pastures new

The one thing you do not want to do, says Jacques, is give in to the temptation of implementing a greenfield application – such as an electronic medical records application – on a full-on all singing and dancing cloud.

"This is where you can fall right into the trap," Jacques tells El Reg.

"It is not that you can't build a cloud for a business critical app – you absolutely can. But if you start there, you can make decisions that can hurt you in the long run, such as creating a highly scripted, management-heavy environment to meet the needs of one project.

“It makes sense not to over-complicate your first cloud. With VMware, start with vSphere and vCloud Director. If you want your cloud to do everything, we have the technology, but I don't know if you will be able to get up to speed on day one."

In the driver's seat

Rackspace Hosting is happy to sell you some compute, storage and networking capacity to buy your cloud. You can install it on the Rackspace public cloud or you can have a slice of the Rackspace Cloud and install it in your own data center.

You might need this for data security reasons, running the OpenStack cloud control freak and, if you choose, relying on what Rackspace calls Fanatical Support which also supports the Rackspace public cloud.

Tony Campbell led the cloud software development teams at Rackspace for nearly a decade and was then tapped to create training and certification operations relating to OpenStack a year and a half ago.

He says: "The first thing you need to ask yourself is do you really want to be in the business of running that cloud? It's not that a racing car driver doesn't know how to change the tires but he wants to focus on winning the race. You can outsource all of that to a pit crew, and that is where companies like Rackspace come into play."

The other big question you need to consider, says Campbell, is if your workloads will actually benefit from the rapid scaling up and scaling down of capacity across clusters of machines that are provided by a cloud controller.

"Ask yourself this: does your application require that kind of capability?" he says. "If the app is built to handle that, then cloud is a good move. If I am just trying to save some hardware space or drive up utilisation, then virtualization is a good move."

Rackspace is telling customers to watch their costs when they build their first cloud. "I don't think people are doing that math. And on a small scale cloud, that's not an issue," says Campbell.

"But when your cloud grows, costs will become important very quickly. The bigger you grow, the more you will need to pay attention to that."

Take a deep breath

The first thing Red Hat wants you to do when considering your first cloud is to take a deep breath. Then take another one. Take your time. Think about where you want your data center to be 10 years from now. Because the decisions you make on this first cloud will have a profound and lasting effect.

The server and storage platforms you have to keep limit your choices. Your data center is probably more like a brownfield post-industrial zone than a greenfield.

You want to be able to bring as many platforms as possible into this cloudy world as you can and in as open way as possible.

If there is one thing you know your company is not going to do after spending so much on creating applications on disparate platforms it is to rip and replace them onto some new cloud stack. If you didn't dump everything and move to Unix, or Windows and Linux, you aren't going to do it with cloud.

That is why Red Hat advocates an approach called open hybrid cloud. It is unapologetic about the fact that the situation is more complex than those peddling vCloud, OpenStack, CloudStack or SmartCloud would have you believe.

As far as Che is concerned, the other option is "cloud in a box", which means picking a particular cloud controller, say OpenStack, and building a cloud for a particular application or set of similar applications.

If you build a private cloud, you still need a way to integrate various private and public clouds together and manage them, as well as managing physical servers that are still running applications. And that is where Red Hat's CloudForms management platform comes in.

An open hybrid cloud puts customers in control

Red Hat CloudForms is one example of an open hybrid cloud product, It supports multiple virtualization and public cloud providers – running on Red Hat Enterprise Virtualization, VMware's vSphere and Amazon's EC2 Web Services. According to Red Hat, an open hybrid cloud puts the customers in control of their cloud infrastructure and allows them to select the right infrastructure for the right job.This supplies a flexibility not offered in a cloud in a box, Red Hat argues.

"The challenge is that if your solution can work with only one hypervisor and the set of clouds that are compatible with it, what are you going to do with your other hypervisors such as Hyper-V and KVM?" says Che.

"What are you going to do with developers who are going out to Amazon? What are you going to do with physical systems? You are basically turning your virtualization silo into a cloud silo and you are making it a whole lot easier to manage, but you are still not solving that fundamental problem of IT complexity."

There is another larger and potentially more difficult issue. Just as cloud controllers have their own APIs, so do the frameworks that support modern, webby applications such as Heroku, CloudFoundry and Force.com. And you have to take these APIs into account too.

"You have to think about whether you will be able to write your applications in the languages and frameworks of your choice, and deploy them to the cloud of your choice," says Che.

"This becomes a huge issue once you move beyond worrying about how you are going to manage your cloud to how you are going to put applications on it. The app has to be portable – meaning you use the same release manager, the same deployment tools and so on, or you will never take advantage of that portability."

And thereby avoid vendor lock-in. This could give you a headache now, but you might save yourself some headaches later.

Think of everything

Here's what you have to think about before you start building your cloud:

Take a survey of your IT infrastructure

Until Diane Bryant took over as general manager of Intel's data center and connected systems group earlier this year, she was Intel's CIO. Last year, when she was still CIO, Intel did a server audit and found 2,500 servers doing absolutely nothing.

During her keynote address at Oracle OpenWorld in October, Bryant said that when she became CIO in 2008, not one server in the Intel data center was virtualized - even though Intel had been selling server processors tuned for virtualization for four years. Now all of them are.

Storage arrays were running at under 12 per cent utilization, but with de-duplication software the company has been able to save $9m a year in storage costs.

In your shop, the savings from virtualizing servers and storage and running both more efficiently can help pay for cloud projects.

Survey your apps and operating systems

Find out how many applications have been virtualized and how many cannot be easily virtualized. If it isn't virtualized, then it probably isn't the place to build a cloud.

There are metal-as-a-service features with Ubuntu Linux and similar tools for managing images and data for physical servers on Unix and proprietary systems, and you will need to consider these as well. But the object of this exercise is to identify what apps might be a good starting point for your first cloud. And while you are at it, find out how much stuff you have running out on Amazon EC2 and other public clouds.

Get those Microsoft, VMware and Red Hat coffee mugs

There is nothing quite like having multiple vendors competing for the same projects.

"I see lots and lots of people with OpenStack science projects, and by the way I see lots of Hyper-V science projects, too, where someone thinks this is a great part of their negotiation with VMware," says Jacques.

Think through your hybrid strategy

Your first cloud is just your first step on a journey to a fully virtualized, software-defined data center .


By standardization, we mean choosing one thing to support all jobs – this has often been espoused as leading to significant benefits. But companies with decades of investment in legacy applications on myriad types of systems can't just start all over again.

If we could, we would all be running on the cheapest possible platforms available at any given time. Systems persist because applications do. Odds are that you will have to cope with managing disparate platforms in the future as you do now, so it makes sense to keep your options open.

Don't skimp on training

By definition, if this is your first cloud, you don't know what you are doing. And you don't just want to give an army of consultants a blank check, either.

So get some training for yourself and your staff. This is costly on the front end, but so is the time you waste when you try to manage a cloud without proper training. Your first cloud project is not proper training, however much you learn from it.

Don't skimp on the budget

This is not about getting some servers and storage and slapping on OpenStack or vCloud. Figure out how your simple cloud could evolve towards more sophisticated self-service and management as well as the workloads it will be able to absorb. Plan for both.

Don't forget all those legacy systems

Wherever possible, you want to be able to provision and scale these systems using the same tools as you use on your clouds.

In many cases, such technology does not yet exist. So start putting pressure on vendors to get their act together. ®