Comment by slad | Hacker News Reader

Comment by slad | Hacker News Reader

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.

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.

I don't think the number of users has as much to do with partitioning a system as the variety of required tasks does.

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.

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

Don't forget POJSON services lol!

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?

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

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

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

Reply on news.ycombinator.com