4 ms·

Service-Oriented Architecture: Scaling Our Codebase As We Grow

54 points by robzyb 11y ago

thom 11y ago
Any sufficiently complicated distributed architecture contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of SOAP.
- arethuza 11y ago
  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 11y ago
    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.
    - arethuza 11y ago
      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.
    - brightball 11y ago
      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 11y ago
        > 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.
- tokenrove 11y ago
  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.
  - InvisibleCities 11y ago
    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.
    - thom 11y ago
      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.
eva1984 11y ago
They discovered that SOA is the remedy, and will begin to use Thrift, well in later half of 2015.
aantix 11y ago
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.
- eikenberry 11y ago
  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.
  - morgante 11y ago
    > It could be modeled after the most largest, most successful system ever built. What system would that be? (The internet?)
  - aikah 11y ago
    > 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...

54 points by robzyb 11y ago

thom 11y ago

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

arethuza 11y ago
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 11y ago
  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.
  - arethuza 11y ago
    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.
  - brightball 11y ago
    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 11y ago
      > 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.
tokenrove 11y ago
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.
- InvisibleCities 11y ago
  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.
  - thom 11y ago
    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.

eva1984 11y ago

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

aantix 11y ago

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.

eikenberry 11y ago
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.
- morgante 11y ago
  > It could be modeled after the most largest, most successful system ever built. What system would that be? (The internet?)
- aikah 11y ago
  > 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...