Replacing the dev-test-deploy-ops rut with a collaborative approach to delivering business app services

DevOps for Business Application Services

Subscribe to DevOps for Business Application Services: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get DevOps for Business Application Services: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


DevOps Authors: Yeshim Deniz, Ilya Bohaslauchyk, Carmen Gonzalez, Andreas Grabner, Pat Romanski

Related Topics: Cloud Computing, Virtualization Magazine, Infrastructure On Demand, Cloudonomics Journal, CIO, SaaS Journal, Infrastructure 2.0 Journal, SOA Best Practices Digest, Government Cloud Computing, SOA & WOA Magazine, IT Strategy, CIO/CTO Update, DevOps for Business Application Services, DevOps Journal

DevOps: Blog Feed Post

IT Fears Change...and Cloud Computing

Cloud computing adoption requires organizational change, the kind that also threatens an established order

Cloud Computing on Ulitzer

One of the stumbling blocks toward a complete adoption of cloud computing is certainly around ensuring the stability of the underlying network for it is the enabling factor in all IT efforts.

We have a brittle system underpinning the data center: the network. It’s brittle, yes. But it works. Thanks to years of tweaking and tuning and troubleshooting, it works. We know where everything is, and how everything interacts, and it works. It works well, in fact, now that we’ve got it all figured out.

Is it any surprise then that we might be resistant to change that might (probably will) upset that delicate balance?

One of the most difficult challenges in advocating the employment of a solution that is essentially a hybrid of two existing (and entrenched) concepts such as networks and applications is not only getting those responsible for each “side” of the solution to talk to each but to work together. Each one lacks the control over the solution because it is a hybrid, and thus each group is generally unwilling to give up any of their control to the other. The network team doesn’t want the application developers mucking around in “their” network and the application developers don’t want the network team mucking around in “their” application.

"Oh, East is East, and West is West, and never the twain shall meet." – Rudyard Kipling, Barrack-room Ballads, 1892

And that’s really at the core of why application-aware networking is sometimes difficult to make stick and why, ultimately, cloud computing will also be as difficult to “make stick.”

Brad Casemore reminded me of this fact recently in his post, ““The Long Winding Road to Application-Intelligent Networks”:

blockquote The defining concept of application-aware networking has been with us for some time, and the technologies clearly exist to facilitate its widespread deployment. What’s preventing it from coming together is the balkanized thinking and — why not say it? — the entrenched politics of the traditional data center and its vendor ecosystem.

We’ll get there, though. The wheels are in motion, and the destination is in sight.The trip just took longer than some of us though it would.

Lesson learned: Never underestimate institutional resistance to change that is seen to threaten an established order.

-- Brad Casemore, Twilight in the Valley of the Nerds

Ah, yes. Application-aware networking, the hybrid solutions of networking and development, threaten the established order within the data center. This is mine and that is yours. We fear change, for it may upset the balance – not just in the underlying systems but in the balance of power in the data center.


WHO YOU GONNA CALL?

One of the stumbling blocks toward a complete adoption of cloud computing is certainly around ensuring the stability of the underlying network for it is the enabling factor in all IT efforts. Without a network there’s nothing but a disconnected set of resources. Moving from a static network to a dynamic one means change, and change means things are going to break. When things break it is the role of IT – particularly network and systems operations – to stay late and try to figure out how to fix it. That’s not something that anyone looks forward to, so it should be no surprise that IT “fears change”.

And while “self-service” and the ability to provision servers, applications, and other services on-demand by business users sounds like a great time saving thing, it can backfire horribly. Because when something goes wrong, who you gonna call? That’s right – IT and most likely specifically you’re going to call operations. The black-box effect of external cloud computing on troubleshooting application and network problems may prove to be the balancing factor in the cost-savings benefit equation; the one that offsets the savings and results in the external cloud experiment being deemed a “financial draw.” It’s one thing for IT to troubleshoot issues in an environment they know and, in many cases, designed. But to also be responsible for problems that may occur with external systems with which they’ve had very little exposure may be asking for trouble. And when it isn’t the business users but the developers bypassing processes and going straight to the cloud, look out. After all, “they should know better” because they’re part of IT, aren’t they?

While the notion of “self-service” may be very appealing to “the business” or developers because it bypasses IT and/or its processes, this is likely to bite them both in the proverbial derriere precisely because it bypasses IT and its processes. A human architecture for dealing with cloud – whether internal or external or both – is necessary to deal with not just the rate of change in the network but in the overall organization as well.


HUMAN ARCHITECTURE

The problem is that this same resistance to change will certainly impact cloud computing adoption on a grand scale, the kind that some purport to be “on the horizon” and that some claim will happen, absolutely (probably because they’ve bet their futures on it). But as has been pointed out by many very smart people, cloud computing adoption requires organizational change, the kind that also threatens an established order and therefore as Brad points out, will be resisted by many. Consider Vanessa Alvarez’s commentary on this very topic in “The Emerging & Shifting Role Of The IT Professional”

blockquote In this kind of environment, the role of IT professionals strategically changes. As enterprises move their IT organization away from just managing and maintaining a corporate network or data center and look to make IT more strategic, it will require not only technological and operational change, but also an organizational change. This transformation will require organizations to further align the business with IT. It means much more open communication with line-of-business managers, accounting, finance, procurement, and marketing. This model drives all aspects of a business to work closely together to enable this type of environment to achieve the efficiencies and performance the model is designed to deliver.

We’ve heard this song before, and though the lyrics have changed slightly to match the buzzwords of the day, the melody remains the same. Early proponents of SOA (Service-Oriented Architecture) sang the same song: we need to work more closely with the business, this will help us align with the business and its goals, a common language (terminology) will help us unify IT and the business to better deliver solutions.

For the most part, this didn’t happen. Now we see the emergence of DevOps as an IT discipline, as the means to bridge one of the many gaps within IT that exist between two disparate sets of foci (development and operations) that must be better aligned and unified if cloud computing and virtualization is to truly succeed. But there are stumbling blocks along the road to integration that must be addressed first. What we need to do is learn from past mistakes and identify where obstacles may lie and then attempt to address them before they trip up a movement toward a unified “human architecture.”

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.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.