
Service-Oriented Architecture: Scaling Our Codebase As We Grow - robzyb
https://eng.uber.com/soa/
======
thom
Any sufficiently complicated distributed architecture contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of SOAP.

~~~
arethuza
I must admit that having been through multiple generations of tools and
approaches to support distributed programming - ONC RPC, CORBA, SOAP and now
REST the one I liked least was SOAP - largely as it seems to favor initial
ease of use (particularly in tools like Visual Studio) than long term
operational support and ease of debugging.

Interesting to see that they had started using JSON Schema for specifying
documents in a RESTful world - I've just started that myself and it seems to
work fairly well.

~~~
thom
Indeed, drag and drop SOAP/WSDL based on objects in your app never really gave
you a great API, just like randomly creating opaque REST endpoints never gives
you a great API. Most SOAP stacks are extremely well orchestrated, I'd be
interested to hear the specific operational and debugging issues you had.

Look, I'm not madly in love with SOAP and I don't intend to throw myself on a
bonfire of downvotes in its defence, but all the problems described in the
article have been solved for a long time, including the ones lamented at the
end - headers and authentication.

People are of course welcome to go to whatever lengths they like to have
complete control of their stack, I'd just hate to think it was because either
nobody in the room mentioned it, or that they wrote it off because it was
enterprisey.

~~~
brightball
Totally agree with you there. It's been kinda funny watching the popularity of
JSON grow while the world around it constantly spends time reinventing
everything around XML like schemas.

The biggest difference between REST and WSDL services just boiled down to
whether you were using a scripting language or a strongly typed language.
Strongly typed languages greatly benefited the extra schema details that WSDL
provided. Scripting languages didn't have to care so WSDL seemed bloated and
unnecessary.

It's only when you start running into all of the problems associated with SOA
that WSDL/SOAP already had solved that you truly start to appreciate the
original spec.

~~~
aikah
> Scripting languages didn't have to care so WSDL seemed bloated and
> unnecessary

This is an excellent point. And even a stronger point when one think about the
popularity JSON. There is very little advantage with using JSON with Java for
instance (architecture wise). XML,SOAP and co gets a lot of hate today.

And it's funny how people are now reinventing the wheel with GraphQL and co
... when all that is needed has already been invented but for some religious
reasons devs refuse to take advantage of it.

------
aantix
500 services? Any choice of language? I can only imagine how much logic
repeated amongst these services because "fuckit, I need this module over here
and there's no great way to share it amongst all of these languages/services,
so let's just copy/paste".

This sounds more like the wild wild west of coding and less of an
architecture.

~~~
outworlder
The fact that they CAN technically use any language, doesn't mean the new hire
is going to start implementing a new service in brainfuck on day one.

In addition, if they are services, and you need some logic that's implemented
in another service, why don't you, like, call it, instead of copy/paste? It's
what services are for.

~~~
eikenberry
+1. Services, not libraries. Standard libraries turn micro-services into
components.

------
eva1984
They discovered that SOA is the remedy, and will begin to use Thrift, well in
later half of 2015.

