We’re continuing with our series of posts on creating performant and scalable web APIs using ASP.NET Core. In this post, we’ll look at using a Microservices architecture to help scale out our APIs …

What are Microservices?

James Lewis and Martin Fowler described microservices as “an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

The diagram below shows a simplistic model of a monolithic CRM system and one that uses a microservices architecture. The monolithic system equates to a single database and a single deployed ASP.NET Core app. The microservices system equates to 4 databases, 4 services in addition to a frontend app that talks to the backend services over HTTP.

How it helps us scale

The monolithic CRM system is more challenging to scale out. A common approach to scaling a monolithic system out is to run multiple instances of the app behind a load balancer. However the instances will still likely need to talk to the single database which will become the bottleneck.

So, very often, in order to scale a monolithic system, we would need to scale up - which is basically running the whole system on more powerful hardware.

We have more scalability options with the microservices CRM system. The whole system could start out all on one server. We can scale out by moving services to separate servers as the load grows, moving the services under the most load first. We have more flexibility on scaling up as well because we can choose to apply more powerful hardware only to the services that are creaking rather than to the whole system.

Another interesting point with the microservices CRM system is that there is potential to use different database technologies for the different services. For example, a Mongo database might be more efficient in the order processing service whilst SQL Server might be more efficient in the customer support service.

Conclusion

Whether we are maintaining an existing API system or building a new one, a microservices architecture gives us a lot of flexibility in terms of how we can scale the whole system - so well worth considering!