An advantage of a monolith code base that can go overlooked is the minimal entry barrier to getting up and running for junior developers or new members of the team.

Setting up a basic database and my application with a background process was a pretty defined process. I’d have the readme on Github, and often in an hour or maybe a few I’d be up and running when I started on a new project. Onboarding a new engineering, at least for an initial environment would be done in the first day. As we ventured into micro-services onboarding time skyrocketed. Yes, we have docker and orchestration such as K8s these days to help, but the time from start to up and running a K8s cluster just to onboard a new engineer is orders of magnitude larger than we saw a few years ago. For many junior engineers this is a burden that really is unnecessary complexity.

— Give me back my monolith by Craig Kerstiens

Even those in senior roles may struggle to hold in their head an entire stack composed of micro-services. Sure it becomes familiar over time, but it’s another learning curve that can be unnecessary. It’s why I love working in monoliths.

They are a one-stop stack that contains everything or at least most of the components that we need to know about. An engineer can get up and running in a matter of hours. Why make it more difficult to onboard engineers?

Maybe the hype-cycle for micro-services is finally passing.