First blog post of the AKS series explains to setting up Azure Kubernetes Services (AKS) with Advanced Networking & Application Routing. This current blog post would be exploring Application Deployment and Packaging using Helm on Azure Kubernetes Services.
Helm faciliate and helps to manage Kubernetes applications efficiantly. Helm Charts helps to define, package, install, upgrade, roll-back, delete most complex Kubernetes applications. Helm is incubated and maitained by CNCF and ofcoursed backed up by big technology giants such as Microsoft, Google, Bitnami, etc. There are already many popular projects offering out-of-the-box Helm Charts, a GitHub Repository (kubernetes/charts) would be a good starting point.
Kubernetes is an open-source system for orchestrating containerised applications. Kubernetes builds upon decade plus years of experience running workloads at Google and practices from the community.
This blog post is going to demonstrate, “How to getting started with Advanced Networking and AKS in Azure”. During the blog post, we would be creating following Azure artefacts,
For the blog post, Azure Portal as primary tool choice for creating and provisioning Azure Resources. For production and more serious implementations, I would recommend ARM and Automation for provisioning and configuring these artefacts.
Containers provides unique value for Microservices implementation. I am not trying to open a debate on computing options in the article. The scope of the article is to enable you and get you started with .NET Core Microservices using Kubernetes and Azure Container Registry.
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes is the production ready container orchestration open-source system. The Kubernetes project is becoming very popular among enterprise scale implementation for its execution ability. Automatic Binpacking, Self-healing, Scaling, Service Discovery, Automation, Configuration & Secret Management and Orchastrative Abilities are some of exciting selling points of the Kubernetes project.
Kubernetes is available (Generally Available) on Azure Container Service ( reference ). Azure Container Service (ACS) is a container hosting environment optimised for Azure, and it leverages the technologies such as Docker, Apache Mesos and open source components of DCOS.
Docker would play a vital role as part of your development pipeline. Azure Container Registry supports
docker format. Therefore, the journey would be similar as DockerHub. Development Pipeline can benefit by tagging images for target environments (i.e.
:prod). Ideally, I recommend keeping the Container Images light-weight as possible and prefer layering them instead of going two step backwards by creating a monolithic image. I am restraining myself opening up the topic, but I will try to write a separate blog post on the subject.
The article splits into following sections,
App Service, Service Fabric and Serverless Azure Function are becoming flagship computational service for Microsoft Azure. I am trying to find an economical benchmark for Computing in Azure. It is not a straight-forward task, but I am employing a simple methodology to find cost/computing rational between all three computational platforms.
Following is the highest throughput and zero error load test’s summary out 5 various load patterns for Azure App Service Server Farm of 3 instances.
|Hourly Cost (3 x Instances)||0.131183505 GBP x 3 =|
0.393550515 GBP per Hour
|Hourly Test Count||579,600 Api Calls||Load Test Stats & Profile|
|Zero-Fault Average CPU Consumption||91.490875%||Performance Stats|
App Services, Service Fabric and Serverless Azure Function are becoming flagship computational services for Microsoft Azure. I am trying to find an economical benchmark for Computing in Azure. It is not a straight-forward task, but I am employing a simple methodology to find cost/computing rational between all three computational platforms.
Following is the highest throughput and zero error load test’s summary out 5 various load patterns.
|Hourly Cost (3 x Nodes)||0.305159022863118 per Hour||Azure Pricing|
|Hourly Test Count||687600 Api Calls||Load Test Stats & Profile|
|Zero-Fault Average CPU Consumption||88.234625%||Performance Stats|
Networking and Security could be challenging in the Cloud but at any point that doesn’t make the Cloud Solutions less secure. The key is to understand the shift in the paradigm. As someone quoted to me “Rules are same but Methods changed” - and I could not agree more. In this article, I would like to discuss Network and Perimeter security for Azure IaaS, Cloud Services and Service Fabric.
Network and Perimeter is undoubtedly one of the important aspects that you would like to cover within your Cloud Cyber Security blueprint. Especially, public clouds (i.e. Azure, AWS) also increase the threat perception due to openness of accessibility. I am going to demonstrate the security pattern with Zero-Knowledge Virtual Appliance in Azure, securing Service Fabric and the topology of IaaS (Service Fabric Node).
This guide would demonstrate the steps to connect Service Fabric Nodes or VM Scale Set Instances in the cloud or the hybrid infrastructure to OMS Workspace. Microsoft Monitoring Agent (MMA) enables rich and real-time analytics for operational data (Logs, Performance, Alerts and Inventory) from a tenant.
You can install agents using Installer (manually on the physical machine), Resource Manager Template, Resource Manager CLI/PowerShell and Desired State Configuration (DSC). If you are considering a general best practice for VMSS instances and Service Fabric nodes, then Azure Resource Manger Templates would be an ideal option in my opinion.
Microsoft Monitoring Agent extension can be defined in Azure Resource Manager template
virtualMachineProfileensures consistency across VM cluster.