Introduction
Howdy, fellow dev chads!
So by now, you've probably heard of Forrest Brazeal's Cloud Resume Challenge. If you haven't, you can read all about it here.
Unlike typical dev tutorials, the coolest thing about the challenge is the setup. Forrest breaks down the project into digestible parts, explains its relevance, and offers a broad expectation of what it should look like. Alongside some documentation to start, you basically get told to go build it yourself. And that is where the real learning happens!
Note: Rather than a traditional blog post detailing what I did and how I did it, consider this as simply highlights of the learnings I think are important.
GUI First, CLI Second
Okay, so if you've never deployed a cloud resource in your life, heading straight into the Azure CLI might be biting off more than you can chew.
It's important to first have a strong mental model of the resources you're building and how they rely on and connect with each other. Practicing setting up resources via the online Portal will strengthen that mental model.
You'll know you're ready for the CLI when it becomes annoying to click through the same things over and over again.
Quick solutions aren't always the best
So, I got to a point where I had all my resources set up and properly configured. Now, the next step was to automate it.
I had a couple of options but wanted to explore ARM and Bicep templates. After digging around, it was kind of straightforward but a little intimidating. Luckily for me, I found a neat 'Export template' button that apparently analyzed and generated an ARM template of my resource group for me! Perfect. Right?
Well sadly, when I went to deploy that template, I got hit with multiple errors. They were vague and hard to debug. On top of that, the ARM template was verbose and just hard to read.
I spent a couple of hours trial-and-erroring with no luck. So, it was back to the drawing board. I figured I may as well start with Bicep (I had enough of ARM at this point). And let me tell you, Bicep is kind of great.
Why Is Bicep So Great?
- Linting Support: Debugging is so much easier when something is screaming at you to fix it.
- VS Code Extensions: Enabled visualization of the resource map.
- Conciseness: Easier to write and understand.
- Documentation: Abundant quick starts and templates for different architectures.
And the best part? Deploying the new Bicep templates I started from scratch worked. No need to rely on any 'Export templates' here.
Save your precious time by validating
Using CLI to validate templates
So building these templates is great and all, but you really need to be able to validate them without running the GitHub action pipeline every time. Depending on how you set it up, each pipeline run can take 3+ minutes to complete. Imagine all that extra overhead!
Introducing the Azure CLI validate command:
# Validate Bicep file
az deployment group validate --template-file ./main.bicep
It'll basically return any errors the template outputs.
You can read more about it here.
There's probably some better tools to help with this, but this is what I found so far. If anyone knows anything, let me know.
Heck, I'm still learning about GitHub Actions, and those were a pain to validate as well.
Conclusion
The journey from manually setting up resources in the Azure portal to doing so programmatically with Bicep enabled me to understand the intricacies of cloud services. While the 'export template' button seemed convenient, it was prone to errors and complexity. Building the Bicep template from scratch with the aid of well-structured documentation and supportive tools provided a more robust, debuggable, and clear solution. This process not only saved time but also instilled confidence in using Bicep for defining and deploying resources, making it a recommended approach for both front-end and back-end development.
With that said, these are really the first steps on my cloud journey. There's heaps more to learn, and as I get better, I'm sure this project will need a refactor.
For now, that's all, folks.
Top comments (0)