Earlier this year, at a CIO gathering hosted by the Boston chapter of the Society for Information Management, cloud...
experts from VMware, Cisco, Microsoft and Greystone Solutions Inc., a technology services provider based in Boston, were grilled on the major cloud computing trends affecting their customers.
Here are highlights -- the good, the bad and the ugly -- from the panel of cloud experts: Chuck Hollis, chief strategist, VMware; Chris Marino, director, business development, Cisco; Hai Ning, technology architect, Microsoft; and Bob Shear, president, Greystone Solutions.
Size matters when choosing between public and private cloud
1. Skills and staff
Chuck Hollis (VMware): We have a saying, 'Are you going to be a builder or broker?' At smaller organizations you don't have the skills or staff, so the external solutions look great. But at larger organizations, parts is parts. If it is cheap for Microsoft or Amazon, you have access to the same technologies models and modes, etc., so it becomes a decision on whether you want to invest and have that capability in your own organizations.
To the question, 'What is cheaper, public cloud or doing it yourself?' It's like saying, 'What's cheaper, renting a car or buying one?' It depends on situation. In larger environments, with hundreds of terabytes, the numbers work out pretty good for people who want to do it themselves. That seems to be one of the defining factors, [asking,] 'Am I going to try to do this myself or am I going to have to outsource the expertise to an external cloud?' At some point, this becomes a skills arbitrage as opposed to an assets issue.
2. Storage, networks
Chris Marino (Cisco): Storage is typically the deciding factor on the decision to make a public or private cloud choice. The security or proximity or some other aspect of storage is typically top of decision tree -- 'Can we put it outside the data center or inside?' And other decisions just flow naturally from that.
The problems we see first [with public cloud] are network-oriented problems. It may be hard to believe but a lot of the issues with moving something into the cloud are rooted in the limitations of the network in the public cloud.
Just to give you a very simple example of that: Enterprise applications were generally built to run inside a data center with low latencies, with high bandwidth access and secure access to storage nearby, and that was a baseline assumption for designing that application. So, taking that application and migrating it to a public cloud where those assumptions are false is a problem -- you cannot assume low latency, high throughput [or] secure access to storage infrastructure in the public cloud. So in terms of workload, if you've got an enterprise app that was designed with those design constraints, it may never be a candidate for deployment in the cloud, because the public cloud was developed under a totally different set of assumptions and application developers embraced that different set of constraints for that public cloud workload.
So, that is probably one of the biggest workload constraints we see today and also probably one of the hardest to overcome. As a service provider deploying a public cloud, mimicking an enterprise network service is a really hard thing to do and by the time you do, it almost doesn't look like a cloud anymore -- it starts to look like your old data center with VLANs and all sorts of crazy things.
3. Cloud as experimental laboratory
Bob Shear (Greystone Solutions): One of the things that is great about some of the larger public clouds is the ability to do a quick experiment. I could sneak out back while all the other guys are answering the next question and come back with a complete WebSphere stack up and running. This is something that would normally take a couple months of provisioning. On the other hand, if I forget to shut it off tonight and forget about it for a few weeks, I'll get a rather nasty bill.
A much more subtle [trap] falls under the rubric of DevOps. When you build out a computer or even a virtual machine by hand, it is a long, careful [and] slow process. When you do that in the cloud, it is click- click-click and you're done. We believe that unless it is just an experiment that you are committed to throwing away in a couple of weeks – which, by the way, is a great use case for the cloud -- you have to be as disciplined about configuring and building that machine in the cloud as you would be about configuring, managing, versioning and building any one of your software applications.
Notable trends in cloud computing: PaaS, Python skills gap, repatriation
Hai Ning (Microsoft): It is Microsoft's belief that platform as a service (PaaS) is the future of companies. Infrastructure as a service is currently is flourishing -- everybody is jumping on it -- but we think the vast majority of enterprise companies will run on PaaS, and the reason is simple: Who wants to manage hardware? And the next stage is, who wants to manage virtual hardware?
Your competitive advantage is in the algorithm, the code that you wrote [and] the data structure that you create. It is not how efficiently you run any kind of virtual hardware, and this is why Microsoft is investing so heavily in PaaS.
2. Skills gap
Marino (Cisco): One of the skills gaps that we see among almost all customers when it comes to their Open Stack cloud deployment is they just don't have the Python and dev op skills that are needed to operate an Open Stack cloud. So, that represents a tremendous challenge to the IT organizations that are considering that. It is getting better, but before the release of commercially supported Open Stack distributions, you couldn't even go anyplace to find someone to support these deployments.
But now that Red Hat has an Open Stack distribution, [and] now what VMware supports Open Stack as an extension of vCloud Director, it is ok for mere mortals. Before that, it was not for the faint of heart; you had to be almost a committer on an Open Stack project to understand the depth of complexity and the moving parts for an Open Stack deployment. That is changing, but nevertheless if you do want to be successful, you do need to embrace the dev ops culture of continuous integration to build and deploy and manage your Open Stack deployment. That skill gap is a big skill gap. And it is one of the things that have frustrated a lot of companies that want to deploy it -- there is a company called Mirantis[Inc.], whose entire success has been satisfying that demand.
Hollis (VMware): I see a lot of analytics starting in the cloud; the addiction begins, bills go up and people do a little cost arbitrage and say, 'Gee we could be doing this ourselves!' Either that, or you realize you're doing analytics in the cloud on regulated data. ... For those of us in the industry, it is a revolving door, and we encourage customers to think that way: [i.e.] 'I sent it out there; I would like to bring it someday or at least have the option.' So, one of the better pieces of advice for an external cloud strategy is to think about your exit strategy. Just like when you're buying that new house -- what's it going to look like in the market in a few years?
Marino (Cisco): With modern applications -- ones that were designed for and perhaps began as public cloud applications -- what we're seeing is repatriation. This is where the direction is going from the public cloud back into the data center and the private cloud, because of economics, data sovereignty or security issues. In fact, one of the drivers for enabling private cloud infrastructure is to bring back some of those workloads that have been deployed and designed for the public cloud.
More advice from cloud experts:
Think twice about putting these apps in the cloud