| By Brandon Watson |
Article Rating: |
|
| April 25, 2009 09:30 PM EDT |
Reads: |
15,792 |
Brandon Watson's "Many Niches" Blog
What happens when your cloud provider has multiple datacenters and has the ability to move your code around based on their need (read: not your need)? One thing that any enterprise IT buyer knows how to say is “who’s throat do I choke?” When you have a composited application, who exactly are you going to be calling? The cloud providers have yet to address the myriad of problems which can, and will, arise.
Just when you thought it was safe to start thinking about putting together all of those services into a composite app, the dreaded siren call of “whose neck do I choke”beckons. If you ever plan to have an IT manager look at your application, get used to hearing that one.
I’ve been off for a few weeks launching a little thing called Azure Services Platform. Did you miss it? There are plenty of videos over at the PDC 2008 site. Here’s a great video of Steven Marx doing a walk-through of the Windows Azure code.
I will post my in depth thoughts on what we released at another time. The coverage has been impressive, as you can see from these search results to the techmeme run. I will revisit the topic later when I have something new to add.
The topic I did want to cover is the coming need for SLAs and trade agreements between trading partners who may not know that they exist in an application with one another. Imagine a developer building a composite application through the use of multiple web services, each of them running via a different hosting provider. The myriad of problems which can, and will, arise, have yet to be adequately addressed by the cloud providers. One thing that any enterprise IT buyer knows how to say is “who’s throat do I choke?” What they are referring to, of course, is the notion that should something go wrong with their applications, they need to know that there is someone whom they can call, scream at, and from whom they can expect a late night visit of the monkeys to the cages to fix whatever errant process is running amok.
When you have a composited application, who exactly are you going to be calling? How can you even begin to diagnose the root cause of the issue. Further, what if QoS (quality of service) is the culprit? You calls are failing because the data is getting to you too slowly. It eventually gets there, it just gets there too slow. Is that factored into your agreement with the service providers? Or were you only thinking about SLAs? Either way, you still have the problem of who to blame, the ingress or egress traffic provider. What happens when this is a duplex, synchronous transfer? The real challenge for anyone looking to build composite apps will be ensuring that the service is uniform from each of their providers, which could be compounded by the fact that those providers may very well exist in different hosting facilities in different parts of the world. Want yet more complication? What happens when your cloud provider has multiple datacenters and has the ability to move your code around based on their need (read: not your need)?
As you can see, we’re just now starting to scratch the surface of what’s possible with cloud computing, but also just starting to understand what can go wrong. Without proper planning and thinking, we are going to be digging ourselves some real holes in terms of end customer sat, partner sat, and developer sat. Anyone have any thoughts?
[This post appeared originally here and is republished in full by kind permission of the author.]
Subscribe to Ruby-On-Rails Email News Alerts
Subscribe via RSS
