SOA and the Tar Pit of Irrelevancy (2009)
nealford.com
nealford.com
I have done in-depth analysis and refactors of dozens of these doodleware objects purely with vim macros. Portable gVim was literally the only thing I could get on the customer supplied Windows laptop to do this job. Export (through a semi-manual hack) dozens/hundreds of 10k line XML files, build a vim macro, cry, cross my fingers that the manual hack to replace the doodleware objects would work, cross them again that the objects weren't irreparably damaged.
Now I'm seeing doodleware on the rise in cloud platforms, making business process flows "easy". Connecting different services "effortlessly".
"The term SOA has been so co-opted by vendors trying to sell stuff that I think it will die off as a term."
I think it did! I definitely didn't remember what it stood for. (The author does provide a definition, but it's on the 25th time he uses the acronym :) )
so we can service 500 users with between 10 and 100 requests a day.
At least we improve on the paradigms on each iteration. Maybe one day one day both of them will be good enough to let us swing toward something new.
Other than the WSDL/BPEL nonsense, is there any difference between service-oriented architecture and microservices architecture?
To me, SOA is more about the implementation-- especially the old WSDL-driven part.
But Kubernetes is more about infrastructure. The applications are written in different styles and different languages. K8S is more like a platform than anything else, to me.
But, net net, I put SOA in the same general bucket as ITIL and other associated practices of the time. They meant well but for most purposes they involved too much process and were ultimately too tied to big vendors trying to sell stuff.
"REST" microservices also do that, but they aren't bound to quasi-proprietary protocols and tooling.
By "REST" I assume you're referring to non-SOA distributed systems which might happen to use REST or RPC-over-HTTP interfaces, and not the architecture style.
Assuming that, "REST" handles all those features by integrating services that support coordinated transaction rollback/compensation over multiple heterogenous service calls.
> How is SOAP, XML, WS-*, AMQP proprietary?
If you read what I said you'll notice that I explicitly said "quasi-proprietary protocols and tooling".
That was one of the tragedies of SOA. The S was meant to be service as in windows service but it was co-opted to be service as in web service.
Had it been called Daemon Oriented Architecture things may have turned out differently.
The same thing is playing out now with micro services.
That assertion makes no sense as SOA is a software architecture approach and the communication between services has no impact on the system's architecture.
For all it's highly proscribed, heavyweight, over-engineered approach, SOA could have succeeded if the focus of implementations been on the semantic coupling problem.
Sadly, I see little evidence that the majority of the current crop of technologists have learned this lesson (irrespective of the technology choices).
http://www.lhotka.net/weblog/SemanticCouplingTheElephantInTh...
As far as I know, SOA means "safe operating area", and I have no idea how the hell this pertains to anything they're discussing.
Google tells me SOA probably means "service oriented architecture" (or the "society of actuaries"), but geez.
The definition is written out in the final section of the linked page. These were originally separate blog posts, so I assume the author got some feedback on this and decided to spell it out finally.
"SOA" means "microservices for Gen X'ers".
"Microservices" means "SOA for millenials".
I don't know what Baby Boomers called it.
CORBA