What actually happens, tough, is that (uninformed) people choose it because they think it brings them scalability (wrong), it's more cloud compatible (wrong) or the worst offender, it's more modern.
And "properly designed" is very hard to achieve.
It's often much more productive to start with a monolith and experience the pain of extracting a piece that needs horizontal scaling, than to start by horizontally scaling everything.
Microservices can be a good architecture, but it's far from a no-brainer, even for high scalability. Servers are incredibly fast these days and can typically scale very well vertically.
The "services" part makes a lot of sense in certain situations, and I feel like one of the best application architectures is what I call disconnected monoliths. Centralise and standardise core concerns - like authentication, external communications. Build monoliths for everything else.
Such as higher quality, higher "velocity", separation of concern and hopefully a clear sense of ownership.
These are some of the things in my opinion that allows you to scale.
> Such as higher quality, higher "velocity", separation of concern and hopefully a clear sense of ownership.
No, it means you pay a huge overhead. Quality and velocity both drop as your day-to-day development requires a lot more setup and faff to do anything, and counterintuitively so does separation of concerns as your interfaces become more rigid. Small organisations should do things that don't scale, turn their size into an advantage.
If you think of your overhead as ax + bx^2 where x is the number of developers, microservices are a way to reduce b, but at the cost of a big increase to a. It makes sense when x is huge but not before. My litmus test would be: do you need to do multiple (unrelated) deployments of different services at once? If your organisation is small enough that you can get away with only deploying one thing at a time, you'll probably have less overhead if you work without microservices.
This done right reduces overhead and gives you an edge in repeatability and quality. Both are required to scale.
Automation in this context is for me more than just the deploy bit, it’s also about testing and service management which includes for example service relationships and discovery.
If you could do local dev on that app as a monolith, it can most likely be done broken up in smaller services as well.
There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess.
It's possible, but the overhead is a lot higher, and that weighs down everything you do. Your edit-test cycle gets longer, development gets slower.
> There are no silver bullets to be had anywhere, right? Just use whatever processes and tools that work, until they don’t I guess.
Nothing is perfect but often one choice is better than another. I've seen microservices go badly much more often than monoliths, and most successful microservice systems were built as a monolith first with services separated out only when it became necessary.
Regarding monolith -> ms — I’m starting to think this is the way to do it — once you have the flow of data already estblished and the (working) system(s) somewhat defined it becomes easier to decouple bits and pieces.
I think microservice architectures can genuinely decouple teams to iterate faster and consolidate efforts. But it's not a free lunch.
What I was trying to say is that _if_ you go down the many services route, a lot of automation and integrations will be needed, and perhaps in completely new places.
No free lunches ever... just a lot of hard work. :)