We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
Cloud Computing

Does It Matter Whether It's SOA or Cloud Services?

Vote 1 Vote
A dispute has recently risen up around SOA and Cloud where, last week, as David Linthicum wrote, Gartner Gets Cloud Computing Wrong.  As Joe McKendrick writes in his ZDNet blog, Does it matter it is't SOA or cloud Services? not to the business, "Some analysts, such as David Mitchell Smith, say SOA isn't necessarily cloud, while others such as Dave Linthicum say a service-oriented foundation is essential for cloud." So what's your take, is this an important distinction?

7 Replies

| Add a Reply
  • SOA is a service based architectural style and an integration technology for IT. Its implementation in the Enterprise often failed (SOA was pronounced dead some time ago) because it requires business reorganization which is not really the competence or the business of IT, where it often started.

    The Cloud is an IT implementation solution based on outsourcing. The Cloud does not have to be SOA or Web Services based but it is much better off with them since it takes advantage of the service paradigm and existing WS technology. Otherwise the Cloud would transport us back to the ASP era.
    Enterprise Architecture is Enterprise Architecture all the same, Cloud or not, since the Cloud is just an option to deploy technology by outsourcing, which is simply documented in an EA. The Cloud is in fact the reason EA is moving towards the business architecture realm since soon enough The Enterprise may not own the IT any longer.

    Here is an article on the new breed of Cloud Enterprise which describes how the Enterprise would look in the outsourcing and Cloud era.

  • Before the cloud, SOA was one part philosophy and one part vendor speak for web services software. The very nature of the cloud, with granular and distributed services, makes it the technical manifestation of SOA for all intents and purposes. While there may be some argument over the semantics and application of specific architectural patterns of SOA in the cloud, the fact of the matter is that the "everything as a service" paradigm of cloud computing is what many of us have been striving for as the realization of the SOA vision. While cloud services are still too immature and coarse-grained at this point in the game to make the SOA connection self-evident, the parallels are too strong to dismiss in the current state, and the future state will achieve the realization of pervasive SOA / cloud linkage.

  • Alas, the IT industry is drowning in its own buzzwords!!!


    SOA is an approach to modularize application software into smaller, more usable components. The core principle behind SOA is modularity. D. Parnas wrote a paper about modularity in 1972 long before WSDL and the slew of other technological advancements related to SOA. While SOA permeates all four of the TOGAF architecture domains (business, application, information, technology) I feel its critical mass lies in the application architecture space.

    Cloud computing is about elastic availability of computing resources. CPU and storage are made available dynamically (like cell phone minutes) without the need to forklift in new equipment. This is primarily a technology architecture concern to address quality attributes/non-functional requirements around response time, availability, and scalability.

    Sure, my shiny SOA services can be hosted in the cloud. But I don't see how the two should be intertwined. For the sake of architectural simplicity, I contend they should be kept as separate, but very important, concerns. In the end, they both serve to drive down the TCO of IT solutions.

    • Eric

      that's again melting in my mouth: IT industry is drowning in its own buzzwords.

      Anyway, to me modularity is just half of the SOA essence. Top-down working. In fact, the more easy half. No (serious) problem with that. The hard problem seems to come in with the other half. Bottom up. EAI, in the widest sense.

      As I understand it, the central question of 'integration' is one of architectural style (in the sense of Fielding): 'REST, drawing from self-organization, realized in the Web' versus 'BPM, betting on governance, realized in those IT-solutions, running at Application servers serving as BP-Engines'.

      I think, if we have a look at SOA with 'integration' in mind, we cannot but touch the Hamlet-question: Web or Intranet, Web-Server or Application server, REST or BPM - to state it coarse-grained. What's the right mix for each and every single company, given its grown collaboration culture?

      Couldn't this problem, together with the above mentioned lack of terminological dsicipline, be the motive force driving (some) IT-people into that state of excitation, which soon will come down again and fade out without having done any harm?

  • SOA is an architecture for the Enterprise and the Virtual Enterprise, so for the Business it does not matter if a service is deployed in the Enterprise or the Cloud (virtual Enterprise). Technically it could matter e.g. Integration and Security issues. Do not forget that Service Oriented Infrastructure (SOI) are also SOA Services. The Cloud services provider is responsible for defining SOI services.

  • SOA is more of a technology and faces a challenge in making a business case, on the other hand - Cloud services is more about business case and less about what technology is being used. So it depends, who you are asking this question. Obviously, SOA as a foundation to cloud services makes more sense, but then the consumer of this service is not much concerned about how it is being implemented. It is the provider, who has to worry about the performance, availability and economics and needs to decide either to choose SOA or not.

  • Cloud is built using SOA concepts so is naturally pre-disposed to SOA capabilities (aka services) hosted within it. The benefit is that the fixed cost of re-platforming to a cloud will be smaller because the service contracts and their implementations can be more easily plumbed in.

    Of course you can always just use IaaS without having to think about things but you loose potential cloud candidates by doing so. So the logical thing to do is to service enable that that makes sense to increase the candidates.

Add a Reply

Recently Commented On

Monthly Archives