Monolith Defence Protocol

Background

This post is the start of a discussion in response to this question:

For context I’m talking about a small niche service solution, low usage, with no proposed requirements for exposed API, with both internal and external users.
when is it acceptable to avoid complexity in your architecture?
i.e. at what point does an application qualify as a monolith, rather than a web app?
- Steven Alexander

DHH, creator of Ruby on Rails and CTO at Basecamp for 13 years writes about the Majestic Monolith

TL;DR: Run a small team, not a tech behemoth? Embrace the monolith and make it majestic. You Deserve It!
- DHH

That’s super cool and there is some mad sense in there. Also, the fact that he has 13 years experience of doing this might also be at play.

Another referenced monolithic example in the wild is Etsy. Depending on who you ask actually. John Allspaw, vice president of operations and infrastructure at Etsy is probably the right person.

TL;DR: The thing that I would do at any other company is to write software for people to reason about.
- John Allspaw

So he cares less about the architecture or the name of the thing and more about the people who need to understand it. This is something I agree with entirely, but it is a whole other post.

Back to the discussion at hand. These are big ass things that are allegedly ‘monolithic’.

Not everyone is building Etsy, or Basecamp, or Facebook (apparently they are also a monolith in some way) and it seems that these places have people working for them who contribute to the languages and frameworks that they run on, so sort of cheating.

Sometimes the ‘hype cycle’ generates a lot of noise, and people that make decisions, andmaybe don’t get things just say stuff out loud and then it has to happen. Other times, you might get caught up in that hype and just follow the crowd.

Microservices!

Oh YEAH, i’ve been into them since their first demo on soundcloud.

This isn’t deciding, this is just doing stuff.

As Lyn Collins advises think (link to utterly dope song).

Thinking

Don’t immediately leap to ‘MICROSERVICES’.

Behold the monolith! A pillar of views, models, libraries, controllers and all manner of sub-systems. All in one code base. All working together to deliver something.

Manifestly glorious. Now lets decide actually should we break this thing apart.

How big is this thing?

First things first. Actually, how big is this ‘monolith’ because if it isn’t…

…why bother splitting apart at all? Seems like it’s more minilith than monolith.

Let’s assume it’s actually big enough to think about splitting up.

Launch analysis

Let’s launch some missiles at it:

There are ‘forces’ external to the system you are going to build that will influence whether or not it needs to be split apart.
- me, literally just now

I’ll list a few below, but this is by no means an exhaustive list.

Security

Think about the bits of the application that matter, if someone compromises one bit, can they run rampant through the whole system?

Operational Maturity

This is the stuff Martin Fowler talks about in his Microservices Prerequisites post. Can you deploy quickly, are you really good at monitoring and so on.

Skills

This is about the people. Do you have the skillset to run a tonne of services, to develop them. Do you even need to?

Maintenance

Do you need zero downtime deploy? Most people love to default to yes, but really, do you? Can the users deal with some downtime? You can achieve zero downtime with monoliths too, but it requires some investment.

User Need

Can people deal with things going wrong sometimes? Is eventual consistency OK? (These are real considerations when you flip the distributed switch).

Cost

Can you afford to do all of the things above? This could be pricey.

There a lots of other things you can launch at your monolith to see if it breaks apart. But this is the sort of thinking you need to apply when making a decision.

Analysis Assault Outcomes

Maybe this happens:

The monolith stands up to all attacks. There is literally no need to break this thing down.

Or maybe this happens:

The monolith starts to break apart. It doesn’t make any sense to do this anymore. Let’s break this thing down. You have met the Microservices Prerequisites and you are all set to build distributed utopia.

Universal truth

Regardless of how you end up going, either monolith or multilith…you need to make sure when you look inside at the code and how it has been constructed you get this:

and most certainly not this:

If you can’t build a single decent minilith or monolith you certainly wont be able to build lots and lots of them.

Footnote

If people feel like working on getting a good ‘checklist/rubric’ for this give me a shout or comment below the line. I’d love to develop something a bit more detailed!