Microservices Architecture Explained

To understand why microservices are so helpful, we should first explore how it was originally done before them.

Monolithic Architecture

Monolithic architecture diagram

Before microservices, the main architecture style for web services was the monolithic architecture. This architecture based running everything in one application process. Anything needed for a service is included here. That means any calculations, transformations, loading, etc., etc., all happens within one application process. Let’s explore an example…

PickleBalm.com example

Let’s imagine we have an eCommerce site, PickleBalm.com, which is selling the highest quality pickle lip balm:

pickle lip balm

Our site very likely has a few key systems including a inventory maintenance, checkout, and shipping. In a monolithic architecture, these are all run on the same server/application process. This means that if any one of those goes down, everything else running within that process suffers as well. If we want to update the inventory maintenance system then we need to build the checkout and shipping systems too. Along with that we need to run all tests associated with all of them because they are all one monolithic service.

Now, let’s say that usually we have 200 checkouts a day that we can easily handle. Today, BuzzFeed’s latest article promotes our pickle lip balm and we now have 100,000 checkouts today that we definitely can’t handle at current capacity. If we want to scale our site to handle this with a monolithic architecture, we need to create copies of every part of our service since they were built to run in the same process. Doing this is expensive, slow, and clearly a pain to maintain. This is where microservices comes in.

Microservices Architecture

Microservices takes the pieces of our service that can be split up, and splits it up into their own standalone service that runs in its own process. This means that each service is now rather small, but that’s exactly what we want. Microservices are services that a two pizza team, or teams small enough that you can feed with only two pizzas, can build. Being small also means that they can be spun up and torn down much quicker than a monolithic system. This is because the only things needed for each service are what that specific service needs and no more. Since each service is now broken apart, we can scale individual services faster, without breaking the bank. We can also deploy services much faster as we only need to make sure that what we promise our service will accept and return is what we accept and return.

PickleBalm.com in a microservices architecture

Let’s take our example again and now say we convert our site into a microservices based architecture. This means our inventory system is now its own service, our checkout system is its own service, and our shipping system is its own service. Each service has its own team, server/container, and requirements. If, all of a sudden, Mashable runs an article about our pickle lip balm and we have 200,000 people checking out today, we can scale the checkout service to meet this demand. We wouldn’t need to scale the whole system, only the service that needs the extra capacity. This drives down overall costs and speeds up development dramatically.

Thanks for reading ❤

If you liked this post, share it with all of your programming buddies!

Monolithic Architecture

PickleBalm.com example

Microservices Architecture

PickleBalm.com in a microservices architecture

Further reading about Microservices

jonrcorbin.com

Microservices Architecture Explained