Microservice Architecture:

Microservices-based application architecture represents a collection of small, autonomous, and self-contained services which are built to serve a single business functionality/capability.

The following is a sample microservices-styled application landscape representing a set of microservices. Pay attention to different microservices accessed through the API gateway.

What are microservices?
Microservices also known as the microservice architecture is an architectural style that structures an application as a collection of services that are,

• Highly maintainable and testable
• Loosely coupled.
• Independently deployable
• Organized around business capabilities.
• Owned by a small team.

The microservice architecture enables the rapid, frequent, and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

• In this method, we easily define, deploy, debug and upgrade microservices applications and automatically containerize our applications.
• All the services are separated based on their domains and functionalities and are further allotted to individual microservices.
• These microservices have their own load balancer and execution environment to execute their functionalities, at the same time captures data in their own databases.

Microsoft Azure Kubernetes Serviceshas its own components which matches these requirements for implementing microservices architecture:
IP address: IP Address are assigned to pods where each micro service will be deployed, and which is available all the time.

Load balancing: All the service request traffic sent to load balancing server from there it is sent to the respective API gateway based on the availability of the resources which in term will redirect to the specific services.

Service discovery: All the microservices are assigned to the DNS entries which will be used by API Gateway to identify the services dynamically based on the request from client and redirect it to the specific services.

API Gateway: API gateway sits between clients and microservices, it is responsible for redirecting the services request from the clients to the services.

API Gateway can be implemented using number of different technologies such as Nginx, Azure Application Gateway, and Azure API management.

Scalability Considerations: Kubernetes supports two level of scaling PODS and Nodes. Manually we can do the scaling of resources, but the recommendation is to automate it since when the resource utilization is high the service will not be available which should not happen in real time.

Microservices in AKS:
AKS to simplify the deployment and management of microservices-based architecture. AKS streamlines horizontal scaling, self-healing, load balancing, and secret management.
This reference architecture shows a microservices application deployed to Azure Kubernetes Service (AKS). It describes a basic AKS configuration that can be the starting point for most deployments.
This article assumes basic knowledge of Kubernetes and focuses mainly on the infrastructure running a microservices architecture on AKS.

The architecture consists of the following components:
Clients — Different users from various devices like mobile app, tab and browsers will access the applications.

Microsoft Azure Kubernetes Service (AKS). AKS cluster is a managed container orchestration service available in the Microsoft Azure environment to implement microservices architecture application.

Azure load balancer: Azure load balancer is created and configured with our public IP address and all the traffic is redirected to azure load balancer and it’s responsible to redirect to specific API Gateway based on the load.

Azure Active Directory: AKS uses AD Identity to create and manage azure services required while creating the Kubernetes clusters. Azure AD can be used to authenticate users for accessing the applications installed in the POD.

Nodes: AKS cluster has one or more node which is an Azure Virtual Machine.

Pods: AKS pod is responsible for running the application basically it’s an instance of your application.

Data Storage: Microservices architecture should not share storage data between one service to another services. Microservices should be independent to each other services so at any point of time any service can be developed, build and deployed independently. Data should not be stored in the local cluster because it will be lost when we do the deployment always, data should be stored in some external services Azure SQL.

Azure Container Registry: Use Container Registry to store private Docker images, which are deployed to the cluster. AKS can authenticate with Container Registry using its Azure AD identity. Note that AKS does not require Azure Container Registry. You can use other container registries, such as Docker Hub.

Azure Key Vault: In AKS, we can mount one or more secrets from Key Vault as a volume. The volume reads the secrets from Key Vault. The pod can then read the secrets just like a regular volume.
The pod authenticates itself by using either a pod identity (described above) or by using an Azure AD Service Principal along with a client secret. Using pod identities is recommended because the client secret is not needed in that case.

Azure Monitor: This will collect all the data from the different azure services like metric and logs. We can user this data to monitor the health of the application, setting up alerts on any azure service failure and do the analytics on the data which is collected from different azure services.

Container and Orchestrator security:
Threat Monitoring:
Monitor for threats using Azure Defender for container registries and Azure Defender for Kubernetes (or 3rd party capabilities). If you are hosting containers on a VM, use Azure Defender for servers or a 3rd party capability. Additionally, you can integrate logs from Container Monitoring solution in Azure Monitor to Azure Sentinel.

Vulnerability monitoring — Continuously monitor images and running containers for known vulnerabilities using Azure Security Centre or a 3rd party solution available through the Azure Marketplace.

Automate image patching — Using ACR Tasks, a feature of Azure Container Registry. A container image is built up from layers. The base layers include the OS image and application framework images, such as ASP.NET Core or Node.js.

Store images in a trusted private registry — Such as Azure Container Registry or Docker Trusted Registry. Use a validating admission webhook in Kubernetes to ensure that pods can only pull images from the trusted registry.

Azure DevOps CI & CD Process In AKS:

In this architecture diagram we describe the Azure DevOps pipelines features to help our application to get build with Docker containers and deploy them to Azure Kubernetes clusters (AKS) using Azure DevOps CICD.

AKS Deployment Strategy:
1. Developer pushes the source code to Azure repository.
2. Azure pipeline triggers the build by cloning the application code from Azure repo to either Microsoft hosted build agent or self-managed build agents.
3. Azure build agents are going to build the job and generates deployable artifacts, which can be pushed to a drop location in artifact staging directory.
4. Azure pipeline creates docker image with application code artifacts, tag the image, and push to Azure container registry.
5. Azure pipelines tag the application code that was containerized and pushes the code to Azure repo.
6. Azure release pipeline executes the kubectl commands to re/deploy pods.
7. Redeployment process starts by pulling the latest image from the Azure container registry to AKS pods.

Azure DevOps Build Pipeline for Continuous integration:

Build pipeline for Kubernetes usually contains the steps that will fetch the code, build the Docker image, push that image to your Docker repository and then publish the artifacts.
Get sources from your favourite code repository, Microsoft supports most of the options with ready interfaces for even authenticating and choosing the right repository and default branch.
Define the agent you want to run for building your code (Windows agent, Ubuntu agent).

• Choose the Docker “Build an image” task, choose the Azure container registry with Azure subscription and the name of the registry, then choose the docker file name.
• Choose the task for docker image push. Also provide Azure container registry information where we can upload docker images for further AKS deployment process.
• Choose the “Copy files” step to copy the files to an artifact staging directory and we will only need to copy the deployment file that we will talk about next in the deployment section.
• Choose Publish build artifacts step to drop deployment file(.yaml).

Azure DevOps Release Pipeline for Continuous Deployment:
The release pipeline usually used to put the correct build to its correct running environment.
In our scenario usually, starts by reading the Artifacts from the build pipeline and fires one of the pipeline stages according to the build code branch.

• Release stage will be enough with only two tasks, one of them to copy the building code to the deployment yaml file so we can choose the right docker version for the release, and there is a ready pre-defined step for that purpose which is “Replace Tokens”. All you need to do is to select the deployment file from the Artifacts using “Root Directory” and “Target files” fields.
• Next you can use “Deploy to Kubernetes” ready task from the templates, that task actually will only run Kubectl apply command on your deployment file. From the “Configuration file” field you can choose the deployment file.
• The deployment file will define a deployment in the AKS mesh that will take the last Docker image and deploy it to the mesh (After we inject the build id with the previous step).