Serious question. I know there are a lot of memes about microservices, both advocating and against it. And jokes from devs who go and turn monoliths into microservices and then back again. For my line of work it isn't all that relevant, but a discussion I heard today made me wonder.
There were two camps in this discussion. One side said microservices are the future, all big companies are moving towards it, the entire industry is moving towards it. In their view, if it wasn't Mach architecture, it wasn't valid software. In their world both software they made themselves and software bought or licensed (SaaS) externally should be all microservices, api first, cloud-native and headless. The other camp said it was foolish to think this is actually what's happening in the industry and depending on where you look microservices are actually abandoned instead of moving towards. By demanding all software to be like this you are limiting what there is on offer. Furthermore the total cost of operation would be higher and connecting everything together in a coherent way is a nightmare. Instead of gaining flexibility, one can actually lose flexibility because changing interfaces could be very hard or even impossible with software not fully under your own control. They argued a lot of the benefits are only slight or even nonexistent and not required in the current age of day.
They asked what I thought and I had to confess I didn't really have an answer for them. I don't know what the industry is doing and I think whether or not to use microservices is highly dependent on the situation. I don't know if there is a universal answer.
Do you guys have any good thoughts on this? Are microservices the future, or just a fad which needs to be forgotten ASAP.
No. They're the "right now".
The future will be something else.
Have to keep changing it. No idea why, but it keeps us employed, so c'est la vie.
I find small services work fine for well defined and context free tasks. For example, say you have common tasks like handling user authorization, PDF generation, etc. Having a common service to handle that is a good idea. This sort of a service bus can be leveraged by different apps that can focus on their business logic, and leverage common functionality.
However, anything that's part of a common workflow and has shared state is much better handled within a single application. Splitting things out into services creates a ton of overhead, and doesn't actually address any problems since you have to be able to reason about the entirety of the workflow anyways. You end up having a much more difficult development process where you need a bunch of services running. Doing API calls means having to add endpoints, do authentication, etc. where within a single app you just do a function call. Debugging and tracing becomes a lot more difficult, and so on.
My take is that pretty much everything should start out as a monolith and evolve organically from there. You will know if/when you need a separate service.
