Do we always use microservices?

Introduction

Today we will look at a very common question that comes up in the minds of all application designers and developers. This question is when to use the standard N-Tier architecture as opposed to the much-hyped microservices architecture for building our applications. Recently, there has been lot of discussion on the design, development, and overall advantages of using microservices architecture. However, building these applications comes at a cost. Is this cost always worth it? We will try and analyze this in today’s article.

 The N-tier architecture

I am sure everyone knows of the n-tier architecture. This has been in use for many years now especially with the rise of web applications and later this has also been implemented in other applications as well. To quickly recap, in this architecture we divide our application into three/four main areas. The UI which is the user interface displayed to the end user. The middle tier or sometimes called the business tier in which we add functions for business logic, data access etc. Sometimes, the data access tier can be mentioned separately. The final layer is the data layer in which we persist our data using some store like a relational or non-relational database. A very powerful design which has been a major success over the years. 

The Microservices architecture

The new buzz word these days in the development world is microservices and the many benefits they bring. These are independent service like applications which exist on their own. Have their own logic, state, and deployment. They interact with each other via API calls, queues etc. depending upon the requirement. These microservices combine to provide the overall application solution. As they are very loosely coupled, they can be maintained, scaled, and upgraded independently from each other and we can even have different teams working on them at the same time. I would also like to mention that the n-tier architecture can be used to design and develop these individual services.

Do we need to shift everything to microservices?

As the n-tier architecture is sort of a group which is mostly updated and deployed together and microservices are independent and very loosely coupled, do we shift everything or build all new applications only using microservices? For me, the answer is No. We need to analyze each situation and the type and scope of the application before we decide on which design to use. For smaller applications which have a few thousand users we can build the application using the standard n-tier architecture using the SOLID principles which will make our application very scalable, maintainable, and highly performant. With the new cloud solutions like App services in Microsoft Azure, we can deploy these applications and have them to scale-up and scale-out using the infrastructure and hence the n-tier architecture provides us a very viable solution. This solution is also very cost-effective as we normally have one team working on the application and coordination between the team does not become an issue.

On the other hand, if we are building a very large application to cater to hundreds of thousands of users or more where we need a high level of reliability, we can go for the microservices architecture. Keep in mind when building microservices a lot more planning goes into the process, and we cannot jumpstart the agile development process as soon as in a standard n-tier single application.  We might need to setup different teams to handle different microservices, work on the coordination method between them and have extensive design work on the interaction methodologies between different services. Similarly, during the development phase, a lot of more work will be required to be done in order to keep the project going smoothly. In the cloud we have some good services for microservices we well. In Microsoft Azure we have AKS (Azure Kubernetes services) and Service Fabric. These services also need much more planning, design, deployment, and maintenance work as opposed to the App services we discussed before.

Hence, when do we go with microservices. The simple answer is when we can justify a large design and development effort as compared to a standard n-tier application. How do we justify this? Firstly, a very large userbase. Secondly, an application which would need independent components that are built and maintained separately as opposed to a single solution.

 Summary

In this article we looked at the scenarios when we can design and develop an n-tier architecture application as opposed to a microservices architecture application. The simple answer is that it depends on what we are trying to achieve, and can we justify the larger effort, time, and cost that goes towards planning, designing, developing, deploying, and maintaining a microservices architecture application. This justification can come in the form of the number of users, reliability, scope, or scalability required from the application. Just building an application for the buzzword is not recommended and if these points are not justified, we can build a simple n-tier application applying SOLID principles which will be usable for many years.