> Definitely agree you shouldn't start with a ton of services, but I think you should definitely start with more than one. The jump from monolith to service-oriented thinking is a huge one.

I can't get my head around this.

Why should you start with more than one?

What is so different about "breaking your application into services" and "breaking your your application into appropriate modules / classes"?

If those need to scale then you should have an interface that you can expand to a micro-service.

As another poster said "It just replaces internal calls between services of your monolith with flaky and slower network calls. "

I've been doing enterprise software and SOA too long. I don't develop programs, I develop 'systems.' So, I tend to see a service where a normal person would see a module.

I work in defense, where software systems tend to stay in service for a very long time... It is very, very hard to keep a monolith from turning into a big ball of mud after it's handed off to O&M. Very often a different company will be awarded the contract to maintain a system you developed (and it may change hands more than once), and they will strive to do the absolute minimum possible to keep the software functioning until it is retired (which is always at least 10 years longer than anyone planned).

It's a form of https://en.wikipedia.org/wiki/Zero_one_infinity_rule; by starting with two, you're already at "infinity", and it's easier to go from there than it is to transition from 0-1 or from 1-infinity.

What is different about breaking an application into services is that because services run as different processes: * you have an immediate natural failure domain (the process) as well as resource isolation between services, * services can be updated independently (something that is done many thousands of times every day at companies like Amazon or Google), * a corollary of independent updates is that services can be tested independently and new code can be "canaried" by initially deploying only a single instance of a service.

The statement that service orientation "... just replaces internal calls between services of your monolith with flaky and slower network calls" is correct in that network calls are flaky and slower but incorrect in its assessment that you gain nothing from using services.

I'll give you that you can deploy services separately, but the other advantages that you give could be accomplished with automated testing - that's kind of the point in unit testing to test components independently.

The vast majority of people aren't working at Amazon or Google's scale despite developers seeming to think that they need to work the same way.

In theory, translating an interface-based monolith to a SOA should be straightforward - drop-in some replacement classes for your services and you're good to go.

In practice, it's not as simple as that. Serialization across service boundaries requires a bit of thought - invoking a method via a local call stack can accidentally cause a blowout on an SOA service buffer. Network timeouts suddenly become a thing. Latency might be an issue.

Of course, these aren't critical obstacles, and I agree that the architecture should look very similar, no matter whether it's a monolith or microservice. But designing one from the ground up would look a bit different.