How Does SOA Relate to Cloud Computing?
Joe McKendrick has published a transcript of the session "Challenges and Opportunities in SOA and Cloud: Lessons Learned" , session attended by Phil Wainewright, David Bressler, Ed Horst and Joe McKendrick.
The session started with the question asked by Phil Wainewright:
How do you -- each of you - define cloud and what do you think of the key differentiations, if any, from SOA.
According to Joe McKendrick:
... it's just been amazing the past year or so how these concepts are converging or coming together and I'm talking about SOA and cloud in particular. SOA is something that's been around since the beginning of the decade and a lot of companies have been working with it... And now, we're seeing a lot of this emphasis shift to the cloud... I think the main way you can distinguish between the two is SOA is the architecture, SOA is the underlying architecture, the way you build, maintain, govern, and orchestrate the services you deliver. And the cloud is the technology, the vehicle by which these services are delivered from party to party. But I think, it's getting to the point where you're not going to have one without the other.
Phil Wainewright continued by asking:
Is it as simple as that, cloud is just SOA but kind if implemented in some kind of Web-oriented way?.. And what I mean by that is because it's an open environment and you don't know who're interacting with. You have to do all the service level things, you have to define the contract..., you have to define your security requirements, you have to do all of those things you didn't necessarily bother to do in a controlled enterprise environment because it was controlled, because you knew what was going on... I think there's a lot of commonality that we've established between SOA and cloud. Cloud is doing a lot of the things that SOA was setup to enable so; therefore, I think we can go onto perhaps to make the premise that cloud can learn from the experience of SOA. So what are some of the things that SOA teaches us? What are some of the lessons learned that we perhaps don't want to repeat the same mistakes when we're implementing cloud?
Trying to answer this question, Ed Horst mentioned the three main SOA lessons:
... start with a specific project that has some kind of reasonable boundaries to it that's going to have daily business impact when it's done... you do want something that has regular use. The other thing is ... avoiding the kind of boil the ocean architecture approach where we're going to get everything to be cloud before we really do anything in cloud... But that does not say that that first project can be done without regard to some ultimate directions. So an hybrid, one of the more successful strategies I've seen is kind of a hybrid of kind of broad strokes as to where the overall architecture is going, where we really want to end up in two, or three, or four, or five years even but some real practical realities around that initial project. And then,... manage the system, govern the system kind of early and often. You don't usually regret having done that early on but you often times regret not having done it if you don't.
In Phil Wainewright’s opinion, an all encompassing Web Oriented Architecture allows to unify SOA and cloud computing. He continued by saying that:
... one of the characteristics of Web Oriented Architecture is the REST interface, the simpler interface that doesn't have all the other stuff that kind of SOAP has involved with it. And is that a characteristic - a necessary characteristic of a cloud environment as well that it tends to have these more, I don't know, lowest common denominator interfaces?
In Ed Horst’s opinion, both REST and SOAP have a particular place and usage depending on the type of interactions:
If it's more transactional in nature, if it's more guarded in nature, its more business critical, oftentimes, the information is coming across SOAP interfaces. But if it's more kind of query and update and kind of lightweight with less business impact, customers are using REST interfaces... that's not to say that REST can't be used for transactional behavior but when you start to add all the things in there you need in order to do transactions, security elements, and well formed messages and things like that, REST starts to look a lot like SOAP.
Today the Cloud is a new IT buzzword, while SOA seems to be slowly coming out of favor, at least in the view of some analysts. Consequently, it is currently a popular assumption that whatever flaws and difficulties SOA had, they would be solved and improved by the cloud. In reality, as Joe said, SOA is about proper system architecture, while cloud is about infrastructure. And as we all know, even an excellent infrastructure can’t save a bad architecture. So let’s stop hoping for a silver bullet and let’s start concentrating on fundamentals: proper service architecture.
Cloud requires change in mindset
REST + Cloud offerings
InfoQ Sep 01, 2015