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

Are the lessons of SOA being ignored with the cloud?

Vote 0 Votes
As Joe McKendrick writes on ZDNet, Hey big consultants: isn't there architecture behind that cloud? David Linthicum said "Many are not chasing cloud computing the right way, missing many of the architectural advantages. Instead they are just tossing things out of the enterprise onto private and public clouds and hoping for the best." Do you agree, and what should be done about it?

10 Replies

| Add a Reply
  • I believe a lot of the lessons have been lost. SOA originally promised the ability to choose and use best of breed technologies from different vendors inter operating using a number of standards. This was watered down to being able to use SOA software stack from vendor a, b or c.

    The Cloud providers have now done the same by locking people into their particular Cloud so that if you go with Cloud provider a, b or c, you are simply locking yourself into yet another proprietary architecture.

    Ideally what would be nice would be to have a generic Cloud image and run it in whatever Cloud you wish. Perhaps for a given workload, the day will even come you can choose your Cloud provider on a daily basis depending on what are your key criteria (e.g. cost) and then deploy your image to that Cloud......however, this wont happen anytime soon IMHO.

    In the mean, the use of interoperability standards can help to allow you to black box your Cloud providers to move workload from one to the other. More on this here if you wish to read more.

  • Actually, poor architecture is one of the main showstoppers of cloud computing. So, SOA is an enabler for cloud computing. But that is the other perspective. New technologies and new ways of doing things always makes some people forget those old lessons. This means that the old lessons must be learned and paid for one more time. This is certainly true for cloud computing too. But, hopefully some companies will think one more time. SOA could make cloud solutions more flexible and easier to mix or even replace - that is take advantage of new and better cloud offers around the next corner. Maybe even from another vendor? But I guess the cloud vendors won't help us think that way :/ My prediction: The more we rely solely on cloud vendor guidance, the less SOA we will see.

  • user-pic

    Until Cloud providers turn into commodity providers, everyone will try to lock you in thier Cloud solution. IN the Business, money go first, Cloud and technology in Cloud - second. Learn from IBM.

  • Yes. What providers are offering today are service-enabled APIs, not true service-oriented operations. Just as we boiled down SOA to little more than a service-enabled veneer over SDKs and APIs for integration, or as an interface to functions in our applications, cloud providers are merely offering a service-enabled interface to a very sparse set of operational processes.

    We're still failing to recognize the core of service-orientation and abstraction as a means to achieve true interoperability and service-oriented architectures. HTTP+SOAP does not automatically confer SOA status upon an offering.

  • I've noticed a number of prevailing patterns over the past several years:

    1. A company "gets" the cloud and looks at it from the perspective of changing the way services are delivered, rather than the underlying technology itself. I would categorize this as still being somewhat rare, but when we engage with customers that understand what a game changer the cloud is, we find that their thinking is very much aligned with SOA whether they explicitly reference SOA patterns or not.

    2. A company drank the Microsoft, salesforce.com, or other vendor's Kool Aid, and to @John's point, they lock themselves in to a specific product or set of services (voluntarily or otherwise). In the case of Salesforce, that's not such a bad thing because Force.com is a platform that supports SOA "inspired" patterns more than others, but Microsoft is just calling everything "cloud" now to sell more Office and Windows licenses. We see this about 50% of the time.

    3. Much like #2, Kool Aid has been consumed, but we can't quite figure out what it was spiked with...this is where someone will use cloud terminology, but their processes and/or technology are so locked into legacy patterns that the cloud has little or no relevance. And at this point, SOA becomes a chicken-or-egg proposition, because at the end of the day, an entrenched mindset needs to be blown up and reprogrammed before anything resembling SOA or cloud can have any chance of being delivered or adopted.


  • SOA proponents inside and outside of enterprises spent the past decade debating and developing governance strategies -- the lack thereof which is the greatest showstopper of service orientation. Governance is the line between evolving toward SOA or having JBOWS (Just a Bunch of Web Services.) Now, many companies have are supporting a JBOCS (Just a Bunch of Cloud Services) anti-architecture that ultimately costs more than any savings realized.

  • I would not say lost. I would claim that a lot of SOA lessons are not implemented on the cloud. Connectivity between applications are not made easy because their on the cloud. People still program and secure the same way they would do on premise.

  • At the risk of over simplification...

    The use of cloud computing should be driven by requirements - and specifically non-functional requirements. In a TOGAF-context, one is continually gathering, prioritizing, and refining requirements of the architecture during iterations of its ADM. The choice of cloud computing solutions - as cool and sexy as they may appear - should be the *result of* a requirement and not the requirement itself. For example, does the architecture (application or service, in this case) require the benefits of elastic computing resources or HA?

    Requirements-driven, not buzzword-driven.

  • A major mistake in SOA initatives was building a wild forrest of Web Services (which were not even SOA Services).
    Some people called this ABOS (A Bunch of Services) I called it SCS    
    Now Enterprises are migrating services and applications to The Cloud with no Architecture, no Planning and without taking into considerations Integration issues and Priorities.
    Nothing has changed? I am not sure. At least Large Enterprises tend to postpone for few years Core Business Applications migration to the cloud. For more details read SaaS is Going Mainstream.

  • If we think that we've moved past complexity going from SOA to more of the cloud, then we've deluded ourselves. And therein lies a huge (and ever-growing) task that needs to be hurdled just the same.

Add a Reply

Recently Commented On

Monthly Archives