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. 

Build resilient, highly-scalable, independently deployable, and easily-evolved applications with #Azure microservices. A successful microservices architecture requires a different approach to designing and building applications. Read more here:https://t.co/pjCFEDnYvq pic.twitter.com/D6k2dkNiN7

— Azure Support (@AzureSupport) October 26, 2020

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: 

Service	Description
Azure Containers Apps	A managed service built on Kubernetes. It abstracts the complexity of container orchestration and other tasks.  It simplifies the deployment process of containerized apps and microservices in the serverless environment.
Azure Service Fabric	A distributed systems platform to manage microservices. Microservices can also be deployed to service fabric as containers, or reliable services.
Azure Kubernetes Services (AKS)	A managed K8s (Kubernetes) service.  It provisions and exposes the endpoints of Kubernetes API but manages and hosts the Kubernetes automated patching, Kubernetes control plane, and performing automated upgrades.
Docker Enterprise Edition	It can run in the IaaS environment on Azure.

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 –

Comparison Aspects	Orchestrator	Serverless
Manageability	An orchestrator is something that might force the development team to think about various issues like networking, memory usage, and load balancing.	Serverless applications are very simple and easy to manage as the platform itself will help in managing all resources, systems, and multiple subsystems.
Flexibility	An orchestrator offers good control over managing and configuring the new microservices and the clusters.	In serverless architecture, a developer might have to give up some degree of control as the details in it can be abstracted.
Application Integration	In Orchestrator, It can be easy to integrate applications as it provides better flexibility.	It can be challenging to build a complex application using a serverless architecture because it requires good coordination between managed services, and independent components.
Cost	Here, one has to pay for the virtual machines that are running in the cluster.	In serverless applications, payment for only actual computing resources is necessary.

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 –

Challenges	Possible Solutions
Resiliency	Microservices can fail because of many reasons like hardware, VM reboot, or node-level failures. To avoid it, resilient design patterns like retry and circuit breaker are used.
Load Balancing	When one service calls another, it must reach the running instance of the other service. Kubernetes provides the stable ip address for a group of pods.  This gets processed by iptable rules and a service mesh that offers an intelligent load-balancing algorithm based on observed latency and few other metrics.
Service Versioning	Deploying a new service version must avoid breaking other services and external clients that depend on it.  Also, you may be required to run various versions of the service parallel, and route the requests to a particular version. For the solution, go through the next step of API versioning in detail.
Distributed Tracing	Single transactions extend various services which make it difficult to monitor the health and performance of the system. Therefore, distributed tracing is a challenge.  For the solution, follow these steps: Assign unique external id to each external request  Include these external Ids in all log messages Record information about the requests.
TLS Encryption and Authentication	Security is one of the key challenges.  For the same, you must encrypt traffic between services with TLS, and use mutual TLS authentication to authenticate callers.

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.

Considerations	Details
REST API vs RPC	It is a natural way to express the domain and enables the definition of a uniform interface that is based on HTTP verbs. It comes with perfectly defined semantics in terms of side effects, idempotency, and response codes. RPC is more oriented around commands and operations. RPC is an interface that looks just like the method calls and enables the developers to design chatty APIs. For the RESTful interface, select REST over HTTP using JSON. And for RPC style interface, use frameworks like gRPC, Apache avro, etc.
Interface Definition Language (IDL)	It is a concept that is used to define the API’s parameters, methods, and return values. It can be used to create client code, API documentation, and serialization.
Efficiency	In terms of memory, speed, and payload size efficiency is highly considered.
Framework and Language Support	HTTP is supported in every language and framework. gRPC, and Apache Avro all have libraries for C#, JAVA, C++, and Python.
Serialization	Objects are serialized through binary formats and text-based formats. Some serialization also requires some compiling of a schema definition file and fixed schema.

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 – 

Gateway Design Patterns	What do They do?
Gateway Aggregation	It is used to aggregate various individual requests into one single request. Gateway aggregation is applied by the development team when a single operation requires calls to various backend services.
Gateway Routing	This is a process where the gateway is used as a reverse proxy for routing requests to a single or more backend service with the use of layer 7 routings. Here, the gateway offers clients a single endpoint and decouples clients from services.
Gateway Offloading	Here, the usage of the gateway is done to offload functionalities from various individual services. It can also be helpful in consolidating the functions in one place rather than making all the services in the system responsible for the implementation of the functions.

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 – 

API Gateway Implementation	Approach
Azure Application Gateway	It is a concept that helps in handling load-balancing services that consist of the capability to perform SSL termination and layer-7 routing. This gateway also offers WAF.
Azure API Management	This implementation approach is known as the turnkey solution which can be used while publishing APIs to both internal and external customers.  Features of this approach are beneficial in handling public-facing APIs like authentication, IP restrictions, rate limiting, and more.
Azure Front Door	Azure Front Door is a modern cloud Content Delivery Network that offers secure, reliable, and fast access between the application’s dynamic and static web content and users. It is an option used for content delivery using a global edge network by Microsoft.

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 –

Tools	Usage
Azure Data Lake	With Azure Data Lake, developers can easily store data of any shape, size, and speed for processing and analytics across languages & platforms. It also removes the complexities of storing and ingesting data by making it faster to run the data with streaming, batch, and interactive analytics.
Azure Cache	Azure Cache adds caching to the applications that have more traffic and demand to handle thousands of users simultaneously with faster speed and by using all the benefits of a fully-managed service.
Azure Cosmos DB	Azure Cosmos DB is a cloud-based, and fully managed NoSQL database. This relational database offers a response time of single-digit milliseconds and guarantees speed & scalability.

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.