Cloud Computing: Architectural Limbo

When abstraction becomes a distraction, cloud computing becomes a realm of architectural limbo…

Cloud. It sounds so grand in NIST’s description; full of promises with respect to the ability to provision and manage resources without having to muck around in the trenches. Compute! Network! Storage! Cheap, efficiently provisioned resources in minutes, not months! The siren call of cloud continues to lure many a curious folk, only to trap it in what is rapidly becoming architectural limbo.

Differing slightly from the original meaning, in colloquial speech, "limbo" is any status where a person or project is held up, and nothing can be done until another action happens.

-- Wikipedia

The problem is, unfortunately, at the root of all architectures – the network.

ARCHITECTURE and the NETWORK

Architecturally, from a “stack” point of view, the network always resides at the bottom. Like other forms of architecture, that shouldn’t be taken to mean it's of less importance than the upper layers of the stack, but rather that it is the foundation upon which all other layers are ultimately laid.

A strong foundation is critical to the resilience of the rest of the architecture.

That is not to say that cloud computing environments have weak foundations. On the contrary, they have very firm network foundations that make the rest of the stack possible. The problem is that cloud promises us provisioning and management of resources and that includes the network, and yet many cloud providers seem to stop short of offering this capability in a way that meets the needs of enterprise-class architectures. Instead, providers encourage (read: require) a change in the way network resources are architected and ultimately managed.

Consider, for a moment, the stark reality of a realm with no real network boundaries offered by AWS in “Building three-tier architectures with security groups”:

Unlike with traditional on-premise physical deployments, AWS's virtualization of compute, storage, and network elements requires that you think differently about how to build network segregation into your projects. There are no distinct physical networks, no VLANs, and no DMZs.

The post goes on to describe the means in which a secure, traditional three-tiered application architecture can be deployed using AWS security groups. This architecture is a fine approximation of the traditional, data center deployed architecture based on the available abstractions offered by AWS.

Note the use of the term “approximation”. That’s important, because it’s indicative of one of the core issues with cloud today: the inability to replicate architecture.

You might be thinking that’s okay as long as you can replicate it using available services.

No, actually, it’s not necessarily okay – especially when you consider the close relationship between architecture and operational process and the implication of radically changing either one.

ARCHITECTURE and OPERATIONAL PROCESS

The problem is that in order to fully deploy in the cloud you have to deploy an architecture that will be different from the one you currently maintain in the data center. What that ultimately entails is a separate and environment-specific set of processes, as well, that could quickly become operationally expensive. This is especially true when compliance enters the picture, and even more so when the regulations in question are those that focus on process (think SOX) and not just technological implementation.

By encouraging (read: requiring) changes in the core architecture of applications, cloud computing is introducing another set of processes and challenges, many of which have already been faced and overcome in the data center by careful application of infrastructure architecture principles. Those processes must be managed, they must adhere to regulations and comply with requirements, and they must be integrated into and with existing data center operational processes. Because the tools and mechanisms by which those processes are managed are likely very different from those used to manage the data center, IT organizations run the risk of needing two separate but equally important sets of operations teams, each of which are focused on their areas of responsibility. Operational silos, by necessity. Architectural limbo. Neither fully here (the data center) nor there (the cloud), such approaches are fraught with the same potential to minimize the benefits associated with cloud computing by wrapping it in another set of mostly manual IT processes.

A more operationally consistent approach is necessary, one that does not require new architectures (and the operational processes to manage them) but instead incorporates cloud computing resources as part of an existing data center model. A hybrid cloud model based on the premise of operational consistency.

If we treat cloud computing as it was originally described, as utility computing, and view it as a vast pool of readily available compute and storage resources to be integrated into existing architecture and processes, the biggest benefits are likely to be realized. Cloud computing is unlikely to mature fast enough to provide the full range of infrastructure services that are required to properly transplant enterprise-class applications and systems into the public cloud, but it can be a great asset in implementing what are already proven, trusted and controllable architectures that exist inside the data center today.

The cloud can be a vital asset, if it's viewed with the proper perspective of what it is, not what it could be or might be one day. Avoid architectural limbo. Leverage - but don't live - in the cloud.

Related blogs & articles: