My co-worker gave me the quote - "if you have more microservices than clients, you're doing it wrong". Not sure if it was original or not but makes sense to me.
Monolith First (2015)
21–30 of 82 posts
Re: Monolith First (2015)
#22[dead]
Re: Monolith First (2015)
#23Whenever this man write anything the cargo cults are flocking. That's totally okay as long as you are aware.
I recommend you to learn to think for yourself given the context you are in, along with the power and social dynamics of such.
Re: Monolith First (2015)
#24Re: Monolith First (2015)
#25I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact. Monoliths are simpler to understand, easier to run, and harder to break -…
Kind of side steps the fundamental scaling issue though.
In a banking app there will be more requests for the account balance than there are logins, but logins will likely take longer.
Your argument is more around who is allowed to touch which and who is responsible when it breaks, but not around one of the core reasons to choose microservices.
Re: Monolith First (2015)
#26I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact. Monoliths are simpler to understand, easier to run, and harder to break -…
This 100%. Still depends on the specific context (e.g. what type of software are you going to build and run), but for a typical case, like web-based transactional self-service business platforms, this is where I arrived after more than 25 years in the industry.
Re: Monolith First (2015)
#27I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact. Monoliths are simpler to understand, easier to run, and harder to break -…
Kind of side steps the fundamental scaling issue though. In a banking app there will be more requests for the account balance than there are logins, but logins will likely take longer. Your argument is more around who is allowed to touch which and who is responsible when it breaks, but not around one of the core reasons to choose microservices.
You scale the whole thing. There's no issue at all.
Re: Monolith First (2015)
#28I firmly believe that monolith vs microservice is much more a company organization problem than a tech problem. Organize your code boundaries similar to your team boundaries, so that individuals and teams can move fast in appropriate isolation from each other, but with understandable, agreeable contracts/boundaries where they need to interact. Monoliths are simpler to understand, easier to run, and harder to break -…
This is also my experience.
It's always that projects grow large in terms of people working on them and that is when you want to create independence between teams by reducing the amount of cooperation needed on a very defined boundary/interface between them.
Usually you start small and grow bigger, so there is only rare exceptions where it makes sense to merge microservices back into a monolith, except maybe for cases where going for a microservice architecture was a bad decision taken without actually having the above mentioned problem.
Re: Monolith First (2015)
#29Recently was looking at a distributed microservice system at a company that thought they would need massive scale, but pivoted from d2c to enterprise b2b and then found out enterprise b2b companies want data separation. They would have been much better off going monolith first and probably actually sticking with a monolith.
You mean it's easier to shard databases per tenant when it's a monolith?
Data separation in enterprise-land means customers don’t want components that touch their data to be shared with any other customers. So a shared but sharded database is no good. In practice you often run a standalone stack for each customer, including their own database. This pattern is a nightmare from an operational scaling perspective, but that’s part of why enterprises are asked to pay so much.
Re: Monolith First (2015)
#30Earlier quoted context omitted.
A monolith is not a single microservice.
Any arguments to support this claim? What's the difference then? If there is three communicating servces: first has 90% of the business logic, second has 7%, and the last one has 3%. Should we call the first one a monolith? And if they don't communicate?
You can have a single codebase, deployed in multiple kind of configurations
One code, multiple roles