Coding Tips: Introduction to Microservices

Microservices are small, autonomous services that work together. In this post, I will explain what are the advantages of using microservices, and how they compare with monolithic systems.

Small and Focused on Doing One Thing Well

A good approach to follow is to group together the things that change for the same reason, and separate things that change for different reasons.

As codebases grow, it can be difficult to know where a change needs to be made. Code related to similar business logic starts to become spread all over the codebase, making maintenance and feature addition more difficult.

With microservices we focus our service boundaries on business boundaries, making it obvious where code lives for a given piece of functionality. By doing that, we avoid getting the codebase become too large.

The smaller the service, the more you maximize the pros and cons of the architecture.

Another way to put it is a system can be characterized as a microservice when it’s something that can be written in two weeks.

Autonomous

Every microservice is a separate entity. These in turn need to be able to change independently of each other, and be deployed by themselves without the need to redeploy the whole system.

If there’s too much sharing, this will decrease our autonomy, as it requires additional coordination with other engineers when a change needs to be made.

Our service exposes an API, and collaborating services communicate with us via those APIs. Without decoupling, everything breaks down for us.

Ask yourself: can you make a change to a service and deploy it without changing anything else?

Technology Heterogeneity

With a system composed of multiple collaborating services, we can opt to use different technologies inside each one. This allows us to pick the right tool for the job, rather than trying to achieve a one-size-fits-all approach and have everything be written in the same language, and follow the same patterns.

One of the biggest problem with monolithic applications is that they’re so big that it’s really hard to upgrade different parts of them, as any change will impact a large amount of the system.

Another advantage of microservices is the ability to adopt technology faster.

Resilience

In a monolithic service, if something fails in it, then everything stops working. Whereas in microservices we can build systems that handle the failure and degrate functionality accordingly.

Scaling

With one large monolithic service it’s difficult to scale any part of it, as the whole system needs to scale together.

Whereas with smaller services (i.e.: microservices), scaling is just simpler due to the fact that you can scale one system at a time as needed.

Deployment

A small bug fix, or tweak will require the deployment of the whole monolithic service in order to release the change.

Hence developers cramp to find a small window to release the changes as to not affect customers using the product. Which means that changes will keep piling up between releases, and a higher risk that something might go wrong, with bigger changes going all at once.

With microservices, changes go into a single service at a time, and can be deployed separately. If a problem occurs, you can roll back that service only. That way you’ll be more encouraged to release often and get the goodies out to customers faster.

Organizational Alignment

Having one large monolithic codebase means that the company’s org structure will have people working everywhere in that codebase. Which make developers step on each other’s toes.

Smaller teams always work better together on smaller codebases, hence more productive in general.

With microservices, we can better align the company org with the codebase’s architecture, helping keeping the number of people working on a codebase small, which boosts productivity.

Spring Cleaning Code

I’m sure you’ve probably faced a situation where the code is outdated and needs to be replaced with something better, but you’d rather not touch it as it’s a risky job and the code is huge.

Well that often happens in monolithic code bases.

But when a specific part of the code is small, you wouldn’t mind updating the code with something better, even deleting it altogether!

That’s the case with microservices, the barriers to rewriting or removing services entirely is very low, and team members don’t get usually attached to them, hence they’re easily replaceable.

Conclusion

Microservices are no silver bullet, they have all the associated complexities of distributed systems. If you’re coming from a monolithic system point of view, you’ll have to get much better at handling deployment, testing, and monitoring to unlock the benefits mentioned in this post.

Every company, organization and system is different. A number of factors will play into whether or not microservices are right for you, and how aggressive you can be in adopting them.

I hope you enjoyed this short introduction to microservices and some of the benefits they offer. As always, please subscribe for more content 🍻

10