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.

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 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 think micro services are useful if you need to scale your application parts independently from other parts.

But I think now everyone uses micro services because it fulfills the developer dreams of being able to write code independently, and have it run on your computer inside docker.

So using docker is probably the best part about micro services. The downside of all this is the extra complexity in having them talk to eachother and that is the difficult part. When everything goes over the network and is async, you run into lots of potential error scenarios that must be handled. And each call is a million times slower compared to local.

It's not the future. It's just a tech trend and it will be something else in a few years. Tech never stays the same for very long.

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"

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.

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.

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

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).

No.