InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

How Does SOA Relate to Cloud Computing?

Posted by Boris Lublinsky on Sep 02, 2009

Sections
Architecture & Design,
Enterprise Architecture,
Operations & Infrastructure
Topics
Cloud Computing ,
SOA ,
Enterprise Architecture ,
Architecture
Tags
Service Design ,
SOA Adoption

 

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.

  • This article is part of a featured topic series on SOA
Cloud requires change in mindset by Udayan Banerjee Posted
REST + Cloud offerings by Saurabh K Posted
  1. Back to top

    Cloud requires change in mindset

    by Udayan Banerjee

    Cloud is not just about infrastructure - it needs a change in mindset - setandbma.wordpress.com/2009/08/24/does-cloud-r...

  2. Back to top

    REST + Cloud offerings

    by Saurabh K

    Written my thoughts on REST + Cloud offerings
    saurabhkaushik.wordpress.com/2009/09/27/cloud-i...

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.