You know that feeling you've got like a pile of articles, maybe some research papers, notes scattered everywhere, all on a topic you really need to get your head around fast.
Yeah, it happens all the time.
Well, imagine just handing that stack over to some experts and like in minutes, getting the absolute essence those real aha moments, feeling genuinely clued in, big nice. That's exactly what we're doing in our deep dive today. We're plunging right into the latest on building powerful apps on Microsoft Azure.
Our source is the brand new Azure for Developers, third edition by Camille Murzagoud, just out from Packed Publishing, copyright twenty twenty five, off the presses totally and it's it's not just a book, right, It's packed with over a decade of real world experience. Focuses on secure, scalable apps using all the cool stuff Jenai, Serverla's DevOps pipelines. So our goal for you today a shortcut, basically a shortcut
to getting good at cloud development on Azure. Whether you're already a pro, looking to update your skills, or just starting out, will pull up a key stuff to get you up to speed. Thinking like a real Azure architect.
Yeah. And what's really cool about it, I think, is that this book sort of meets you where you are, but then it takes you deeper. You know, it's not just the what. It explains, the why gives you that bigger picture context that's frankly essential with how fast the cloud changes, helps you connect the dots.
Okay, so let's unpack this starting with the practical stuff, the foundations before you even think about code. The book really hammers home getting your.
Local setup right super important.
Like choosing between a free Azure account or pay as you go. It's not just about cost. It's about setting yourself up for easy learning versus like full on production.
Scale, different mindset's different needs.
Exactly, and picking that local environment carefully early on. That can save you so many headaches later with access problems and whatnot now tools or our tools. The book really pushes VS Code visual Studio code not just as an ide, but like a central hub for Azure stuff.
It's pretty central these days.
It mentions, it's almost unlimited integration options with Azure and plugins for tens of Azure services. Kind of makes it a no brainer for a lot of workflows. Sure, obviously a visual studio is still a big player.
Great integration too.
But then you've got the command line as your CLI, as your PowerShell, your go to's for scripting.
Automation essential, and.
The CLI even installs extensions automatically, which is pretty neat. Plus things like WSL the Window subsystem for Linux super helpful if you're mixing ocs. Need those Unix.
Tools right, keeps things consistent, and.
As your data studio for database work, So a whole toolkit that's.
A good rundown. But there's this other piece the book talks about for local dev emulators Azure emulators. They seem great, right, develop locally, no costly Azure services running.
Yeah, sounds idea.
You get isolated testing, no shared databases interfering. But the book pulls no punches, calls them error prone.
Ah okay, the catch.
Because they emulate, they don't perfectly replicate Azure. So thinking about someone experienced, where do developers maybe misuse these or like, rely on them too much? What's the book say about when you really need a proper cloud sandbox.
That's a really good point because it is a common trap. The book points out emulators are mostly for storage stuff like Azu're right right, something like the Cosmos dB emulator. Mainly Windows needs dock or elsewhere. So the real takeaway is they're great for that initial deb cycle, saving some cash, but they are not a replacement for testing in an environment that actually behaves like production. The best bet, the most reliable way. A dedicated cloud environment might cost more, sure,
but you get that fidelity exactly. It's that trade off budget versus needing that one hundred percent match to the real service. Okay, so local setup, sorted tools ready, next big question. The book gets into where do your apps actually live in Azure and that there's a whole spectrum from the you know, the old reliables to newer serverlest container options.
Yeah, lots of choices.
The classic the work course for web apps is as your app service. The book breaks it down neatly. The app service plan that's your compute power, and the web app that's your code and config simple enough, but people sometimes underestimate its power. You can easily scale up more CPU memory or scale out more instances, all.
At the plan level right flexibility.
And you can do that manually or set up automatic rules. It supports loads of runtimes, dot net Java no JS, plus it plugs right into CICD pipelines. It's actually pretty capable even for complex stuff. And then there's the rise of static web apps, much simpler, often cheaper. If you're building an SPA, a single page app that mostly runs in the browser, a.
Full app service might be overg totally.
You could use Azure storage static website for really basic things like a landing page, but the book really likes Azure static.
Web apps and managed service Yeah, purpose.
Built for these static first apps, usually paired with Azure functions for any back end bits. It handles authentication smoothly, integrates with on tri d at hub. Plus it has a really nice local CLI tool for dev with off mocks and stuff.
And if you connect that to the bigger picture, this shift from app service towards static web apps, it reflects that wider trend right optimizing hosting for specific architectures definitely. The book does a good job showing those trade offs back end integration versus cost and ease of use. Static web apps are fantastic when the front end does the heavy lifting and you just need a light back end. App service is still the versatile beast, but static web apps nail that specific growing niche.
Okay, now here's where it gets really interesting. I think diving into serverless where you just focus on code on events, not managing servers. It's a different way of thinking.
Big paradigm shift first up.
Azure functions the function as a service or phase platform. Yeah, lets you write code snippets triggered by events, and you mostly pay for when they run.
Simple model.
The book lays out the hosting plans really clearly. You've got the consumption plan paper use great for a predictable loads, but limitations like a ten minute max runtime, no vnet integration. Then the Premium plan more predictable performance. You get vnet integration, longer run times up to thirty months, but you pay for the allocated resources. Can't always scale right down.
To zero right, more guarantees, more cost potentially.
And there's this newer one in preview. Still, the flex consumption plan tries to blend the best of both supports. V nets has always ready instances, but with consumption style pricing and better scale limits one.
To watch interesting a hybrid approach, but.
The real magic of functions. The core idea is triggers and binding. Functions are event driven a trigger only one per function kicks it off an HTTP request, a message, and a queue, a timer whatever, starting pistol exactly. Then input bindings pull data in automatically from other services, and output bindings push results out. It handles so much of that integration plumbing for you.
Yeah, cutsound boilerplate.
Code super useful for quickipisackground jobs. Way better than web apps for those actually, or even just acting as a simple proxy. But okay, standard functions are stateless. They don't remember anything between runs. What if you need to manage complex process, something long running that needs state maybe over days.
Yeah, the stateless thing is limiting sometimes.
That's where durable functions come in. They're built on verager functions, but add state management you get orchestrator functions the brains managing the workflow saving state, and they coordinate activity functions the actual workhorses.
So it remembers where it got to precisely.
If the workflow crashes, you can restart it from the last checkpoint. No loss work, no rerunning completed steps enables cool patterns like asnc httpapi's user kicks off a long report check status latter.
Ah the fire and forget.
But check back pattern exactly, or human interaction workflows that pause maybe for weeks waiting for approval and the crazy thing on the consumption plan you don't pay while it's just sitting now.
Wow, okay, that's powerful.
Plus they have things like critical sections to avoid race conditions when talking to external systems and durable entities for modeling stateful business objects, really sophisticated stuff.
And then for.
Totally different approach, more visual, low code. There's Azure logic apps.
Right, the Dragon draw workflow builder.
Yeah, you build workflows with a visual designer or using JSON. Great for integrating different services, even things like SAP scales automatically, plus good error handling, retry policies for API calls, steps that only run if a previous one failed.
That kind of thing which brings up that common question, doesn't it? Durable functions versus logic apps, code first power versus low code speed?
Yeah, when do you pick which?
And the book stress is it's not about which is better, It's about fit. What's your team comfortable with? Code? Visual tools? How complex is the custom logic? How fast do you need to build it? Both are great for orchestration, just different ways to get there.
Right makes sense. Okay, let's switch gears, security, managing, secrets, configuration supercritical. Azure's got dedicated services here. First as your key vault, your digital vault.
In the cloud, the strong box.
Exactly store secrets, connection strings, passwords, API keys plus crypto keys, certificates, the book flags that old instrumentation keys are being deprecated. Use connection strings now. Good tip and for using it with app service, the best practice is key vault references combined with managed identities way more secure, easier to manage than passing around admin credentials.
Definitely avoids hard coding secrets.
You can also grab secrets directly in your code using SDKs, more flexible sometimes, especially if you deploy across different platforms. There's this handy default is your credential object that figures out credentials automatically, whether you're running locally or in Azure, smooth things out nice. Then there's Azure App Configuration, a separate service just for application settings and importantly feature flags.
Centralize can fix YEP.
It plays nicely with keyvol you can reference secrets stored there, and integrates with web apps functions aks, all the usual suspects. The killer feature I think is labels. Let's you have different sets of config values for dev tests, prad whatever. Using the same keys makes managing environments so much easier.
Yeah, that combo keyvolt for the actual secrets app configuration for the settings and flags. That's really powerful for modern apps. Centralizes everything. Helps with secure deployments, dynamic feature rollouts, big improvements. But as the book points out, you still need good access control discipline and don't make your labels too complicated or you create a different kind of mess for your op steam use the power wisely good point.
Okay, containers they're everywhere. I just got a whole ecosystem charting with Azure Container Registry ACR your private Docker hut. Basically, it's rivit image store, right simple to set up, manage images, use repositories and tags for versioning, has scope maps for granular permissions, plugs right into CICD pipelines, supports different off methods like federated identity for GitHub actions. The book even gets into performance stuff like artifact caching and multi arch images.
Important detail usual for efficient pipelines then for quick maybe one off container jobs. Azure Container Instances ACI. The book describes it as run a piece of code for a moment and then discard obsolete infrastructure.
Serverlest containers effectively.
Pretty much pay for use, isolated run time. Great for those bursty tasks batch jobs. You can set restart policies always never on failure, depending on the job, and you can control it all via SDKs, start stop containers, run commands, insides, stream logs.
Very flexible for automation, handy for specific use cases.
Now for the more serious micro services stuff, there's Azure Container Apps ACA. The book really leans into this as a modern and flexible platform for containerized apps, especially micro services.
Kind of like Kubernetes light but managed sort of.
Yeah, it DIDs a lot of the K eight's complexity but gives you similar benefits. It's great at handling multiple revisions versions of your app side by side. Uses something called a k TO scaler for smart event driven scaling like scale based on Q length not just CPU often way better for micro services.
That event driven scaling is key.
Yeah, it handles ingress storage mounts. It's really geared towards that microservice architecture. But you can also run containers and Azure App service which sounds confusing.
Maybe filled Yeah, when would you do that.
It's a good option if you've already got stuff inn app service and want to containerize it without a huge re architecture. App service even supports multi container apps with doctor composed, so you can do sidecar patterns like a separate container for logging or monitoring alongside your main app, all within that familiar app service model.
Uh okay, So that distinction the book makes is important. ACA is really designed for micro services, greenfield event driven scaling. APP Service for containers is more like bring containers to the existing app service.
World exactly a pathway for containerizing existing workloads.
Perhaps right. Choosing between them really shapes your architecture and what you have to manage. Getting that right early is key for scaling and cost.
Definitely okay. Data can have an app without data. Azure's got tons of options. The book walks through the choices really well. Take Azure storage the Swiss Army knife, right, there's a bit of everything for no seqel. You've got table storage good when you don't need complex joints. Schema might change and you know how you'll partition it indexes on partition key and ro key, So design matters a
lot for performance and cost. Interestingly, the book says data duplication is actually one of the viable patterns here to optimize reads.
Yeah, denormalization basically common in no SQL.
Then blob storage for just dot files objects. Key things here are the access tiers hot cool, cold archive to save money based on how often you access stuff. Archive is super cheap. It takes hours to rehydrate data. Got a plan for the latency and blob types. Block append page choose based on usage block for general files, a pen for logs, page for virtual discs, and crucially you pick the type when you create it.
Can't change it later important constraint.
And for reacting to changes you can use the change feed or event grid. Events different ways to get notified now. Queues essential for decoupling services, handling load spikes, making sure messages don't get lost. But which queue service? The book clarifies the landscape.
Yeah, there are a few options.
Queue storage the basic one part of Azure storage simple message passing.
The entry level cube.
How's your event hubs? Are you built for massive ingestion? Think IoT data streams millions of events. Kofka compatible has schema registry, auto scales. It's about volume high throughput and Azure Service Bus. This is for enterprise grade queues when you need guarantees. It has advanced filters sekl Booleon correlation that look at message properties, sessions for guaranteed first in, first out ordering, built in duplicate detection.
It's the heavy duty option, so reliability in features overraw throughput.
Sometimes exactly knowing when you need those enterprise features is the key. Insight and relational databases, Azure manages the popular ones Azure SQL, postgrescool Myseql, though Maria dB is being retired. The book notes for Azure SQL you've got choices SQL on VMS, Managed Instance pay or Azure sql Database dBase. The book suggests Azure SQLDB is often the go to for new apps because it's fully managed. Let's admin overhead right scaling up or down causes a brief connection blip,
something to be aware of. Backups are automated or on demand. Need to think about replication LRSCRS for nonprod grs, r AGRs for production resilience and your Recovery Point Objective RPO.
Standard database considerations and.
Security databases are private by default. You need firewall rules, IP whitelists or ideally use Azure private endpoints for access only within your virtual network.
Private endpoints are generally the way to go, now, you know, going through all these data options, it really hits home that principle. There's rarely just one right way to store data in Azure.
So many choices.
It's all about picking the right tool for your specific job, understanding those trade offs chem of flexibility, indexing, access patterns, cost reliability, features like choosing service bus over event hubs. It's not just features, it's about whether you need strict ordering and transactions versus just handling huge volume. The book really helps make those informed decisions.
Yeah. Absolutely, Okay, nearly there. Let's talk visibility and intelligence, keeping apps healthy, making them smart. Azure Application Insights is your main health monitor essential service, and the book makes a crucial distinction. Logs don't provide any specific value as opposed to metrics. Logs tell you why a metric is what it is. Metrics tell you what's happening, good way
to put it. App insights streamlines all this again that change instrumentation keys are out, use connection strings with newer SDKs key features. Dependency monitoring automatically tracks calls to databases. External APIs various sampling methods to control costs, rich data types, metrics, dependencies, page views, traces.
Requests, lots of data points.
And you query it all with Custo query language KQL, super powerful for digging into behavior. Cost control features like daily caps and sampling are vital, Otherwise telemetry costs can sneak up on you.
Yeah, monitoring is definitely not an afterthought. It's core and app INSIGHT's ability to autotract dependencies and give you that fine grained control over sampling. That's huge. You get deep visibility without drowning in data or managing logging infrastructure yourself. It really shifts you from being reactive to proactive.
Massive win agreed. And finally, the really exciting stuff, generative AI with Azure Open Ai service the hot topic. This service gives you managed access to those powerful open AI models gpt DL, whisper embeddings, but hosted with an Azure so you get Azure sexcurity, private networking content filtering, all that good stuff. Abstracting away the infrastructure pain makes it enterprise ready. Key concept tokens basically chunks of textra code,
billing model limits. It's all based on tokens, you need to understand them. There are SDKs for different languages to talk to. The APIs chat completions API for building chatbots uses system user assistant messages, but you gotta handle storing the conversation history yourself.
Right, it's stateless by default.
There's a newer response API that can stream long answers back better UX speech to text using models like Whisper image generation with Deli creating images from text prompts, often saving results to Blob storage.
Cool use cases and embeddings.
This is interesting. Turns data, text, audio, whatever into vectors. These mathematical representations lets you calculate cosigine similarity basically how related things are, and you can use this with specialized vector databases for similarity searches.
Opens up semantic search recommendations lots of possible abilities.
And if just prompting better or using ag retrival augmented generation isn't quite cutting it for your specific needs, you can fine tune the models with your own data, usually in Jason format, to make them better at very specific tasks.
Yeah, fine tuning is the next level of customization. This Azure Open AI service really makes integrating powerful AI accessible. It lets you build much richer apps, automate complex stuff, find hidden patterns. It's genuinely a game changer for cloud applications right now. But like the book mentions, you really need to nail your prompt engineering and keep an eye on those token limits for performance and cost.
Definitely Wow. Okay, what a tour. We went from setting up your local machine, figuring out hosting for web apps and static sites, designing server lists, workflows, locking down secrets.
Powered a lot of ground.
Then into the huge world of data storage, queues, databases, and finally monitoring and adding that AI magic with Azure Open Ai. This Azure for Developers third edition really is hacked. We've only scratched the surface here.
It's a comprehensive guide for sure.
So the final thought for you listening, what does all this mean? We've seen Azure is constantly changing right more and more specialized services, sometimes they even.
Overlap a bit, always evolving, which.
Gives you incredible power, But also it's a challenge. How do you as a developer keep navigating this? How do you consistently pick not just a solution, but the best solution for what you need right now? Especially knowing that today's shiny new thing might be legacy tomorrow. It's just a continuous deep dive, isn't it, Always learning, always evaluating,