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