It doesn't pay to keep private cloud experts on staff, and I have a hard time believing there are service providers with deep core competencies here.
I attended a local cloud computing conference this week, and the sessions and speakers were great. But as usual for me at most conferences, the aha moments came during the one-on-one conversations after the sessions and during the breaks. So here's my aha moment of the week: For most organizations, the implementation risk for private clouds outweighs the benefits.
Here's my thought process. I was chatting with a bunch of guys who had done lab work with some of the private cloud platforms. And they were grousing that, just as introducing a hypervisor creates another layer of complexity around a server (though it does remove some complexity as well), private cloud software introduces yet another layer of complexity. So IT folks who implement Eucalyptus need to master the Eucalyptus skill set as well as the hypervisor skill set. Not only that, prior to implementing Eucalyptus, they need to master the Rocks Cluster software, since it's a dependency of Eucalyptus. There are similar examples with other cloud software.
That's indeed a very different cup of tea from just clicking "launch instance" in your Amazon Web Services console, while allowing Amazon to manage all of the hairy backend complexity.
There's complexity underneath public cloud services, but it's not your complexity. It's the service provider's. And chances are your service provider is way more situated to handle that complexity because of (and I know this is a tired old phrase when it comes to the cloud, but it's true) economies of scale. As in, they do it all the time and you don't.
The discussion turned to the "core competencies" principle: the one that stipulates in-house IT staffers shouldn't take on tasks they don't do very often because the cost and risk are way too high. For instance, how many times does in-house staff do the architecture planning, installation, and integration for Microsoft Exchange Server 2010? Probably once in the lab (if they're disciplined) and once in production. Woo. Isn't that fantastic. As opposed to, call in a contractor who has done it 20, 40, 60 times.
That service provider has run into scary crazy moments during installation. That service provider has run into many of the undocumented workarounds, limitations, and bugs requiring hot fixes. So why would you pay your staff to do this? It's not a core competency because it's not done more than once or twice. Instead, farm it out to a contractor.
How many times do you really want to touch your private cloud software? Ideally, you won't touch it much at all. Ideally, it will run fine while you provision private cloud instances all over your organization. But if there are problems, does your team have the core competency to handle them?
Not having a core competency in private clouds or anything else makes it effectively more complex, and as complexity rises, so does the risk of failure. Since public cloud providers handle the complexity--and it's a core competency--the relative complexity and risks of those services are lower. Somewhere in between would be a private cloud maintained by a service provider.
It's a common model for complex systems to be maintained by a service provider. VoIP comes to mind, as it's a curious amalgam of traditional telephony and data networking. Do you really want a voice CCIE on staff, with a similarly competent backup person, when you can contract out for annual service at a fraction of the cost? The question is how competent is that service provider? If the private cloud service provider does a tremendous volume and thus has a high core competency, then the relative complexity of that kind of implementation is toward the low end of the scale.
The trouble is that I have a hard time believing there are private cloud service providers with deep core competencies. Private clouds just aren't entrenched yet.
It's a lot like virtual desktop infrastructure: Everyone's talking about it, but not a lot of people are actually doing it yet. As someone who really wanted to do a VDI pilot, I scouted around and did an RFP, trying to find a deployment expert. Suffice it to say that the service provider we ended up hiring was only marginally more competent in VDI than my staff. I think that those who seek private cloud service providers will have a similar experience. It won't be that way forever, but that's what I'm thinking right now.
So for now, I'm very cautious about private clouds. I'm not a Pollyanna about the public cloud. I realize that hybrid clouds--with a relatively small private cloud component--are very likely for a number of organizations. But the benefits of maintaining an actual private cloud (not just lots of virtualization, but an actual scalable, API-driven private cloud) in-house probably don't outweigh the implementation risks. It's a huge opportunity for service providers that build a competency, and when they finally get their acts together, the implementation risks will be on par with public cloud services. It's just not there yet.
Jonathan Feldman is a contributing editor for InformationWeek and director of IT services for a rapidly growing city in North Carolina. Write to him at firstname.lastname@example.org or at @_jfeldman.
Read our new report, State Of The IT Service Desk: Change Management Remains Key. Download the report now. (Free registration required.)
Multicloud Infrastructure & Application ManagementEnterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. Who among us has mastered provisioning resources in different clouds; allocating the right resources to each application; assigning applications to the "best" cloud provider based on performance or reliability requirements.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.