Monoliths & Microservices: a technical explanation for non-technical people

Let's face it, we’ve all been in meetings where technical conversations can go over our heads. As a Product Manager, a big part of my job is to bridge these technical conversations between developers and non-technical stakeholders.

‍

I’ve done my best to do this on a particularly complex topic as part of this blog.

‍

How do features actually get delivered?

Before we dive into the details, it’s maybe worth briefly giving the context of how features actually get delivered. Although the details differ company to company, the key concepts are the same.

1. Developers take the latest codebase and ‘clone’ or duplicate it to their own computers. This is so they can make and test changes without these changes impacting the actual codebase and customers. 

2. Next up, developers write code in this ‘cloned’ environment. Once the code is written they’ll test to see if it does what it should do. 

3. It’s now time to check their work, so developers submit a ‘Pull Request’ which entails another developer reviewing the code they’ve written to see if it’s good enough to go into User Acceptance Testing (UAT).

4. Once approved, the new code gets deployed to UAT, which is a close replica of the production environment. This allows the ‘end user’ alongside a QA or testing team to see if the new feature does the jobs it’s meant to. 

5. If the feature is working then it’s now time to ‘deploy’ to the ‘production’ codebase so the change is live for customers. 

So, now you know how features get built, tested and deployed, it’s time to discuss Microservices, Monoliths and everything in between! 

What’s a Monolith?

Imagine you’ve got two teams working on a presentation in Google Slides. Now imagine that the presentation is a single slide and you’ve got multiple members of each team focusing on different parts of the slide. Sometimes you accidentally overwrite each other's changes, mess up each other's formats and, frustratingly, you need everyone else in the team to be finished before you can submit the slide to your boss.

A software Monolith is much like this ‘single slide’ example. 

A Monolith is a single package of code that contains all the software, features and functionality your company offers. Given it’s a single thing, it has to be deployed all together in one big bang. This means if one team has successfully tested a fix for a tiny bug in UAT, they have to wait until all other features and new pieces of functionality in the monolith are successfully tested before they can ‘deploy’ to customers. This means teams are dependent on each other to get changes live, and changes made by one member of one team are more likely to impact something else being worked on by another team.

What’s a Microservice?

Using the same example, a microservice architecture would be equivalent to a Google slides presentation with multiple slides. Each slide is fully owned by an individual or team and when a slide was finished it could be saved without requiring the rest of the deck to be finished first.

In software, microservices are essentially a broken-up monolith; individual microservices contain a specific feature, function or part of the wider codebase. If teams need to change how a feature works, they only need to do so on a single microservice. Equally, they can deploy that feature quickly without waiting for other teams to make their changes. If something goes wrong it’s easier to spot where things have gone wrong and revert the change (roll back the code) quickly.

So, which one is better? 

Neither! They both have different strengths and weaknesses depending on your needs. Most startups begin with a monolith to keep things simple, allowing them to ship new features quickly without having to design complex technical architecture. As companies grow, so do their codebases, which often become more complex with more teams working on them simultaneously. For this reason, companies in ‘scale up’ mode often transition to a microservice model which brings all the benefits I mentioned above.

Conclusion

In order to keep this short, sweet and simple I’ve avoided many of the nitty gritty details that can make this conversation overwhelming. I hope you’ve left this blog with an expanded technical vocab so fewer of those technical conversations go over your head in future.

‍

Where you come in

‍
If you’d like to learn more about our product team at Freetrade or our mission to get everyone investing, get in touch.

‍
We’re always on the lookout for engineers, as well as product managers and product designers to help build our platform and mobile apps.

‍
If you want to help build a world where everyone is investing, come join the fun at freetrade.io/careers.

‍