When it became clear cloud computing and software-as-a-service would emerge as serious options, SOA bloggers and analysts spent a bit of time exploring how internal SOA efforts would work with cloud computing.
It seemed like a very promising match, and most of the news was largely optimistic: Of course your SOA efforts would help you move to the cloud; service-oriented architecture and the cloud were a match made in heaven. (David Linthicum offered a particularly useful and restrained explanation of their relationship, if you're curious.)
But the longer I write about integration, the more I find myself mutter, "The devil's in the details," and as always, the details take a bit of time to wiggle their way into the sunlight.
ZDNet's SOA blogger, Joe McKendrick, has been digging around this topic detail recently, which triggered others to chime in more cautionary advice about this SOA/cloud match. If you're hoping to leverage SOA with the cloud, you should definitely take a look at this emerging conversation.
But, as always, for those short on time, I'm offering three key cautionary cloud take-aways:
Using services with the cloud may make you a victim of your own success, McKendrick warned readers on Tuesday. This has always been one of the hazards of designing a SOA-you never know how much the service may be called, and so your architecture has to be anticipate that the service may be used more in the future. The cloud gives you more opportunities to leverage that service, and, as result, the risk of failure goes up. McKendrick explains how this can affect ROI:
Organizations deploy shareable services, only to have them pounded into the ground by a growing number of requesting applications. Here's a case where SOA costs may be driven up by the need to quickly put in or provision additional hardware. Cloud adds a new dimension to the challenge.
The cloud complicates performance problems, including load balancing. Linthicum made this point in July, observing:
The use of a federated architecture, inclusive of cloud computing, typically comes with a systemic performance problem considering that the processes, services, and data are not collocated. Cloud computing makes this much worse, since in many instances coupled services could be 10,000 miles away across a very bursty Internet, and architects typically don't consider performance until it's too late.
But McKendrick found an excellent real-world example-posted by Oracle consulting architect Stephan Koser-of the type of unforeseen performance problems you can have with SOA anyway, and how the cloud can make it worse. Koser's post is technical and a good read for architects. The problem had to do with the load balancing of services-one instance of a service was being hit repeatedly while others would ignore, and you can image the problems that created.
But it was Lori MacVittie, a DevCentral blogger and technical marketing manager for Application Services at F5, who put the problem into a larger, strategic context, explaining the bigger architecture challenge is "understanding the interaction between the network, the application network, and the services themselves."
This isn't a problem unique to SOA, but it's certainly a major potential headache for SOA, and it can become doubly challenging when you place infrastructure in the cloud. MacVittie warns:
You can't-or shouldn't-assume that the load balancing provided is going to magically distribute requests perfectly across your scaled application because it wasn't configured with your application in mind. Applications are not islands; they aren't deployed stand-alone even though the virtualization of applications is making it seem like that's the case.
Don't overestimate the maturity of the cloud. Anne Thomas Manes of the Burton Group made this point when responding to to McKendrick's proposal that the cloud is the SOA we've always wanted, because it covers issues that are hard for traditional SOA implementations. She seems to consider his post overzealous, because she offers a long list of things she feels the cloud can't deliver yet, including providing more visibility and transparency into IT costs and better support for service contracts. She says:
... cloud is too nascent for such assertions. Besides, in order to achieve these characteristics in cloud-based systems, organizations have to 1- design them that way, and 2- develop the contracts and trust described. You won't achieve these characteristics automagically just by deploying a system to EC2, Force.com, or some other cloud provider.
So, if you're hoping the cloud will help you solve some of these SOA problems by outsourcing, Manes recommends you think again.