Monoliths make getting started easier

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.