Introduction
Today we will look at a very common question that comes up in the minds of all application designers and developers at some point. This question is when to use the standard N-Tier architecture, as opposed to the much-hyped microservices architecture, for building 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
![The N-tier architecture]()
I am sure everyone knows about n-tier architecture. This architecture has been in use for many years now, especially with the rise of web applications. Later, n-tier architecture was also implemented in other applications, as well. To quickly recap, in n-tier architecture, we divide our application into three or four main areas. The UI, which is the user interface, is displayed to the end user. The middle tier, sometimes called the business tier, is the one 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. This is a very powerful design which has been a major success over the years.
The Microservices architecture
![The Microservices architecture]()
A new buzzword in the development world is microservices, and alos the many benefits they bring. Microservices are independent services like applications, which exist on their own. The have their own logic, state, and deployment. They interact with each other via API calls, queues, etc., depending on the requirements. These microservices combine to provide the overall application solution. As they are very loosely coupled, microservices can be maintained, scaled, and upgraded independently from each other. We can even have different teams working on them at the same time. I would also like to mention that n-tier architecture can be used to design and develop these individual services.
Do we need to shift everything to microservices?
As n-tier architecture is a group of sorts that is mostly updated and deployed together, and microservices are independent and very loosely coupled, should 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 that have a few thousand users, we can build the application using the standard n-tier architecture using the SOLID principles. These principles will make our application scalable, maintainable, and highly performant. With the new cloud solutions like App services in Microsoft Azure, we can deploy these applications and have them scale-up and scale-out using their infrastructure. Hence, n-tier architecture provides us a very viable solution. This solution is also very cost-effective, as normally there is one team working on the application, and coordination between teams 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, especially one where we need a high level of reliability, we can go for microservices architecture. Keep in mind, when building microservices a lot more planning must go into the process. We cannot jumpstart the agile development process as soon as we can in a standard n-tier single application. We might need to set up different teams to handle different microservices, as well as work on the coordination method between them and conduct extensive design work on the interaction methodologies between different services. Similarly, during the development phase, a lot more work will be required in order to keep the project going smoothly. In the cloud, we have some great services for microservices, as well. For example, 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.
So, when do we use 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, if we have an application that needs independent components that are built and maintained separately, as opposed to a single solution.
Summary
In this article, we looked at the scenarios where we can design and develop an n-tier architecture application as opposed to a microservices architecture application. It depends on what we are trying to achieve, and if we can 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 based on a buzzword is not recommended. If these points are not justified, we can build a simple n-tier application applying SOLID principles which will be usable for many years.