Container and Serverless with Azure

Author: Yu Li

Microsoft Azure and its ecosystem offer a very wide range of services in terms of container services and serverless computing. The diversity of the public cloud offering not only brings flexibility, efficiency and innovation, but also poses challenges for many cloud architects and public cloud managers when it comes to architectural decisions. Hip technologies like Kubernetes and Serverless are not necessarily the solution to all problems. In which scenarios should which service be applied? In this blog you will find the thoughts and experiences of ipt.

Which service for which scenario?

To give you a clear overview of the topic, the figure below shows five relevant Microsoft Azure Services in the context of containers and serverless, as well as their core functions and possible deployment scenarios.

The selected Azure services cover one or more of the following core tasks:

• Container Service includes the functions to operate a container, from networking, security and scaling to deployment. 
• Orchestration includes the management functions of multiple containers, such as deployment and rollback of containers, scale-out and custom scaling, allocation of host resources to containers, load balancing, and monitoring. 
• Serverless is a cloud-native capability that allows developers to build and run applications without having to manage servers.
• Hybrid cloud is where the public cloud and private cloud are managed in a unified way. 

The figure also shows the corresponding deployment scenarios of the following five products:

• Azure App Service for Containers runs containerized applications in a fully managed manner and offers features such as AuthN/AuthZ and CI/CD. Azure App Service for Container also enables integration with Azure Active Directory, or even Facebook and Google for authentication and authorization out-of-box. A so-called "Easy-Auth" side-car container [1] is deployed alongside the application container to handle the AuthN/AuthZ logic queries. Azure App Service for Containers also provides out-of-box integration to Azure Container Registry and various code repo providers such as Github when deploying. Therefore, either container images or source codes with a Dockerfile are accepted as input for deployment. Despite many advantages, this platform reaches its limits when it comes to operating and managing applications that consist of multiple microservices.

Recommendation 1

Deploy Azure App Service for Containers for a simple application with few microservices.

Recommendation 2

Use Azure App Service for Container to start the project when the business requirements and technical complexity are still unclear.

• Azure Kubernetes Service is the managed Kubernetes service from Microsoft and is suitable for complex applications based on a microservice architecture. The core function of AKS (Azure Kubernetes Service) is container orchestration, which covers many aspects from deployment to scaling to monitoring. During deployment, Kubernetes ensures that all container services of the application are deployed simultaneously with a new version. In the event of a failure, these can be synchronized and rolled back to the last version. AKS also ensures that only individual microservices, rather than the entire application (all microservices), are scaled during peak loads based on metrics such as CPU, memory or queue fullness.

Recommendation 3 

Deploy Azure Kubernetes service for complex applications. Complex in this case means that the application consists of multiple microservices and is often developed by different teams.

• Azure Red Hat Openshift is one of the most popular Kubernetes variants and is used by many companies for their private cloud. For some time now, Openshift has also been available on Azure in a managed version. Out-of-the-box, Openshift offers many enterprise-friendly features such as monitoring, logging and CI/CD. Unlike Azure Kubernetes service, where these are integrated with . Services such as Azure DevOps (CI/CD) or Azure Monitor need to be covered. However, Openshift also charges a corresponding price for this. In addition to the infrastructure costs (VMs), license costs (around $124 for a D4s v3 VM) must also be paid. In comparison, AKS does not incur any license costs in addition to the infrastructure costs [2][3]. Moreover, AKS is already fully integrated into the Azure ecosystem, for example through Azure DevOps or Azure Monitor Security Center. In this respect, an informed consideration makes perfect sense.

Recommendation 4

Consider Azure Red Hat Openshift if you are already using Openshift for private cloud and on-prem and have a hybrid cloud strategy.

• Azure Functions is the serverless offering from Microsoft Azure. When using Azure Functions, Microsoft Azure takes over the operation and scaling of the code logic, allowing the DevOps team to focus on the functional requirements. For logging and monitoring, Azure Function provides built-in integration with Application Insights. For CI/CD, many options are supported, such as Azure Pipelines or GitHub Actions. With numerous triggers and bindings, you can integrate other services such as Azure Storage Account with little effort. For scaling, Azure Functions automatically scale as needed; scaling is handled entirely by cloud providers. However, there are downsides to using Serverless, such as vendor lock-in and latency. For more details on the pros and cons of Serverless, see my blog post Cloud-Native! But How? Containers vs Serverless.

Recommendation 5

Serverless is not suitable for every situation. You will get the most benefit from Azure Functions if you follow an event-driven architecture.

• Azure Container Instance + Virtual Nodes is a combination that enables the Azure Kubernetes service to scale in seconds and with ease. Azure Container Instances (ACI) are managed services for running short-lived container instances. Among other things, ACI caches the base operating system image to accelerate the deployment of short-lived container workloads. ACI enables much faster scaling compared to Azure App Service for containers or VMs. Further, Azure Virtual Nodes acts as a good complement to Azure Container Instance. Azure Kubernetes Services integrate with Azure Container Instance at the network layer, extending the Kubernetes API in this way, which can support Azure Container Instance. The combination of Azure Container Instance and Virtual Nodes allows for faster response to peak loads by not having to create VMs to scale up. This combination is also Microsoft's approach to evolve Azure Kubernetes Services to Serverless Kubernetes.

Recommendation 6

Consider using the Azure Container Service and Virtual Nodes combination for applications with many peak loads or isolated calls.

Conclusion

The optimal selection of services in cloud-native development is critical to project success. Choosing an "aircraft carrier" service for a "rubber boat" problem increases cost and complexity, this metaphor also applies to cloud-native development. A clear overview of Azure-native services and a strong understanding of their advantages and disadvantages helps to make the right architectural decision.

Sources

[1] Microsoft App Service Easy Auth. 

[2] Pricing Azure Openshift

[3] Pricing Azure Kubernetes Service