Beware the danger of building out isolated network and application network infrastructures in the cloud lest we end up with silos from which it is difficult to escape.  

While writing a separate post on the business value of public versus private cloud computing investments I specifically called out the fact that infrastructure – virtual or physical – provisioned in a cloud environment is applicable only to that cloud environment; it really can’t be shared within the enterprise architecture or other public cloud computing environments, for that matter.

That led to considering the impact of the cloud computing deployment model on general application architecture and how much “sharing” of provisioned resources would occur “out there”. There appears to be a very real possibility that the lack of visibility in cloud computing environments may very well lead to the creation of silos in the cloud.

One of the alleged benefits of public cloud computing is that anyone within your organization can take advantage of it. We’ve seen the results of isolated, disconnected departmental-level architecture and development before; internal technological silos. When there is no centralized infrastructure management, each department/project is left to its own devices. This isolation and separation from a shared IT infrastructure management could easily lead to two or more different applications being provisioned with their own “copies” of infrastructure in a public cloud computing environment.

Somewhere along the line “on-demand” came to carry with it a subtext of “ad-hoc” and was applied to not only provisioning of compute resources but infrastructure resources as well. Application not performing well enough? Provision an application delivery controller with application acceleration features and solve the problem. Application needs to scale up? Provision a load balancing solution and a second or more application instance and solve the problem. Eventually, if there are enough infrastructure services available, you can see where this might lead: isolated, application-specific infrastructure architectures that unnecessarily increase the total cost of ownership for the application. Also inherent in the idea of ad-hoc provisioning of architectural components is a lack of adherence to organizational policies for security, availability, and reliability of application services.

The concept of governance and its relationship to cloud computing has been discussed but those conversations tend to revolve around the need for more generalized governance. That is, a service catalog of all cloud provider offered services as well as a cloud-application service catalog for consumers. But there’s little mention of the need for architectural governance at the organizational level. The ability of an enterprise architecture group that is responsible for setting the direction of application architecture across all deployments, not just those internal to the organization.

A centralized architectural approach could eliminate the possibility of silos in public cloud computing deployments by enforcing the use of shared infrastructure services provisioned into the public cloud computing environment. Indeed, without some sharing of infrastructure the concept of Intercloud and cloud-balancing becomes inherently more difficult – nearly impossible, in fact – to implement. For example, one approach to enabling cloud-balancing is to employ the functionality of an intelligent global application delivery platform, a GSLB (global server Load balancer), to determine based on the context of a request for an application which location will best serve the specific needs of the user and request in question. Assuming the application is deployed in only one location makes this decision fairly straightforward, but the use of the GSLB provides a layer of abstraction between the consumer of the application and the actual implementation and hides its location while presenting a single, unified “presence” to the consumer. It also centralizes DNS management, which is critical when considering the implementation and deployment of DNSSEC.

Without a governance strategy, it is possible and probably likely that silo-like deployments will occur, especially as the service offerings in cloud computing providers continues to mature and expand. Fragmentation of infrastructure across multiple silos also makes it difficult to integrate into existing management systems and makes more complex troubleshooting, log aggregation, event correlation, and reporting in general.

"We were experiencing what others had warned me about. We suddenly realized ‘wow, this is an extremely complicated environment’ and when there’s a problem, you get 8 staff and 3 vendors on the phone all pointing fingers at one another.  The need for cross-silo insight became absolutely critical”.

                                                                                    -- VP of Virtualization Operations, unnamed organization “The Virtualization "Tipping Point" in 2010”

Silos, except on farms, are just plain bad news. But without governance and a strategy with which to approach public cloud computing-based application deployments, they may pop up without intent.

Maybe this is a job for “Cloud Coordinator”, or whatever you might want to call such a group or individual. SOA eventually came up with a similar notion, often called the “Registrar” or the “Librarian”, depending on what governance solution was being implemented. Someone or some team that is responsible for (a) understanding what services are available in the apposite cloud computing environments and (b) managing those services with an eye toward sharing or at least ensuring consistency of solutions across applications  deployed in a public cloud computing environment. One thing that will greatly improve the ability to keep that consistency is the vendor-enablement of shared configurations across disparate instances. Not synchronization, necessarily, but simply sharing of configuration across devices that may or may not (most likely the latter) be paired. Better would be the ability to “share” granular configuration settings – on a per-policy or per-application basis – with other like-devices.

Avoiding the creation of silos in the cloud will be a challenge. Recognizing the need for a consistent strategy and enforceable governance policy will go a long way toward avoiding the pain of trying to extricate applications and isolated infrastructure deployments from the silos created by ignoring the ad-hoc provisioning of entire infrastructures to support each application.

Related blogs & articles:

• Cloud Balancing, Cloud Bursting, and Intercloud
• The Cloud Metastructure Hubub
• Governance: Service Catalogs and the Cloud
• Emergent Consensus: Private Cloud Needs a Front Office Part 1
• The Virtualization Tipping Point in 2010