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.