New command line tools for  Static Web Apps come your way.   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. Hi, I'm Erik Gross, welcoming  you to another episode of Azure This Week.   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 from multiple deployment  environments, Microsoft is all in on Static Web   Apps. Having created a few of them myself, I  understand the appeal. From portfolio sites,  

to a gorgeous React front end for your  API, 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 to 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 same skills to  bear in working on your Static Web Apps.   Azure Containerized Apps are 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, develop, and deployment  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 outta luck unless you took special steps,   like putting them behind the gateway.  But that's just changed as Azure has   just 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.   Every month, A Cloud Guru has a number of  totally free courses which change over time.   This month is Azure month. So we have a bunch  of Azure courses free for you, including   Introduction to Governance and Compliance  on Azure, Azure Active Directory Deep Dive,   Introduction to Azure Resource Manager, Intro to  Serverless on Azure, and Azure Storage Deep Dive.  

A free account is genuinely free as well. No  credit card needed, just content delivered.   Let's wrap this week's episode up with some  thoughts about putting your development machine   out in the cloud. When Microsoft announced a  release of Dev Box at Build a few weeks ago,   it got me thinking, why should we care about  this? I don't mean that in a negative way. I'm   actually curious, and I wanted to ask you  about it as well. The idea of working in   a cloud-hosted development box is not a new  one at all, but until recently you had to jump   through a few hoops to get a decent setup. 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.  We make the sausage. The main opposition to   using a cloud-based dev machine usually comes  down to the perceived loss of control.   We've 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 set-up on your  local box can be really challenging. I've tried,   and it's not a lot of fun. Second, if you're  working on several different project types at   once, and they each have significantly different  dependencies and development tool chains,   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. Those are some of my thoughts, but I'm really  

interested in yours. Have you tried working  on a cloud-based dev machine? How did it go?   If you are enjoying it, what's your setup look  like and how do you use it? Let me know in the   comments. Thinking about shifting your Static Web  App work to the command line? Got a custom domain   you want to use in your Azure Container App? Jump  on our Discord channel and let us know. You can   also interact with other students and ACG people,  and get help for your cloud journey. You'll find   a link below in the description. See you next  week and keep being awesome Cloud Gurus.