4 ms·

I have worked at several companies with SOA. In fact, I was lead at one of the companies where we were breaking monolith to smaller services. We were having lot

by slad 6y ago

I have worked at several companies with SOA. In fact, I was lead at one of the companies where we were breaking monolith to smaller services. We were having lots of issues with scalability with monolith. First we tried breaking to scale it horizontally by creating shards and routing users to different shards. That helped but with the growth we were seeing, we were back to scaling issue in 14 months. We broke it further into 4 shards and started working on SOA. After year and half we had dozens of smaller services and scaling was really smaller problem as it boiled down to scaling specific service. Over all, few points to add for without regards to SOA that I didn’t see here in threads - - smaller blast radius: every change is small and specific to service so easy to rollback and understand the impact - load tests: capacity management was relatively easy; small services with small dependencies - easier to update dependencies: java version updates was not huge project with every feature development on hold - autonomy: team had more autonomy as it didn’t require committee approvals - prolific design patterns: services could use different architectural patterns This obviously came with lot of other issues - latencies, cross service atomocity, logs correlation. But at the end I believe pros outweigh the cons and I would continue to use SOA pattern wherever I could. Industry has been trending towards microservices/lambdas which in my opinion take it too far. Finding that balance between Monolith and micro service is what works in my opinion.

bertjk 6y ago
In your opinion what is the difference between an SOA and microservice architecture? When does a microservice become just an SOA service or vice versa?
- mr_nobody 6y ago
  I think the biggest difference is as defined by Martin Fowler: " When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules. The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool." https://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes https://martinfowler.com/articles/microservices.html#SmartEn...
  - hackerfromthefu 6y ago
    Look this is a great answer, and I love Martin Fowler. That's one rational explanation. It may however be a rationalised explanation that misses out on the difference that makes a difference to understanding what's really going on. So here's another perspective, that of a software anthropologist .. . Common patterns of networked systems were developed over decades, and as it developed over decades it built various advanced features on top of the core network call/response features - service busses - routing - useful abstractions like decoupling services from host processes - propogating security contexts through the chains of service calls that can develop when these systems evolve - strong typing, which enabled layers of tooling to replace manually doing jobs with these systems and various advanced features. That was called SOA, because it looks at software architecture as a set of services. Then along came a bunch of programmers that weren't very studious, started from scratch just doing basic message passing without all the advanced features that had been built up by the decades of previous hard won lessons. That was called microservices. Note the removal of the 'architecture' from microservices! slightly /s
vkazanov 6y ago
I work at a company that uses a hybrid monolith/service approach to serve millions and millions and millions of users. Unless you work for one of the top-top-top social networks we probably serve many more users that your systems do. And even our existing services are not "micro": they are relatively large, and were mostly extracted to handle tasks that needed a different language. This massive code base is a very good example of how most people can do just fine with a monolith. I even learned to appreciate this uniform approach to things: monorepo, unified ci/cd process, shared responsibility.
- saberience 6y ago
  This comment shows an extreme naïveté. Just because at your anecdotal example, a monolith, works, it does not mean that it always works. There is a time and a place for every kind of design. There are many different kinds of applications and the number of users isn't the only factor when trying to understand the optimal architecture. In many cases you can have lots of users but what the application is doing is relatively simple, especially in terms of the data access patterns, state, etc. At other companies, they might have low numbers of users, but extreme requirements in terms of latency or data integrity (e.g. HFT applications or bank ledgers) Look for example at the requirements of Netflix (obviously lots of users) versus the requirements for Reddit (also lots of users). Both sites have high usage but have completely different use-cases and as such, their architectures will be radically different. I've also worked for a company with insanely high numbers of concurrent users (along with very sensitive latency requirements), and one where I'm sure performance was more critical than your systems, and we didn't use a monolith. There's no way that company could operate with a single monolith for the various products. Again, this is just an anecdote, just like yours, and just as meaningless.
  - vkazanov 6y ago
    Yes, sure, we need better definitions and a limited scope. I also don't think ppl would have a monolith vs numerous services discussion in HFT or MMO game development or a major search engine development context. It seems that we're talking about typical web apps, shared mobile app backends, etc. I believe that most code developed with this use-case in mind doesn't have to know anything outside of the usual 3 layers: client-side, server-side (aka "the monolith) and a database backend.
tannhaeuser 6y ago
It would appear to make sense to separate two things - a service as isolated business logic with clean requirements process, ownership, SLAs, interfaces, testing, and build infra for maintenance - a service as an endpoint you can access from most any environment (other services in whatever language, web apps) The trick is to keep these two things apart and assign services to physical/virtual nodes/pods/whatever as late as possible rather than making deployment decisions through choosing implementation techniques. Eg it's not reasonable to expect scalability by deploying individual services to a large number of nodes with excessive granularity of services; having the option to deploy a called service on the same host as the calling service to have essentially no network overhead might make more sense. It's also not reasonable to attempt to scale out services to a large number of nodes when your bottleneck is an RDBMS or other storage. This was already very clear with 2nd gen SOA architectures like SCA (service component architecture) around 2007 or so, with options for binding implementations to remote protocols (SOAP) or locally via procedure calls, or both at the same time. This separation is notably absent from microservice architectures which always want to produce a pod or vm image as result artifact. Now SOAP (and SCA and other SOA frameworks) also allowed transactions and auth context propagation; something that isn't even on the radar of microservice-like approaches. The (many) ones I saw at customers at least only naively implemented the happy path, not allowing for two-phase commit or at least compensation services to be called on abort by an aggregating service.
- hackerfromthefu 6y ago
  You are so right here. Clearly you worked with enterprise distributed systems and learned the industry body of knowledge for that - things like configuration driven binding 'services' to 'host processes', distributed transactions or compensation, auth propogation, and advanced tooling for distributed development enabled by strong typing. Alas most developers weren't aware of all these things that SOAP delivered. . Programming's Eternal September of the twenty first century has thrown the baby out with the bathwater - those unwashed masses didn't understand why SOAP was a wee bit complex, the very good reasons! They RESTed instead of scrubbing up on their studying. They twittered and twattered instead of studying. In their multitudes they cast a POX of JSON on our world! They weren't the strong silent type to refactor, to compensate and rollback their mistakes .. and that is why they renamed SOA to micro services .. to make the huge mess sound smaller than it really is .. /s okay okay I will get off my soapbox now
konschubert 6y ago
> - prolific design patterns: services could use different architectural patterns Very true. But there is still a lot of architecture that crosses microservice boundaries: How the domain is split, the dependency hierarchy (or lack thereof) between services, data lifecycles, ... It's important not to forget that.

by slad 6y ago

bertjk 6y ago

In your opinion what is the difference between an SOA and microservice architecture? When does a microservice become just an SOA service or vice versa?

mr_nobody 6y ago
I think the biggest difference is as defined by Martin Fowler: " When building communication structures between different processes, we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules. The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool." https://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes https://martinfowler.com/articles/microservices.html#SmartEn...
- hackerfromthefu 6y ago
  Look this is a great answer, and I love Martin Fowler. That's one rational explanation. It may however be a rationalised explanation that misses out on the difference that makes a difference to understanding what's really going on. So here's another perspective, that of a software anthropologist .. . Common patterns of networked systems were developed over decades, and as it developed over decades it built various advanced features on top of the core network call/response features - service busses - routing - useful abstractions like decoupling services from host processes - propogating security contexts through the chains of service calls that can develop when these systems evolve - strong typing, which enabled layers of tooling to replace manually doing jobs with these systems and various advanced features. That was called SOA, because it looks at software architecture as a set of services. Then along came a bunch of programmers that weren't very studious, started from scratch just doing basic message passing without all the advanced features that had been built up by the decades of previous hard won lessons. That was called microservices. Note the removal of the 'architecture' from microservices! slightly /s

vkazanov 6y ago

I work at a company that uses a hybrid monolith/service approach to serve millions and millions and millions of users. Unless you work for one of the top-top-top social networks we probably serve many more users that your systems do. And even our existing services are not "micro": they are relatively large, and were mostly extracted to handle tasks that needed a different language. This massive code base is a very good example of how most people can do just fine with a monolith. I even learned to appreciate this uniform approach to things: monorepo, unified ci/cd process, shared responsibility.

saberience 6y ago
This comment shows an extreme naïveté. Just because at your anecdotal example, a monolith, works, it does not mean that it always works. There is a time and a place for every kind of design. There are many different kinds of applications and the number of users isn't the only factor when trying to understand the optimal architecture. In many cases you can have lots of users but what the application is doing is relatively simple, especially in terms of the data access patterns, state, etc. At other companies, they might have low numbers of users, but extreme requirements in terms of latency or data integrity (e.g. HFT applications or bank ledgers) Look for example at the requirements of Netflix (obviously lots of users) versus the requirements for Reddit (also lots of users). Both sites have high usage but have completely different use-cases and as such, their architectures will be radically different. I've also worked for a company with insanely high numbers of concurrent users (along with very sensitive latency requirements), and one where I'm sure performance was more critical than your systems, and we didn't use a monolith. There's no way that company could operate with a single monolith for the various products. Again, this is just an anecdote, just like yours, and just as meaningless.
- vkazanov 6y ago
  Yes, sure, we need better definitions and a limited scope. I also don't think ppl would have a monolith vs numerous services discussion in HFT or MMO game development or a major search engine development context. It seems that we're talking about typical web apps, shared mobile app backends, etc. I believe that most code developed with this use-case in mind doesn't have to know anything outside of the usual 3 layers: client-side, server-side (aka "the monolith) and a database backend.

tannhaeuser 6y ago

It would appear to make sense to separate two things - a service as isolated business logic with clean requirements process, ownership, SLAs, interfaces, testing, and build infra for maintenance - a service as an endpoint you can access from most any environment (other services in whatever language, web apps) The trick is to keep these two things apart and assign services to physical/virtual nodes/pods/whatever as late as possible rather than making deployment decisions through choosing implementation techniques. Eg it's not reasonable to expect scalability by deploying individual services to a large number of nodes with excessive granularity of services; having the option to deploy a called service on the same host as the calling service to have essentially no network overhead might make more sense. It's also not reasonable to attempt to scale out services to a large number of nodes when your bottleneck is an RDBMS or other storage. This was already very clear with 2nd gen SOA architectures like SCA (service component architecture) around 2007 or so, with options for binding implementations to remote protocols (SOAP) or locally via procedure calls, or both at the same time. This separation is notably absent from microservice architectures which always want to produce a pod or vm image as result artifact. Now SOAP (and SCA and other SOA frameworks) also allowed transactions and auth context propagation; something that isn't even on the radar of microservice-like approaches. The (many) ones I saw at customers at least only naively implemented the happy path, not allowing for two-phase commit or at least compensation services to be called on abort by an aggregating service.

hackerfromthefu 6y ago
You are so right here. Clearly you worked with enterprise distributed systems and learned the industry body of knowledge for that - things like configuration driven binding 'services' to 'host processes', distributed transactions or compensation, auth propogation, and advanced tooling for distributed development enabled by strong typing. Alas most developers weren't aware of all these things that SOAP delivered. . Programming's Eternal September of the twenty first century has thrown the baby out with the bathwater - those unwashed masses didn't understand why SOAP was a wee bit complex, the very good reasons! They RESTed instead of scrubbing up on their studying. They twittered and twattered instead of studying. In their multitudes they cast a POX of JSON on our world! They weren't the strong silent type to refactor, to compensate and rollback their mistakes .. and that is why they renamed SOA to micro services .. to make the huge mess sound smaller than it really is .. /s okay okay I will get off my soapbox now

konschubert 6y ago

> - prolific design patterns: services could use different architectural patterns Very true. But there is still a lot of architecture that crosses microservice boundaries: How the domain is split, the dependency hierarchy (or lack thereof) between services, data lifecycles, ... It's important not to forget that.