I somewhat agree but I find that the added complexity is segmented, you shouldn’t need to care about anything but the contracts themselves when working within a micro service.
That means less code to take into account, less spaghetti and an easier time with local testing.
Micro services also have a ton of advantages at the infrastructure level.
Imo if your doing it right your monolith is also broken up into chunks that are segmented with clear defined apis and well tested (apis in this context are whatever your public functions/method/top level objects). With clean internal apis and properly segmented code it should be easy to read and do what you need.
I don’t know if I agree with the infra level. What makes you say it has advantages there?
Biggest two advantages to micro services in my mind is you can use different tools / languages for different jobs and making it easier for multiple teams to work in parallel. Two biggest disadvantages in my mind is you lose code sharing and services become more siloded to different teams which can make it more difficult to roll out changes that need multiple services updated.
There is also the messaging problem with micro services. Message passing through the network rather then in memory. (Ex calling the user_service object vs user_service micro service)
One other big disadvantage of a monolith I also can think of is build time and developer tools can struggle with them. A lot more files/objects to keep track of and it can often make for an annoying development flow.
My preference is to monolith most things and only split off something into a micro service if you really get a big benefit from another tool or language for a specific task.
Micro services are a lot easier to scale out since they behave independently from each other, you can have different levels of replication and concurrency based on the traffic that each part of your system receives.
Something that I think is pretty huge is that, done right, you end up with a bunch of smaller databases, meaning you can save a lot of money by having different levels of security and replication depending on how sensitive the data is.
This last part also helps with data residency issues, which is becoming a pretty big deal for the EU.
Something to consider is a monolith can have different entry points and a focused area of work. Like my web application monolith can also have email workers, and background job processers all with different container specs and scaling but share a code base.
And coming from a background where I work heavily with Postgres a bunch of smaller segregates databases sound like a nightmare data integerity wise. Although I’m sure it can be done cleanly there are big advantages with having all your tables in one database.
Exactly! Monoliths can work in theory but, in practice, end up becoming bloated messes since it’s just easier to do so.
And in practice micro services become a fragile mess and takes longer to develop new products due to low code share and higher complexity.
Ofc not always the case, just like large monoliths can exist without being a mess.
I somewhat agree but I find that the added complexity is segmented, you shouldn’t need to care about anything but the contracts themselves when working within a micro service.
That means less code to take into account, less spaghetti and an easier time with local testing.
Micro services also have a ton of advantages at the infrastructure level.
Imo if your doing it right your monolith is also broken up into chunks that are segmented with clear defined apis and well tested (apis in this context are whatever your public functions/method/top level objects). With clean internal apis and properly segmented code it should be easy to read and do what you need.
I don’t know if I agree with the infra level. What makes you say it has advantages there?
Biggest two advantages to micro services in my mind is you can use different tools / languages for different jobs and making it easier for multiple teams to work in parallel. Two biggest disadvantages in my mind is you lose code sharing and services become more siloded to different teams which can make it more difficult to roll out changes that need multiple services updated.
There is also the messaging problem with micro services. Message passing through the network rather then in memory. (Ex calling the user_service object vs user_service micro service)
One other big disadvantage of a monolith I also can think of is build time and developer tools can struggle with them. A lot more files/objects to keep track of and it can often make for an annoying development flow.
My preference is to monolith most things and only split off something into a micro service if you really get a big benefit from another tool or language for a specific task.
Micro services are a lot easier to scale out since they behave independently from each other, you can have different levels of replication and concurrency based on the traffic that each part of your system receives.
Something that I think is pretty huge is that, done right, you end up with a bunch of smaller databases, meaning you can save a lot of money by having different levels of security and replication depending on how sensitive the data is.
This last part also helps with data residency issues, which is becoming a pretty big deal for the EU.
Something to consider is a monolith can have different entry points and a focused area of work. Like my web application monolith can also have email workers, and background job processers all with different container specs and scaling but share a code base.
And coming from a background where I work heavily with Postgres a bunch of smaller segregates databases sound like a nightmare data integerity wise. Although I’m sure it can be done cleanly there are big advantages with having all your tables in one database.
I see, I’m definitely biased towards micro services after years of dealing with horribly made monoliths but I see what you mean.
At the end of the day I think both approaches have pros and cons.