June 11, 2026

Infrastructure as Code, DevOps & the Future of Azure with Maik van der Gaag [MVP]

What does the future of Azure look like, and how are Infrastructure as Code and DevOps transforming the way organizations build and manage cloud solutions?

In this episode of M365 FM, host Mirko Peters is joined by Microsoft Azure MVP Maik van der Gaag for an in-depth discussion about modern cloud engineering, automation, and the evolving Azure ecosystem. Maik shares insights from his extensive experience helping organizations adopt cloud technologies and modern development practices.

The conversation explores why Infrastructure as Code (IaC) has become a critical foundation for scalable and reliable cloud environments. Maik explains how tools such as Terraform and Bicep enable teams to automate deployments, improve consistency, reduce configuration drift, and accelerate delivery across Azure environments.

Beyond the technology, the episode highlights the cultural side of DevOps. Successful cloud transformation is not only about tools and automation but also about collaboration between development, operations, security, and business teams. Topics such as GitOps, governance, security, and cloud best practices are discussed throughout the conversation.

Mirko and Maik also examine current trends shaping Azure, including hybrid cloud strategies, cloud governance, identity management, and the increasing role of AI in infrastructure management. The discussion covers how solutions like GitHub Copilot are helping engineers work faster while reinforcing the need for human oversight and strong engineering fundamentals.

You see a shift in how organizations manage infrastructure with azure infrastructure as code. When you adopt iac, you unlock automation and consistency for every azure deployment. This approach brings reliability and security to your cloud environment. Teams collaborate better when you use infrastructure as code and integrate DevOps practices. You build a culture where developers and operations work together. AI tools and hybrid cloud models now shape the future of azure infrastructure. You can use these strategies to support a cloud-first strategy and make every iac deployment faster and more secure.

Azure infrastructure as code and DevOps deliver key benefits:
Benefit Description
Speed New environments can be created in minutes instead of days.
Consistency Every environment looks the same across teams and regions.
Reliability Fewer human errors mean fewer outages.
Security Security rules are built into the infrastructure itself.
Compliance Every change is tracked and auditable.

Key Takeaways

Infrastructure as Code (IaC) automates Azure deployments, enhancing speed and reliability.
IaC ensures consistency across environments, reducing human errors and deployment issues.
Integrating DevOps with IaC fosters collaboration between development and operations teams.
Using tools like Terraform and Bicep simplifies infrastructure management and promotes reusability.
Automated security policies in IaC help maintain compliance and protect sensitive data.
AI-assisted tools can speed up coding and improve the accuracy of infrastructure scripts.
Regular testing and version control are essential for maintaining a secure and efficient IaC process.
Start small with IaC projects to build skills and gradually expand your team's capabilities.

Azure Infrastructure as Code Evolution

From Manual to Automated Deployment

You have seen a major shift in how you manage infrastructure in Azure. In the past, you might have relied on manual steps for every deployment. Today, you can use infrastructure as code to automate these tasks. This change brings speed and reliability to your cloud projects. You no longer need to configure servers or networks by hand. Instead, you write code that defines your entire environment.

AI-driven operations now handle many tasks that once required manual effort, especially in network operations.
A cloud-first approach in Azure improves reliability, efficiency, and cost savings for your organization.
With 98% of IT infrastructure in Azure, you gain better observability and control over your resources.
Decentralized IT empowers your teams with self-service, cloud-native solutions while keeping security and compliance in check.
Automated updates through platform services make patching and maintaining infrastructure much easier.

You can see how automated deployment with azure infrastructure as code leads to more effective infrastructure management. This approach reduces errors and helps you scale your operations quickly.

DevOps and IaC Integration

When you combine DevOps with infrastructure as code, you create a strong foundation for modern cloud operations. You encourage collaboration between development and operations teams. This teamwork leads to a shared understanding of your infrastructure and deployment processes.

IaC improves consistency by making sure every environment matches, which reduces deployment issues.
Automation speeds up infrastructure provisioning, so you can deliver new features faster.
Version control for IaC helps you manage risk and support compliance.
You can rebuild infrastructure quickly from code, which supports disaster recovery.

By integrating DevOps and IaC, you build a culture of trust and efficiency. You make your azure infrastructure as code deployments more reliable and secure.

Hybrid and Sovereign Cloud Trends

You may need to address compliance and governance requirements in your organization. Hybrid and sovereign cloud models in Azure help you meet these needs. Many organizations now embed compliance and governance into their cloud strategies to align with local and international regulations.

The demand for regulatory compliance and data sovereignty drives the adoption of hybrid and sovereign cloud models.
Sovereign Landing Zones in Azure give you a structured way to meet regional requirements and simplify policy management.

With azure infrastructure as code, you can manage both public and private environments from a single platform. This flexibility supports effective infrastructure management and ensures your deployments stay secure and compliant.

Defining Infrastructure as Code in Azure

What Is Infrastructure as Code?

You use infrastructure as code to manage and provision your infrastructure through code instead of manual steps. This approach lets you describe your azure environment in files that you can store in version control. You gain the ability to automate deployment, which reduces errors and speeds up your work. You can create, update, or delete resources in azure with simple scripts. You make your infrastructure consistent across development, testing, and production. You also track every change, which helps you meet compliance requirements.

Tip: When you use infrastructure as code, you can rebuild your entire azure environment quickly after a failure. This makes disaster recovery easier and more reliable.

Azure IaC vs. Traditional Infrastructure

You see clear differences between azure infrastructure as code and traditional infrastructure management. Traditional methods rely on manual setup, which often leads to mistakes and slow deployment. Azure infrastructure as code uses automation to deliver faster and more reliable results. You can scale your resources up or down with ease. You pay only for what you use in azure, while traditional infrastructure requires large upfront investments.

Here is a comparison table:

Feature	Azure IaC	On-Premise IaC
Scalability	Highly scalable	Limited by hardware
Deployment Speed	Fast and automated	Slower and manual
Cost Efficiency	Pay-as-you-go model	High upfront costs
Maintenance	Managed by provider	In-house management
Disaster Recovery	Automated and quick	Manual and slow

You benefit from ease of deployment, consistency, scalability, and auditability. Azure infrastructure as code lets you track every change and maintain compliance. You can quickly replicate or adjust your infrastructure to handle changing loads.

Key IaC Concepts in Azure

You need to understand several core concepts to use azure infrastructure as code effectively. You manage your infrastructure using a descriptive model, which ensures consistent environments. You use idempotence, which means your deployment commands always produce the same result, no matter the starting state. You define your infrastructure in a declarative way, focusing on what you want rather than how to build it. Azure provides tools like Azure Resource Manager templates, Terraform, Ansible, and Bicep to help you manage your infrastructure.

Infrastructure as code: Manage infrastructure with code for consistency and automation.
Idempotence: Ensure deployments always result in the same configuration.
Declarative definitions: Describe what you want, not how to do it.
Azure tools: Use ARM templates, Terraform, Ansible, and Bicep for cloud-based solutions.

You build reliable, scalable, and secure environments with azure infrastructure as code. You gain speed, consistency, and control over every deployment.

Azure Infrastructure as Code Tools

Azure infrastructure as code gives you a wide range of automation tools to manage your cloud resources. You can choose from several popular options, each with unique strengths for iac and automated provisioning. In 2024, Microsoft Azure and Amazon together held over 14% of the infrastructure as code market, showing strong adoption of these solutions. You can use these tools to improve consistency, speed, and security in your deployments.

ARM Templates and Bicep

Azure Resource Manager (ARM) templates and Bicep are the primary iac tools for azure. These tools help you define, deploy, and manage your infrastructure using code. Many businesses use ARM templates and Bicep to automate the creation of resources like virtual machines, networks, and databases.

Template Structure

ARM templates use JSON files to describe your infrastructure. You write code that lists every resource and its settings. This approach ensures you can deploy the same environment every time. ARM templates support idempotent deployments, so you get consistent results even if you run the template more than once. You can also manage dependencies between resources, which helps you control the order of deployment.

Bicep builds on ARM templates by offering a simpler, more readable syntax. You write Bicep files using a programming-like language that reduces errors and makes your code easier to understand. Bicep compiles into ARM templates before deployment, so you keep full compatibility with existing azure infrastructure as code processes.

Feature/Limitations	ARM Templates	Bicep
Syntax	Verbose JSON format, prone to syntax errors	Concise, programming-like syntax, easier to read
Learning Curve	Steeper due to complex JSON structure	Easier for those familiar with programming
Modularity and Reusability	Limited modularity	Supports modular design, promotes reusability
Type Safety and Validation	Limited type checking	Strong type checking, catches errors early
Integration with Azure Ecosystem	Works with Azure tools but less intuitive	Seamless integration with Azure services
Backward Compatibility	N/A	Full backward compatibility with ARM templates
Community Resources	N/A	Emerging community, fewer resources than Terraform
Cost Optimization	N/A	More precise resource definitions, reduces overprovisioning
Readability	Poor readability due to verbosity	Improved readability, fewer errors
Deployment Process	Interpreted directly by Azure Resource Manager	Compiled into ARM templates before deployment

Bicep Advantages

You gain several advantages when you use Bicep for azure infrastructure as code. Bicep uses a clean syntax that looks like programming languages, which makes it easier to write and read. You can create modular templates, so you reuse code and simplify management. Bicep offers strong type safety, helping you catch errors before deployment. This feature improves reliability and reduces troubleshooting time. Bicep integrates seamlessly with azure services, making it a powerful choice for iac. You can also use Bicep to define secure resources, such as azure key vault, to protect sensitive information.

Terraform for Azure

Terraform is one of the most popular iac tools for azure infrastructure as code. Many organizations choose terraform because it supports multiple cloud providers and offers advanced features for managing infrastructure.

Multi-Cloud Support

Terraform stands out because it works across different cloud platforms. You can use terraform to manage resources in azure, Amazon Web Services, Google Cloud, and more. This platform-agnostic approach gives you flexibility if you need to run workloads in more than one cloud. You can use the same terraform configurations to deploy similar environments across different providers. This feature helps you avoid vendor lock-in and supports hybrid cloud strategies.

Azure Provider Features

Terraform provides a rich set of features for managing azure resources. You write declarative code to describe your desired infrastructure state. Terraform automates the deployment and management of resources, making your iac process efficient. You can use version control to track changes and roll back if needed. Terraform supports modules, so you reuse code and maintain consistency. State management lets you track the current state of your infrastructure, which helps you plan and apply changes safely. Terraform integrates with automation tools and scripts, giving you more control over your deployments.

Feature/Advantage	Terraform	Azure Bicep
Platform Agnostic	Yes	No
Multi-Cloud Support	Yes	No
Declarative IaC	Yes	Yes
Version Control	Yes	Limited
Automation through Code	Yes	Limited
Extensibility	High (supports various providers)	Limited to Azure
Code Reuse	Yes (through modules)	Limited
State Management	Yes (tracks infrastructure state)	No

You can use terraform to automate complex deployments, manage infrastructure at scale, and support compliance requirements. Many teams rely on terraform for its flexibility, extensibility, and strong community support.

Ansible and Scripting Tools

Ansible is another popular choice for iac in azure. You use Ansible to automate IT orchestration, configuration management, and application deployment. Ansible uses YAML playbooks, which are easy to read and write. You do not need to install agents on your servers because Ansible communicates over SSH or WinRM. This agentless approach simplifies management and improves security.

Ansible playbooks are idempotent, so you get the same results every time you run them. You can use Ansible to configure new servers, deploy applications, and automate routine tasks. Ansible also helps you orchestrate multi-tier deployments and manage complex environments.

Automation with PowerShell and CLI

You can use scripting tools like PowerShell and the Azure CLI to automate tasks in your azure infrastructure as code projects. PowerShell scripts let you manage resources, configure settings, and perform bulk operations. The Azure CLI gives you command-line access to azure services, so you can script deployments and updates. These tools work well for custom automation and integration with other iac solutions.

Tip: Combine Ansible, PowerShell, and Azure CLI to create powerful automation workflows for your azure infrastructure as code deployments.

You can choose the right mix of iac tools and automation tools to meet your needs. Each tool offers unique benefits for managing infrastructure, improving efficiency, and supporting secure, repeatable deployments.

Version Control and CI/CD Integration

You need strong tools to manage your Azure infrastructure as code. Version control systems help you track every change you make to your infrastructure code. You can see who made each change and when. This makes your work more reliable and easier to audit. You can use systems like Git to keep a history of your code. If something goes wrong, you can roll back to a previous version. This reduces downtime and helps you recover quickly.

When you use version control systems with Azure infrastructure as code, you gain several benefits:

You keep a clear log of all changes. This helps with compliance audits and builds accountability in your team.
You can easily revert to a stable state. This makes disaster recovery simple and reduces risk.
You and your team can work together on the same codebase. This improves collaboration and keeps everyone on the same page.

You can use tools like terraform with version control systems to manage your Azure resources. Terraform files can live in your Git repository. You can review changes before you apply them. This process helps you catch mistakes early.

Continuous integration and continuous deployment (CI/CD) pipelines take your automation to the next level. You can set up pipelines that test, validate, and deploy your infrastructure code automatically. When you push a change to your repository, the pipeline runs checks and applies the changes to Azure. This reduces manual work and speeds up your deployments.

Here is a simple workflow for Azure infrastructure as code with terraform and CI/CD:

Step	Description
Code	You write or update terraform files in your repository.
Commit & Push	You commit your changes and push them to the version control system.
Continuous Integration	The pipeline runs tests and validates your terraform code.
Review & Approve	Your team reviews the changes and approves them for deployment.
Continuous Deployment	The pipeline applies the terraform code to Azure, updating your resources.

Tip: Use branch policies in your version control system to require code reviews before merging changes. This adds another layer of safety to your deployments.

You can use terraform modules to share code across projects. This keeps your infrastructure consistent and easy to manage. You can also use terraform state files to track the current state of your resources. This helps you plan and apply changes safely.

With continuous deployment, you can deliver updates to your Azure environment quickly and reliably. You reduce the risk of human error and make your infrastructure more secure. You can also use terraform with other tools like Ansible or PowerShell to create end-to-end automation.

You build a strong foundation for Azure infrastructure as code when you combine version control systems, terraform, and CI/CD pipelines. You gain speed, reliability, and control over every deployment.

Benefits of Azure IaC Deployment

Consistency and Repeatability

You want every deployment in Azure to look the same, no matter who runs it or when. Infrastructure as code gives you this power. When you use IaC, you document your configurations and repeat them across all environments. This reduces the risk of human error and stops configuration drift. You can recreate identical environments for development, testing, and production. This makes your deployments predictable and reliable.

You use the same code for every environment, so you avoid unexpected issues during testing or release.
You minimize differences between builds, which helps you catch problems early.
You make your infrastructure easier to audit and manage.

With azure infrastructure as code, you build trust in your deployment process. You know that your infrastructure will match your expectations every time.

Scalability and Efficiency

You need to scale your infrastructure quickly as your business grows. Azure infrastructure as code helps you do this with ease. IaC tools like Terraform let you adjust resources to meet changing demands. You can scale up or down without manual steps. This flexibility supports both small projects and large enterprise workloads.

Aspect	Description
Scalability	Infrastructure can be easily scaled up or down to accommodate changing demands, fostering flexibility and responsiveness.

Automation plays a big role in efficiency. Automated infrastructure management reduces human error by nearly 30%. Most businesses see a boost in workforce efficiency when they use IaC. You can replicate or adjust your infrastructure to handle different loads. Azure IaC tools enable dynamic scaling, so your applications always perform well.

You save time by automating repetitive tasks.
You respond faster to business needs.
You keep your deployment process smooth and reliable.

Terraform makes it easy to manage complex environments. You can use modules to share code and keep your infrastructure consistent. This approach supports rapid growth and helps you stay competitive.

Security and Compliance

You must protect your data and meet regulatory requirements. Azure infrastructure as code helps you achieve both. IaC lets you define automated security policies that apply to every deployment. You standardize security controls across your environment, which strengthens your security posture. Automated security policies reduce the chance of mistakes and make your infrastructure safer.

Continuous compliance monitoring ensures you meet standards like PCI DSS, HIPAA, and GDPR.
Automated security controls help you manage complex environments with less effort.
You use managed security features to protect sensitive data.

Cloud-native application protection becomes easier with IaC. You can track every change and prove compliance during audits. Terraform supports secure deployments by letting you review and approve changes before they go live. You build a secure foundation for your business with every deployment.

Tip: Use IaC to automate security checks and compliance reporting. This keeps your Azure environment safe and up to date.

Cost Optimization

You want to make the most of your cloud budget. Azure infrastructure as code helps you optimize costs by automating resource management and reducing waste. When you use IaC, you gain control over every resource. You can track usage, adjust capacity, and avoid paying for unused services.

You can build fault-tolerant workloads with Azure Spot Virtual Machines. These machines cost much less than standard ones. You save up to 90% by running workloads that can handle interruptions. IaC lets you set up these environments quickly and ensures your architecture stays resilient. You do not need to worry about manual setup or missing savings.

You can also manage Azure Reservations and Savings Plans with IaC. You use data to forecast your needs and commit to resources only when you know you will use them. This approach prevents over-provisioning and underutilization. You maximize savings by matching your commitments to actual usage.

Azure Spot Virtual Machines: Save up to 90% by running fault-tolerant workloads. IaC helps you automate deployment and manage interruptions.
Azure Reservations and Savings Plans: Use IaC to analyze usage patterns and make smart commitments. You avoid paying for resources you do not need.

You can automate scaling with IaC. When demand increases, your infrastructure grows. When demand drops, your resources shrink. You pay only for what you use. This flexibility keeps your costs low and your performance high.

Tip: Review your IaC templates regularly. Update them to match your current needs. This practice helps you avoid unnecessary spending and keeps your cloud environment efficient.

You can set up alerts to monitor spending. IaC makes it easy to add cost controls and budget limits. You get notified when usage exceeds your targets. You can respond quickly and adjust your resources.

You can use tags to track costs across projects. IaC lets you add tags to every resource. You see which teams or applications use the most resources. You can make informed decisions and allocate budgets wisely.

You build a cost-effective cloud environment with Azure infrastructure as code. You automate savings, monitor spending, and adjust resources to fit your needs. You keep your cloud budget under control and support your business goals.

Challenges in Azure IaC Adoption

Complexity and Learning Curve

You face several challenges when you start using Azure infrastructure as code. New languages and tools require training. You may need to learn Bicep, Terraform, or ARM templates. This increased specialization can lead to vendor lock-in if you rely on one tool. You must keep your IaC code secure and current, which adds maintenance effort. Sometimes, command-line or portal deployments seem faster, but they lack the rigor of coding. Modularization brings benefits, but more modules can complicate debugging and documentation.

You see many IaC tools available. Tool proliferation can cause confusion and fragmentation. You need deep infrastructure knowledge to use these tools effectively. Managing changes becomes complex when multiple team members work on different environments. Configuration drift often happens when someone makes changes directly in the cloud instead of through code. You must watch for drift to keep your infrastructure consistent. Security concerns arise if IaC code exposes sensitive information. Enterprise governance can become difficult as IaC disrupts existing compliance workflows.

Tip: Start with small projects and build your skills gradually. Document your code and processes to help your team learn faster.

Managing State and Dependencies

You must manage state and dependencies carefully in Azure infrastructure as code projects. State management helps you track the current status of your resources. You use standardized tools to enhance consistency and efficiency. Modularization lets you break down infrastructure into manageable pieces. This makes updates and maintenance easier. Testing is important for deployments and configuration updates. You ensure reliability by testing before you apply changes.

CI/CD integration streamlines updates. You automate deployments and reduce manual errors. Security best practices protect your infrastructure. You include security measures in your deployment pipeline. Configuration drift can occur if you do not manage state and dependencies well. You must monitor for drift and correct it quickly. Cloud-native application protection becomes easier when you follow these strategies.

Note: Use version control to track changes and facilitate collaboration. This helps you avoid configuration drift and keeps your infrastructure secure.

Security Risks and Mitigation

You must address security risks when you use Azure infrastructure as code. Manual processes can lead to errors and inconsistencies. Slow updates leave systems vulnerable to security issues. Complex disaster recovery processes increase downtime. You implement modularization and automated testing to manage infrastructure easily and detect issues early. Version control documents changes and helps your team collaborate.

Thorough documentation supports onboarding and troubleshooting. You keep credentials safe and follow compliance policies. Secrets management tools like Azure Key Vault securely store sensitive information. You automate Azure pipelines to reduce human error and ensure consistent deployments. Auditing monitors changes and evaluates compliance with standards. Configuration drift poses a risk if you do not control changes. You must check for drift and fix it quickly.

Alert: Always use secrets management tools and automate your pipelines. This reduces risk and improves security.

Organizational Change

You cannot succeed with Azure infrastructure as code (IaC) by only changing your tools. You must also change how your organization works. Many teams start with manual steps in the Azure portal. This habit leads to mistakes and slow progress. When you move to IaC, you shift to automated processes. This change requires you to train your teams, set clear rules, and begin with a small project. You build trust by showing early wins.

You should not try to change everything at once. Start small. Pick one team and one use case. Let this team learn and share their experience. This approach helps you avoid confusion and resistance. As your team grows more confident, you can expand IaC to other groups.

Note: Training is key. Teach your team how to write, review, and manage infrastructure code. Make sure everyone understands the new process.

You need to create new habits for your team. Encourage everyone to use code for all infrastructure changes. Avoid manual updates in the Azure portal. This rule keeps your environments consistent and secure. You should also set up code reviews for every change. Code reviews catch mistakes early and help your team learn from each other.

A modular design makes your IaC easier to manage. Use clear naming conventions and reusable patterns. This practice helps your team understand the code and reduces errors. You should also protect sensitive information. Use secret management tools like Azure Key Vault. Never store passwords or keys in your code.

Keep your documentation up to date. Good documentation ensures that everyone follows the same process. It also helps new team members get started quickly. When you document your code and workflows, you make your infrastructure more reliable.

Here are some key organizational changes you should make for successful Azure IaC adoption:

Ensure consistency and standardization across all environments.
Automate provisioning to increase speed and efficiency.
Design your infrastructure to scale easily as your needs grow.

You can also follow these best practices:

Start with one team and one use case.
Use modular design and clear naming conventions.
Review all infrastructure code before deployment.
Protect secrets with secure tools.
Maintain thorough documentation.

When you make these changes, you help your organization move away from manual work. You build a culture that values automation, learning, and collaboration. This shift leads to faster deployments, fewer errors, and a more secure Azure environment.

IaC Deployment Best Practices

Modularization and Reusability

You can improve your infrastructure as code projects by breaking your code into smaller, reusable modules. This approach helps you keep your iac organized and easy to manage. When you use modularization, you create self-contained pieces for networks, databases, or storage. You can share these modules across teams and projects. This saves time and reduces errors.

Here is a table with best practices for modularization and reusability:

Best Practice	Description
Modularizing Infrastructure Code	Break down code into reusable modules for consistency and scalability.
Reusable Self-Contained Modules	Use modules for common services to reduce duplication and ease maintenance.
DRY Code Development	Write code that avoids repetition to streamline provisioning and support future deployments.

You should follow the DRY (Don’t Repeat Yourself) principle. This means you write code once and reuse it everywhere you need it. Tools like Terraform and Bicep make this process easier. Modularization and automated testing together help you scale your iac and keep your deployments consistent.

Testing and Validation

You need to test your iac before every deployment. Testing helps you catch mistakes early and ensures your infrastructure works as expected. You can use different types of testing to check your code and your environment.

Here are some common testing methods:

Test Type	Purpose
Unit testing	Checks small parts of your code for errors.
Smoke testing	Confirms basic functions work after deployment.
Load testing	Measures performance under normal use.
Stress testing	Finds the limits of your system and how it recovers.
Chaos testing	Tests how your system handles failures.
Penetration testing	Looks for security weaknesses in your deployment.

You should run these tests in your CI/CD pipeline. Automated testing gives you confidence that your iac will work in production. Always validate your templates and scripts before you deploy them. This step reduces downtime and keeps your environment stable.

Secure Coding and Access Controls

You must protect your infrastructure as code from security risks. Secure coding practices and strong access controls keep your deployments safe. You should scan your code for vulnerabilities using tools like Static Application Security Testing (SAST). This process finds problems early in development.

You can use Policy as Code to enforce rules and compliance. Azure Policy and third-party tools help you set these policies. Always use least-privilege access configuration. Give users and services only the permissions they need. This reduces the risk of accidental changes or security breaches.

Here is a table of secure coding and access control tools:

Practice/Tool	Description
SAST	Scans code for vulnerabilities before deployment.
Policy as Code	Enforces compliance and security rules automatically.
ARM Templates/Bicep	Standardizes resource definitions for better security and maintainability.
Terraform	Supports reusable security configurations across environments.

You should review your iac regularly and update your access controls. Secure coding and strong policies help you meet compliance needs and protect your cloud resources.

CI/CD for IaC

You can boost your Azure infrastructure as code projects by using continuous integration and continuous deployment (CI/CD) pipelines. CI/CD helps you automate your deployment process, which reduces manual errors and speeds up delivery. When you set up CI/CD, you make sure every change to your infrastructure code goes through a repeatable and reliable process.

Many teams use Azure DevOps, Terraform, and ARM templates to manage their infrastructure as code. These tools let you automate deployments and keep your environments consistent. You should version all your code, including scripts for infrastructure. This practice helps you track changes and roll back if something goes wrong.

Here are some best practices for CI/CD with infrastructure as code:

Automate deployment steps to reduce mistakes.
Use approval gates and environment promotion to control releases.
Store all code in version control systems like Git.
Centralize environment variables for easier management.
Create a clear branching strategy for your team.

When you use automated pipelines, you can add governance and monitoring to your process. This ensures your deployments meet compliance and performance standards. Many organizations have seen faster feature delivery and fewer manual interventions by using CI/CD pipelines with approval gates.

Tip: Set up automated tests in your pipeline to catch errors before they reach production. This step keeps your Azure environment stable and secure.

Monitoring and Auditing

You need strong monitoring and auditing to keep your Azure infrastructure secure and compliant. Monitoring helps you track the health and performance of your resources. Auditing lets you see who made changes and when. Together, these practices protect your environment and help you meet regulatory requirements.

Continuous compliance checks are vital for standards like PCI DSS, HIPAA, and GDPR. Automation ensures these checks run often and stay current. You can use Azure Policy and Role-Based Access Control (RBAC) to enforce governance and access control as code. This approach creates audit-ready access trails and tightens security boundaries.

DevOps workflows can enforce just-in-time access, tagging, and resource limits. These steps make it easier to align with legal and security audit needs. You should also use monitoring and logging tools to collect data on your resources. This data helps you spot issues early and respond quickly.

Here is a simple checklist for effective monitoring and auditing:

Set up monitoring for all critical resources.
Enable monitoring and logging to capture important events.
Review audit logs regularly for unusual activity.
Use automation to run compliance checks.
Apply policies and access controls as code.

Note: Good monitoring and logging not only improve security but also help you optimize performance and costs.

By following these practices, you create a secure, compliant, and well-managed Azure environment.

AI and the Future of Azure Infrastructure as Code

AI-Assisted Development Tools

You now have access to powerful AI-assisted development tools that make working with Azure infrastructure as code much easier. Tools like GitHub Copilot and Microsoft Copilot help you write code faster. These tools suggest code snippets as you type, answer your questions, and help you solve problems right inside your editor. You can ask for help with Bicep, ARM templates, or Terraform scripts, and the AI will offer suggestions that fit your needs.

Generative AI platforms, such as GitHub Copilot, use advanced models to understand your intent. You can describe what you want in plain language, and the tool generates accurate infrastructure code for you. Specialized tools like Stakpak also help you create optimized code quickly. This means you spend less time on repetitive tasks and more time designing solutions. You can boost your productivity and reduce errors by letting AI handle the routine parts of your workflow.

Tip: Use AI-assisted tools to speed up onboarding for new team members. They can learn best practices and common patterns by seeing AI-generated suggestions in real time.

Automated Remediation and Self-Healing

AI is changing how you manage and maintain your Azure environments. You can now use AI to enable automated remediation and self-healing. This means your systems can detect problems and fix them without waiting for human intervention.

AI agents perform regular checks on your infrastructure. When they find an issue, they follow predefined steps to fix it.
Policy-driven automation lets you set rules for different environments. The AI makes sure every action follows your safety and compliance standards.
Intelligent workflows use machine learning to decide which problems to fix first. The AI learns from past incidents and improves over time.

With these features, you can keep your Azure environment healthy and reduce downtime. You do not have to worry about missing critical issues because the AI monitors everything for you.

Productivity and Validation with AI

AI tools do more than just write code. They help you validate your infrastructure as code before you deploy it. You can use AI to check your scripts for errors, security risks, or compliance issues. This step helps you catch problems early and avoid costly mistakes.

You can also use AI to review your code and suggest improvements. For example, if you write a Terraform script, the AI can point out better ways to structure your resources or highlight missing security controls. This feedback helps you learn and improve your skills over time.

Benefit	How AI Helps You
Faster Development	AI suggests code and automates repetitive tasks.
Fewer Errors	AI checks your code for mistakes before deployment.
Better Security	AI highlights risks and suggests safer configurations.
Continuous Learning	AI provides tips and best practices as you work.

You can rely on AI to make your Azure infrastructure as code projects more efficient and secure. By using these tools, you stay ahead of problems and deliver better results for your team.

Future Innovations

You stand at the edge of a new era for Azure infrastructure as code. AI continues to change how you build, manage, and secure your cloud environments. In the coming years, you will see several innovations that will shape your experience with Azure and IaC.

Machine Learning Enhancements: Azure now offers advanced tools for every step of the machine learning process. You can use Azure ML Studio for no-code development. If you want more control, you can work with the Azure ML SDK. These tools help you create, train, and deploy models faster than ever.
Generative AI Capabilities: Azure’s generative AI features let you create new content from your data. You can use these tools to automate documentation, generate infrastructure templates, or even design new workflows. This saves you time and helps you focus on solving bigger problems.
Custom-Built AI Hardware: Microsoft has introduced custom silicon, such as the Azure Maia AI accelerator. This hardware boosts performance for specific AI tasks. You can run complex models more efficiently and handle larger workloads without delays.
Confidential Computing: Azure now supports confidential virtual machines with NVIDIA H100 GPUs. You can run sensitive AI applications while keeping your data private. This is important if you work in healthcare, finance, or any field that requires strict data protection.

You will also face new challenges as you adopt these innovations. Many companies struggle to build and maintain the right AI infrastructure. You may need to work with partners who can help you solve complex problems and speed up your projects. Strategic partnerships will become more important as you look for ways to innovate faster.

As you use more AI in your infrastructure, your focus will shift. You will want better performance and tighter integration with cloud services. Azure will continue to optimize its platform to meet these needs. You can expect faster deployments, smarter automation, and more reliable systems.

Innovation Area	What You Can Expect
Machine Learning Tools	Easier model building and deployment
Generative AI	Automated content and template creation
Custom AI Hardware	Faster, more efficient AI workloads
Confidential Computing	Secure, private AI processing
Strategic Partnerships	Access to expert support and faster innovation

Note: Stay curious and keep learning. The future of Azure infrastructure as code will reward those who adapt quickly and embrace new technology.

You have the chance to lead your organization into this future. By using these innovations, you can build smarter, safer, and more efficient cloud environments.

You gain many advantages when you use infrastructure as code in Azure. Azure infrastructure as code helps you automate, secure, and scale your cloud deployments. You see how iac improves consistency and supports DevOps culture. AI and hybrid cloud trends shape the future of iac. You face challenges, but you can overcome them with training and teamwork. Start small, review your iac often, and join the community to keep learning about infrastructure as code.

FAQ

What is Infrastructure as Code (IaC) in Azure?

You use Infrastructure as Code to define and manage your Azure resources with code. This approach lets you automate deployments, track changes, and create consistent environments.

Why should you use IaC instead of manual setup?

Manual setup often leads to mistakes and slow progress. IaC helps you avoid errors, speeds up deployments, and ensures every environment matches your requirements.

Which tools can you use for Azure IaC?

You can use tools like ARM templates, Bicep, Terraform, Ansible, PowerShell, and Azure CLI. Each tool offers unique features for automation and resource management.

How does IaC improve security in Azure?

IaC lets you build security rules into your code. You can automate compliance checks and use tools like Azure Policy to enforce security standards across all deployments.

Can you use IaC for hybrid or multi-cloud environments?

Yes, you can. Tools like Terraform support Azure, AWS, and Google Cloud. This flexibility helps you manage resources across different platforms from a single codebase.

How do you handle secrets and sensitive data in IaC?

You should never store secrets in your code. Use Azure Key Vault or similar tools to manage passwords, keys, and other sensitive information securely.

What is the best way to start learning Azure IaC?

Start with small projects. Use official documentation and tutorials. Practice writing simple templates or scripts. Join the Azure community to ask questions and share your progress.

How does AI help with Azure IaC?

AI tools like GitHub Copilot suggest code, check for errors, and help you follow best practices. You save time and reduce mistakes by using AI-assisted development.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:03,440
So welcome back to the ANST-65 podcast today.

2
00:00:03,440 --> 00:00:07,520
Today I'm joined by someone who has spent more than 15 years helping organization,

3
00:00:07,520 --> 00:00:13,600
monetize, automate and transformation their technology landscape with Microsoft Cloud Technologies.

4
00:00:13,600 --> 00:00:17,840
He is the city of 350, a Microsoft focused console.

5
00:00:17,840 --> 00:00:23,680
JAN-C founder of the Dutch Cloud Meetup and frequent international speaker,

6
00:00:23,680 --> 00:00:27,120
blogger event organization and Microsoft Azure MET.

7
00:00:27,120 --> 00:00:30,320
This expert is Spence Cloud Architecture,

8
00:00:30,320 --> 00:00:32,800
DevOps, Infrastructure, and Discord,

9
00:00:32,800 --> 00:00:36,560
platform engineering, Cloud transformation and everything teams deliver,

10
00:00:36,560 --> 00:00:39,040
software faster and more reliable.

11
00:00:39,040 --> 00:00:44,400
If you ever wondered how Elite Teams automate infrastructure,

12
00:00:44,400 --> 00:00:48,720
building scalable Cloud environments and make DevOps actually works in a real life,

13
00:00:48,720 --> 00:00:50,400
this is a episode for you.

14
00:00:50,400 --> 00:00:52,640
Welcome, Mike van de Gaak.

15
00:00:52,640 --> 00:00:53,520
Thank you, Mirka.

16
00:00:53,520 --> 00:00:55,920
Nice to be here as well.

17
00:00:56,720 --> 00:00:57,360
And thank you.

18
00:00:57,360 --> 00:01:00,240
It was quite a mouthful of already of an introduction.

19
00:01:00,240 --> 00:01:10,960
Yeah, before we redepad into the topic, can you a little bit tell what was your way into the IG?

20
00:01:10,960 --> 00:01:16,480
Oh yeah, that's what a quite normal route, I think.

21
00:01:16,480 --> 00:01:23,520
Especially as a child, I already want to go to IT and do something with computers.

22
00:01:23,520 --> 00:01:26,400
I really didn't have something in my water I wanted to do,

23
00:01:26,400 --> 00:01:28,160
but I wanted to do something with computers.

24
00:01:28,160 --> 00:01:34,160
I started doing basically a study on that as well.

25
00:01:34,160 --> 00:01:38,640
I finished that directly, got hired by a company in the Netherlands,

26
00:01:38,640 --> 00:01:39,680
Lachpacimgi.

27
00:01:39,680 --> 00:01:42,800
Simgi, I think nowadays.

28
00:01:42,800 --> 00:01:47,760
And from there on, I moved into IT, moved into the development as well.

29
00:01:47,760 --> 00:01:51,680
First started off doing basically the old stuff,

30
00:01:51,680 --> 00:01:56,000
building windows, business forms, applications, everything else.

31
00:01:56,960 --> 00:01:59,680
Then I got hired by a company called Motion10.

32
00:01:59,680 --> 00:02:07,520
They basically did SharePoint and integration stuff with this dog.

33
00:02:07,520 --> 00:02:13,840
So what I've done there is basically moved towards SharePoint

34
00:02:13,840 --> 00:02:17,520
and see how SharePoint works and everything else, all in an on-prem scenario.

35
00:02:17,520 --> 00:02:21,680
Then came the days that Office 365 came out.

36
00:02:24,160 --> 00:02:29,040
And we also needed to use Azure in combination with Office 365 and everything else.

37
00:02:29,040 --> 00:02:32,480
That's basically where my journey into Azure started as well.

38
00:02:32,480 --> 00:02:39,120
Did that for a couple of years and then a company called 350 came along.

39
00:02:39,120 --> 00:02:42,800
And I started working there.

40
00:02:42,800 --> 00:02:46,960
And basically the only thing I did there was working the cloud.

41
00:02:46,960 --> 00:02:52,560
We only did cloud implementations, cloud transformations, cloud migrations.

42
00:02:53,840 --> 00:02:59,360
That's a cool thing about your introduction as well is that it's a little bit outdated already.

43
00:02:59,360 --> 00:03:06,240
For some part, I still work for 350.

44
00:03:06,240 --> 00:03:14,800
But 350 was acquired in 2025 by a company called Data Balance in the Netherlands.

45
00:03:14,800 --> 00:03:18,560
But basically we are now part of the Data Balance Group.

46
00:03:18,560 --> 00:03:23,760
And we're working towards a final integration of 350 itself as well.

47
00:03:24,080 --> 00:03:29,680
So that's basically also where my role changed from being a CTO with 350 to now being the head of

48
00:03:29,680 --> 00:03:36,000
technology for the Microsoft part of the company. So there's a lot of things changed already.

49
00:03:36,000 --> 00:03:45,920
And even the user group is changed as well because I basically now run a user group together with

50
00:03:45,920 --> 00:03:48,960
Danny Krueger in the Netherlands called Azure Heroes.

51
00:03:48,960 --> 00:03:52,400
Okay, yeah, I know the Azure Heroes.

52
00:03:52,400 --> 00:03:58,320
That's cool. So the not just cloud meeting is now the Azure Heroes.

53
00:03:58,320 --> 00:04:05,520
Yeah, yeah, it's basically what we did in the past is that when Corona came,

54
00:04:05,520 --> 00:04:10,880
we noticed that doing user groups, media ups and everything else was getting really hard.

55
00:04:10,880 --> 00:04:19,680
Basically, Henry and I where I did the user group with were not a complete fan of doing online

56
00:04:19,680 --> 00:04:26,400
meetups because we like the to have the conversations and discussions as well with the participants.

57
00:04:26,400 --> 00:04:31,120
And that's the you missed that really on doing and the online ones.

58
00:04:31,120 --> 00:04:37,680
And after Corona, it was really hard to start off again and get a lot of people involved in

59
00:04:37,680 --> 00:04:41,440
everything else. So basically we we stopped doing the Dutch cloud meetup.

60
00:04:41,440 --> 00:04:47,840
And the fun thing is a few months later, Danny took over the meetup group on meetup.

61
00:04:48,960 --> 00:04:51,440
I didn't know about that and I'm Mac Danny.

62
00:04:51,440 --> 00:04:59,280
I think one of one of one of a year ago on one of the Azure Heroes days.

63
00:04:59,280 --> 00:05:05,040
And for some reason, it's really clicked. So we became friends.

64
00:05:05,040 --> 00:05:09,680
And I started working with Azure Heroes as well.

65
00:05:09,680 --> 00:05:14,480
And then I noticed that he just took over our meetup group and everything else.

66
00:05:14,480 --> 00:05:21,520
So it's really a cool combination on how things come together and how basically how small the I2 rule

67
00:05:21,520 --> 00:05:23,760
this as well. Yeah.

68
00:05:23,760 --> 00:05:28,560
Is there something you can say you learned from running these communities?

69
00:05:28,560 --> 00:05:34,080
Yeah, basically that's just a lot of time.

70
00:05:34,080 --> 00:05:37,840
You have to put a lot of effort in it.

71
00:05:37,840 --> 00:05:44,240
But that's also the thing I really love because I really love doing things related to

72
00:05:44,240 --> 00:05:52,400
IT. I really love being able to share knowledge and also to network with a lot of people as well.

73
00:05:52,400 --> 00:05:58,640
And see and have discussions around the most different topics that they are.

74
00:05:58,640 --> 00:06:02,800
And also getting those people together basically in a room.

75
00:06:02,800 --> 00:06:10,320
And the thing that I've learned the most, I think it's that it's you think it's you think there

76
00:06:10,320 --> 00:06:16,560
would be a lot of people that are wanting to come to one location.

77
00:06:16,560 --> 00:06:22,960
But it still seems to be a bit hard to get a lot of people involved in the same location.

78
00:06:22,960 --> 00:06:26,400
And also basically doing that on-prem with them as well.

79
00:06:26,400 --> 00:06:36,400
And that's I think that's also something in the way people are now working.

80
00:06:36,400 --> 00:06:42,000
And basically if you look at the young people, they are more of, they're more

81
00:06:42,000 --> 00:06:47,600
infinite with the online way of working. And that's the old change.

82
00:06:47,600 --> 00:06:53,760
And you and that also helped me in doing my work as a CTO and then head of technology as well,

83
00:06:53,760 --> 00:06:59,040
is that young people look at things very different than the old people.

84
00:06:59,040 --> 00:07:03,600
I would not say that I'm old, but there's a real reputation there, right?

85
00:07:03,600 --> 00:07:14,240
So let's a little jump a little bit in the state of Azure and Clouds in 2000, 206.

86
00:07:14,240 --> 00:07:18,080
What are biggest cloud trends you're seeing right now?

87
00:07:18,080 --> 00:07:21,840
There are a lot of cloud trends.

88
00:07:21,840 --> 00:07:28,720
I would mainly say that we, and basically that's also because I now work for

89
00:07:29,360 --> 00:07:35,840
for Data Balance as well. And it's basically, the company has a different mindset than we had in the

90
00:07:35,840 --> 00:07:41,600
past. Basically if you look at the how 350 works, basically we were a cloud-only copy.

91
00:07:41,600 --> 00:07:49,040
The only thing we did basically was doing Microsoft's cloud of 365 or maybe Azure.

92
00:07:49,040 --> 00:07:58,800
Data Balance is one of the largest MSPs in the Netherlands as well. And they also have their own

93
00:07:58,800 --> 00:08:03,680
data center. So basically we have our own data center on prem as some in Netherlands.

94
00:08:03,680 --> 00:08:09,840
So the mindset there is also a bit different than how our company was.

95
00:08:09,840 --> 00:08:16,800
But the cool thing about that was is that we also saw a shift in the market.

96
00:08:16,800 --> 00:08:22,720
Our companies also more moving to hybrid scenarios.

97
00:08:24,640 --> 00:08:31,680
All because of the America discussion and how that is run. So they're really looking at the

98
00:08:31,680 --> 00:08:37,840
sovereign cloud in combination with Azure or maybe a data center on prem and also having

99
00:08:37,840 --> 00:08:42,720
that stuff on prem. So basically the combination of what happened with Data Balance is that

100
00:08:42,720 --> 00:08:48,320
we have some cool stuff that we can do together because we have our own data center.

101
00:08:48,320 --> 00:08:53,360
We have the knowledge of the cloud. So we really can work towards those hybrid scenarios as well.

102
00:08:53,360 --> 00:09:02,640
But for a commodity, we also still have full cloud-only companies that really want to focus on the

103
00:09:02,640 --> 00:09:11,680
cloud part as well. And don't see the things around the sovereign cloud. And they see it, but they

104
00:09:11,680 --> 00:09:22,800
don't think that it's that important. Yeah, I think that's interesting transformation.

105
00:09:22,800 --> 00:09:27,520
And that's what I had a podcast and I learned Active Directory is not that.

106
00:09:27,520 --> 00:09:30,960
I think that's certainly not that.

107
00:09:30,960 --> 00:09:34,560
We still feel a lot.

108
00:09:34,560 --> 00:09:44,400
What mistakes are organizations still make? Yeah, I call it cloud transformation.

109
00:09:44,400 --> 00:09:47,840
What do you mean? Which question?

110
00:09:49,360 --> 00:09:54,720
What are the mistakes are organizations still making during cloud transformation?

111
00:09:54,720 --> 00:10:03,600
That's easy. And that's basically the whole problem I see with basically the Azure cloud or

112
00:10:03,600 --> 00:10:11,520
maybe AWS or the Google cloud as well is that it's so easy to just get started.

113
00:10:11,520 --> 00:10:17,760
Creating account, setting up the credentials and then basically creating a VM.

114
00:10:18,640 --> 00:10:24,000
You can do that within five minutes and that you have a data center up and running.

115
00:10:24,000 --> 00:10:31,280
But yeah, do they really know how it works? And do I really understand on how the connections work

116
00:10:31,280 --> 00:10:36,960
and everything else? How do you set up MFA? Make sure entrius completely safe? No, they don't.

117
00:10:36,960 --> 00:10:42,080
And that's basically that's still the problem we see with a lot of companies where we

118
00:10:42,080 --> 00:10:47,600
speak to companies where they have started using Azure and they just started off.

119
00:10:47,600 --> 00:10:56,480
Now we need to completely set up the complete environment again because they just did something.

120
00:10:56,480 --> 00:11:04,000
And they do it from their point of knowledge and see, oh, okay, that's easy. But they don't look

121
00:11:04,000 --> 00:11:10,240
further than just creating a VM and having it up and running. They still think that everything

122
00:11:10,240 --> 00:11:16,240
is secure by default. But as we know, mainly in Azure and nothing is secure by default and they

123
00:11:16,240 --> 00:11:21,120
basically they are moving that way, making everything secure by default. What it wasn't in the past.

124
00:11:21,120 --> 00:11:28,640
Meaning that if you just created a VM or a SQL database, it's open to the complete world.

125
00:11:28,640 --> 00:11:33,280
That's some kind of way, of course. There's still a authentication in there, but you also need to

126
00:11:33,280 --> 00:11:44,000
make arrangements for that as well. And did you see especially the last two years,

127
00:11:44,000 --> 00:11:52,000
the AI topic is growing everywhere. So is it also an error cloud topic?

128
00:11:52,000 --> 00:12:00,000
It's a topic everywhere, right? It's not yet made to cloud topic. It's an M365 topic. It's a

129
00:12:00,000 --> 00:12:08,320
window topic. It's basically an everywhere topic. And you can start off basically even doing a

130
00:12:08,320 --> 00:12:16,880
conference without having something related to AI. So it's really, yeah, it's really, it's at some point,

131
00:12:16,880 --> 00:12:26,480
it's really gets a moment, right? For me then, especially because everything where you look at

132
00:12:26,480 --> 00:12:32,960
conferences and everything else, it always needs to be AI. It is, AI is, AI by that. And it's also fun.

133
00:12:32,960 --> 00:12:42,400
I really love AI. Don't get me wrong about that. I use it on a daily basis, even working on

134
00:12:42,400 --> 00:12:49,120
infrastructures, code, working on my Azure environment, and everything else, I use AI, of course.

135
00:12:49,120 --> 00:12:57,040
And I really think that companies all around should really invest in moving towards AI.

136
00:12:59,600 --> 00:13:10,320
But at some points, yeah, it's, how do I say that nicely? It's a both world, right? It's making

137
00:13:10,320 --> 00:13:16,800
everything about AI, around AI. And yeah, we really need to invest in towards AI.

138
00:13:16,800 --> 00:13:24,800
But for my point of view, we should really stop using it as a buzzword as well for everything.

139
00:13:25,680 --> 00:13:32,480
And even making everything possible with an agent, we need to have an Azure agent. We need to have

140
00:13:32,480 --> 00:13:37,680
an 365 agent. We need a PowerPoint agent. We need a word agent. We got a lot of agents already.

141
00:13:37,680 --> 00:13:44,320
That's fine if it works and if it works perfectly, but we really need to focus on doing one thing right.

142
00:13:44,320 --> 00:13:52,160
And it, I think doing one thing right is also moving towards having good adoption for AI.

143
00:13:53,040 --> 00:13:58,720
And we see a lot of companies having problems with that as well. You need to, you need really need

144
00:13:58,720 --> 00:14:06,000
to look at towards AI and how do we want to use it? Use the public AI. We still see companies using

145
00:14:06,000 --> 00:14:13,600
the public AI with data that they really can't use on public AI. And people don't understand

146
00:14:13,600 --> 00:14:20,320
that risk completely fully at this point. Yeah, it's also nice topic. I was on hardware,

147
00:14:20,960 --> 00:14:28,320
Favourite T. And also they had also PC towers now with integrated AI. So,

148
00:14:28,320 --> 00:14:39,360
I found everybody. So, um, only towards everything, I think it's something you, in the tech,

149
00:14:39,360 --> 00:14:45,760
you have to label it today, everything the AI. But another topic you are, I think, you're

150
00:14:45,760 --> 00:14:52,960
often in addition for its infrastructure as a code. Can you, for people that are not familiar

151
00:14:52,960 --> 00:14:59,840
with this concept, can you a little bit explain it? Yeah. So, let me explain it then as simple as

152
00:14:59,840 --> 00:15:07,440
possible. I always see it as a piece of code or a piece of writing depending on the language

153
00:15:07,440 --> 00:15:17,520
you use. That represents your infrastructure. So, may it be DNS entries, may it be Azure resources,

154
00:15:17,520 --> 00:15:25,360
may it be a database and everything else. And basically specifying that in a piece of code,

155
00:15:25,360 --> 00:15:32,080
so just a piece of writing and having that available in, for example, version control.

156
00:15:33,920 --> 00:15:40,480
So, that it's really easy to maintain your infrastructure and also keep that in line with

157
00:15:40,480 --> 00:15:46,560
the rules or regulations you have within the company. So, for example, if I would be in a

158
00:15:46,560 --> 00:15:52,720
company, I needed to create a VM. I can let me leave. That's easy, right? So, creating one VM is

159
00:15:52,720 --> 00:15:59,760
easy, manually. And maybe I also have to do some configurations as well. That's easy. But if I

160
00:15:59,760 --> 00:16:06,560
ask the same person to do it 10 times, it will be hard. It will not be hard, but the hard point

161
00:16:06,560 --> 00:16:14,960
about it is then you will never do it 10 times the exact same way. We see differences there because

162
00:16:14,960 --> 00:16:22,560
it's all done manually. So, if we specify that in a piece of infrastructure as code, he just runs

163
00:16:22,560 --> 00:16:30,400
the script 10 times and he gets 10 times the same result and not 10 times a different result.

164
00:16:30,400 --> 00:16:37,440
That pair are really, that's the thing I love of infrastructure as a code. And we see it a lot

165
00:16:37,440 --> 00:16:44,000
within IT, especially within Cloud environment as well, even on prem environments.

166
00:16:44,960 --> 00:16:54,960
We are running as well. It's really handy as well. And it's also a cost-safer as well because

167
00:16:54,960 --> 00:17:03,440
doing a lot of things twice is made easy as well because you just run a piece of infrastructure

168
00:17:03,440 --> 00:17:08,640
as code with different input variables. So, you can reuse it every time.

169
00:17:11,360 --> 00:17:20,640
I think the one problem I understand is it's safe time, especially we doing this boring stuff

170
00:17:20,640 --> 00:17:28,400
again and again. And the other thing I think it makes it more, yeah, also more handable for

171
00:17:28,400 --> 00:17:39,520
all the other things you have to secure your VMs. And then you have, I think, yeah,

172
00:17:39,520 --> 00:17:46,160
then you can do all the same things on Defender and so on. I don't know if it works,

173
00:17:46,160 --> 00:17:53,040
oh, we got all the tools on error. But what does what see you especially or what problems do

174
00:17:53,040 --> 00:18:03,040
it also, yeah, solve. It's also a piece of automation, right? So, basically, there are a lot of ways

175
00:18:03,040 --> 00:18:08,240
where you can specify infrastructure as code, right? So, you have, for example, you have Terraform,

176
00:18:08,240 --> 00:18:16,160
you have Bysup. And I mainly don't have, you always see discussion around in the community on

177
00:18:16,160 --> 00:18:22,160
that you should write Terraform, that you should write Bysup. And I really don't have any

178
00:18:22,160 --> 00:18:30,880
obligations since to a specific tool or maybe Plumi as well. You can use a lot of things already nowadays.

179
00:18:30,880 --> 00:18:38,000
And basically the problems that it solves, it solves also a part of the automation part.

180
00:18:38,480 --> 00:18:45,200
And also about the configuration drift, depending on how you set it up and how you configure it,

181
00:18:45,200 --> 00:18:50,000
of course. So basically by default, it doesn't solve anything. But if you look, for example,

182
00:18:50,000 --> 00:18:57,680
in a way that you can solve a configuration drift. So, you can imagine that if you deploy,

183
00:18:57,680 --> 00:19:03,920
let's say an app service in the Azure platform, you can do that manually. And then you

184
00:19:03,920 --> 00:19:08,400
can figure it out everything else. You can set environment variables and everything out to the

185
00:19:08,400 --> 00:19:17,760
amenity. And basically, even doing that manually will get you into problems. So you maybe make a typo

186
00:19:17,760 --> 00:19:23,520
or if anything else, you do it for one customer, now for the second customer and then you have different

187
00:19:23,520 --> 00:19:30,080
configurations. You maybe have a typo somewhere. So if you have that in an infrastructure,

188
00:19:30,080 --> 00:19:36,480
code language like, for example, Terraform, you have everything specified out. You sure you will not

189
00:19:36,480 --> 00:19:41,920
make typos because it's all an infrastructure, so you have specified it once already.

190
00:19:41,920 --> 00:19:49,280
And you can automate the process around doing the deployments. But what it also solves is that if you

191
00:19:49,280 --> 00:19:54,960
for some reason make a manual change in the Azure platform because people have, you'll always see

192
00:19:54,960 --> 00:20:00,240
within companies that people have specific rights within the Azure subscription, for example, maybe

193
00:20:00,240 --> 00:20:07,680
the current contributor. And they think, okay, let me just set this service completely open to

194
00:20:07,680 --> 00:20:13,040
the Internet. You can use the infrastructure code as a manual configuration drift check.

195
00:20:13,040 --> 00:20:21,600
To check if there are made configuration changes. So you can really do the state management part

196
00:20:21,600 --> 00:20:28,000
of doing it via Terraform or maybe work towards when you're more into bicep and Azure

197
00:20:28,000 --> 00:20:34,960
and everything else, you could use deployment stacks to basically close down specific resources.

198
00:20:34,960 --> 00:20:38,080
So that you don't have any configuration drift anymore.

199
00:20:38,080 --> 00:20:49,920
You have also to say, to products bicep Terraform and I also will not add R& templates. How do you

200
00:20:49,920 --> 00:20:59,280
compare them? Basically, I see bicep and ARM templates as exactly the same. Basically bicep is

201
00:20:59,280 --> 00:21:05,200
an instructional layer on top of a R&M. So that it makes it easier for you to write

202
00:21:05,200 --> 00:21:14,240
infrastructure code for the Azure platform. So bicep now mainly points towards

203
00:21:16,480 --> 00:21:27,440
the Azure platform. There are possibilities to move from the Azure platform. I will tell you

204
00:21:27,440 --> 00:21:34,560
that a little bit later. Terraform is basically the main difference I see between those two is that

205
00:21:34,560 --> 00:21:44,560
of course Terraform works for AWS, works for Azure, Google, Outflare, you name it and it's almost

206
00:21:44,560 --> 00:21:51,200
possible with Terraform. Bicep is mainly for the Azure platform. That's the main difference, I think,

207
00:21:51,200 --> 00:22:00,880
besides that Terraform maintains the state. That's something that bicep cannot do. Terraform basically

208
00:22:00,880 --> 00:22:11,360
does it maintains the state file off your state from your resources, meaning that there's also a way of

209
00:22:12,320 --> 00:22:17,280
checking your configurations with, checking your changes that you are doing towards your cloud

210
00:22:17,280 --> 00:22:25,360
resources. That's something that bicep doesn't really have because bicep really sees the resources

211
00:22:25,360 --> 00:22:31,760
in Azure state. You can do a what if to see basically the changes you are doing,

212
00:22:31,760 --> 00:22:38,720
but it doesn't have a complete state management capability around the language itself.

213
00:22:40,000 --> 00:22:46,800
I've met with extending bicep. There is a preview functionality now in bicep so that you can create

214
00:22:46,800 --> 00:22:54,640
your own extensions. Basically what you can do is now create HTTP extensions. There are already

215
00:22:54,640 --> 00:23:01,280
extensions for cloud flare for AC DevOps, forget a bent price so that you can basically

216
00:23:02,960 --> 00:23:10,560
make your specific resources like a cloud for DNS entry or a repository also in bicep.

217
00:23:10,560 --> 00:23:15,520
But you have to build it yourself because there's a C# extension

218
00:23:15,520 --> 00:23:18,640
you can start building your own extensions.

219
00:23:18,640 --> 00:23:31,760
So the infrastructure has code. It's all based on C#, I think the most Microsoft products.

220
00:23:32,720 --> 00:23:39,280
It's 365 and so on, run on PowerShell and Graph API. How does this work?

221
00:23:39,280 --> 00:23:41,840
You mean infrastructure scope?

222
00:23:41,840 --> 00:23:50,000
Basically bicep is its own language, so basically bicep is more or less looks like YAML.

223
00:23:51,680 --> 00:24:01,920
Derroform has its own HashiCob language and you can still use PowerShell or C#.

224
00:24:01,920 --> 00:24:05,200
It basically depends on what you want to do and what kind of scenario.

225
00:24:05,200 --> 00:24:13,040
You can even use the FGCLI to make your configuration changes. But more or less if you

226
00:24:13,680 --> 00:24:21,200
even as an infrastructure scope part, if you use Pulumi, I guess, yeah I think Pulumi is also

227
00:24:21,200 --> 00:24:25,520
that's a C# representation of doing infrastructure scope. So there are a lot of choices

228
00:24:25,520 --> 00:24:32,400
depending on what kind of language you want to use. You can always use them in different kind of scenarios.

229
00:24:32,400 --> 00:24:38,080
And what does the road, I think a little bit about,

230
00:24:39,600 --> 00:24:49,600
yeah, how implement the infrastructure as code, how implementation had it on, yeah, say secret and

231
00:24:49,600 --> 00:25:00,000
governance? So basically you always have to check on how you do with secrets, right? And it's

232
00:25:00,000 --> 00:25:07,760
no different if you create an application or if you create infrastructure scope as well,

233
00:25:08,480 --> 00:25:14,000
you always have to check on where you keep your secrets, how you save them and how you maintain them.

234
00:25:14,000 --> 00:25:18,480
So for example, you can, in infrastructure as code, you can reference keyboard secrets.

235
00:25:18,480 --> 00:25:27,600
Or if you use them in an automation like at a Benz price, you can save them in a repository secret

236
00:25:27,600 --> 00:25:32,880
or an action secret. It's all depending on your use case and how you want to do with it as well.

237
00:25:34,400 --> 00:25:46,000
So have you a real use case scenario from a project without X play or the, yeah, I can explain

238
00:25:46,000 --> 00:25:51,280
the use case. So for example, basically use case, we are working at this point now is basically

239
00:25:51,280 --> 00:25:58,000
creating a landing zone in Azure for customer, having different subscriptions, different

240
00:25:58,000 --> 00:26:02,480
management groups, of course, and also making a subscription vending system around it as well.

241
00:26:03,520 --> 00:26:07,920
And basically what we are doing now, we are, we have set up a get a enterprise environment for

242
00:26:07,920 --> 00:26:15,680
that customer with different kind of projects and repositories so that they can work towards

243
00:26:15,680 --> 00:26:22,720
a one single plane of class for the platform, but also maintain those secrets. So what we do there is

244
00:26:22,720 --> 00:26:29,920
the secret that we really need are saved as environment secrets within get a Benz price.

245
00:26:31,360 --> 00:26:38,400
But we also want to move towards a system where we don't really need those secrets.

246
00:26:38,400 --> 00:26:43,280
So basically now if you look at towards automation with get a Benz price and get a

247
00:26:43,280 --> 00:26:51,520
actions of course, you can use federated identity credentials, basically specifying

248
00:26:53,040 --> 00:27:01,840
on your credentials which system can communicate. So you can, to give you an idea, you can create

249
00:27:01,840 --> 00:27:07,120
many identities within the Azure platform. And with those manage and the entities, you really say

250
00:27:07,120 --> 00:27:12,320
to Microsoft, okay, I have an identity and I really don't know, I don't want to know the secret,

251
00:27:12,320 --> 00:27:18,560
but I give that identity specific rights. So that identity can for example,

252
00:27:18,560 --> 00:27:25,200
to go to my keyboard and with federated identities, I can give, I can explain a complete scenario

253
00:27:25,200 --> 00:27:31,920
for that identity and save that on the identity to say, okay, I have a get up action and this

254
00:27:31,920 --> 00:27:38,800
get up action can use that identity. So then I really don't have to think about how do I want to

255
00:27:38,800 --> 00:27:47,920
maintain my secrets. And how do you infrastructure, the code, the infrastructure task code work together

256
00:27:47,920 --> 00:27:54,480
with dev ops. It basically enables a certain dev ops scenarios, right? So basically,

257
00:27:54,480 --> 00:28:03,440
if I look towards dev ops, you also look in towards how you organize your teams, how you want to

258
00:28:03,440 --> 00:28:11,760
work with your teams, mainly make them self organizing as well. So you have some kind of way where

259
00:28:11,760 --> 00:28:17,680
they can do their own things in their own environment. So you want to give them a piece of the

260
00:28:17,680 --> 00:28:24,720
platform and really have them maintain that piece of platform. And if I look towards

261
00:28:24,720 --> 00:28:31,040
infrastructure's code, it's a way for them to maintain that piece of platform and work towards

262
00:28:31,040 --> 00:28:40,160
a useful platform for them and maintain it themselves without me being there and being

263
00:28:40,160 --> 00:28:45,440
hammered with questions, okay, can I have an absurge? Can I have this? Can I have that? No, I give them

264
00:28:45,440 --> 00:28:52,880
rules and regulations a part of my platform and they can do whatever they want in their based on

265
00:28:52,880 --> 00:29:04,960
those rules and regulations? Also in dev ops, I see, I will say it's an all the product. It's

266
00:29:04,960 --> 00:29:14,800
has been here for some years. But have you an idea why so many companies struggle with dev ops,

267
00:29:14,800 --> 00:29:21,520
actually? Oh, you mean the product? I should dev ops. Do you mean that? Yeah.

268
00:29:21,520 --> 00:29:30,160
No, it's more, do you think, do you mean that companies are struggling with it? Basically

269
00:29:30,160 --> 00:29:34,320
having it maintained and everything else? I really don't see that, but

270
00:29:34,320 --> 00:29:41,680
basically, I was more referring to dev ops as being a principal in a culture, right? So

271
00:29:43,520 --> 00:29:50,000
from my point of view, dev ops is really a culture within a company that should help a company do more

272
00:29:50,000 --> 00:29:55,200
automation and everything else may be with infrastructure, scope, or other stuff.

273
00:29:55,200 --> 00:30:05,840
But if we look towards actually dev ops, I think it's a good product

274
00:30:08,640 --> 00:30:16,080
that can help you with setting things up. And I don't see a lot of companies struggling with it.

275
00:30:16,080 --> 00:30:23,360
It's more about, and it's also the same thing I refer to with Azure. It's easy to start with.

276
00:30:23,360 --> 00:30:32,560
And doing a thing good is hard. But because it's easy to get started,

277
00:30:33,200 --> 00:30:40,320
you see a lot of companies moving from doing just one project to doing multiple projects within

278
00:30:40,320 --> 00:30:45,600
Azure dev ops. And they really don't have an idea on how they have to set it up correctly to have

279
00:30:45,600 --> 00:30:56,240
those complete integrations they really want. Yeah, I think let us go back to dev ops else. Yeah,

280
00:30:56,240 --> 00:31:15,840
I think as I got down, yeah, as a principle, how much of dev ops is technology and,

281
00:31:15,840 --> 00:31:22,080
yeah, I say, versus culture? I think it's, oh, that's a hard question.

282
00:31:22,720 --> 00:31:26,400
I think more or less you are working towards 80% of culture.

283
00:31:26,400 --> 00:31:35,120
No, it's not more or less it's culture and processes, right? Even it really doesn't

284
00:31:35,120 --> 00:31:42,400
mind which kind of technology you use. It's more a way of how you work and how you get those principles

285
00:31:42,400 --> 00:31:51,920
in there. It's not about the tooling. The tools enable you to do something. So that's the, mainly

286
00:31:51,920 --> 00:31:59,200
people see it as technology, but it's really not because you have to have a specific kind of way

287
00:31:59,200 --> 00:32:03,920
of working and you have a lot of tools, right, to enable you to do in dev ops.

288
00:32:03,920 --> 00:32:15,120
And that's, I think on there, yeah, I say it's a little bit add on, but there's a found in a new,

289
00:32:17,200 --> 00:32:24,880
yeah, I don't know, buzzwords on dev ops. A lot of people now discuss get ops. Can you

290
00:32:24,880 --> 00:32:33,440
a little bit a picture what is this? I really, I really am, I'm a person that really is not into

291
00:32:33,440 --> 00:32:44,640
the buzzwords. I really don't follow those, all those buzzwords. But if I should try to explain

292
00:32:45,440 --> 00:32:53,840
dev ops and slash get ops, I think get ops is more working towards the technology using get, right?

293
00:32:53,840 --> 00:33:04,640
So that's the, I see there is, I think that's the only difference. Because you move towards using

294
00:33:04,640 --> 00:33:10,640
get and that's more or less also already stating which kind of technology you use, right? But even

295
00:33:10,640 --> 00:33:18,800
you also have, for example, dev sec ops and dev bishops. When dev ops was a thing, right, I think, I

296
00:33:18,800 --> 00:33:27,200
still think dev ops is a thing, but back in the days, let me, let me say it that way. When dev

297
00:33:27,200 --> 00:33:33,040
ad really started off, you, you, you ball got those abbreviations of dev sec ops, dev bishops.

298
00:33:33,040 --> 00:33:40,240
And it's still about doing this exact same thing from my point of view, because if you develop

299
00:33:40,240 --> 00:33:46,720
applications in a dev ops team, you also need to think about security. So why call it dev sec ops?

300
00:33:46,720 --> 00:33:53,280
Because it's, it's a principle of you developing software and if you develop software, you need to

301
00:33:53,280 --> 00:34:01,200
think about security. And of course, you need to, because the dev sec ops, I think the abbreviation

302
00:34:01,200 --> 00:34:06,800
came from development and operations. That's why they started with dev sec ops. So you have

303
00:34:06,800 --> 00:34:13,040
development security and operations. But in my point of view, a dev ops team should always be

304
00:34:13,040 --> 00:34:21,600
a team with people that know different stuff. So you should have security people in there. You

305
00:34:21,600 --> 00:34:28,640
should have people coming from the business. But there's more in those, the business side of you

306
00:34:31,600 --> 00:34:37,520
and work towards one integrated to you that can develop software or maintain environments.

307
00:34:37,520 --> 00:34:46,240
And do that all in all one operation. But did you think GitHub will become the default platform?

308
00:34:46,240 --> 00:34:56,640
You never know, but there still, there are still, yeah, for Microsoft's,

309
00:34:57,520 --> 00:35:04,720
and people that are really into Microsoft, I guess, GitHub will be one in some kind of way, right? Be

310
00:35:04,720 --> 00:35:14,400
one of the preferred platforms. But they don't think as you dev ops will, will go away. Not anytime soon.

311
00:35:14,400 --> 00:35:24,160
Because we still, there's still a lot of large companies that really invest into dev ops, in as you

312
00:35:24,160 --> 00:35:36,720
dev ops. And I think GitHub enterprise is, it's moving towards the difference between GitHub

313
00:35:36,720 --> 00:35:43,040
and as you dev ops is more or less, as you dev ops is set up in a way for the largest,

314
00:35:43,040 --> 00:35:50,880
larger companies, right? And GitHub itself came from a community standpoint, running for the community.

315
00:35:51,520 --> 00:35:57,280
It has not been set up in a way that people think, okay, an enterprise will use our system. That's not

316
00:35:57,280 --> 00:36:03,520
how GitHub started, GitHub started really as a community effort and supporting those community efforts.

317
00:36:03,520 --> 00:36:10,400
And it's now moving towards being the enterprise platform. And it's, it's gone a long way. And I think

318
00:36:10,400 --> 00:36:18,400
they, they really made good steps. But for example, if you look at enterprise boards, I know a lot of

319
00:36:18,400 --> 00:36:24,480
companies that really like the enterprise board stuff. Yes, you dev house boards. More deficialization,

320
00:36:24,480 --> 00:36:29,520
how it works, how they can track everything around. But you also have already have GitHub enterprise

321
00:36:29,520 --> 00:36:36,480
projects, for example. And it also looks very nice and very handy to work. And you also see companies

322
00:36:36,480 --> 00:36:42,880
doing, basically doing both. So they have as you dev ops for doing their projects, engineering and

323
00:36:42,880 --> 00:36:48,960
everything else, making sure that every work item is every there. And then you have the source code in

324
00:36:48,960 --> 00:36:58,720
GitHub. That's also good combination. So I don't think there is a specific preferred platform,

325
00:36:58,720 --> 00:37:09,280
because you also still have platforms like GitLab. And it can be used to use Git. So I think there

326
00:37:09,280 --> 00:37:16,080
are a lot of choices for companies always to use a specific platform. And in your daily work,

327
00:37:16,080 --> 00:37:25,200
let's look a little bit into the AI topic. Is there, how are the way changed for infrastructure

328
00:37:25,200 --> 00:37:32,800
teams working with AI, actually? I think they move faster than they did.

329
00:37:34,640 --> 00:37:41,600
So if you look at writing infrastructures code, normally you would have to do everything

330
00:37:41,600 --> 00:37:49,600
yourself, right? You have to write every piece, every line of code yourself. Now I explain a scenario

331
00:37:49,600 --> 00:37:54,720
to my, to get a code pilot, for example, I explain the scenario of what I want to do.

332
00:37:56,800 --> 00:38:05,040
And then just ask, okay, write me the terraform for this. And then in less than two minutes,

333
00:38:05,040 --> 00:38:13,760
I have a lot of lines of code. And hopefully it does what I've asked it to do.

334
00:38:13,760 --> 00:38:20,480
And then you only need, and that's the thing that I really find important, you need to validate

335
00:38:21,120 --> 00:38:27,200
what came out of code pilot, not just to, okay, it created this infrastructure code. I will just

336
00:38:27,200 --> 00:38:31,120
write a very deploy it to my Azure environment. No, you have to do a validation.

337
00:38:31,120 --> 00:38:39,840
Because, and that's a thing we have discussions around with companies as well is,

338
00:38:39,840 --> 00:38:44,720
some people are scared of the fact that when I use AI,

339
00:38:46,560 --> 00:38:52,240
that people and their co-workers and everything, I will get dumber because they really don't have to

340
00:38:52,240 --> 00:39:01,520
write it themselves anymore. No, they just ask AI and say, okay, great, me this power show script.

341
00:39:01,520 --> 00:39:06,880
I want to delete all share-pon sites, give me a power show script to do this.

342
00:39:06,880 --> 00:39:16,000
And AI will make it within a few seconds, but people don't understand what all those lines of

343
00:39:16,000 --> 00:39:21,920
code are. So what we do within our company as well is that basically everyone within our company

344
00:39:21,920 --> 00:39:28,960
can use AI. If they want to use AI, they can use AI. But the main point there is that if I see a

345
00:39:28,960 --> 00:39:36,160
pool request or any line of code, and people can't explain to me what that line of code is,

346
00:39:36,160 --> 00:39:41,280
I will send them back to the drawing board and let them start off again.

347
00:39:42,720 --> 00:39:47,040
Because that's a very important thing you need to understand what you're doing and how you're doing

348
00:39:47,040 --> 00:39:57,360
it. And you can use AI to foster your work and make it even faster, but you have to know what you're

349
00:39:57,360 --> 00:40:04,240
doing and be able to explain what you're doing as well. No, that's a really cool thing, I think,

350
00:40:04,240 --> 00:40:09,040
to validate AI generated infrastructure. And I think itself also the people learning

351
00:40:09,840 --> 00:40:17,760
more what they do in it, I think, yeah, some surprising, I think there was a lot of company that

352
00:40:17,760 --> 00:40:25,120
have surprising results when they use AI, when we look at some LinkedIn posts or a community posts.

353
00:40:25,120 --> 00:40:35,520
So can you a little bit more how you, for yourself, validate AI generated infrastructure?

354
00:40:36,640 --> 00:40:45,200
Yeah, basically how I validate my, so if I work with infrastructure as code and use AI to validate,

355
00:40:45,200 --> 00:40:50,480
basically, I use AI to create my, for example, my telephone code or my bicep code.

356
00:40:50,480 --> 00:40:57,760
I haven't in the last couple of months, I haven't had a scenario where I just started of myself.

357
00:40:57,760 --> 00:41:05,520
No, I basically for every piece of code I wrote, I used AI. And just because it's easy and

358
00:41:05,520 --> 00:41:17,040
easy to get started and everything else, the thing I do after AI generated my code, I basically

359
00:41:17,040 --> 00:41:25,120
really go from line to line, but I also use specific instructions, specific prompt files and

360
00:41:25,120 --> 00:41:33,520
everything else to make the generated code in a way I want it to be. So I really, in that point,

361
00:41:34,320 --> 00:41:42,000
AI really knows me. And by using GitHub Enterprise and, for example, GitHub Co-Pilot, it really

362
00:41:42,000 --> 00:41:51,120
has contact on how we write code as a company. Oh, it will also generate it this almost exactly

363
00:41:51,120 --> 00:41:59,360
the same way as we normally do, making it easy for us to validate as well. And also easy to go through

364
00:41:59,360 --> 00:42:06,960
it as well. And if you know, so I've written infrastructure code for years, so I know basically

365
00:42:06,960 --> 00:42:12,800
what it does, how it does it, and how it should work. And making it also easy for me to be able to

366
00:42:12,800 --> 00:42:21,920
validate all the lines of code. And just basically going through it and see what it does. And if I see

367
00:42:21,920 --> 00:42:30,800
something that I don't understand, I always, I also try to learn from what AI generates for me. So I've

368
00:42:30,800 --> 00:42:37,440
had situations where AI generated some pieces of code where I really did not understand what it was

369
00:42:37,440 --> 00:42:43,120
doing. As I really needed to take the time as well to basically start learning about, okay,

370
00:42:43,120 --> 00:42:50,240
he generated something cool for me, but then understand it. Let me just take an hour to go through it

371
00:42:50,240 --> 00:42:56,880
and see what it did and why it did that. And when different kind of scenarios, I was thinking about

372
00:42:56,880 --> 00:43:01,760
that really helps me as well of basically learning everything else as well, because you see different

373
00:43:01,760 --> 00:43:11,360
scenarios. When someone says, or people they like to start with infrastructure as code today, so

374
00:43:12,800 --> 00:43:22,720
how they, what tips can you give them, how they should start? Basically, for at first look at which

375
00:43:22,720 --> 00:43:30,160
kind of language you want to start off with, because there are a lot. And mostly the language you

376
00:43:30,160 --> 00:43:39,120
start with is dependent on the company you work for. So in the past, our company, we had,

377
00:43:40,640 --> 00:43:45,840
we said we do bicep only. That was because we were a Microsoft company, we really focused on

378
00:43:45,840 --> 00:43:55,120
Microsoft stuff. So we said bicep only. Basically now at the company, we say, okay, we focus on Terraform,

379
00:43:55,120 --> 00:44:02,240
because we do much more than just Microsoft. We also do on-prem stuff. We do a cloudflash stuff,

380
00:44:02,240 --> 00:44:08,640
convolt, rename it, basically we do all kind of stuff. We do get a enterprise. So we really want to

381
00:44:08,640 --> 00:44:15,440
focus on one language. So that basically everything within the company can read and write and understand

382
00:44:15,440 --> 00:44:21,840
what people are making. So that's where we said, okay, we will move towards Terraform. So that's

383
00:44:21,840 --> 00:44:31,360
basically the first thing you need to do. But also, in the basis, start off, okay, why do I want to use

384
00:44:31,360 --> 00:44:39,120
infrastructure schedule? There should also always be a Y in Y or doing stuff. Don't just do stuff.

385
00:44:39,120 --> 00:44:46,400
No, think about why am I doing stuff? Why am I building infrastructure? And if you have that,

386
00:44:46,400 --> 00:44:56,320
just look forward to words, which kind of language fits the best. Because we even see companies where

387
00:44:58,320 --> 00:45:04,320
and customers that basically say, okay, we have a Microsoft only environment and we really want to

388
00:45:04,320 --> 00:45:09,840
start off with infrastructure scope. And then basically we always tell them, okay, we have,

389
00:45:09,840 --> 00:45:13,600
we explain them what Terraform is, we explain them what bicep is, for example.

390
00:45:13,600 --> 00:45:22,880
And then we'll also look at the learning curve of the people within the company. Because from my

391
00:45:22,880 --> 00:45:32,080
opinion, I see to get started off with Terraform, it's much harder to do. Because if you look at

392
00:45:32,080 --> 00:45:37,520
state management, now you need to do that in the correct way. We see a lot of people

393
00:45:37,520 --> 00:45:44,240
going wrong at that side. And then it's much easier to start off with biceps. So for example,

394
00:45:44,240 --> 00:45:49,840
if a Microsoft company says to me, okay, we really want to start doing infrastructure scope. We have a

395
00:45:49,840 --> 00:46:00,000
Microsoft only environment. And it shouldn't be that hard to get started. Then I would have a

396
00:46:00,000 --> 00:46:05,840
discussion, okay, maybe then bicep fits you best. But if they say, okay, but next year we are thinking

397
00:46:05,840 --> 00:46:13,120
about also doing AWS. Yeah, then it will be a different conversation. So it's always looking at

398
00:46:13,120 --> 00:46:22,160
use cases in the scenarios we have. Okay, cool. Yeah, let's jump into the fast

399
00:46:22,160 --> 00:46:29,520
to buy around. I give some short questions and you say what comes in your mind.

400
00:46:29,520 --> 00:46:38,320
Mr. Adolf Gita. Get up. Most underrated era service.

401
00:46:40,960 --> 00:46:44,480
Azure app service configuration. Azure app configuration. Yeah.

402
00:46:44,480 --> 00:46:52,240
Most over the technology trend. AI. No, no, no, no, no, no, that's not joke.

403
00:46:52,240 --> 00:46:55,920
Boo. Ah, that's a hard one.

404
00:46:55,920 --> 00:47:09,200
Most overrated. Yeah, I really don't have anything that comes into mind,

405
00:47:09,200 --> 00:47:16,480
sorry. Yeah, it's also cool and there are no overrated. No, yeah, but yeah, they're always

406
00:47:16,480 --> 00:47:24,720
over what I really, really overrated. No, no, I don't have something popping up.

407
00:47:24,720 --> 00:47:29,840
Then it's also okay. What is the biggest cloud mistake companies make?

408
00:47:31,600 --> 00:47:42,160
How did it? It's easy. Yeah, I really think that a lot of companies that really start off

409
00:47:42,160 --> 00:47:50,400
in the clouds. We have seen them a lot. Yeah, it's really easy to be sure by default. Let me

410
00:47:50,400 --> 00:47:56,080
put it that way. Okay. What was the best career advice we ever received?

411
00:47:56,080 --> 00:48:10,480
That's a cool one. I think that would be that just be yourself.

412
00:48:10,480 --> 00:48:17,840
And make sure that you have fun in what you're doing. If you have to,

413
00:48:17,840 --> 00:48:23,440
if you call it, say Microsoft one feature, they should roll out tomorrow. What should it be?

414
00:48:26,000 --> 00:48:42,640
Oh, that's cool. That's also a tough one. That's just because of, I really look at things

415
00:48:42,640 --> 00:48:49,840
from a simple point of view. So if there's something that I need, that isn't there, I just created.

416
00:48:51,360 --> 00:48:56,560
So that makes it hard for me. Oh, that's...

417
00:48:56,560 --> 00:49:03,120
Then the best tip is for Microsoft to take the tools from your board.

418
00:49:03,120 --> 00:49:09,760
No, but for example, basically in the past, and that's something I did a lot of years ago,

419
00:49:09,760 --> 00:49:19,680
I noticed that, for example, there wasn't an option to deploy your Power BI templates.

420
00:49:20,320 --> 00:49:26,400
Your Power BI reports, Fire Azure DevOps. So I created an extension for it.

421
00:49:26,400 --> 00:49:33,600
And that has still a lot of downloads as well and still being used on Azure DevOps as well.

422
00:49:33,600 --> 00:49:40,400
So I always look at things, I like the gaps between the products as well, right? Because that,

423
00:49:40,400 --> 00:49:46,560
also as a company, those gaps give me opportunities. If Microsoft just created everything,

424
00:49:47,680 --> 00:49:55,360
yeah, there wouldn't be any fun anymore. So, but if I look technology-wise, I would really love,

425
00:49:55,360 --> 00:50:02,800
because I'm also a bicep fanboy. I work a lot with Terraform, but I'm also a fan of bicep.

426
00:50:02,800 --> 00:50:08,880
I would really love that they... It's now preview, but

427
00:50:08,880 --> 00:50:13,440
and I really hope that they bring it to GA, the extensionability of bicep.

428
00:50:13,440 --> 00:50:16,960
I would really love if they bring it to GA.

429
00:50:17,600 --> 00:50:18,720
Let me put it. Yeah.

430
00:50:18,720 --> 00:50:24,080
Biter morning or a second?

431
00:50:24,080 --> 00:50:28,800
That's the other one. Depends on my mood.

432
00:50:28,800 --> 00:50:34,480
If I drink a beer, I would like a bit more.

433
00:50:34,480 --> 00:50:40,160
What's your favorite productivity habit?

434
00:50:42,240 --> 00:50:45,680
Putting up music, very loud.

435
00:50:45,680 --> 00:50:46,720
Basically, two louds.

436
00:50:46,720 --> 00:50:52,800
Yeah, so yeah, thank you, Rasmores.

437
00:50:52,800 --> 00:50:56,880
Really great record. Thank you for your time.

438
00:50:56,880 --> 00:51:06,000
So my last question is, what should everyone taking from this session when you can take one thing?

439
00:51:06,000 --> 00:51:08,480
You should remind them.

440
00:51:08,480 --> 00:51:15,920
Basically, the same as the advice I got as well is basically do the things you love to do.

441
00:51:15,920 --> 00:51:22,320
Basically, be also be open for the community and always try to support the community as well.

442
00:51:22,320 --> 00:51:28,160
And basically also looking at technology.

443
00:51:28,160 --> 00:51:31,120
Basically, technology isn't an easy thing.

444
00:51:31,120 --> 00:51:34,160
You really need to sometimes overthink stuff as well.

445
00:51:36,160 --> 00:51:41,520
And make sure that just make sure you do the things you love.

446
00:51:41,520 --> 00:51:45,120
Most important thing I think.

447
00:51:45,120 --> 00:51:48,560
Yeah, then I say thank you so much for joining me today.

448
00:51:48,560 --> 00:51:54,480
And yeah, cool. So have a nice day.

449
00:51:54,480 --> 00:51:59,280
And yeah, I hope we hear the next time again.

450
00:51:59,280 --> 00:52:03,680
Have a nice day. Bye.

451
00:52:03,680 --> 00:52:04,180
Bye.

452
00:52:04,180 --> 00:52:14,180
[BLANK_AUDIO]

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Maik van der Gaag

CTO at 3fifty | Microsoft MVP | Architect | Author | International Speaker

Maik van der Gaag is CTO at 3fifty, an experienced consultancy company with a strong focus on the Microsoft Cloud. He has over 15 years’ experience providing architecture, development, training and design expertise. During his works he works in a variety of projects ranging from Cloud Transformations to DevOps implementations.

He loves to share is knowledge which was also one of the reasons why he founded the Dutch Cloud Meetup. Maik is a public speaker, writes blogs and organizes events. Microsoft has recognized him as Microsoft Azure MVP.

Benefit	Description
Speed	New environments can be created in minutes instead of days.
Consistency	Every environment looks the same across teams and regions.
Reliability	Fewer human errors mean fewer outages.
Security	Security rules are built into the infrastructure itself.
Compliance	Every change is tracked and auditable.