Azure Static Web Apps CLI

This week in Azure news we have new command line tools for Static Web Apps; Azure Container Apps can now have custom domains, and the release of Microsoft Dev Box has us wondering, “should I even care about developer workstations in the cloud?” While we’re busy absorbing everything Microsoft released at Build, the Azure world is still moving forward. So let’s jump right in!

Your keys to a better career

Get started with ACG today to transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.

It’s only been a month or so since we shared news about new Azure features for Static Web Apps - from custom URLs to support for multiple deployment environments, Microsoft is all in on Static Web Apps. Having created a few of them myself, I understand the appeal — from a portfolio site to a gorgeous React front end for your APIs, the possibilities are pretty varied.

Azure has just released one more tool for devs who do a lot of work in this area: a command line interface for Azure Static Web Apps. Using the CLI, you can authenticate with Azure, initialize your project, build and deploy, even preview and debug your app— all from the command line. If you’re like me, you’re probably doing more and more of your work in a CLI — and now you can bring those skills to bear in working on your Static Web Apps. 

Azure Containerized Apps is a great offering from Microsoft. You can deploy microservices and containers without having to pay a lot of attention to orchestration and infrastructure. And Microsoft has certainly provided a lot of support for the offering — from tutorials to support for both CLI and Azure Portal control and even built-in node health metrics. They aim to provide a complete design, development, and employment solution for simplified containerized application systems. 

Until now, though, your containerized apps were given an auto-generated URL. If you wanted custom domains for those containers, you were out of luck unless you took special steps — like putting them behind a gateway. But that just changed, as Azure has announced support for custom domains and TLS certs in Azure Container Apps. The process is pretty simple and straightforward, which is great; no one wants to spend a bunch of time on TLS certs and DNS configuration unless you're a glutton for punishment.

Let's wrap up this week's post with some thoughts about putting your development machine out in the cloud. When Microsoft announced the release of Dev Box at Build a few weeks ago, it got me thinking, "why should I care about this?" I don't mean that in a negative way — I'm actually curious.

The idea of working in a cloud-hosted development box isn't new, but until recently, you had to jump through a few hoops to get a decent set up. The fact that Microsoft put all this work into their Dev Box offering, though, tells me they see a real future there. 

Once I got over how "cool" it sounded, I decided to take a closer look. I was curious — why would a dev really want to do this? Is it for everyone? Does it lend itself to certain types of dev work? 

What I found is that there aren't any clear-cut answers here. The pros and cons of "DaaS" or "Desktop as a Service" have been talked about a lot, but rarely with a focus on the developer experience. Let's face it; we don't use computers the way most other people in our companies use them. They aren't a general-purpose productivity tool; they are a specialized environment where we can craft executables destined for deployment as productivity tools.

The main opposition to using a cloud-based dev machine usually comes down to the perceived loss of control. We have spent so long controlling our local machines that we won't easily give up the ability to view and customize our development machines on a deep level. 

The two strongest arguments that I see in favor of doing your dev work on a cloud machine are these: 

• First: If you're building distributed, microservices applications, it can be much easier to replicate a real-world system for development and testing. Getting that kind of setup on your local box can really be challenging. I've tried, and it's not a lot of fun. 
• Second: If you are working on several different project types at once, and they each have significantly different dependencies and development toolchains, it is much easier to just keep multiple dev machines in the cloud, each with the setup you need. This means you won't have to manage multiple runtime versions and dependency chains on your local box. 

Want to learn more about Azure certifications?
Check out our Azure Certifications and Learning Paths.

Well that’s all for this week! Want to keep up with all things cloud? Follow ACG on Twitter and Facebook. You can also subscribe to A Cloud Guru on YouTube for weekly Azure updates, and join the conversation on Discord.

Looking to learn more about cloud and Azure, or begin your cloud career in 2022? Check out our rotating line-up of free courses, which are updated every month. (There’s no credit card required!)