The email sent will contain a link to this article, the article title, and an article excerpt (if available). For security reasons, your IP address will also be included in the sent email.
This is a guest Post by Jake Lumetta, Founder and CEO, ButterCMS, an API-first CMS. For more content like this, follow @ButterCMS on Twitter and subscribe to our blog.
Conventional wisdom for startups counsels starting with a monolith, but are there situations where you should start with microservices instead? Interviews with dozens of CTOs illuminated the key considerations when deciding whether to start with a monolith or microservices.
Challenging Conventional Wisdom
My good friend Darby Frey recently kicked off a greenfield project after assuming his new role as Sr. Platform Engineering Lead of Gamut. Despite starting out with monolith at his previous company Belly, he discovered that — in the right circumstances — starting with a monolith isn’t always the best way to go.
“As one does, I allowed much of my thinking in my early days [at my new company] to be influenced by my previous company,” Darby told me.
At Belly, Darby and his team broke down their monolith into a fairly large microservices architecture. They managed to get it to a good place, but only after months of trials and tribulations migrating to microservices.
With this experience fresh in his mind, he approached his new project at Gamut a bit more cautious of microservices.
“I was firmly a member of Team Monolith. [I thought] let’s build a single application and just pull things apart later if we start to feel pain,” he said.
While this was a greenfield project, Darby’s team was small, and he had aggressive timelines, so on the surface, a monolith seemed like the obvious choice.
“[But with this new project], I was anxious to not repeat the mistakes of the past.”
And with that, he found himself faced with a decision we all struggle with, should we start with a monolith or microservices and how do we decide?
Evaluating Pros and Cons
Facing A Monolith