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.
The reality is, as always, “it depends”.
If you’re a smaller team that needs to do shit real fast, a monolith is probably your best bet.
Do you have hundreds of devs working on the same platform? Maybe intelligently breaking out your domains into distinct services makes sense so your team doesn’t get bogged down.
And in the middle of the spectrum you have modular domain centric monoliths, monorepo multi-service stuff, etc.
It’s a game of tradeoffs and what fits best for your situation depends on your needs and challenges. Often going with an imperfect shared technical vision is better than a disjointed but “state of the art” approach.
Thanks for your excellent response. The way these two sides were talking it seemed like there is no actual middle ground. But from what you say there actually is.
Tech people tend to be very black-and-white when discussing ideology. Reality is more forgiving.
If you can get your hands on it, the opening chapters of “Practical Event Driven Microservices Architecture” by Hugo Rocha gives a reasonable high level view of when you might decide to break a domain out of a monolith. I wouldn’t exactly consider it the holy grail of technical reading, but he does a good job explaining the pros and cons of monolith v microservices and a bit of exploration on those middle grounds.
Cool! I will check that out for sure, if it’s available easily.
Online discussions tend to be very polarising.
Nothing special about this topic, but something you should always keep in mind about any topic.
Very true, but this was a real life discussion.
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.
Only a Sith would deal in absolutes. Same goes in programming. Microservices have their benefits . So do monoliths. Neither is going away in the foreseeable future.
Safest bet is probably to do monoliths first. Use microservices once it makes sense.
I mean, I like complete microservices in principal, but I think they design of your software and organization, its style of operating, size, and budget all play into the decision. I think the issue lies in presenting it as a binary rather than a spectrum. You can have something that is largely a monolith, but some bits of it are split out into microservices. The opposite is true as well.
My company tried to do the “microservice all of the things” approach and we’re already back to combining a handful, but definitely not back to one monolithic app.
I would say service-oriented is definitely but sometimes microservices are more trouble than they’re worth. They scale well but can be overengineering for smaller scale applications. And like Donald Knuth says: “premature optimization is cringe”
There’s a spectrum between architecture/planning/design and “premature optimization.” Using microservices in anticipation of a need for scaling isn’t premature optimization, it’s just design.
I mean, if anything, I would say microservices are the present.
As assaultpotato said, horses for courses, but I mean, microservices aren’t really a new concept at this point.
Sure, but are they the future? At this point there is some microservices oriented software available, but still plenty of monoliths as well.
Are the monoliths dying and microservices the only way forward? Or is there always going to be a balance? Or will microservices turn out to be only worth it in very few cases and become niche?
I guess what I’m saying is that I think things will generally stay balanced the way they are. Monoliths are never going to completely die out, and neither are microservices.
They both serve different functions, so there’s no reason to think one will “win” over the other.
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.
I have the unpopular user’s opinion that I expect transparency in my connections and interactions. I won’t use any commercial websites that have ambiguous connections on a whitelist firewall. I expect all businesses to operate like a brick and mortar store in real life. If I enter a grocery store, I’m not entering a bank, a bookstore, and a restaurant to purchase an apple, nor am I selling or giving up any part of my autonomy in my quest to satisfy my fundamental needs.
Personally, in my opinion alone, I view any business that is not transparent and straight forward about who and what I am dealing with as illegitimate and untrustworthy. I view it like inviting someone to a house party that then goes to the bathroom, opens the window, and lets other people enter my home. Or like a retail store that adds a bunch of hidden fees to their products because of something like various distributor logistics costs; stuff that belongs in the back office accounting of running a legitimate business. To me, the practice feels wrong because the default state of the internet being theft of individual autonomy with no freedom of information from determinism. I must assume that everyone is stalkerware, so I must be selective about who I enable in such a system. Micro services remove all accountability and make the problem of digital autonomy exponentially worse in the cases where they are exposed to the end user (data).
I don’t know how common my attitude is, but the only one I pay is for iCloud storage. I will find an app with a one off payment or nothing
No.
