Cloud computing causes confusion about services dependencies
What is one of the scariest things that most companies don't understand about cloud computing?
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