Building Microservices on Azure

  1. Home
  2. Building Microservices on Azure

Go back to AZ-304 Tutorials

Microservices are for building applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. However, a microservices architecture contains a collection of small, autonomous services that implements a single business capability.

Microservices architecture
Image Source: Microsoft

Overview of Microservices

  • Microservices are small, independent, and loosely coupled using which a single small team of developers can write and maintain a service.
  • Secondly, each service is a separate codebase, that can be managed by a small development team.
  • Thirdly,the services can be deployed independently. In other words, the team can update an existing service without rebuilding and redeploying the entire application.
  • These services are responsible for persisting their own data or external state. As this differs from the traditional model, where a separate data layer handles data persistence.
  • Moreover, the services communicate with each other by using well-defined APIs. And, they don’t need to share the same technology stack, libraries, or frameworks.

There are some other components appear in a typical microservices architecture:

Management/orchestration:

This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. However, this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

API Gateway:

The API gateway is a direct calling services, clients call the API gateway, which forwards the call to the appropriate services on the back end.

AZ-304 Practice tests

Benefits

  • Firstly, it’s easier to manage bug fixes and feature releases. You can update a service without redeploying the entire application, and roll back an update if something goes wrong. 
  • Secondly, a microservice should be small enough that a single feature team can build, test, and deploy it. Small team sizes promote greater agility. Large teams tend to be less productive, because communication is slower, management overhead goes up, and agility diminishes.
  • Thirdy, it has a small code base as adding a new feature requires touching code in a lot of places. So, by not sharing code or data stores, a microservices architecture minimizes dependencies.
  • Fourthly, teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.
  • Then, it provides Scalability. Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. 
  • Lastly, Data isolation. It is much easier to perform schema updates, because only a single microservice is affected. 

Challenges

The benefits don’t come for free. Some of the challenges to consider on a microservices architecture are:

  • Firstly, a microservices application has more moving parts than the equivalent monolithic application. 
  • Secondly, Development and testing. Writing a small service that relies on other dependent services requires a different approach than writing a traditional monolithic or layered application. 
  • Thirdly, Lack of governance. The decentralized approach to building microservices has advantages, but it can also lead to problems. You may end up with so many different languages and frameworks that the application becomes hard to maintain. 
  • Lastly, Network congestion and latency. As there is use of many small, granular services that can result in more interservice communication. However,  if the chain of service dependencies gets too long then  latency can become a problem. You will need to design APIs carefully.

Process for building a Microservices architecture

In this you will get a structured approach for designing, building, and operating a micro-services architecture.

Domain analysis

For avoiding some common pitfalls when designing microservices, use domain analysis for defining your microservice boundaries. Follow these steps:

  • Firstly, use domain analysis to model microservices.
  • Secondly, use tactical DDD to design microservices.
  • Lastly, identify microservice boundaries.
Design the services

Microservices require a different approach to designing and building applications. 

Operate in production

As microservices architectures are distributed, so you must have robust operations for deployment and monitoring.

  • Firstly, CI/CD for microservices architectures
  • Secondly, build a CI/CD pipeline for microservices on Kubernetes
  • Thirdly, monitor microservices running on Azure Kubernetes Service (AKS)
Az-304 online course

Reference: Microsoft Documentation

Go back to AZ-304 Tutorials

Menu