Automated deployment and the like is worthwhile whether your system is microservice or monolith. But no amount of automation can eliminate the overhead a network boundary brings to local development.
We view this a bit different, and that’s fine (not the automation part, here we agree).
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.
> 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.
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.
Yes, there is bound to be overhead as you describe.
For some it might be worth the effort, but no doubt effort is involved.
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.
In think your interlocutor's point is that type checking by a compiler is a lot simpler, more reliable and more performant than any networked service discovery scheme so far conceived.
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. :)
