[pelasaco]

And maintenence and onboarding.. I guess to find the right balance is the key. I tend to go with monolith and use microservices to offload heavy dutie tasks or to benefit from other languages and framework when they are a better fit for a specific problem domain

[arp242]

That doesn't sound like "microservices", but like a monolith with a few services split out where it makes sense. People have been doing that for a million years, long before the web and certainly long before "microservices" was coined. It's just "using common sense" basically.

[pelasaco]

I'm not aware of such nuanced definitions. For me a microservice is a one endpoint service, designed to do one task, with full introspection, and deployed on the "cloud". As fair as I know, I can orchestrate them with monoliths and they still microservices.. or where you draw the line between services and microservices? The size of the service itself or with whom it interacts?

[arp242]

There is no One True Definition™, but I think most people understand "microservices" as "an application where splitting the functionality up in small services is core of the architecture", or something along those lines.

"We split off 2 things in to small services because it made sense" is rather different. I mean, I don't really care if you call this 'microservices" I guess, but it is different, right?

[antupis]

yup, monolith goes very long only to the point where you have hundreds of engineers or some very specific niche technical problem that I would start thinking about microservices.