Cloud computing causes confusion about services dependencies

Cloud computing causes confusion about services dependencies

What is one of the scariest things that most companies don't understand about cloud computing?

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to provide a unique online resource for developers, architects and development managers tasked with building and maintaining enterprise applications using Visual Basic, C# and the Microsoft .NET platform.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchWinDevelopment.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchWinDevelopment.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Service dependencies
As developers start to look at services provided by other vendors or service providers, or internal Stovepipes, they see massive application potential as the ability to produce and consume services becomes easier by the day and more and more public and private services start to become available. So developers start to connect and consume both private and public services to give new functionality to their customers.

So taking the above as an example, lets say we have 1 service from Stovepipe A, 1 service from Stovepipe B, and a new service that Stovepipe C created using Stovepipe A's service. These are combined with a public service outside the organization and both Stovepipe A and Stovepipe B are using stovepipe C's service in some individual applications. Got that?

Now start adding the concept of exposed services. In the above example, if the Public Service goes out I have a small issue, but what if Service A gets changed and that change breaks Service C, which is not Service A's direct responsibility? What if Service C can't update Service A, but the combined update for SomeWork Component A needs to go in that night? I just can't rollback Service C…I now have to rollback all of Stovepipe A's changes to get back to a good state.

Here in lies the 8000 pound giant. What agreements, service-level agreement (SLA), or normal works contracts are in place to ensure a complete update. If I'm the manager for Stovepipe A, I have no real jurisdiction over Stovepipe C, so if an update in Stovepipe C goes wrong, what is the recourse of action. Not to mention that there is also a public service dependency and what are its agreement from outside. Point in example, what if Public Service A changes it interface or has a breaking interface, thus bringing down all three stovepipes in the process, what is the recourse?

This was first published in March 2010

Back to top