If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Blog Feed Post

Cloud is an Exercise in Infrastructure Integration

When you get down to the architectures involving cloud – whether on or off-premise or hybrid – it’s really all about integrating infrastructure.

imageIt remains to be seen if network and operations are better off never using the word “integration” given the nearly violent negative reasons one sees in the development and architecture sides of IT to the word. Integration, even after the introduction of SOA and the nearly messianic view of the role of the enterprise service bus (ESB) in saving us from the horrors of traditional enterprise application integration (EAI), remains problematic for IT. Standards weren’t, interoperability didn’t and reuse was a concept that was thrown under that bus by developers reluctant to trust or simply unaware of existing services.

But integration also remains necessary. The dominant web 2.0 model leverages APIs instead of endpoints, but ultimately it attempts to do the same thing that every integration model in the history of IT has done: share data and enable business processes to span applications.

What cloud computing is doing is forcing infrastructure –network, storage and application delivery – models to adopt many facets of development. A services-based approach to provisioning as a means to enable IT responsiveness through the application deployment process. Multi-tenant models of management to support fault-isolation and self-service. And integration to support sharing of data and enable operational processes to span components. The data is different, the processes have a different focus, but the concept is exactly the same. Applying the web 2.0 model of API integration to infrastructure enables the sharing of data (context) as well as automation and the ability of infrastructure systems to instruct and be instructed by the management frameworks that drive automation and orchestration.

Today there are very few examples of “public only” cloud computing deployments. Even those that might at first appear to be “public only” such as a SaaS are not; those applications are ultimately integrated with systems and applications and, in many cases, infrastructure that still resides within the physical data center because the data housed in SaaS is only part of the big business picture. It needs to be correlated and integrated and analyzed and warehoused somewhere, and all that requires integration of some sort via APIs to pull the data out of the cloud and put it into systems internal to the data center where they can be used.

Cloud bursting or cloud extension or cloud-what-have-you models that leverage cheaper compute and storage resources from public cloud providers require integration at the infrastructure layers. Using storage resources from the cloud as part of a larger tiering strategy mean that some piece of infrastructure – storage virtualization likely – is integrating those resources via an API. Similarly, compute resources must be integrated – included – in architectures in the data center if they are used as  part of a dynamic capacity extension strategy. That requires some integration via an API or infrastructure capable of natively managing those resources in public cloud environments (which, if we peer close enough, we’ll see is enabled via .. an API).

Integration means including, to make part of the whole and to do so – hopefully – seamlessly and automatically. Even if an application is completely deployed in a public cloud computing environment it is almost a Heisenberg certainty that its data will be integrated back into some warehouse or application in the data center or that it will ultimately need to participate in some larger process that requires spanning both public cloud and private data center. Or the cloud-deployed application will become so critical to business that it must be managed in the same way as other business-critical applications – it must use corporate identity stores, it must be monitored and managed via existing enterprise application performance management systems, it must be integrated with the rest of the business and operations.

Which means infrastructure integration. Let’s hope we’ve learned enough from the trials and travails of enterprise integration that we get it (mostly) right the first time. I’d also suggest investing heavily in turkeys. Because if enterprise application integration required sacrificial chickens, we’re probably going to need something a bit bigger to meet the challenge of integration efforts that will span environments, models, and architectures.

Connect with Lori: Connect with F5:
o_linkedin[1] google  o_rss[1] o_facebook[1] o_twitter[1]   o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1]

AddThis Feed Button Bookmark and Share

Related blogs & articles:

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.