When getting started, do you consider the overall architecture or just put out a MVP to test out the idea?
Microservices is an investment you can't afford to make in the early stages of product development. You'll spend more time building the architecture rather than the product.
A monolith will allow you to iterate fast and if you need to scale you can just spin up more instances from your cloud provider.
Once you have a (more) solid product and some more devs, then infrastructure/architecture becomes more important.
Just make sure to keep in mind that at some point you might have to split up the monolith. Maybe not everything at once, but extract services one by one.
The idea is to have as little coupling as possible between your features. Don't spend too much on keeping them separated though, just whenever you have a choice choose the way that would make it the easiest to remove/extract that feature at a later time.
Monolith, just get it done
Never microservices. 99% of the time you won't need them. Even if you grow very huge you can still use well designed monolith - e.g. StackOverflow is a great example.
But still you should consider good architecture/coding standards, so you can easily grow when your startup gets traction. So go with clean monolith 💪
Coming from an IT enterprise background I know both worlds.
From my point of view, architecture is always a bet on the future.
For example, a typical tiered architecture would pay off if at some point in the future you decide to replace one layer by a different one - e.g. you decide to replace the persistence layer by switching the database technology.
If all your database specific code is in one layer then you do not have to touch other layers.
The same is true for a microservice architecture, but here many architects slice code not into technical layers, but by contexts of business functionality - however, this is not the only criteria for defining boundaries between services, often rate of modifications, scalability and other criterias are taken into account as well. Therefore a microservice architecture is also a bet: A bet that the criteria by which you sliced your code into microservices keep stable. From my experience, it is pretty hard to predict the future, and therefore microservice architectures carry a significant overhead: You will always be adapting your services to match your expectations of the current future (=costs). Of course microservices have their advantages as well. When your development hits a specific size you have to introduce subteams. It is often easier to assign responsibilities in a microservice architecture.
To get started I would always go for the monolith, just as the others said: Building, deploying, testing and so forth will get much more complicated with a microservice approach. The most valuable thing you get at the beginning is feedback, and you get most feedback if you get your stuff released.
Microservices add value when big teams are working on different aspects of the same systems. When starting out that is not the case: the team is small, maybe even a solo developer.
I’d focus my effort on developing the product in a monolith rather than developing the infrastructure to support an hypothetical scale that you might not even ever reach.
It’s also worth noting that monoliths can (and should) be well organised and modular. With a bit of discipline you can get to a well organised monolith that gives you most of the benefits you would get from microservices
I considered both models and I didn't like both. So, I came to the intermediate architecture - monolith core with pluggable parts. But it was when I run my second version and the architecture was really important because the product is for developers.
If you try something that nobody actually cares about code, I would always suggest monolith as it's much easier to manage and develop.
My day job is working in enterprise IT so this is a question we deal with on a daily basis.
I agree with the other posters, for your MVP you really just want to prioritize getting something out there so you can start getting feedback.
It is very likely you will make lots changes and refactorings once that feedback starts coming in anyway
Besides that, one of the things I think of first when working with teams on their architecture is their change velocity and trying to organize services in such a way that they can quickly be changed, tested, and deployed without needed to slow down other teams.
For an Indie Hacker. you are probably a little ways off from having to worry about that. Once you start hitting scale, service architecture becomes much more critical.
Start with good code architecture.
Then if you need split to microservices you can do this by changing "infrastructure" part not business domain logic. Good architecture is better to scaling in case of "market fit".
It's better to focus on business logic than infrastructure part in my opinion.
*DDD - Read Eric Evans or Vernon books, on youtube you can check nice videos about (vernon channel)
Definitely monolith when you're just starting. Managing microservices has a non-zero cost in terms of time and skill, and one of the main reasons microservice architectures are popular is the flexibility in how an organization can develop and maintain them (e.g. different teams can develop them using the languages and technologies they know). When you're first starting it'll be a long time (if ever) before you get to the point of needing that flexibility, so there's no sense wasting your time on them.
On the other hand, under the right circumstances not all decisions need to be about getting something done as quickly as possible. If developing your app as a suite of microservices keeps you interested and moving forward and/or you want to gain experience developing and managing them (and you have the time to) then by all means go for it.
From my experience, I think it's easier to split monolith into microservices than set up the whole inftastructure from scratch.
You can do it when for example when your app can't handle the load anymore you can start from most highly used parts of your application etc.
I'm in agreement with the other commenters. Here's an article on the topic: https://nickjanetakis.com/blog/microservices-are-something-you-grow-into-not-begin-with
Never ever start with Microservices. Even when the argument can be made for a service orientated architecture (Read +100 devs employed) it's still a trade off.
When starting out it serves no purpose and you will likely rewrite the application on the road to employing that many devs anyway.
Start monolith, iterate to micro-services as your team grows and tech ownership becomes more isolated.
IMO starting with a micro-service architecture is a prime example of premature optimization.
In my experience, the best approach (for me) has always been to just put out the MVP to test a market. I say this as I used to do the opposite and have since learned my lessons (easy when you write software for a living).
There is a very little correlation between the software architecture and the success of MVP in early stage. Start with the one that you can build the fastest.
Definitely monolith, going micro services unless you really know what you're doing and have both, the budget and a huge software codebase to support is just a nightmare waiting to happen. Just Google it for micro service disasters.
Nextlix came out with micro services concept, now everyone thinks they're Netflix for some reason. It's a hype that's being pushed by incompetent developers and can easily turn into a nightmare for the business owner.
You should consider the overall architecture at the beginning, but the choices should be pretty high level. Basics like the database to use, the language and web framework for the backend, the choice of front-end framework (if any), the platform to host on, etc.
But absolutely do not do microservices from the get-go. They make basic things, like deployment, more complicated and only slow you down when you're starting off. Many companies start off with a monolith and break things out when they start running into problems. DigitalOcean just released a post describing part of their move from more monolithic services to Go microservices [1], which goes to show how far you can get even with a not so great architecture.
The biggest advice I have is that you break up separate domains into different modules with clear interfaces so that it's easier to break things up if you need to eventually. As an example from the DO post, it sounds like they didn't have a shared client library used to access the MySQL queue. If they had done that for the beginning, it would have been much easier to change the backed from MySQL to Rabbit because they could have updated the client library, bumped the version number, and made some config changes to have everyone upgrade.
Let me know if you have any questions or need clarification on something.
[1] https://blog.digitalocean.com/from-15-000-database-connections-to-under-100-digitaloceans-tale-of-tech-debt/
I also read the piece, and I agree with @Pentlander. I also wouldn't go for micro-services from the get go.
We're a group of part-time indie hackers with my friends. All of our backgrounds are different. We have a back-end developer, a data engineer, and 2 data scientists in our hacker team.
Since we all have different backgrounds, we're using different technologies in our daily life. For example:
Backend Developer uses PHP and Go,
Data Engineer uses Java and Python
Data Scientists use R and Python (and also SQL :) )
So, when we're developing an MVP, we first split the product and then use our favorite language for our part. (Of course, they're logically different modules in the product).
In our case, it's super-efficient to use microservices. Everyone is focusing on their own part.
It also helps us to be flexible. Let's say we need data manipulations. So we use a pandas repo with pandas for it.
Or, we found a Java package for a specific task. We just add it to our project and implement MVC quickly.