Breaking the monolith – How to design your system for both flexibility and scale – Part 2: The Cathedral & The Bazaar

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

This post is part of a series. you’d probably like to read it from the beginning. You may also be interested in the next part of the series.

 

As a paraphrase on Eric Raymond’s famous book under the same title (O’reilly ,open format) let us, for a moment, think of the church as a computing system. The  service (no pun intended) is led by the priest, and has a single, general, output, it is very reliable (when comparing to other medieval services) but given under very strict terms (start time, end time, location, donation). If you don’t like your town’s priest, the next best option (if you are a medieval peasant)  probably involved some serious walking and certainly was not the safest things you could do in your day off (how’s that for a captive audience?) .

The Bazaar, On the other hand is a whole different animal Continue reading “Breaking the monolith – How to design your system for both flexibility and scale – Part 2: The Cathedral & The Bazaar”

Breaking the monolith – How to design your system for both flexibility and scale – Part 2: The Cathedral & The Bazaar

Breaking the monolith – How to design your system for both flexibility and scale – Part 1: The monolith is broken

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

Every start-up gets to this point. At first the design was perfect. Perfect for the MVP, and you know what? it was even perfect for the full prototype. Then things didn’t went as planned – some adjustments were made for the test phase product, and then again for the first user group of the soft release, which were (of course) nothing next to the changes you did after the user results came back. Now you have a deployment to a big (and paying) client and the entire thing is out of whack – it now takes eight fully trained engineers and half of an EC2 Region just to keep the whole thing running in quarter speed during the on-site integration phase. You became too big too fast, and you NEED a redesign. Continue reading “Breaking the monolith – How to design your system for both flexibility and scale – Part 1: The monolith is broken”

Breaking the monolith – How to design your system for both flexibility and scale – Part 1: The monolith is broken