They don’t NEED to

It will be made so trivial to do so it will be impossible to avoid it

Medium will be awash in howtos, github will have 9,000 CLI tools to generate yml templates for all this shit

Nothing stopping us from taking advantage of this and building local hosted Docker/Kube setups importing from github what they need to run private social media portals for friends and family, with dynamic DNS and other tools for finding each other

Microservices are for scaling development teams. They're not inherently better to maintain.

You just can't reliably work on one artifact with dozens of people without creating a lot of complexity, this is why microservice architectures can be better in some cases.

If you're not going to increase the development team beyond a single smallish group of people, you'll be much more productive and your service will be way faster as a monolith.

I'm pretty sure most SaaS companies want to scale their development teams, so it's basically a given that most want to use microservices as well.

Individual microservices are definitely easier to maintain than a monolith. Ever experience a big ball of mud? Every monolith I've worked with, turned into one.

Sounds like you are arguing that for small teams a monolith is better. No one would argue that they are not. If you read my post, I talked about business that become a SUCCESS meaning that they grow beyond that initial small team. Once your team becomes large, if you started with a monolith, you will eventually need to either break it apart into microservices or try to manage the monolith across many teams.

IF microservices could be as easy to develop from day 1 as a monolith, why would you start with a monolith? Isn't that what technologies like Dapr are trying to do? Make developing microservices easier?

> Individual microservices are definitely easier to maintain than a monolith. Ever experience a big ball of mud? Every monolith I've worked with, turned into one.

Can we just create a Visual Studio extension that allows you to pretend the various components of your software are "microservices"?

"Sorry, you're trying to stuff too much functionality into your XYZ class. You'll need to break it off into another class if you want the Pseudo-Microservice plugin not to complain."

Too much functionality in your XYZ class is not generally the problem. Its the dependencies between the classes and the way the frameworks (looking at you spring and hibernate) can make it too easy to couple your code via transactions, ORM graphs, etc.

All modern ides analyse dependencies. Spagheti is usually built when there are too many people working on one project. Microservices is to scale people, no need for microservices when your company has very few employees.

This is an engineering argument that's disguised as a business argument. In reality a monolith had way less overhead when starting a new product or business and makes a lot more sense than sinking resources into something that isn't even needed at the time. Not to mention that from an engineering standpoint you can't even know for certain which components need to be broken out onto a microservice without the evidence of traffic.

Following your logic to its ultimate conclusion, you may as well also over-hire on staff, get a super expensive office, crazy benefits packages, etc. Why not? You dont need that stuff if you think your business will eventually fail.

If you read my post I never argued against starting out with a monolith. Of course they have lower overhead. I argued that if your successful like say Twitter, then you will eventually have a problem with your system all tied together in a monolith.

> Its extremely difficult to change a monolith to microservices

I beg to differ. It's completely straightforward, for the most part. You split them out, one by one. That's a big part of the reason for its popularity.

If it's really that difficult, maybe it's not a great fit for the problem at hand.

No, the problem is it can be extremely easy to break services into microservices, especially using the slick tools I've seen in Azure (I'm sure other providers have them as well). They just work, and they're cheap!

But then you realize debugging and refactoring is way harder, and you aren't getting any real benefits from splitting things apart like that.

OK agree to disagree then. I spent a year on a team trying to break a monolith into microservices generally we failed. We ended up with microfrankenservices that had no clear seams. Problem is generally the state gets mixed up throughout the app. Unrelated entities participating in the same transaction for example. References to domain objects everywhere in the monolith.

The first developer (who was fired) of the startup I am working for exactly presented this arguments. Not having any experience in developing and maintaining any real system and reading some consultants' blog he was confident that the microservice architecture will solve all the problems. The product got delayed by months, extremely buggy and (god knows why) it was an asynchronous architecture (the front-end would have to poll for basic CRUD operation). This costed us losing a big customer.

If you are starting out, please make sure the complexity and development overhead for a microservice is worth it. Don't listen to hypes.

The system you build initially when you're not exactly sure how your product or business are going to work should definitely not be the system that you then take and "scale up" to 100+ developers. Any expectation of doing that is foolhardy and a sure recipe for never emerging from the tarpit of microservice complexity.

What on earth makes people think the responsibility divisions they make on day 1 are going to be the right responsibility divisions further down the line? Transplanting parts of your data model across boundaries is a complex and painful job.