Why Working on Monoliths Is Bad for Your Career

Despite having spent the last two years working specifically on addressing the operational issues caused by a monolith, I couldn't find anything apart from the title and the implied pro-microservice premise in this post that I agree with.

A monolith's tests need not take all day to run. Features don't need to take weeks or months to ship—one can practice agile even inside a monolith. A monolith does not preclude the use of modern tooling—we adopted CI/CD and distributed tracing despite having a monolith, and use them to great effect.

In some cases scaling a monolithic codebase may be _more_ instructive about how to scale, because it's not as simple as "pay AWS more money and use more instances." Instead, you're forced to understand bottlenecks and consider how to solve them with algorithmic changes. Circuit-breaking is a critical feature in a monolith, even more so since one bad type of request could otherwise ruin the day for everyone.

The inability to "rewrite your business" has more to do with how well-architected your platform is than whether you have microservices. Both monolithic and microservices can be built well and built badly; a clean monolith is straightforward to rewrite the same way that cleanly-designed microservices are.

My personal opinion aligns with that of the author and greatly favors microservice architectures. But the usual hatred of monoliths strikes me as more dogmatic than well-reasoned, and I find this post to ultimately fail in defending its claim by falling victim to that.

Either the author is trolling or they are trying to convince us to switch to Microservices, so that once we have a big ball of mud Lightstep can come in to save the day.

They're just describing the difference between good development practices and bad ones.

Is it just me or is the author confusing the concepts of ci/cd and microservices?

BS

bad