This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
Microsoft launched new tools (and updated existing ones) at Ignite and .NET Conf that can help to bridge the gap between the different breeds of nerds (dev & ops). There were of course good sessions for all of them, but I still thought I'd take a quick tour trying to tie it together.
Think of it as getting started with infra for devs if you will.
Azure Dev Box
This might be your new starting point with developer experiences. Virtual Desktop Infrastructure (VDI) solutions are not a new thing, and many developers have used profanity when forced to log on to a woefully underspecced remote desktop session to do their work. Dev Box has hardware you might actually want driving it and with good integration to the local desktop feels smoother than ever before. (You can do Teams calls with video and audio within Dev Box and it behaves like just another app you have installed.) Do you need this if you have a top-notch top-dollar laptop already? Well, that's not really the issue Dev Box is good at solving. If you're a single developer working on a single project you set things up the way you want it locally and you're done. What if you have a team of developers who needs to hit the ground running with pre-configured environments? What if you're a consultant working with different customers with different tools and very little acceptance of their stuff bleeding into other companies' solutions?
That's where Dev Boxes become more interesting.
As developers we like having a clean config - having an older version of something needed for one project conflicting with a newer version in a different project is no fun. For practical purposes it is however slightly impractical to have ten computers on your desk for different projects. Not to mention the cost. Having ten dev boxes is much more practical, and as you only pay a minor cost for storage when the box isn't running it can be cost efficient as well.
A Dev Box is a normal Windows installation and optionally the Office Suite and Visual Studio can be preloaded. Should you require it there's also the option to load a custom configuration upon creation, so if you have a suite of tools you want/need you can install those as part of the provisioning process. It is of course great if a team shares this config file instead of a long list of "how to get started" instructions on a Wiki.
Dev Box ties into an offering called Dev Center in Azure where you have different projects defined that the box attaches to. While it's entirely doable to configure this in the Azure Portal I have built out some Bicep code to simplify the process. A couple of resources are created:
- Virtual network
- DevCenter
- Network connection to a DevCenter subnet
- Environment Type
- Project
- Dev Box definitions and a pool
The repo can be found here:
https://github.com/ahelland/azure-dev-center
If you clone the repo and hop on over to the devCenter folder you can run the following command to provision a dev center:
This only creates the Dev Box templates and configuration so you need to create the actual instance afterwards by going to https://devportal.microsoft.com
Remember to assign permissions to yourself (and other developers first). For Dev Box you need DevCenter Dev Box User.
And then you can spin up a box:
Azure Deployment Environments
Ok, you've built a virtual computer or just fired up your laptop. And you have access to an Azure subscription. Now what? As developers we understand the value of infrastructure as code, but that doesn't mean we know everything about the infra bits. Ever been handed a wieldy ARM template with some unhelpful instructions on how to modify and deploy?
If an architect tells you that you should build containers and microservices you don't want to spend the next two weeks figuring out how to build a cluster. Nor do you want to wait for someone else to do it. You want a few clicks of a button. And that happens to be what you can use Azure Deployment Environments for. As part of the Dev Center you can have templates to choose from for creating new environments.
This might seem a bit convoluted, but you cannot deploy this directly as part of the Bicep code. You need to store the templates in a repo that you sync into your Dev Center. Well, you can deploy the link to that repo as part of the Dev Center provisioning, but for the purposes of this blog post it's better to do in the portal since that leaves you with choosing between Azure DevOps and GitHub as well as different auth mechanisms.
You should either acquire a PAT or configure a managed identity before adding the catalog of templates:
I have included two sample environments - a sandbox which is nothing but an empty resource group, and one that deploys an Azure Container Apps environment.
Same repo, https://github.com/ahelland/azure-dev-center, in the Environments folder.
Deployment Environments is a separate permission from Dev Box, so you should add Deployment Environments User to those that need it.
Right, so someone still has to write IaC? Yes, that part isn't removed. This takes care of the delivery to the teams. One of the tricky parts in platform engineering (everyone needs a platform these days) is how to deliver it. I have seen variations of cloning repos, versionless Terraform files, etc. that makes it hard to get going. Provided an effort is put into creating the template library this looks fairly nice.
Creating a container environment would be as easy as going back to the Dev Portal and choose to create a new environment:
The snetId that is asked for is related to the virtual network we created when provisioning the Dev Center so it would be in this format (where you just need to supply your subscription id if you went with the defaults):
/subscriptions/subscriptionId/resourceGroups/rg-devcenter/providers/Microsoft.Network/virtualNetworks/core-vnet-weu/subnets/cae
Here's another little gem with Dev Boxes. Have you ever struggled with the fact that services are locked to private endpoints and you have to jump through hoops to connect to them? (This is a common pattern enforced in the enterprise.) The Container App Environment subnet and the Dev Box subnet are part of the same virtual network so that's not an issue here. The container environment template also provisions a private DNS Zone and a "hello world" container app with a DNS record registered. You need to locate the app in the Azure Portal, but the url should just work, just for you, and not the whole of the internet.
No, I didn't fake this:
Azure Developer CLI
Getting pre-made infra templates in the hands of developers is nice, but there could still be some disconnects. Azure Developer CLI was launched at Build and it helped speed up the deploy & test cycle of developers. You can point it at your code, run "azd up" and have bits pushed into Azure. In effect this lets you bypass CI/CD pipelines for more rapid testing. Is this a good thing? Yes and no. Azd will also create pipelines for you if you like, and if you are a team you should of course push code to test environments properly. I am however not against a developer doing validations of their own code in a separate section of an Azure subscription first. Think through what works for you and implement a good inner vs outer loop.
With azd you could either write Bicep yourself or retrieve templates from "Awesome AZD" (https://azure.github.io/awesome-azd/). Which is great when you want to test out new patterns and the like, but not necessarily hitting the specifics of your team. So, there's a new feature I like in the latest release. You can retrieve templates from Azure Deployment Environments :)
Details here: https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/ade-integration
Just run azd config set platform.type devcenter and that's where azd will look for templates. (It will look across all dev centers you have access to.)
This opens up new use cases for Deployment Environments. Say you have something complicated you need for your solution like Kubernetes. The K8s pros provide a template for what the cluster should look like as well as an Azure Container Registry to go along. You just spin it up and add your specifics like actual containers.
Take note of the following restriction:
When platform.type is set to devcenter, all azd remote environment state and provisioning will leverage new dev center components. This configuration also means that the infra folder in your local templates will effectively be ignored. Instead, azd will use one of the infrastructure templates defined in your dev center catalog for resource provisioning.
This means that the Bicep still lives in the cloud, and an azd up will not let you do a full modification locally. But you can work around this in other ways.
.NET Aspire
The life of a developer is complicated in more than one way. Sure, it can require some work to deploy a bunch of microservices to Azure in the right way. But how about deploying and debugging locally? Turns out that can also be tricky. Microsoft came up with Project Tye a few years back as a way to tackle this. For various reasons it was abandoned, but the learnings from it was taken into a new concept called .NET Aspire that launched alongside .NET 8.
What it does is basically taking care of the tooling and orchestration required to run a number of microservices and gives you a nice dashboard to boot.
Read more about it here:
https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview
Aspire isn't a deployment tool and doesn't get into debates about whether Terraform or Bicep is more suitable or the right way to build a layered architecture in Azure. However, it does play nice with azd:
This opens up a rabbit hole I guess. Start in Visual Studio and build code, generate an Aspire config, check-in to a repo, sync into a Deployment Environment catalog, pull down with azd, provision with azd… You get the idea.
Rabbit holes can be entertaining, but can also have you feeling frustrated for obvious reasons. What if Aspire doesn't get it right? Or you have an environment with a cluster and you want to add a database?
I have opinions and thoughts on this. However, the intent of this post was really just getting started with Dev Centers. Let's see if we're able to revisit these questions in a subsequent blog post 