It’s likely you don’t need microservices if you go by ‘best ‘practices’ definition (as in — as ‘micro’ as possible, keeping to a certain single responsibility paradigm).

But … multiple services can be a rewarding architecture if you don’t go too extreme.

“Is your application large enough to be broken down to Microservices?”

• that’s an irrelevant question. Size alone isn’t a factor in itself. Can you identify reasonably self contained responsibilities for which it would make sense to break away is a better question, with the caveat that “it would make sense” can have one or more factors depending on your situation ,environment, etc.

“Do you really need to scale Individual components of the Application”

• valid question, but I found that scaling is but a bonus in other circumstances revolving around the previously mentioned “it makes sense”

“Do you have transactions spanned across services?”

• probably the best question and to overcome this in a meaningful way that is justified by tangible benefits you need a lot in terms of environment, knowledge and of course requirements
• Just one observation: “REST services are stateless by definition. And they shouldn’t be participating in transactions where the boundary exceeds more than a single service” — well, they are stateless, but why shouldn’t they participate in such transactions? The service is defined by a performed operation but on the other end there can be stateful service (like a DB), while a logical transaction of the system may involve several such services and intermediaries may be restful. Sure, you do have the challenge of consistency and assuming a large enough system, the idea of a rollback becomes necessity and with it comes a lot of responsibility.

And the rest of the points you make are good, but they are challenges rather than reasons against. The question is whether a potential microservice environment brings one or more of those challenges and whether is it worth it to take it on.

I can give a nice situation I was in where the solution for a new project was built around several interconnected services. Not microservices “by the book” but more like a monolith-ish application served by several services with a clear domain (communication: sms + email, payment and an internal messaging broken). The main reason wasn’t a need to scale or anything but more the ability to leverage knowledge in the company (eg: some services were python, other in java and others in go — we wanted to keep clear of a large application that would lock in people of a certain skillset). The ecosystem was small enough that a fairly basic monitoring solution was enough, no dedicated devops team was needed, the automated CI/CD pipeline was built 2 years ago and since then it needed light touches and regular updates, sure (something like 1–2 man weeks a year)