Azure FinOps using Terraform and Infracost - Finding the hourly or monthly cost before Azure DevOps Deployments

A while ago i created a demo for Azure VWAN using  terraform and Azure DevOps. I dive headfirst without realizing that i am using premium SKU for firewalls and my Dev teant is shutdown for a month in few days due to my billing cap of 230 NZD.

Next time when i create a demo for APIM instances, i dint realize Premium SKU costs 7500 NZD/month. Even before i finish my POC, the teant again shutdown in few hours this time.

Our objective is to find the cost of the IAC we are deploying even before we deploy. 

In this post i will show how we can utilize Infracost a opensource plugin in both VSCode and how we can make it part of our Azure DevOps pipelines to manage cost of the resources we are going to deploy.

Like this :

or like this:

Azure DevOps Self-Hosted Agents Automation Using Packer and Terrafrom

In Azure DevOps, "self-hosted agents" refer to agent machines that you set up and manage yourself, instead of using Microsoft-hosted agents. These self-hosted agents can be beneficial in various scenarios:

    Security and Compliance: In some organizations, data security and compliance policies may require running build and deployment processes on infrastructure managed within their own network.

    Access to Internal Resources: Your build and deployment processes may require access to internal resources (databases, network drives, etc.) that are not accessible from external Microsoft-hosted agents.

    Performance and Customization: Self-hosted agents can be tailored to specific hardware configurations, which might be necessary for resource-intensive builds or specialized build environments.

    Cost Management: Azure DevOps provides a certain number of free Microsoft-hosted parallel jobs, but if you have large-scale or resource-intensive projects, self-hosted agents can be more cost-effective in the long run.

    Reducing Build Queue Times: When using Microsoft-hosted agents, you share resources with other users, which might result in longer build queue times. Self-hosted agents allow you to control the resources dedicated to your builds, potentially reducing waiting times.

    Offline Environments: If you have environments without continuous internet access, self-hosted agents can be used to facilitate builds and deployments within those isolated networks.

In this post i will be:

1. Generating a Managed VM Image using Packer.
2. Saving the Managed image to a Image gallery within my tenant.
3. Create a Virtual Machine Scale Set(VMSS) from the said image.
4. Register the VMSS as DevOps Self-Hosted agents.
5. Run a time intensive project using self-hosted pool to see how VMSS will autoscale.
6. Then update the VM image with new build and see how we can update the existing Self-hosted agents.

Terraform Azure Application Landing Zone - TF AZ Bootstrap

Objective: This post is to provide a kick strat your Azure DevOps journey by providing a Seed Repo for your Azure DevOps organization. Every time when a new application is about to be launched into Azure, you have to go through the provisioning of launchpad and Devops Repo and building the CI/CD pipelines. Below project will address all of those concerns. 

Now i want to create similar thing and add couple of more steps and make it avilable for everyone.

Here is what you gona get.

Deploying Virtual WAN using Terraform & Azure DevOps

Let me summarize Azure networking options based on usecase:

• You need network connectivity between resources across different virtual networks in same region, you need to implement VNet peering.
• You need connectivity between resources in virtual networks spanned across different region, you need to implement Global VNet peering.
• You need network connectivity between your Organization (On-Prem) and your azure tenant and you are ok to have the secure channels over the internet, You need to implement site to site VPN gateways.
• You want network connectivity between your offices to azure tenancy with high throughput and not over internet, you need to implement Express Route.
• You need individual users to use services hsoted in your Azure tenant, you will implemnet Point-to-site VPN gateway.

 All the above implementations are different on thier configurations and they each cater for each use case in its own capacity.

Here is why you need to choose Virtual WAN if you are already using more than 2 capabilities mentioned above.

•  VWAN brings all of the above network connectivity implemntations under one centralized platform.
• VWAN automatically deployes one hub in each choosen region which implements Hub-spoke network design by default.
• Site-to-Site VPN gateways supports max of 10, 30 and 100 tunnels in Basic, Standard and HighPerformance SKUs. VWAN supports upto 1000 branch conncetions per VWAN hub, which can throuhput at 20GBps per hub.
• Though private communication between VNets in both VNet Peering and VWAN are ecrypted over MS backbone network, Adding additional firewall security is way easier in VWAN comapred to VNet peering.
• VWAN has most of the above services deployed across all avilability zones in a given region thus making it more relaible and scalable without any manual intervention.
• Virtual WAN provides many functionalities built into a single pane of glass such as site/site-to-site VPN connectivity, User/P2S connectivity, ExpressRoute connectivity, virtual network connectivity, VPN ExpressRoute Interconnectivity, VNet-to-VNet transitive connectivity, Centralized Routing, Azure Firewall and Firewall Manager security, Monitoring, ExpressRoute Encryption, and many other capabilities. Pick and choose what you want.

More information is available on MS Documentation. All refrence links are provided at the end of the article.

Now the title of artice is no "Why VWAN?" it says "Deploying VWAN using Terrafrom & Azure Devops". So lets jump in to deployment.

How to build subscription based security around Azure functions

Working in company which deals with hundreds of client azure tenants showed me how different it is working on your own tenant.

Recently i worked on a subscription based service and i want to show you how to build the secruity walls arround your azure functions.

Here is an example of subscriotion service which caters differently for each client based on thier type of subscription. Free or Paid or Premium. 

React Js Modularity - Breaking a monolith react component into modular components

Earlier in 2017, I have written a few articles on Basics of SharePoint Framework, Use of React JS and React JS component life cycle. 

But Most of the SPFx web parts I created were task oriented and not application oriented. This means the size of the React components is small. 

Now I am working on a product / application level components which are complex and big in size.

Here is a screenshot of a POC I am currently working.

Azure PIM Provisioning and Configuration

Setting up PIM Administrator

Global Admins enable PIM provisioning and create PIM Admin role assignment.

PIM Admin Account Pre-requisites:

PIM admin account need to have below 2 licenses assigned.

1.  Azure AD Premium P2
2.  Enterprise Mobility + Security (EMS) E5

PIM Admin Setup:

1. Login to Azure portal as Global admin, navigate to Azure Active Directory.

2. In Featured highlights, click on
3. Click on “Azure AD roles” in left pane=> Navigate to “Roles” by clicking on
4. Search for “privileged role administrator”.



5. Click on “Privileged Role Administrator” role. Click on
6. Follow below configuration

Field	Value	Reason
Selected Member(s)*	PIM Admin Account	This should be an account which will be permanently treated as PIM admin
Assignment type	Eligible	This means PIM admin account is always eligible, but not active. PIM admin need to activate this role every time the changes need to be made to PIM configuration
Permanently eligible	YES	Always eligible, but not active.

 7. PIM Admin setup is finished.

Data Persistence Models in Docker Containers

A container has different layers starting with Minimal Subset of OS topped by Container Filesystem topped by Application layer topped by Hosting layer. All these layers are read-only.

There is a top layer called Container Runtime layer which will be in a Read/Write state. 

The data on Container Runtime layer is persistent only when the container is stopped/started . If a continer is deleted, this data will be lost forever. Also this data is isolated only to that continer and cannot be shared with other containers.

So lets look at better data persistance models to share data between different containers on a Host.

Volume and Bind Mount are two ways of persistent data storage thats avilable on a Host, which can be accessed (read/write) by multiple containers.

Volume is the storage created and managed by Docker. This means no containers can go beyond the boundaries of docker while working with volumes.

Bind Mount is the storage directly from file system of the host file. So if there is a malicious code deployed in a container, it can break the host by manipulating the host filesystem.

By now looking at color coding you should have understood that Volume is a better/safer way of storing and sharing data between containers. Let me show you by a demonstration.

Containerize ASP.Net Core app on Azure Kubernetes Cluster

In my earlier post, we have deployed ASP.Net Core application to a Container hosted by a Linux Server.

There are some problems with this approach.

1. What if the Host VM is stopped?
2. What if Container Instance is stopped?
3. How do we manage the deployment of any app changes?
4. Even when we stop Host VM, you still be paying for the Disk allocated. How we can avoid that?

This is where Azure Kubernetes comes into the picture. 

Azure Kubernetes provide serverless CI/CD experience which also manages Health, Security, Auto-Scaling, Deployment and Governance aspects. More details can be found here. 

In this article we will be:

• Deploy a ASP.Net Core App to a Container
• Create a Container Image from .Net Core Container
• Push the Image to Azure Container Registry
• Use Kubernetes to Pull that image and create mutliple instances of the container in Kubernete Pods.
• Expose the .Net Core App via Azure Load-Balancer.

Containerizing ASP.Net Core Application on a Linux Host

In this article we will see how to deploy a ASP.Net Core 3.1 Webapplication to a container hosted on a Linux Host.

Beofore we jump into implementation, we need to look at every component and know what it does.

1. Host: This can be a Linux or Windows server. Considering Linux servers have used from long time for contanerization, i picked it. But Windows is very close choice considering all the capabilities it acquired in last 2 years.

2. Docker: It is the engine we use to host our containers. It will package the application with its dependecies and run them in isolated containers on the host.

3 Reverse Proxy Server: This will be sitting behind the firewall and redirects the user requests to appropriate apps/containers. This will provide extra layer of abstraction and reduces the public exposure of the containers. 

4. Kestrel Web Server: When you install a .Net Core SDK, it will internally create a webserver to act as a backend server for the .Net Application. Proxy server will be sending the client calls to Kestrel Web server and responds back with the output from .Net App.

5. App: .Net Core Application we deploy to be containerized.