MicroServices - An Intro With Azure Service Fabric

Lately microservices have become the buzz of the industry. Let’s explore that a bit.

In order to understand microservice, let's shed some light on monolithic applications.

We are all so used to monolithic applications without even knowing that's what they are. Get back to your project and take a look at the architecture of the project. All the modules, repositories/DAL, and services/BAL; everything is in a single solution right? That’s what we call monolithic.

Let’s dig a bit deeper into this monolith. Here, I am seriously bored of seeing the same example of E-commerce used for every explanation. Let’s try some other example. I will take a NET banking application. I hope you have accessed net banking applications in the past. As a developer what are all the modules you can think of for a net banking site? There are so many. For simplicity purposes, let’s take three:

  1. Account information
  2. Mobile recharge
  3. Credit card

In a monolithic world, I will have three classes in DAL and BAL for each of these modules. In the Web app, I will add a reference to those BAL, DAL and three Controllers/Views for each module which will implement the modules. All good. So, what’s wrong with that? Nothing. But there are some disadvantages of it. Let us go one by one.

What if we have so many modules?

Just take a look at the left menu and the top menu of your net banking site. How much functionality is there and how many modules could there be? For a simple change in a credit card section, you need to build the whole website and redeploy the whole site again. Maintainability is going to cost you a bundle.

What if I want more computational power for some modules and less for others?

Nope! You can’t do that. You have to scale up and down the resources for the whole application. For example, the bank is giving offers for all of those who do mobile recharges with them. So, many users are trying for a recharge. You can’t scale up the resources like increasing the RAM capacity for this module alone.

What if I want to use different resources for different modules?

For example, I want to use SQL for some modules and NoSQL/DocumentDB for some other module. Yes! You guessed it right. Not possible.

These are a few examples. By now, you can guess that these are all possible with microservices.

So, what exactly is a microservice?

We can say, it is an extended version of modules. We are going to implement these modules as separate services we call it as a microservice because as the name implies it is going to be small part of big application and these services will communicate with each other in a cluster (Service Fabric). These microservices are nothing but individual applications that are combined together to give you the whole application. Each microservices will implement its own set of requirements like modules but can be deployed and maintained individually.

Each microservice can use its own set of resources depends on the requirement. For ex. For net banking site for authentication I can use Asp.net webapi, front end as angular 4 with AD and for documents upload I can go with Node.js and documentDB. It’s all up to you to decide which is best. Lately you can connect them all.

As we now have a fair idea of what a microservice is, in the next article, we will discuss how we are going to implement microservices using service fabric.