Hacker News new | comments | show | ask | jobs | submit login

Beginning in 2003, and until the height of the SOA craze around 2010, the Service Component Architecture (SCA) was seen as the holy grail of service integration. It encompassed both local/in-process (or in-JVM) as well as networked services (SOAP and REST), was polyglot in that it defined API bindings for native, Java, and even PHP and Cobol, could access external services, and was still quite practical. For those needing it, it also supported authorization and transaction policies and protocols.

When commercial interest in SOA middleware products dropped sharply, further standardization of version 1.1 slowed down, and Oracle, sitting on the SCA board, voted down all specs that had been worked on without further explanation.

To this day I still haven't understood what makes microservices different from SOA in a technical sense. I can get that the term SOA was probably burnt at some point, but if there's a real lesson to be learned from SOA failures, I'd really like to know. Maybe SOA was seen as too complex because it addressed some of the harder problems such as transaction and authorization protocols/boundaries, BPM, etc. upfront?




For a while I was consulting a lot around SOA - particularly around the IBM stack, which was one of the biggest SOA evangelists in the early days.

SOA was too complex for sure, but it wasn't just that it was complex. It's that complexity didn't actually deliver the return.

Part of the issue was the way SOA was sold. You buy a BPM or a Rules Engine and suddenly you unlock all this value and you can compose things on the fly -- Rules Engines were particularly bad in this respect. Business users were told they'd be able to tweak rules on the fly. This was never a reality.

Then you get outright hits in terms of complexity. Those BPM systems with two-phase commit were monsters. In fact they were so complex it was _more_ likely to fail. When in the vast majority of cases, actual failure rates were rare and easily handled by a reconciliation process. So the tech never really matched the need.

On top of that, the consultants cost a fortune. Instead of a few test environments, you needed 7. Managing test data and rollout to end-users became a nightmare... And even then, as the technology wasn't mature, you'd hit hurdles very late. Dismal production performance was a common one.

It's a bit sad. A really interesting set of ideas and technologies - but really poorly sold and way past the hype to deliver. It's equally true of related technologies like CORBA.


Re: "rule engines"

I know exactly what you mean, having suffered through JRules projects, but don't consider rule/forward-chaining languages part of a SOA stack per se (I especially loved the idea that rule bases, unlike services, don't need testing, because they're end-user configuration parts, and because, like SQL, they're kindof declarative).

Reading through the answers, I still don't know how microservices are any different from SOA ):


funnily enough, the US military uses CORBA for some systems.

"the Navy has specified the use of the Common Object Request Broker Architecture (CORBA)—the military's favorite mission-critical middleware model."

https://arstechnica.com/information-technology/2013/10/the-n...

of course, the military has control of the allowed corba implementations so they don't suffer from some of the problems that plagued CORBA, including different runtimes, and get all the typed benefits and speed benefits.


I think microservices place a greater emphasis on data-encapsulation & isolation, wheres SOA focused more on the RPC/API surface. I think this is just an emphasis difference though and not a hard separation


All the in the wild SOA applications I've seen were just glorified RPC, not much different than what would have been done with CORBA and the like much earlier. Some seemed to recognize this and create micro services instead, which now seems to have also devolved into RPC by a new name.

I hope the next iteration removes the word service entirely, for too many devs the word service is synonymous with web service. I suggest sticking with daemon.


Microservices is to SOA as "JSON over HTTP" APIs are to REST APIs. Fundamentally the same goals but with a focus more on being a general description of a "style" rather than a specification for how it should be implemented.

This is a double-edged sword of course...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: