back
1 comments
Interesting read. I like the recent discussions on go microservices vs monoliths. There's certain limits to both, but also cool benefits on both ends.

tl;dr of my comment: I think expertise needed on the human side of things causes microservices to be apealing. nothing else. but this is a big (cost) factor and cannot be ignored.

As for the article 1. Minimize Costs of Change: I don't fully agree here. It might be 'easier' to implement changes, but really in a well structured and designed monolith, these costs should not be so different. For most points considered in this segment, this imo holds true. BUTT (we like big butts here sorry), that being said, the costs of developers able to maintain and understand a monolith, and engineer it in a way that minimizes these kinds of costs, separates responsibilities correctly between components / subsystems and such things might be higher and a team might be more tricky to assemble. Hence, the cost-of-change might be simply higher in a monolith due to the cost of expertise required to engineer and maintain it being higher. Not anything to do with the software or system side of things but more the human side of things. (most people can reason about a microservice written in go/python/whatever, but a monolith in c++ using parallel processing and event driven architectures... that's really another story.)

2: Encourage Generalization, Replaceability and Reuse: I think again this falls in the same bucket as 1. It is possible to design monoliths in a way where libraries are written and used where applicable and components are designed in a way to allow for excellent reuse and replaceability. Using good design is key here. Again, microservices does -perhaps- encourage this more, as a microservice can naturally be re-used more likely, ---if designed properly---. Same goes for a monolith. A monolith doesn't mean a big 'main' function with a load of code in it. ECS systems and such designs, having proper interfaces and data models etc. all still apply in monolith land, and keep the same promises.

As for the risks noted I agree, and hence I do not like microservices myself. I try to avoid them in personal projects.

That being said, when collaborating with others, i find microservices more friendly to collaborate on, despite pitfalls and risks associated. This simply because its more likely a colleague will be able to produce a good quality microservice than a good quality piece of a monolith. This will likely no change, as there is always a shortage of good programmers (I myself, am not a good programmer - just a stubborn one... :D ). And due to that shortage, and the relative ease to teach someone python or Go vs Rust/c++ or such languages, microservices will be here to stay. (and to make me cry :'( )