Sadly, Azure Bicep and ARM Templates lack a built-in option for local deployment trials, particularly when your template involves variables, parameters, functions, and outputs. To test the functionality of certain functions or data structures, deploying them in Azure is still necessary. This challenge persists, meaning each time you wish to experiment with just your variables and outputs, initiating a deployment via AZ_CLI or PowerShell is required to observe the outcomes.

However, the Bicep team has been working on a new feature that will make this process much more straightforward. The new feature, known as the "Deployment Pane," is currently in preview and available in VSCode. This feature allows you to deploy your Bicep files quickly and easily, without the need to use the Azure CLI or PowerShell.

In this post, we will be exploring how to engage with the Databricks API through PowerShell. I would love to cover the following topics as parts of this post:

[✔️] Prerequisites: We'll start with the basics, ensuring you have all the necessary setup done. This includes having the right PowerShell modules and permissions in place, and an overview of the Databricks environment we'll be interacting with.

[✔️] Authenticate to the Databricks API via Azure Access Token: Security is our top priority, so we'll walk through the process of securely authenticating to the Databricks API. We'll understand how to obtain and use an Azure access token, which is essential for making it get going.

[✔️] Retrieve the Databricks Resources Using the Databricks API: Once we're in, it's all about getting the information you need. We'll go over how to send requests to the API to retrieve details on your Databricks resources. Whether it's clusters, jobs, or notebooks, you'll learn how to pull the data you're searching for.

Hello Folks, Welcome back to the second part of our journey to transition from the Log Analytics agents to the Azure Monitor Agent (AMA). In the first part, we learned how to find and check the monitoring agents using KQL. In this part, we'll continue our journey by identifying the agents that have reported to the Log Analytics Workspace and then extend our query to include all virtual machines within your subscription or tenant.

Last time, we discovered which virtual machines were running the old MMA or OMS agents. This time, we're refining our search to quickly determine whether a machine uses MMA or the updated AMA.

Hello Folks, We're going to look closely at Azure's monitoring tools, focusing on moving from the Log Analytics agents to Azure Monitor Agent (AMA). This is the first step in our journey. We'll learn how to find and check the monitoring agents using KQL to help us identify the agents we need to migrate.

As Microsoft announced the retirement of the Log Analytics agent on August 31, 2024, it's imperative to gear up for what lies ahead. Post-retirement, utilizing the MMA or OMS agent could lead to certain expectations and operational shifts that we need to be prepared for.

🕐 The Clock is Ticking for MMA and OMS​

Why focus on this transition, you might wonder? Moving from MMA (Microsoft Monitoring Agent) and OMS (Operations Management Suite) to AMA isn't just about staying current with Azure's offerings. It's about tapping into improved security, efficiency, and the fresh features that AMA offers. Microsoft's decision to retire MMA and OMS is a strategic step towards enhancing and simplifying the monitoring experience for infrastructure.

Welcome back! In our previous session, we delved into the strengths of YAML as a tremendous alternative for orchestrating Azure configurations via Bicep. Today, I'll guide you through deploying Azure resources using a YAML with Bicep.

🧑‍💻 Using YAML and Bicep Together​

Revisiting the previous post, you might remember our YAML file, structured as follows:

resourceGroups:
  - name: "app01"
    location: "westeurope"
    tags:
      environment: "dev"
      project: "project01"

  - name: "app02"
    location: "northeurope"
    tags:
      environment: "dev"

This file lists two resource groups, app01 and app02. Each resource group has a name, location, and tags property. It's like a to-do list for our task. Now, we will write a resource block in Bicep to create these resource groups in Azure.

Greetings, everyone! This blog post marks the beginning of a series dedicated to exploring how YAML can be effectively utilized in conjunction with Bicep for deploying resources on Azure. This is the first part of a series. Here, we'll start with the basics of YAML and Bicep and learn how they work together to help us with resource provisioning on Azure.

💬 Why YAML, and What Are the Options?​

After our introduction to this series, you might be wondering, Why YAML? YAML, which stands for YAML Ain't Markup Language, is a human-readable data serialization standard. It is used in a variety of programming and IT contexts, but why is it so important for Azure resource deployment, particularly with Bicep? Before we dive deeper into why YAML is a great choice, let's look at the alternatives available in ARM templates or Bicep:

I had the opportunity to speak at Global Boot Camp 2023 in Istanbul! 🌍✨ It was an enlightening session on the latest in Azure technology. I truly enjoyed connecting with fellow Azure enthusiasts.

Here's the link to the recording: Global Azure 2023 İstanbul

I recently had the amazing chance to collaborate with the folks of the Café Azure Program in Turkey. In my session, I took a deep dive into the Azure Virtual Network Manager and its various components. Pleased to present my detailed demonstrations, offering practical applications and insights for everyone interested.

For those who missed it or want to revisit some of the highlights, here's the recording:

Hey folks, I'm back with the second part of the article for sign Azure Spot virtual machines. In the previous article, I walked you through the eviction policies, the types of Azure Virtual Machines and how to query the prices of Spot VMs. In terms of ways to deploy Spot VMs, my preference is to use Azure PowerShell as much as possible. I will show you how to deploy Spot VMs with Azure PowerShell. Let's dive in!

Hello Friends, I worked on a project requiring many temporary VMs.In that project, I had to find a way to reduce the cost of the VMs. I knew there were several different ways to reduce the cost of temporary Virtual Machines. The first option was on the table Spot Virtual Machines, and we could take advantage of the unused capacity in Azure. Regarding pricing, Spot VMs are tremendously cheaper than regular VMs. However, there is a catch: Spot VMs can be evicted at anytime. We can use Spot VMs for workloads that can be interrupted, such as batch jobs, render farms, and fault-tolerant applications. In this article, I will show you how to deploy Spot VMs with PowerShell. Let's dive in!