Microservices 101

#devops #microservices #architecture

As promised here is the first post on microservices and their advantages and downsides.

To begin with, let's define a few key terms that'll come up frequently in any discussions around microservices.

Monoliths : Not a giant column in a classic sci-fi movie but instead a monolith application. This is when all of the functionality for an application is in a single process. It's often kept in one separate repo as well however with the increasing popularity of monorepos this is becoming less frequent as an implementation method. I'll discuss some of the advantages of monoliths below.

Microservices : When the functionality of an app is broken down into multiple processes which all run separately from each other. Often implemented in different repos although as with monolith applications monorepos are changing the landscapes with this.

So with the definitions broken down let's go into some of the advantages of the different architecture types.

Monoliths

Monolith architecture actually has a lot of advantages over microservices in certain circumstances. The primary use case for a monolith would be for an MVP product, this is due to the ease in which it can be deployed, as well as how easy it can be to setup development environments. This means that your dev team can get up to speed much quicker and start being productive much faster. It's also easier to monitor the application, and as a result, it can be a lot easier to debug any issues with the app.

That's not to say there aren't disadvantages. As time progresses and your app grows you may find that your teams get much bigger in size, once this starts happening it becomes a lot more challenging to maintain the structure and communication channels effectively, see the diagram below to see how many more lines of communication are generated as your team scales.

Deployment becomes more difficult as the app increases in size and capability, and eventually, even small code changes will have the potential to become difficult to manage. Scaling will also increase in cost and complexity as you'll need to scale the whole application and not just the small piece of functionality that's gained a high demand.

Microservices

Now onto microservices. Once you start seeing some of the disadvantages outlined above for monoliths, then it is definitely time to consider changing over to a microservice architecture. Some of the advantages of microservices are detailed below.

As each piece of functionality is broken down into an individual process, it means you can have a much lower overall scope. This means that each functional unit can be designed, built, tested and deployed individually and in isolation from each other. The end result of this is that your build cycle should be able to speed up and features can be deployed more frequently.

You can also scale the features much more comfortably leading to lower running costs, instead of scaling all of your functionality at once regardless of usage you can set it to scale only the parts of the app that are facing higher usage demands. Also because of the split architecture, your app can have a much higher reliability status, if one service goes down, the app can work around it and still function without going completely down.

Microservices aren't without their downsides, because of the distributed architecture it can be much more complicated across a lot of different fronts, not just development. Debugging and monitoring will become a lot more complicated as you'll need to introduce log aggregation tools to the stack and even following where data requests have gone can lead to a trip down the rabbit holes. It can also suffer from a performance decrease due to constant API calls and communications between the services.

Reasons to move

So with the above in mind why should you move from a monolith to a microservice architecture? Well firstly because it's fun, there are a lot of challenges involved sure, but half the fun of developing is overcoming those challenges. That being said it shouldn't be a decision just from technology, there are a lot of valid business reasons to move your architecture over.

Firstly your teams will be much smaller, as you can see from the diagram above when you have a large team your number of potential communication channels increase exponentially, a small team helps massively streamline any communications. The smaller team will also be much more specialised and more efficient as they will only need to worry about the code within their functional unit as opposed to every of function within the app.

Having a smaller team can also enable organising teams around business features instead of capabilities. By organising around features instead of business capabilities, you can avoid siloed structures where the code is 'thrown over the wall' to the next department without a thought about how it will impact the team down the pipeline. It also means that teams can own the whole lifecycle from the discovery of benefit to the customer to the final release of the code into the wild without being a problem for other feature teams.

Secondly, onboarding for new team members will become much quicker as once again they'll only need to worry about how to run their single function as opposed to the entire codebase.

Finally, your releases will be much smaller and more frequent. As part of a CI/CD culture, you should be aiming to release as little code as frequently as possible. This enables you to improve the application gradually and actually deliver customer value instead of doing big bang releases of functionality that the end user doesn't actually want.

Conclusion

There are a lot of reasons to use microservices and a lot of reasons to use a monolith. As I mentioned above using a monolith for your MVP is perfectly fine, and in fact, I'd recommend it, your setup will be quicker and initially, your dev onboarding will go much more smoothly but once you start to encounter the issues outlined above definitely consider switching to microservices.

Lines of communication image is courtesy of Justin Niessner on Stack Overflow

2001: A Space Odyssey gif is used under fair usage and all rights belong to the content creator