Monoliths? 🤔😏

You don't need microservices until you have a lot of customers/users.

99% of the time monolithic application will work just fine with thousands or even hudreds of thousands users. So instead of thinking about structuring, infrastructure and management of microservices, it's just no brainer to build monolith for small teams or solo developers.

If you are an Indie hacker and are approaching an MVP or initial launch with anything other than monolith, you are over-engineering your product and are now in analysis paralysis mode (been there MANY times). As you scale, use the stranger pattern to breakout high throughput areas and bottlenecks.
https://dzone.com/articles/monolith-to-microservices-using-the-strangler-patt

We built our SaaS over the years, from the ground up, purely to meet the requirements of our customers. As we got more users, and they asked for more features, we built them into the app.

End result is a huge monolith app, surrounded by a few microservices for particular features.

By far, the highest maintenance and uptime headache are for the microservices, on a 10 to 1 basis. The monolith part basically just hums away, day after day.

Monoliths are a big plus one for me as an indie hacker. At work on big projects, microservices have their place.

Tooling, deployments, restraints all grow exponentially as we add services. That's fine when there's engineers to throw at the issue but as an indie hacker with only so many hours a week keeping constrained is the best idea.

For solo-developer projects, monolithic architectures are so much easier to manage. Fewer moving parts is the definition of simplicity.

Development environment, deployments, networking between services, code repositories, versioning, mental model—everything is easier with a monolith. (That doesn’t mean the domain is simple or easy, just the architecture is relatively easier.)

A micro services architecture solves problems that large teams and large-scale, complex applications face. You might get there and need something like that.

My general thinking is when you have at least a team per micro service and dedicated DevOps folks, then think about micro services. For solo-devs or small teams, use monolithic architectures with workers if you need them (background processing heavy/slow stuff on a queue).

Until you have a lot of users and you can benefit from scaling specific services on a day where you expect a high volume activity, I think monoliths do just fine.

The maintenance overhead of microservices is not really worth it for small businesses and especially IHs like us.

I actually wrote an article on my personal blog debating this, if you are interested: https://vladcalin.ro/blog/2021-01-04-microservices-for-a-startup .

But to summarize, when starting a new project you should always start with a monolith architecture, and split into microservices as you go, after your requirements become more set in stone. The most important issue for microservices is data partition, because you will have some pieces of information that will always be needed together with other piece of information, so they would need to live inside the same database/api.

Another thing is, the main reason microservice based archictecture appeared is because you can scale a monolith vertically and horizontally, but you'll reach a limit eventually with the database. So it solves scalability, but until you have that problem, there is no reason to over complicate with massively distributed systems.

A web server (with some replicas if necessary) + some workers should take anybody far enough.

I build all of my sites with Python/Django so I am a fan of the monolith. The big distributed systems are for the super large companies with millions of visitors a day. I don't ever plan on getting anywhere near that so the simplicity of the monolith is huge. I have a full time job, a wife, and a daughter. I need something that is simple and allows me to build things as quick as possible during whatever free time I can scrounge up.

Tradeoffs depend clearly on the size. Considering the probabilities of most startups and indie hackers out there (not to mention that most indie hackers want to remain at a manageable size) monoliths offer less complexity and a proven way that previously have worked.

I consider myself very average, and I don't plan to storm the tech world. Just to create a profitable company been an indie hacker with moderate aspirations. I see out there plenty of good business using the monolithic approach. Considering that (in my case Rails) take care of huge amount of edge cases that I couldn't event think of, I'm going that way.

The deal usually is around cohesion vs distributed independence and to even have that discussion you should probably be running a shop of over 10 probably at least 20 developers. Or across some big technical divides.
If not your just not having the scaling problem, so anything just works.

Interesting to not see anyone here mention a clear delineation between types of services/applications. For example, I have 3x different "services" but they basically all share code:

• Frontend, in Svelte. Completely separate from the backend API.
• Backend, in Rails, with Rails API.
• Mobile, in Flutter, to target Android + iOS simultaneously.

The nice thing is with the frontend, I can completely change to Vue/React/Or whatever the flavor of the week is, easily, and without regard to anything on the backend.

With the backend, I can do the same and both the frontend and mobile will keep working so long as my API signatures remain the same.

For mobile, it's nice to have an app, but then also to be able share code for both the big two ecosystems.

Did this slow me down at all? To make anything on mobile, sure, after the MVP. But I built my frontend mobile friendly first, so it's not any slower than just getting to the MVP as is. Splitting the frontend and backend is probably one of the best things I've done, and will always continue to do moving forward.

I have seen microservices gone wrong so many times... I'm all for building a monolith and splitting the pieces that would benefit from being a microservice, only when they start to bottleneck.

Every architecture style has its own pros and cons, so it really depends on the scale you have.

Have you ever heard of a modular monolith approach? In most cases, if possible I follow it.

Coming from a full-time software engineer here too, I have dabled in almost every style. Personally, everyone says go monolith until you need to break it down and can spend the resources doing so - as a startup, basically ignore most tech debt until you have to.

Hell, most of us do that everday anyways because it doesn't make the company more money to chip away at that tech debt.

Now, I personally think, if you are technologically savvy enough or have a founder who is, go for a serverless approach. Slap your CRUD into lambdas and call it a day. There is a learning curve but man does it not make it simple.

I personally run Just Pick Something in a monorepo and it's great. I can change the API while I am working on the admin website or the native app. Most of our backend is DynamoDb with a Neo4j instance running for our recommendations - all spun up via serverless and using AWS's AppSync for GraphQL and running what needs to be run via Lambdas.

Basically, have a lot of experience and knowledge gained over the years and countless iterations, you tend to find what works for you and/or your team.

I will leave you with this - just get it working. Focus on validating the idea and getting that early feedback, tech will figure itself out along the way.

This is a really good question and I love all the responses here so far. Totally agree that micro services are a good pattern for large, multi-team/department companies. I think the simplicity of a monolith can't be beaten for most companies and that micro services are something you transition to when you need to resolve specific problems.

A monolith coupled with jobs/queuing and even some serverless features will get you most of the way. Cloud training/staff is expensive and while it can provide great benefits it's a bit much when you're starting off.

The responses so far are music to my ears- for years i’ve been building monolith apps but in the back of my mind had an itch of “you should be doing this in micro-services!!”.
What has been said is so sensible I need to remind myself of it when that thought pops into my mind or even in a team discussion.
“What is the realistic need for micro-services?”

Monoliths are great until your 10 millionth customer.

I specifically built Nodewood to be a monolith-based web app framework, even down to allowing shared code between the front-end UI and the back-end API (the benefit of using JavaScript for both). I've worked at too many places that saw the benefits of microservices and ignored all the downsides and made the switch far, far too soon, and it just destroyed productivity.

If you're reading this site, it is far too soon to consider microservices. Start with a well-thought-out monolith, and build from there. You will save time, energy, stress, and money.