Application architectures have evolved very quickly during the latest few years. The classic monolithic architecture has been broken down into a collection of microservices to support a more dynamic development and deployment infrastructure. However, albeit its popularity, there are certain downsides to using a microservice architecture. Recently, a more granular breakdown of a distributed application components is becoming popular: nanoservices. Nanoservices aren’t a replacement for microservices but are adept at addressing some of their shortcomings, and they can provide better isolation and granularity.
This article will introduce the nanoservice architecture and show how to create them with ASP.NET and Azure Functions.
From Monolithic to Nanoservice Architecture
A monolithic architecture comprises a collection of components that are built, deployed, scaled, and maintained as a single unit. Albeit the simplicity, it is extremely difficult to change, scale or maintain such applications. A monolithic application typically uses a homogenous technology platform. Building a monolith with heterogeneous technologies is extremely difficult.
Over a while, a monolith can become highly complex to handle: operational agility, scalability, and maintainability can become a challenge. Microservice architecture evolved to address the shortcomings of monolithic architectures over the past few years. Microservices adoption has been on the rise primarily because of the quest for improved scalability, flexibility, and performance.
What is microservice architecture?
Microservice architecture is a service-oriented architecture (SOA) variant that builds an application comprising lightweight, loosely coupled, modular services. These services can execute on a wide variety of platforms and are independently developed, tested, deployed, and managed. Microservice architecture is easier to maintain, scale, and test because they are smaller and more focused than their predecessors. You can leverage microservice architecture to replace long-running, complex monolithic applications with significant resource and management overheads. The term microservice refers to the limited scope of functionality provided by the service rather than the length of the code used to create it.
The advent of nanoservice architecture
There is no precise definition of how big or small a microservice should be. Although microservice architecture can address a monolith’s shortcomings, each microservice might grow large over a while. Microservice architecture is not suitable for applications of all types. Without proper planning, microservices can grow as large and cumbersome as the monolith they are meant to replace.
A nanoservice is a small, self-contained, deployable, testable, and reusable component that breaks down a microservice into smaller pieces. A nanoservice, on the other hand, does not necessarily reflect an entire business function. Since they are smaller than microservices, different teams can work on multiple services at a given point in time.
A nanoservice should perform one task only and expose it through an API endpoint. If you need your nanoservices to do more work for you, link them with other nanoservices. Nanoservices are not a replacement for microservices – they complement the shortcomings of microservices.
Benefits of nanoservice architecture
The advantages of using nanoservices are as follows:
Nanoservices vs. microservices
The words microservice and nanoservice tend to be synonymous, but there are subtle differences between them. While the former has evolved to address monoliths’ shortcomings, the latter is an evolved form of microservice architecture and handles its complexities but is not a replacement.
Nanoservice architecture is a good choice when your microservices become too large or if you need more flexibility and isolation than they can provide. Nanoservices have a limited scope than microservices, and they are typically at the functional level. You could construct a microservice out of nanoservices.
Microservices outperform monoliths in several ways, and nanoservices are even better. You may use nanoservices to build the business logic once and encapsulate it within a serverless function allowing it to be reused. To design a robust, scalable architecture, you should use a combination of both microservice and nanoservice architecture to leverage the best of both worlds while at the same time eliminating the downsides of each.
Serverless computing and Azure Functions
The cloud’s pledge of unlimited size, improved resource maintenance, and lower costs necessitated new ways of thinking about executing apps. Serverless computing is one such technology that has proliferated over the past few years. It allows you to quickly build and deploy software and services while removing the need to maintain the underlying infrastructure.
The nanoservices built in this article will leverage serverless technology by using Azure Functions. An Azure Function is essentially a piece of code that runs in the cloud, typically in a serverless environment designed to accelerate and simplify application development. It is a serverless compute service that allows one to run code on-demand without managing resources or hosting it on a server.
In using Azure Functions, you would need to pay for serverless computing based on the amount of time your Azure Function has run. Azure Functions are a great way to building nanoservices – serverless with simple APIs. You can trigger an Azure Function using any event in Azure, using third-party services as well as any on-premise systems.
The ItemCheckOut Application
Let’s put nanoservice concepts into practice by implementing a concrete example. Consider an item checkout process of an e-commerce application. Typically, the list of the steps you would have to follow is:
Each of these steps corresponds to a nanoservice which can be implemented by a stand-alone serverless function. You can use Azure, AWS or Google Cloud, etc., to write your serverless function. In this article, we’ll take advantage of Azure Functions to build and deploy our serverless functions. Together, these functions comprise the ItemCheckout microservice, as shown in the following picture.
To execute the code examples shown in this article, here are the minimum requirements you should have installed in your system:
The application structure
The application you are going to build will comprise four projects as part of a single Visual Studio solution:
The following picture shows how the solution structure of the completed application will look like:
We’ll be building each of these projects in the sections that follow.
The following are the dependencies of each of the four projects in this application:
The following dependency diagram illustrates these dependencies:
Implementing the ItemCheckOut Application
We’ll follow the steps outlined below to build the ItemCheckOut application and deploy the nanoservices to Azure:
So, let’s start.
Create the entity classes
To keep things simple, we’ll use just three entity classes, namely,
Product. Create a class library project in Visual Studio and name it
Nanoservices.Entities. Then, create a class file in this project named
CartItem.cs with the following code:
CartItem class represents each item in the cart.
Add a new class file to the
Nanoservices.Entities project named
Customer.cs. This class will have the following code:
Finally, add the
Product.cs class file with this code:
Create the repository infrastructure
Create another class library project in the same solution named
Nanoservices.Infrastructure. This project will contain the repository and the business logic classes, and their interfaces. The
Nanoservices.Infrastructure project has a dependency on the
Nanoservices.Entities project you created in the previous step. So, add this dependency in Visual Studio.
Now, create three solution folders in this project named
Services. The following picture provides you with a preview of how we are going to organize the files in this project:
For the sake of simplicity, we’ll not be using any database in this example. Applying the Repository Design Pattern, the sample data will reside in the
CheckOutRepository class only.
Before creating that class, let’s first define an interface named
ICheckOutRepository. In the
Definitions folder, create a class file named
ICheckOutRepository.cs with the following code in there:
Repositories folder, create a
CheckOutRepository.cs class file with the following code:
CheckOutRepository class implements the
ICheckOutRepository interface, and its constructor adds some sample data to play with.
Create the business logic component
The business logic component of our microservice is responsible for providing its core functionalities. This being a minimal implementation of a microservices-based application together with its nanoservices, you wouldn’t actually have any business logic as such in this component. In our case, it will act as a passthrough between the API controller we will implement in a later section and the repository.
Let’s first create the service interface. In the
Definitions solution folder of the
Nanoservices.Infrastructure project, create a class file named
ICheckOutService.cs with the following code in there:
ICheckOutService interface contains the signature of all the operations that correspond to a nanoservice. Next, create a class named
CheckOutService in a file named
CheckOutService.cs inside the
Services solution folder of the
Nanoservices.Infrastructure project with the following code in there:
Create an Azure Functions project in Visual Studio
Assuming you already have an Azure account, we’ll examine how to build and deploy Azure Functions. You can create an Azure Function either from the Azure Portal or Visual Studio. In this article, we’ll create and deploy Azure Functions using Visual Studio 2019.
Follow the steps outlined below to create an Azure Function in Visual Studio 2019.
A new Http-triggered Azure Function project will be created. By default, a file named
Function1.cs will be created with the code of a default function for your reference. Now, delete this file as we don’t need it in our application. We’ll create our own Azure Functions shortly.
Register the dependencies
ASP.NET Core provides built-in support for the dependency injection (DI) design pattern. DI enables you to achieve Inversion of Control (IoC) between classes and their dependencies and helps in creating loosely-coupled components and writing maintainable code. ASP.NET Core provides a built-in service container named
IServiceProvider. You should register your dependencies with the service container in the
ConfigureServices method of the
Startup class in your application.
To learn more on dependency injection in .NET, check out this article.
Azure Functions support dependency injection as well. Let’s explore how to enable it in this project.
As the first step, install the
Microsoft.Azure.Functions.Extensions package in this project by using the NuGet package manager. Then, add the
NanoServices.Infrastructure project as a dependency in this project.
Now, add a class file named
Startup.cs to your Azure Function project with the following code in there:
FunctionsStartup assembly attribute indicates the type name to be used during startup.
Startup class extends the
FunctionsStartup base class. Within its
Configure method, you register the needed dependencies through the
Create the Azure Functions
In this section, you’ll create the Azure Functions that implement the nanoservices. These functions will be invoked based on an HTTP request, hence the name HTTP-triggered Azure Functions. You can learn more on HTTP-triggered Azure Functions from here.
Now, create a file named
CartManager.cs in the root of the
NanoservicesFunctionApp project with the following code in there:
We’ll now create all our Azure Functions one by one as methods of the
The IsItemAvailable Azure Function
This function checks if an item is available for purchase and returns true if it is available, false otherwise. The following code snippet illustrates the
IsItemAvailable method to add to the
The GetAllCartItems Azure Function
This function returns a list of all cart items. The following code snippet illustrates the
The GetAllCustomers Azure Function
GetAllCustomers function retrieves all customer records. The following code snippet illustrates this function:
The GetAllProducts Azure Function
GetAllProducts function returns a list of all available products:
The AddItemToCart Azure Function
This function is used to add items to the cart. The following is the source code of the
AddItemToCart Azure Function:
The UpdateStock Azure Function
UpdateStock function is used to update the stock of items. The following is the source code of this Azure Function:
The CartManager class
The complete source code of the
CartManager.cs file is given below for your reference:
Deploy the Azure Functions
To deploy the Azure Functions we created earlier, follow the steps outlined below:
Once your Azure Function has been published, you can consume it in your application much the same way you consume any other service using
Testing the Azure Functions
So far, so good. Since the nanoservices are deployed in the Azure environment, you can test them from within the Azure Portal itself. To test the Azure Functions, follow the steps outlined below:
Here’s how the output would look like:
Call the Nanoservices from an ASP.NET Core Web API Application
To complete the application, we need to create the
ItemCheckOutAPI microservice, which will consume the nanoservices published on Azure. For this purpose, follow the steps mentioned below in your Visual Studio instance opened on the solution we are working on:
Build the ItemCheckOut microservice
We’ll now build our minimalistic microservice. It will implement action methods that correspond to each operation of the item checkout process we discussed earlier. Each of these action methods would wrap the calls to the serverless functions we created earlier.
Before starting to code, add a reference to the
Now, in the
Controllers folder, create an API controller named
ItemCheckOutController and replace the default code with the following:
Call the Azure Functions from the API Methods
Each of the action methods of the
ItemCheckOutController class corresponds to a nanoservice we’ve implemented using Azure Functions earlier. Note that the methods of the
ItemCheckOutController class having the “Internal” suffix are private. These are the methods that will actually communicate with the Azure Functions.
As an example, the following code snippet shows how the ASP.NET Core Web API calls the Azure Function. The
IsItemAvailableInternal method accepts the product code as a parameter and returns
false depending on whether or not the product is available for purchase.
The other private methods follow the pattern shown above.
Use Swagger UI to Test the ItemCheckOut Application
Now that the nanoservices are already published in Azure, you can run the
ItemCheckOutAPI microservice application and then invoke the API endpoints using Swagger UI with your browser. Swagger is available in your ASP.NET application thanks to the integrated OpenAPI support.
The following picture shows the output of the
GetAllCartItems API endpoint called using Swagger UI:
Nanoservices: The Future
Microservices evolved to address the flaws of traditional monolithic architecture. Nanoservices are essentially extra-small microservices with a narrower scope and are more focused and driven by serverless computing. Although nanoservices are adept at addressing the shortcomings of microservice architecture, they have their own set of issues and challenges.
Nanoservice technology is not quite there yet, but with serverless computing and serverless solutions getting cheaper day by day, it is all set to be the technology of choice for building high-performant and scalable applications for quite some time. It will find its place in this envisioned ubiquitous world where new technologies and architectures suffice the constantly changing business world’s needs.
The era of extra-small microservices powered by serverless computing is inevitable. For example, BBC’s website is a real-world application of nanoservices used to render dynamic web pages, generate the headline, retrieve weather information, and update cricket match scores, among other things.
The complete source code of the ItemCheckOut application built throughout this article is available here.
This content was originally published here.