Building a Model of Hybrid Cloud

For the past few months, I’ve been working with the idea of building a model for the adoption of hybrid cloud. Some people may say that hybrid is already here, but I think what we see today is a set of tactical implementations. Instead, we need a bolder vision of what the use of hybrid cloud could mean. Why create a model like this? Partially this is a process of helping my customers understand where they should be headed. But mainly I think it’s an attempt to put the ecosystem of platforms, product offerings and services into some kind of context.

Having started my career in a managed service business, I was exposed to many aspects of what we see as cloud today. We ran customer applications, charged and billed for them, juggled and managed physical resources and resolved problems. In many respects, not much of that operational aspect of work has changed much over 30 years, although the technology certainly has.

5 Step Process

In this initial model, my focus is Infrastructure as a Service, simply because this is the background I’m most familiar with. Figure 1 shows a series of goals to achieve a mature hybrid cloud strategy.

Abstracted – in this step, I’m suggesting that IT departments need to move their internal customers away from specific technology and vendors. You would expect that this occurs already, but for many reasons, IT teams like specific vendor technology. Being tied to a feature or product creates lock-in. While that’s not necessarily bad, being abstracted as much as possible from one technology is about reducing both risk and cost.
Standardised – this step is all about introducing service catalogues. I’ve been working with the service catalogue for nearly 20 years (perhaps more, although it may not have specifically been called that). It amazed me how many companies simply don’t have a fixed set of product offerings, with anything outside that managed by exception. At this point, project-based requests should be transiting to on-demand.
Automated – with a service catalogue in place, resource consumption can be automated. In public cloud, this is a relatively easy task for the end user to adopt – as long as their credit card is on file. For an internal IT department, things are harder. Budgets aren’t infinite, so some degree of resource control is needed to ensure end users don’t allocate instances and storage without some managed charging. With automation, there’s an opportunity to reduce the billing granularity (e.g. to days not months).
Optimised – this step is perhaps more about the back-end service delivery than consumption by the customer. Moving to on-demand is hard because IT has to translate Capex costs to Opex recovery from the business. This requires planning, data on usage and models that create a notional cost of delivering an item on the service catalogue.
Innovating – by the final step, on-premises and public cloud are fully integrated. Internal customers purchase resources based on the service catalogue. The actual deployment is based on where the service can best be delivered, by features, application dependencies and cost. Applications can be moved dynamically between CSPs and on-premises.

Getting to step 5 could be hugely complicated and only the largest organisations will benefit from a fully dynamic platform. It may make sense to implement a hybrid/multi-cloud environment in a more limited fashion, with a design goal of building for multi-cloud, even if it isn’t directly implemented.

The Architect’s View

At this stage, I’m doing nothing more than testing the waters with my assumptions. I have a wider set of slides that expand on the one presented here. These dig down into some of the detail of the steps, looking at people, process, technology, services and billing. As with anything in IT, there are huge variations in implementations and trying to come up with a generic definition isn’t easy. So, expect the thoughts to be expanded and modified over time.

BTW, in case anyone isn’t aware, I spent the best part of 2017 working on a startup idea for data mobility, so I’ve spoken widely to customers about their requirements as well as researched the market and written a lightweight distributed file system. The startup is on hold, but I do still think that data is the core of a hybrid cloud architecture and from that aspect, we haven’t even got started yet on solving the problems customers have.

Comments are always welcome; please read our Comments Policy. If you have any related links of interest, please feel free to add them as a comment for consideration.