Select Page

Microservice architecture – An Introduction

Microservice architecture
Did someone say micro?

TL;DR

What is a microservice architecture? Why should I use it instead of a monolithic architecture? The microservice architecture has actually been used for a long time, it’s only in the past few years that it’s been caught on to as a buzzword. The gist of this article is that monolithic architectures were great until we started adding more teams to the mix. An application became harder to manage, development slowed down and releases took longer to ship. Microservices solved a lot of these issues

Monolithic Architecture – Where it all began

The most common type of architecture that applications use is known as a monolithic architecture. This simply means that the whole application is held together in a single application. This one large application would contain all the business logic for every user story that’s implemented.

The problems with a monolithic architecture

Monolithic architectures worked pretty well due to their simplicity. New features and updates to an application were pretty easy to implement for a single team. Until we added more developers and more teams. Now we’ve got this huge application that multiple teams are adding and updating code for. This resulted in a bunch of other issues.

  • Due to the high amount of coupling the number of conflicts when committing code increased
  • This also reduced the interval between deployments because multiple teams had to co-ordinate with each other in order to release their application. Every change required some sort of impact analysis
  • Code quality was also a problem due to high coupling
  • Crashes in one part of the application would affect the entire application
  • You can’t scale parts of the application that are used more without scaling the entire application

Microservice Architecture – Where we are now

Microservice architecture is different from a traditional monolithic one because it focuses on splitting out a large application into independently deployable services. Having an architecture solves many of the issues above with the addition if each service being simpler and easier to develop and deploy. Changes to one service no longer require the entire application to go down, only that small isolated service. Performance bottlenecks can be identified and scaled individually. Individual services can also be managed by different teams. Microservices also map better to the real world by organizing them by business processes.

However, microservice architectures also come with their own challenges such as logging, service discovery. When a microservice architecture is poorly planned, you can end up with many more problems than you started with. It also introduces much more advanced topics such as event sourcing and understanding the proper size of your microservices. It’s difficult to know the exact size a microservice should be and it’s also difficult to know what would be dependent on one in the future.

The bottom line

Microservice architecture is an effective method of tackling a specific set of problems for large enterprises and teams. When implemented correctly and for the right reasons, a microservice architecture can provide a huge amount of benefits and can improve development speed significantly. However, taking the leap should be evaluated carefully since it’s definitely not for the faint of heart. Monolithic architectures are also a great option for small to medium-sized enterprises. Sometimes implementing a proper deployment pipeline, automating tests, good software architecture and applying good coding standards is all you need.

If you’re a solo developer and looking to implement the next shiny thing, then microservices is probably something you want to skip. The added complexity can actually reduce development time and increase complexity. If I was building a small application for myself as an MVP (minimum viable product), then I’d definitely go with a monolithic architecture due to the sheer simplicity. Using a good architecture is more than enough in this scenario. The main thing you want to focus on is building and shipping your product as fast as possible. Hey, if it ends up being a success, then pay someone else to implement a microservice architecture for you!

Further Reading

written by: Admin
February 26, 2020

You may also like

0 Comments

Submit a Comment

Pin It on Pinterest

Share This