In parts 1-4 of this blog series we explored some reasons why private clouds bombed. In this final blog, I’d like to discuss a better approach

Finding examples of successful private clouds is difficult because many organisations claim to have a private cloud when in fact all they have done is install VMware. If a project manager has to organise a resource to install something it’s not a cloud. Cloud is not virtualisation.

If you were starting a private cloud environment build 3 years ago, it would look different to one you would begin building now. But I like to live in the here and now so let’s look at what we would do now.

For starters, reverse these unspoken principles:

• IT departments do not need to communicate with their users.
• IT departments are needed and irreplaceable.
• Users don’t know their needs and IT departments do.

Then approach as shown below. Users care about the items closer to the top.

Now, look at your best use-cases and choose a champion project/platform/department to partner with so you can create one end-to-end service.

Then get the right people on board to build it out. The guy who built your virtualisation stack back in the naughties probably doesn’t have the social intelligence (and hygiene) to approach users and “communicate”. Users value the speed in which resources can be allocated to them, the simplicity of getting their work done and the lack of friction involved so put someone in charge who understands public clouds, understands service design and delivery and is willing to start with an open mind. Then create a list of services you wish to offer.

Eventually after much work and discussion you’ll get to the point where you understand the services you want and what is required of the technology to support your cloud. This is where you may get derailed. Whatever happens make sure your choices minimise “tinkering”, promote scalability through modularity, and can work with your current network.

Your network may suck. It may make providing access to external and internal users difficult. It may be impossible to converge data and storage networks. If so, you could wait for SDN to mature and your CIO to give you budget for a Network Refresh or…

1. You could build the cloud off-premises. Private cloud is used only by internal users but can be built anywhere. So build it in Rackspace or AWS, or a local provider if data sovereignty is an issue.
2. You could build the cloud on converged infrastructure which includes its own networking. Something like vBlock or FlexPod. Converged Infrastructure is modular, making it easy to add and manage computing power, storage or networking throughput. The seamless coordination between hardware manufacturer (compute, storage and networking) and virtualisation is key to private cloud computing. It resists “tinkering”.

You’ll need more tools over time to manage this because of new standards and platforms, capacity-managing a pool of resource aggregated at a data-centre level, and also in planning for the hybrid cloud (which may exist for real one day). But all in good time.

The cloud is essentially a vending machine. It’s an automation-oriented, self-service approach to IT. Anything else is folly.

We’ve covered legacy IT, use-case and business case issues. Today we’re talking about the immaturity of private clouds themselves.

There are 4 areas where private cloud deployments haven’t matured yet that you must contemplate:

• Software licensing – When migrating legacy software to private clouds it gets very difficult to track software licensing. Where previously you had a pretty static license pool, in a private cloud your usage may expand and shrink. How do you manage that? For example, how do you deploy Oracle RDBMS in a private cloud if you don’t have an Enterprise agreement? A nightmare!
• Lack of standards – There are many cloud platforms, some proprietary, some open-source. All these are different to their public cloud companions. It’d be good if a public service provider would let you install your own cloud platform on their tin. It’d make hybrid cloud a lot easier. One day I suppose. Until then you have to manage your public and private APIs differently.
• Compliance leakage – Your private cloud is a single environment. Anything that has regulatory or compliance requirements (like PCI-DSS) can’t go on there without bringing the whole cloud into scope because of…..
• The immaturity of cloud networks – I know SDN will save the world but for now the underlying networking concepts of different clouds are of a differing standard and sophistication. Many enterprises therefore deploy cloud networks in a basic, pre-provisioned fashion. (Read about the 6 challenges of private cloud networks in this F5 document.)

Mike DiStaula, little boy (Mike Burns via Flickr)

I suspect one day cloud platforms, standards, licenses etc. will converge enough so that you are running the same technology in private and public cloud stacks. Possibly AWS will provide an on-premise cloud stack, or a provider will start letting you install your own cloud platform as already mentioned. At least with this last one, the enterprise is finally free of the need to actually deal with hardware. What will we call infrastructure specialists then!?

The default answer is that IT’s vision is to provide hybrid or “multi-cloud” environments but not many people can actually articulate what that means, how it can be achieved, and why business users should care.

In the last post in this series we’ll look at the ways forward.

In the past two blogs we’ve looked at the inertia of Enterprise IT and the issues with use-case development for private cloud. Today it’s the business case.

Business cases are typically written for, and approved by, senior management who don’t fully understand technology – its possibilities and limitations. They use IT services more than most demographics and always want the latest tech – for themselves at least!

So what is the business case for private cloud?

Is it to increase revenue? Possibly, in some indirect not-so-obvious way.

Is it to decrease costs? Not at all, unless you were really inefficient to begin with. It does reduce the transaction cost of establishing a new platform but that is but one smallish component of a projects cost. Building a private cloud requires a big upfront investment with no immediate return, a real “field of dreams” situation. Cloud is about speed, automation, self-service and a little experimentation.

A business case must be able to measure and demonstrate success. You need a metric and it’s difficult to measure cost reduction or revenue improvements with a private cloud. You could use project delivery and time-to-market metrics. You could measure how many applications are running on your private cloud. You could measure developer satisfaction and/or usage. None of these metrics are easy to measure or necessarily translate to a successful outcome though. If project delivery times go down is it related to cloud or other improvements? If you measure how many applications are running on the cloud is it just shuffling your existing portfolio around?

The truth as I see it is this. IT has to transform to meet modern requirements and Cloud computing is one necessary component. Disruptions like big data, mobility, wearables, gamification, social networking, high speed networking, Internet of things, global logistics & resourcing can’t be delivered effective using traditional IT.  Practices like Agile and DevOps – and other things – complement cloud computing for these same ends. IT now plays in a border-less environment with abundant resources, nimble competitors and changing technology. The game has changed.

So cloud is one piece of an IT transformation. But why a private cloud? It’s hard for business users and developers to get excited about internally provided services they can get from Amazon, Rackspace, Google or Microsoft already. Enterprise IT wants to demonstrate robustness, stability and change control but users really only care about usability and provisioning times.

To demonstrate the value of a private cloud you need to demonstrate success in the realm of all this disruption and it has to be something that is difficult to do in the public cloud for security, legal, integration or performance reasons. Choose a significant project/platform in this realm, and bolt it to your private cloud project. A champion project for your cloud.

Your business case then includes a complete end-to-end platform and the success of the private cloud is tied to success of the champion platform, by how well the platform is “harnessing change for competitive advantage”. For example, how do the release cycles compare to your existing platforms? What are the scale limitations? How easy is it to add features and fix bugs compared to your legacy platforms? How well does it perform in the digital world? Do developers use the private cloud? Can users get at the data anywhere and any time? What is the next project that could benefit from this approach?

The business case for a private cloud stacks up only if you have a significant partner at the beginning, or at least very early on. This could be a significant project, application or business area. Sure, run some proof of concepts to familiarise yourself with cloud technology but then get this key user who can provide feedback on the platform, someone who can do regular releases on the platform, someone who depends on your cloud to run their business. This partnership could then be the seed for a new digital enterprise.

In the next post we’ll look at all those thing’s private clouds can’t do!

My last post about how to fix your private cloud focused on IT’s organisational flaws, ill-directed focus and lack of customer-responsiveness. If I’m going to fling excrement at my industry peers, I’d at least better have a crack at identifying some good use-cases for the private cloud myself, and highlight where the focus could/should have been.

“Wait here until you are useful”, Matt Brown (via Flickr)

So this post is primarily a bullet point list! Here we go… Private clouds can enable:

• Single OS instances for sand-pitting applications. If a developer needs a server environment, they spin one up in the private cloud, rather than hack their desktop to pieces. The benefit over using public cloud here is that the sandpit will have access to the internal systems a developer needs.
• PaaS-like environments, and by this I mean pre-configured development environments with all the preferred tools and integration technologies already installed. This is a natural extension on the last point. This could also include database-as-a-service (DBaaS).
• Internet-facing applications that need to be spun up, and then down, quickly. The classic example is a marketing campaign. These types of loads may have been handled by a marketing agency in the past. This could be done in public or private cloud, integration depending.
• Internet-facing apps where you want to preserve an architecture that scales when needed (for example a political parties web site which gets hammered once every 3-4 years, or a betting site that gets smashed once a year). Of course some of these would do well in the public cloud but for regulatory, latency, specialty-hardware or integration issues.
• Web portals and e-commerce systems that necessarily combine many internal and external system components. Imagine an e-commerce system that integrates social-login and internal product information systems.
• Web services where utilisation is unpredictable and the service consumer is as likely to be external as internal. Web services typically need access to a company’s data so will likely be “close” to internal data sources making private, rather than public, cloud more likely, especially for large or sensitive data sets.
• Virtual desktop infrastructure (VDI) because workloads are inherently highly variable, which is a good reason for implementing on the cloud. User access to VDI will be from anywhere on any device at any time, which suits private cloud environments. Typically VDI is built on specific hardware, but increasingly integration opportunities between VDI and Cloud vendors are occurring.
• Disaster Recovery/Business Continuity. The public cloud is promoted for this purpose of course, but moving the function in-house could be cost effective for a very large enterprise.
• Platforms that are developed using Agile, Continuous Deployment and DevOps practices. In these instances your infrastructure is part of your deployment process and fully orchestrated. There is typically no “operations handover” in this environment and it evolves over time.
• Systems where you are occasionally grunting through a very large amount of data. For example, 3d rendering, unstructured or big data analysis, and business modelling.

These some use-cases I researched and have observed myself. If you can think of any more, add them in the comments.

One of the interesting things to consider is what is not on the list: legacy systems, Exchange servers, storage systems, Intranet portals… You could put these on your private cloud, but there’s no great benefit. When you factor in the orchestration effort it can actually take longer to get these working on the cloud. They probably don’t need autoscale and other cloud features. So run them on your ol’ VM farm!

IT would have done better to work through the likely use-cases for the cloud and focus on these rather than looking at the private cloud as the latest platform for…. everything. Even better it could have done this before beginning, which leads me to the topic of the next blog in the series: The business case.

Private clouds are difficult to build. In this blog series I’ve surveyed all the common flaws in private cloud design and implementation so you don’t have to chase them yourself. Hopefully you can relate to some of the issues and contribute your thoughts in the comments. In the final blog in the series I’m going to attempt point a direction forward, to fix the private cloud, and share my reading list.

Today’s blog is about the organisational flaws exposed by the private cloud trend.

*********

IT built the private cloud IT wanted to build and not the cloud anyone wanted to use.

Private clouds were commonly seen as an extension of virtualisation. This encouraged IT to have an inside-out cloud mindset. Now virtualisation and cloud typically go hand-in-hand, but they are not the same thing. Even though the IT infrastructure deployed in both instances is usually quite similar, from a user perspective they are completely different. Clouds are quick and self-serviced whereas virtualisation by itself is not. The truth is you can have a cloud without virtualisation. For example, if you build self-service etc. on top of an Oracle RAC Cluster you could have DBaaS. (Be careful to not get screwed too much on the licensing costs.)

IT built the cloud it wanted to build

The virtualisation trend also exposed some organisational issues, which may or may not have been dealt with. It’s part of the phenomenon of Software eating Infrastructure. Virtualisation allowed cloud engineers to make network changes to “soft” switches and firewalls. It allowed them to deploy storage. Storage I/O problems occurred because of poor workload balancing and live migrations. The opportunity to improve IT efficiency by delegating storage, compute and network activities to a semi-orchestrated cloud team existed. In some organisations this change worked, in others it was resisted.

The arrival of private cloud progressed these organisational issues further with many organisations merging specialists into a cloud team and hoping they would abandon their specialist mindset.

I’ve drawn up a very generic cloud stack below:

You should have put most resources into the top block but these skill-sets (establishing services, APIs and managing a relationship directly with cloud users) are not something specialist IT staff are traditionally good at, or have ever had to do. IT shops started reinventing themselves to make this shift.

The bottom two blocks play to IT’s traditional strengths. Depending on how (in)efficient you were you may have spent most of your time and energy stuck in the bottom block, building networks, hypervisors and customised operating systems. If you were still heavily silo-ed there was no way you could match someone like Amazon’s scale and efficiency. Even if you were uber-efficient you probably can’t match AWS. The thing is, if you’ve spent most of your energies in the bottom blocks, and not in the top block, you probably don’t have many users. You spent a lot of time building the “undifferentiated heavy lifting”, as Adrian Cockcroft said back in the day, because it’s what IT knew how to do.

In the next blog post I’ll discuss the business case for private cloud and some use-cases.