Service-Oriented Architecture: Scaling Our Codebase As We Grow | Hacker News Reader

Service-Oriented Architecture: Scaling Our Codebase As We Grow

eng.uber.com

54 pointsrobzyb18 comments

Any sufficiently complicated distributed architecture contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of SOAP.

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.

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.

Indeed, I don't hate SOAP - it's a bit like Java - there is less wrong with the actual technology than you'd think and people can use it sanely. A culture problem more than a technology problem.

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.

> 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.

I don't know why this was downvoted; we're basically watching as the whole SOA/ESB movement from ten years ago is being reinvented today. If we aren't conscious of the mistakes made then, we'll repeat them again.

I've worked on classic WCF/SOAP/ESB systems, as well as the modern equivalent, and NServiceBus + REST beats absolutely everything from the old days, hands down. It's not even close.

Service buses are slightly orthogonal to the point - where do I get schema info for one of your REST endpoints? Looking at C# code? My experience of ESBs is that they provide some valuable technological decoupling, but don't free you from the coordinated governance that SOA should really deliver. Which is fine, because you obviously don't always need that.

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.

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.

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

So now I incur network latency for a method call that I could have made locally?

It could be modeled after the most largest, most successful system ever built. Standard protocols and APIs trump standard language/libraries every time.

In my experiences, standard language/libraries always lead to complex, tightly coupled, and fragile systems. It'd probably be better to require that any one language can't make up more than say.. a third of your system, so as to avoid accidentally falling into a bad architecture.

> It could be modeled after the most largest, most successful system ever built.

What system would that be? (The internet?)

> Standard protocols and APIs trump standard language/libraries every time.

These 2 things are completely orthogonal. You can have 2 services that are totally unrelated(by definition) yet use the same libraries for these different tasks.

> standard language/libraries always lead to complex, tightly coupled, and fragile systems.

Don't blame "standard libraries" when you should blame developers. Do you think developers that write these fragile systems will magically write better systems with all your apis and protocols ? do you think they will magically get the proper discipline ? no they won't. They'll write bad apis and bad services, which will be even harder to refactor.

I don't understand this need for "uber" complexity (no pun). It's obvious that the more languages used the more complex an architecture is. Same with micro-services which are just about shifting cost from dev to ops. I guess it will take an entire new generation of developers to understand that, the one that will have to maintain all that mess...

> These 2 things are completely orthogonal.

Of course they are, yet I see people mix them up all the time and standardize on language/libraries when they mean to standardize on protocols and (having) APIs.

> ... just about shifting cost from dev to ops.

Yes. Dev is people, Ops is process. So by shifting the cost to Ops you are shifting it to something you can automate away.

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

Reply on news.ycombinator.com