Building Microservices Architecture Design on Azure

Nowadays, the usage of Microservices architectures is widely increasing and it is replacing the traditional monolithic application architecture. This approach is generally used by software development companies to develop large-scale applications with the use of public cloud infrastructure such as Azure. This infrastructure offers various services like Azure Functions, Azure Kubernetes Service (AKS), Azure Service Fabric, and many more. To know more about microservices, their implementation benefits, and how cloud infrastructure like Azure help businesses implement the microservices architecture, let’s go through this blog.

1. What are Microservices?

Microservices are known as one of the best-fit architectural styles for creating highly scalable, resilient, modern, large scale and independently deployable applications. There are various approaches available by which one can design and create microservices architecture. Microservice architecture can consist of autonomous and smaller services. And here each service is self-contained which means that it helps in implementing a single business capability within a defined bounded context. Here a bounded context means a natural division within a business that offers boundaries within each business domain.

Basically, microservices are easy to develop and maintain the developers as they are independent, small, and loosely coupled. Each service has its own separate codebase which can be easily maintained by a small development team. Besides this, when it is time to deploy services, it can be done independently. In addition to this, services are also responsible for persisting external or their own data which differs from the traditional method of app development.

Further Reading on: Microservices Best Practices
Microservices vs Monolithic Architecture

2. How can Azure be the Most Beneficial for Microservices Development and Deployment?

Here are some of the reasons that prove that Azure is very beneficial for the implementation of Microservices architectures –

2.1 Creates and Deploys Microservices with Agility

Microsoft Azure enables effortless management of newly released features, bug fixes, and other updates in individual components without forcing them to redeploy the entire application. This means that it enables continuous integration/continuous deployment (CI/CD) with the help of automated software delivery workflow.

2.2 Makes Applications Resilient

Azure microservices help replace an individual service or retire the services without affecting the entire software application. The reason behind this is that microservices platforms enable developers to use patterns like circuit breaking to handle the failure of individual services, their reliability, and security, unlike the traditional monolithic model. 

2.3 Microservices Scale with Demand

Microservices on Azure enables the developers to scale individual services based on the requirement of the resources without scaling out the entire application. For this, the developers have to gather the higher density of services into an individual host with the use of a container orchestrator such as Azure Red Hat OpenShift or Azure Kubernetes Service (AKS).

2.4 Finds the Best Approach for the Team

Another benefit of Azure Microservices is that it enables dedicated software development teams to select their preferred language, deployment approach, microservices platform, and programming model for each microservice. Besides, Azure API management enables the developers to publish microservice APIs for both external and internal consumption while maintaining crosscutting concerns like caching, monitoring, authentication, throttling, and authorization.

3. Building Microservices Architecture on Azure

Here are some steps that will help developers to create microservices architecture on Azure –

Step 1: Domain Analysis

When it comes to microservices, developers generally face issues related to defining the boundaries of each service in the system. And doing so becomes a priority according to the rule which states that each microservices should have a single responsibility. Therefore, by following this rule and putting it into consideration, microservices should be designed only after  understanding  the client’s business domain, requirements, and goals. If this is not the case, the design of the microservice will be haphazard with undesirable characteristics like tight coupling, hidden dependencies, and poorly designed interfaces. Therefore, it is necessary to design the microservices properly and for that analyzing the domain is the best first step. 

In addition to this, Domain-Driven Design (DDD) approach is used as it offers a framework that can help developers create a well-designed service. This approach comes in two different phases: strategic and tactical. In this method, strategic DDD ensures that the service architecture is created in such a way that it focuses on the business capabilities, while tactical DDD offers a set of design patterns for services. To apply Domain-Driven Design, there are some steps that the developers need to follow and they are – 

• The very first step is to analyze the business domain in order to get a proper understanding of the application’s functional requirements. Once this step is performed, as a result, the software engineers will get an informal description of the domain which can be reframed and converted into a formal set of service domain models.
• The next step is to define the domain’s bounded contexts. Here, each bounded context holds one domain model that represents a subdomain of an app. 
• After this, tactical DDD patterns must be applied within the bounded context, so that they can be helpful in defining patterns, aggregations, and domain services.
• The last step is to use the outcome from the previously performed step to identify the app’s microservices.

This shows that the use of the DDD approach enables the developers to design every microservice within a particular boundary and also helps in avoiding the trap that creates boundaries for business organizations or enables them to choose the designs. It enables the development team to keep a close observation of code creation. 

Step 2: Identify Boundaries and Define the Microservices

After setting the bounded contexts for the application and analyzing the domain model in the first step, now is the time to jump from the domain model to the application model. And for this, there are some steps that are required to be followed in order to derive services from the domain model. The below-listed steps help the development team to identify the microservices from the domain model. 

• To start with this process, first, one needs to check the functionalities required in the service and must confirm that it doesn’t span more than one bounded context. And as per the definition, the bounded context marks any particular domain model’s boundary. This basically talks about whether the software development teams want to find out that the microservices used in the system are able to mix different domain models or not. If yes, then domain analysis must be refined in order to make the microservices carry on their tasks easily.
• After that, the team needs to look at the domain’s aggregates. Generally, aggregates are known as good applicants for services and when they are well-defined, they have different characteristics –
  1. High functional cohesion
  2. Derived from business requirements and not technical concerns
  3. Loosely coupled
  4. Boundary of persistence
• Then the team needs to check domain services. These services are stateless operations that are carried out across various aggregates.
• The last step is to consider non-functional requirements. Here, one needs to check factors like data types, team size, technologies, requirements, scalability, and more. The reason behind checking these factors is that they lead to the further decomposition of microservices into smaller versions.

After checking and identifying the microservices, the next thing to do is validate the design of microservices against some criteria to set boundaries. For that, check out the below aspects – 

• Every service must have a single responsibility.
• There should not be any chatty calls between the microservices.
• In lock-step, no inter-dependencies require the deployment of two or more services.
• Small independent teams can create a service as it is small and simple.
  1. Services can evolve independently as they are not tightly coupled.

Step 3: Approaches to Build Microservices

The next step is to use any of the two widely used approaches to create microservices. Let’s go through both these approaches.

Service Orchestrators

Service orchestrator is an approach that helps in handling tasks that are related to managing and deploying a set of services. These tasks include: 

• Health monitoring of the services 
• Placing services on nodes 
• Load balancing 
• Restarting unhealthy services 
• Service discovery 
• Applying configuration updates
• Scaling the number of service instances. 

Some of the most popular orchestrators that one can use are Docker Swarm, Kubernetes, DC/OS, and Azure Service Fabric.

When the developer is working on the Microsoft Azure platform for microservices, consider the following options: 

Serverless

Serverless architecture is a concept that makes it easier for the developers to deploy code and host service that can handle putting and executing that code onto a VM. Basically, it is an approach that helps coordinated functions of the application to handle the events with the use of event-based triggers. For instance, when a message is placed in a queue the function that reads from the queue and carries out the messages might get triggered.

In this case, Azure Functions are serverless compute services and enable support to various function triggers such as Event Hubs Events, HTTP request, and  Service Bus queues.

Orchestrator or Serverless?

Some of the factors that give a clear idea of the differences between an orchestrator approach and a serverless approach are –

Step 4: Establish Communication between Microservices

When it comes to building stateful services or other microservices applications architecture, communication plays an important role. The reason behind it is that the communication between microservices must be robust and efficient in order to make the microservices application run smoothly. And in such types of applications, unlike traditional monolithic applications, various small and granular services interact to complete a single business activity, and it can be challenging. A few of these challenges are – resiliency, load balancing, service versioning, distributed applications tracing, and more. To know more about these challenges and possible solutions, Let’s go  through the following table –

But with the right use of Azure and Azure SQL databases, strong communication can be established without any issue. And for this, there are two basic messaging patterns with microservices that can be used. 

• Asynchronous communication: In this type of pattern, a microservice sends a message without getting any response. Here, more than one service processes messages asynchronously. 
• Synchronous Communication: Another type of pattern is synchronous communication where the service calls an API that another microservice exposes with the use of protocols like gRPC and HTTP. Also the caller service waits for the response of the receiver service to proceed further.  

Step 5: Design APIs for Microservices

 Designing good APIs for microservices is very important because all data exchange that happens between services is either through API calls or messages. Here, the APIs have to be efficient and effective to avoid the creation of chatty I/O. 

Besides this, as the microservices are designed by the teams that are working independently, the APIs created for them must consist of versioning and semantic schemes as these updates should not break any other service.

Here the two different types of APIs that are widely designed –

• Public APIs: A public API must be compatible with client apps which can be either the native mobile app or browser app. This means that the public APIs will mostly use REST over HTTP.
• Backend APIs: Another type of API designed for microservices is backend API which depends on network performance and completely depends on the granularity of the key services. Here interservice communication plays a vital role and it can also result in network traffic.

Here are some things to think about when choosing how to implement an API.

Step 6: Use API Gateways in Microservices

In microservices architecture, it generally happens that a client might interact more with the front-end service to know how a client identifies which endpoints to call or what might happen if existing services are re-engineered or new services are introduced. For all these things, an API gateway can be really helpful as it helps in addressing the defined challenges. An API gateway resides between the services and the clients which enables it to act like a reverse proxy for routing requests from the client side of the application to the services side. Here, it also performs many cross-cutting tasks like rate limiting, SSL termination, and authentication.

Basically, by using an API gateway in the microservices architectural approach, clients will have to send requests directly to front-end services if there is no deployment of a gateway. Here are some of the issues that might occur while exposing services directly to the application’s client-side –

• There can be complexity in the client code for which the client will have to keep a track of various endpoints and also resiliently handle failures.
• When a single operation is carried out, it might require various calls for multiple services and this can result in round trips of multiple networks between the server and the client. 
• Exposing services can create coupling between the front end (client-side) and the back end. And in this case, the client requires to have knowledge about the process of individual services being decomposed. This makes it difficult to handle the client and refactor services. 
• Services that have public endpoints are at the attack surface and require to be hardened. 
• Services must expose protocols like WebSocket or HTTP that are client-friendly and this limits the communication protocol choices. 

But with the right API gateway usage in services, the team can achieve business needs. The reason behind this is that a gateway can help in addressing these issues from services by decoupling the clients. Gateways have the capability to perform various functions and they can be grouped into the following design patterns – 

Some of the major examples of functionalities that can be offloaded by the development team to a gateway are – 

• Authentication
• SSL termination
• Client rate limiting (throttling)
• IP allow list or blocklist
• Response caching
• Logging and monitoring
• GZIP compression
• Web application firewall

For implementing an API gateway to the application, here are some major options – 

Step 7: Managing Data in Microservices Architecture

The next step is managing the data centers in service architecture. Here one can use the single responsibility principle.  This means that each service is responsible for its own data store which is private and cannot be accessed by other services. The main reason behind this rule is to avoid unintentional coupling in microservices as it can result in underlying data schemas. And when a change occurs to the data schema, it must be coordinated across each service that depends on that database.

Basically, if there is isolation between the service’s data store, the team can limit the scope of change and also safeguard the agility of independent deployments. Besides this, each microservice might have its own queries, patterns, and data models which cannot be shared if one wants to have an efficient service approach.

Now let’s go through some tools that are used to make data management in microservices architecture an easy task with Azure –

Step 8: Microservices Design Patterns

The last step in creating microservice architecture using Azure is design patterns that help in increasing the velocity of application releases and this can be done by decomposing the app into various small services which are autonomous & deployed independently. This process might come with some challenges but the design patterns defined here can help mitigate them –

• Anti-Corruption Layer: It can help in implementing a facade between legacy and new apps to ensure that the new design is not dependent on the limitations of legacy systems.
• Ambassador: It can help in offloading common client connectivity tasks like routing, monitoring, logging, and more.
• Bulkhead: It can isolate critical resources like CPU, memory, and connection pool for each service and this helps in increasing the resiliency of the system.
• Backends for Frontends: It helps in creating separate backend services for various clients like mobile or desktop.
• Gateway Offloading: It helps each microservice to offload the service functionalities that are shared.
• Gateway Aggregation: It aggregates single service requests to various individual microservices so that chattiness can be reduced.
• Gateway Routing: It helps in routing requests to various microservices with the use of a single endpoint.
• Strangler Fig: It enables incremental refactoring by slowly replacing the functionalities of an application.
• Sidecar: It helps in deploying components to offer encapsulation and isolation.

4. Conclusion

As seen in this blog, microservices architecture is very beneficial to develop large applications by accommodating various business needs, and using cloud infrastructure like Azure can enable easy migration from legacy applications. Azure and various tools can help companies to create and manage well-designed microservices applications in the competitive market.

5. Frequently Asked Questions about Azure Microservices:

1. What are Azure Microservices?

Microservices refers to the architectural methodology employed in the development of a decentralized application, wherein multiple services that execute specific business operations and interact over web interfaces are developed and deployed independently.

2. What are the Different Types of Microservices in Azure?

• Azure Kubernetes Service (AKS): The Kubernetes control plane is hosted and maintained by the Azure Kubernetes Service (AKS), which is a governed Kubernetes service.
• Azure Container Apps: The Azure Container Apps service simplifies the often-tricky processes of container orchestration and other forms of administration.
• Service Fabric: Microservices can be put together, deployed, and managed with the help of Service Fabric, which is a distributed systems platform. 

3. How do I Use Microservices in Azure?

Step-1: Domain analysis

The use of domain analysis to create microservice boundaries helps designers avoid several errors. 

Step-2: Design the services

To properly support microservices, application development must shift gears. Check out Microservices architecture design to learn more.

Step-3: Operate in production

Distributed microservices architectures need dependable delivery and monitoring mechanisms.

4. Is an Azure Function a Microservice?

Azure functions have the capability to be employed within a microservices architectural framework; however, it is important to note that Azure functions do not inherently possess the characteristics of microservices.

5. How Microservices are Deployed in Azure?

Build an Azure Container Registry in a similar place as your microservices and connect it to a resource group for deploying them. Deployed container instances from your registry will run on a Kubernetes cluster.