Speaker 1: Welcome to the deep dive, where we cut through the
Speaker 1: noise to get you well informed on the topics that
Speaker 1: truly matter. Today. We're navigating the dynamic world of modern
Speaker 1: application development. It's a place where speed, scalability, resilience, they're
Speaker 1: all non negotiable, right, but the complexity, well, it can
Speaker 1: often feel like a massive tangled knot. We're taking a
Speaker 1: deep dive into an incredibly practical guide exploring Azure Container Apps,
Speaker 1: scaling modern and cloud native apps and micro services Marching cash.
Speaker 1: This book by Naga Santos, Ready, Vutakori, Kaser Judae and
Speaker 1: Whale Kodu is really our roadmap today. We're looking at
Speaker 1: how Azure Container Apps, which is powered by something called DAP,
Speaker 1: simplifies building really robust applications in the cloud. Our mission
Speaker 1: today is to unpack how you can get the huge
Speaker 1: benefits of container orchestration thank Kubernetes without needing to become
Speaker 1: an infrastructure guru. We'll explore the core of Azure Container
Speaker 1: apps first, and then we'll reveal how DApp or supercharges
Speaker 1: your ability to create resilient, scalable micro services. It makes
Speaker 1: really complex tasks surprisingly straightforward. We're here to unravel these complexities,
Speaker 1: show you how cloud native can be more accessible than
Speaker 1: you might think, maybe sparking some fresh insights for you. Okay,
Speaker 1: let's unpack this. What exactly is Azure Container Apps ATA
Speaker 1: and why should someone building modern apps really pay attention?
Speaker 1: It sounds like it's a significant shift.
Speaker 2: It absolutely is that. Think of it this way. ACA
Speaker 2: gives you all the robust, sort of self healing power
Speaker 2: of Kubernetes, but without the headache, without managing the underlying
Speaker 2: infrastructure or wrestling with complex yamal files all day. The
Speaker 2: real insight, I think, is it, let's developer ship code faster.
Speaker 2: They focus purely on their business logic, not the cloud
Speaker 2: plumbing underneath. It provides a fully managed, serverless Kubernetes based
Speaker 2: container run time that well, it just works.
Speaker 1: So it's essentially Kubernetes leat for developers. Then that sounds
Speaker 1: incredibly appealing, almost maybe too good to be true for
Speaker 1: anyone who's wrestled with kamil. Are there trayoffs though, or
Speaker 1: specific scenarios where you'd still need the full power of
Speaker 1: as your kubernaty service akas.
Speaker 2: That's a great question, and it really gets to the
Speaker 2: heart of ACA's value. It fully embraces that serverlest paradigm,
Speaker 2: meaning you don't manage the underlying servers at all. The
Speaker 2: platform dynamically gives you resources based on your apps load.
Speaker 2: It scales automatically, even down to zero instances when it's idle,
Speaker 2: then scales up for traffic.
Speaker 1: Spikes, right scaling to zero.
Speaker 2: Yeah, which ensures efficient resource use and cost optimization. It
Speaker 2: aligns perfectly with that pay as you go model. You
Speaker 2: only pay for what your application actually uses and the
Speaker 2: trade off you mentioned. That's exactly why workload profiles exist.
Speaker 1: Okay, that dynamic scaling from zero sounds like a game
Speaker 1: changer for cost, But what if you have a really specific,
Speaker 1: demanding workload. Does ACA still give you that flexibility?
Speaker 2: It does, yeah, through its workload profiles. The default the
Speaker 2: consumption profile is like you said, perfect for those variable workloads.
Speaker 2: Scales on demand goes to zero when idle. But for
Speaker 2: specialized workloads things needing consistent performance or maybe separation, there's
Speaker 2: the DEBT de CATD profile. This offers specific hardware resources,
Speaker 2: general purpose memory focused, even GPU powered instances. Sometimes you
Speaker 2: can define your min and max instances tweak the scaling
Speaker 2: behavior to match exactly what you need. This moves way
Speaker 2: beyond traditional infrastructure as a service where you'd be managing
Speaker 2: VMS and operating systems yourself. ACA handles all that set
Speaker 2: up in scaling automatically. It really does abstract away that
Speaker 2: operational burden.
Speaker 1: That's a huge shift, and it sounds like it's inherently
Speaker 1: suited for micro services. Is that one of his main
Speaker 1: use cases?
Speaker 2: Absolutely, it's perfect for micro services architectures because containers, while
Speaker 2: they're the ideal way to package and deploy these independent services,
Speaker 2: aren't they the insurer services are isolated, portable, consistent across
Speaker 2: different environments. ACA just makes managing a whole bunch of
Speaker 2: microservices significantly easier. And beyond that core functionality, ACA is
Speaker 2: built in monitoring and logging through Azure Monitor, seamless CICD integration. Plus,
Speaker 2: it's built on great open source tech like Dapra, which
Speaker 2: we'll talk more out, Keta for scaling, and Envoy for networking.
Speaker 2: That open source foundation means transparency and flexibility, which honestly
Speaker 2: is a huge win for developers.
Speaker 1: That's a pretty comprehensive feature set. Now for those of
Speaker 1: us trying to place ACA in the let's say the
Speaker 1: wider Azure World. How does it stack up against Azure
Speaker 1: App Services or even AKS right.
Speaker 2: That's a crucial distinction to make, as your app services
Speaker 2: is more of a pitess platform as a service, it
Speaker 2: hides a lot of the infrastructure, gives you a managed runtime. ACA,
Speaker 2: on the other hand, is distinctly container centric. It offers
Speaker 2: more granular control over the container environment itself, and you
Speaker 2: get more precise scaling tightly integrated with those container orchestration capabilities.
Speaker 2: It's really about flexibility for containerized apps now. Comparing to
Speaker 2: azur Kupernetes service, AKAS AKS provides really deep, fine grain
Speaker 2: control over Kupernetes itself, but that requires significant expertise to
Speaker 2: manage and operate effectively. ACA, even though it's built on Kupernetes,
Speaker 2: it abstracts away those complexities. It offers a much more
Speaker 2: dreamline developer experience. So it's a choice really deep control
Speaker 2: with AKAS or simplified faster development with ACA, where you
Speaker 2: get the KS benefits without needing to master every single
Speaker 2: operational detail. Got it.
Speaker 1: Now, let's start to a practical application. The book uses
Speaker 1: a really clear hands on example an expense management solution
Speaker 1: using micro services. Can you give us a snapshot of
Speaker 1: what that application looks like and how its core parts
Speaker 1: get deployed initially.
Speaker 2: Sure thing. The Benefits Manager application in the book is
Speaker 2: a great real world demo of ACA, Dopra, and Keto
Speaker 2: working together. It lets external users, say employees submit expenses
Speaker 2: and internal users administrators they review them. The core micro
Speaker 2: services involved are things like an ACA web app frontend
Speaker 2: that's a Blazer server app for managing the expenses. Then
Speaker 2: an ACA Web API BFF you know, back end for
Speaker 2: frontend it's a minimal sp dot Net API holding the
Speaker 2: business logic specifically for that front end. There's an ACA
Speaker 2: processor back end that's an event driven background thing for
Speaker 2: tasks like sending emails, an ACA mail search service hosting
Speaker 2: an open source search engine, and then a couple of
Speaker 2: ACA jobs, an indexer service and a scheduled service maybe
Speaker 2: for nightly reports.
Speaker 1: Wow. Okay, that's quite a collection of services. Definitely highlights
Speaker 1: a modern distributed approach. So how do they go from
Speaker 1: code on a dev machine to actually running in Azure
Speaker 1: container apps?
Speaker 2: Right? So, the initial deployment, which the book covers in
Speaker 2: chapters two and three, starts pretty standardly. Create the back
Speaker 2: end API, create the Blazer front end. But the process
Speaker 2: shows key steps. First containerization packaging both the API and
Speaker 2: the Blazer app into Docker containers standard stuff. Then using
Speaker 2: Azure Container Registry ACR. It's a managed Azure service to
Speaker 2: store and manage those container images. It handles off integrates
Speaker 2: with CICD pipelines. Finally deploying to ACA itself. This involves
Speaker 2: creating some Azure infrastructure first, like a log analytics workspace
Speaker 2: for logging, application insights for tracing. Then the container apps
Speaker 2: are deployed into an ACA environment, so.
Speaker 1: A full life cycle from dev to deployed and monitored.
Speaker 1: Did the book offer any practical security tips during this
Speaker 1: initial setup.
Speaker 2: Yes, it did. A really crucial security insight comes right
Speaker 2: after deploying the front end. The book shows updating the
Speaker 2: back end web API's ingress setting from external to internal.
Speaker 1: Oh okay, what does that do?
Speaker 2: It means the back end API becomes accessible only by
Speaker 2: other applications running within the same Azure container environment. This
Speaker 2: massively enhances security by blocking direct public Internet access to
Speaker 2: your back end services. It shows how you tailor can
Speaker 2: figs for real world security, not just theory.
Speaker 1: Right. Locking down access between services makes sense?
Speaker 2: Right?
Speaker 1: So okay, we've got our micro services running an ACA.
Speaker 1: But distributed systems, like you mentioned, they have their own challenges,
Speaker 1: right state management, finding other services, secure communication. This is
Speaker 1: where depro comes in. I gather and it seems like
Speaker 1: depth really simplifies all of this.
Speaker 2: That's exactly right. DAP the Distributed Application run Time. It's
Speaker 2: open source, portable, event driven designed specifically to make building, resilience,
Speaker 2: scalable micro services easier. It was originally launched by Microsoft,
Speaker 2: but now it's a graduated project in the CNCF, the
Speaker 2: Cloud Nedive Computing Foundation, so it's got broad industry backing.
Speaker 2: Dapper's whole purpose is basically debstract away those common tricky
Speaker 2: parts of distributed systems. Let's developers focus purely on their
Speaker 2: application code.
Speaker 1: A distributed Application run time sounds powerful, Yeah, but how
Speaker 1: does it actually integrate with my application? Does it add
Speaker 1: a ton of new code or dependencies right into my
Speaker 1: core logic?
Speaker 2: No, and that's the beauty of it. It uses what's
Speaker 2: called the sidecar approach. DAPPER runs alongside your application as
Speaker 2: a separate process. A sidecar doesn't matter if you're running
Speaker 2: locally or in the cloud like ACA. Your application just
Speaker 2: talks to its local Dapper sidecar, usually over standard HGTP
Speaker 2: or gRPC calls, and that sidecar then handles the complexities
Speaker 2: talking to state stores, message brokers, other services.
Speaker 1: Okay, so the app talks to Dapper, Dapper talks.
Speaker 2: To the world pretty much. You know. Before Dapper trying
Speaker 2: to implement, say state management or service discovery car micro services,
Speaker 2: it often felt like building a custom bridge for every
Speaker 2: single river crossing, super time consuming, error prone. Dapper basically
Speaker 2: gives you a standardized, configurable bridge kit for all those rivers.
Speaker 2: It abstracts away the plumbing, lets you focus on your
Speaker 2: actual business logic, and when your application scales, the Dapper
Speaker 2: sidecar scales right alongside it.
Speaker 1: That's a really clever way to keep the application code
Speaker 1: itself clean. So what are some of these complexities that
Speaker 1: Dapper handles Through these building blocks you.
Speaker 2: Mentioned right, the DAP prab building blocks. They encapsulate best
Speaker 2: practices for common patterns. There's service to service invocation for
Speaker 2: secure communication between your micro services, state management for reliable
Speaker 2: ways to save and retrieve, state publish and subscribe or
Speaker 2: pub sub for asynchronous messaging bindings which we'll get to
Speaker 2: for connecting to external systems, and even things like workflows
Speaker 2: and jobs for orchestration and scheduling. When you integrate DAPER
Speaker 2: into ACA, you automatically get features like automatic retries on
Speaker 2: service calls, secure communit cation using MUTUALTLS, access control policies,
Speaker 2: plus comprehensive traces and metrics for diagnostics, all flowing into
Speaker 2: tools like Application Insights. It injects these useful cross cutting
Speaker 2: behaviors transparently.
Speaker 1: Wow, that's a lot of crucial functionality just handle. Can
Speaker 1: you give us a concrete example, like, how does that
Speaker 1: state management building block really make a difference in practice?
Speaker 2: Yeah? The book illustrates this really well with DAP state management. Initially,
Speaker 2: the example claims manager back ends stores its data locally
Speaker 2: using REDTIS that's configured via a simple YAML file telling
Speaker 2: Dapper use reddus for state. But here's where it gets
Speaker 2: really powerful. Without changing any of the application code that
Speaker 2: saves or loads data, no code changes it all none,
Speaker 2: zero code changes it. Then seamlessly switches to using azure
Speaker 2: Cosmos dB as the state store instead. This shows dapper's
Speaker 2: plugable component model in action, same application code, different underlying
Speaker 2: state store. Dapper abstracts away the implementation details. Your code
Speaker 2: just uses the Dapper client SDK to call something like
Speaker 2: save state acinc or get state entry async. Dapper figures
Speaker 2: out where to save it based on the configuration.
Speaker 1: That's huge for flexibility and avoiding vendor lock in. And
Speaker 1: how does dapprehandle security for those state stores, especially in Azure?
Speaker 1: Is it managing connection strings?
Speaker 2: Good question for cloud deployments Like with Cosmos dB, Dapper
Speaker 2: leverages Azure managed identities. This completely eliminates the need to
Speaker 2: store or manage sensitive connection strengths directly in your application
Speaker 2: code or configuration.
Speaker 1: AH managed identities good Exactly.
Speaker 2: You assign a system managed identity to your container app
Speaker 2: in ACA, then you grant that identity a role like
Speaker 2: Cosmos dB built in data contributor on your Cosmos dB instance.
Speaker 2: Dapper uses that identity automatically to authenticate securely. It's a
Speaker 2: crucial security best practice. Simplifies credential management immensely.
Speaker 1: Okay, so that's state. What about building loosely coupled systems?
Speaker 1: The book also dives into Dapper's pub sub pattern for
Speaker 1: acin communication. Why is that so important for micro services
Speaker 1: and how does Dapper help.
Speaker 2: Yeah, loose coupling is absolutely vital for resilient micro services.
Speaker 2: It means your services don't need direct knowledge of each other.
Speaker 2: They don't need to know implementation details or even if
Speaker 2: a consumer service is available writ when a message is sent,
Speaker 2: the dapperpub sub building block abstracts away the complexities of
Speaker 2: the underlying message broker, whether it's reddis rabit, MQ as
Speaker 2: your service bus. It provides a single consistent API for sending, publishing,
Speaker 2: and receiving subscribing to messages. Publishers just send messages to
Speaker 2: a name topic. Any interested subscribers receive them without the
Speaker 2: publisher knowing who or how many subscribers there are. This
Speaker 2: drastically improves resilience and scalability.
Speaker 1: That makes a lot of sense for event riven designs.
Speaker 1: How does the example application, the Benefits Manager, use this right?
Speaker 2: This is where the app introduces that new background service,
Speaker 2: the ACA processor back end. Its only job is to
Speaker 2: process messages received from a queue, for instance, sending emails
Speaker 2: when an expense claim status changes. This offloads that task
Speaker 2: from the main APS service, keeping the API focused just
Speaker 2: on managing claims data improves responsiveness, keeps things separate. The
Speaker 2: book first shows this locally using RDDUS again, but this
Speaker 2: time as the message brooker configured with a pubsub dot
Speaker 2: YAML file. The API publishes messages to a topic maybe
Speaker 2: claim save topic, and the back end processor consumes messages.
Speaker 1: From that topic. And I assume when you move to
Speaker 1: the cloud, Dapper simplifies that transition too, like it did for.
Speaker 2: State, exactly the same principle for cloud readiness. The implementation
Speaker 2: then shifts easily to Azure service Bus. You provision a
Speaker 2: service bus name, space and a topic in Azure, then
Speaker 2: you just update the Dapper component configuration YAML to point
Speaker 2: to Azure service Bus instead of reddis and crucially in
Speaker 2: Azure Container apps, authentication with service bus also switches to
Speaker 2: using managed identities, just like we saw with Cosmos dB,
Speaker 2: no connection strings needed.
Speaker 1: That consistency and configuration and security across different services is
Speaker 1: really appealing. Can you walk us through how a publisher
Speaker 1: and subscriber actually work with Dapper pub sub in this scenario?
Speaker 1: The mechanics of it.
Speaker 2: Sure On the publisher side. Let's say the claims manager
Speaker 2: back end API needs to publish an event. It uses
Speaker 2: the DAP ray client SDK's publish event ACNC method. It
Speaker 2: sends the data. Maybe the claim model specifies the pub
Speaker 2: subcomponent name like dapro pub sub services and the topic
Speaker 2: name claim saved Topic. Dapray handles getting it to the broker.
Speaker 2: On the subscriber side. The ACA processor back end service
Speaker 2: uses a simple attribute like topic. Dapropub subservice claims save
Speaker 2: topic on one of its API endpoints, say Apple claims
Speaker 2: notifier claim saved. When the service starts up, the DAPPER
Speaker 2: sidecar actually calls a well known endpoint dap subscribe on
Speaker 2: the application to discover these subscriptions. DAPRA then automatically tells
Speaker 2: the message broker service bus in this case, to create
Speaker 2: the necessary subscription to route messages from that topic to
Speaker 2: this service. So when a message hits the topic, Dapper
Speaker 2: receives it from the broker and calls the designated endpoint
Speaker 2: on your service with the message payload. There's middleware involved too,
Speaker 2: like app dot use cloud events to unwrap the event
Speaker 2: data into a standard format, and app dot mamp subscribe
Speaker 2: handler to make the subscription endpoint discoverable by Depper, But
Speaker 2: mostly Dopper handles the routing and delivery behind the scenes.
Speaker 1: Okay, that clarifies the pubsub mechanism. Now, building on that,
Speaker 1: the book introduces Depper bindings. If pubsub is mainly for
Speaker 1: communication between our own micro services, what makes bindings different?
Speaker 1: How do they help us connect with systems outside our application?
Speaker 2: Bauttery Exactly. That's the crucial difference. Pubsub is primarily for
Speaker 2: internal asynchronous service to service communication within your distributed application.
Speaker 2: Depper bindings, however, are specifically designed for connectivity and interoperability
Speaker 2: with diverse external systems or services. Think of them as
Speaker 2: universal adapters or connectors. They let your application interact with
Speaker 2: things like databases, message queues, cloud services like Tulio, or
Speaker 2: sendrid file systems even on prem systems, all without needing
Speaker 2: to write specific integration code or include SDKs for each
Speaker 2: external system directly in your service.
Speaker 1: So bindings are outward facing connectors. What's a practical use
Speaker 1: case the book uses to illustrate this.
Speaker 2: The book presents a really good scenario. Imagine there's some
Speaker 2: external system totally separate from your application and it owns
Speaker 2: an Azure storage queue. Your ACA processor back end needs
Speaker 2: to react whenever a message lands in that external queue.
Speaker 2: It uses a dapper input binding to trigger an event
Speaker 2: in your service. Then, after processing the message, your service
Speaker 2: might need to store the result in an Azure blob
Speaker 2: storage container that also belongs to that external system. It
Speaker 2: uses a Dapper output binding to do that. It really
Speaker 2: demonstrates integrating seamlessly with resources that aren't part of your
Speaker 2: core applications infrastructure.
Speaker 1: Okay, interesting, Can you elaborate a bit on how those
Speaker 1: input and output bindings actually function in that scenario without
Speaker 1: getting lost in code specifics.
Speaker 2: Absolutely, for the input binding to receive events from that
Speaker 2: external queue, our ACA processor back end just needs to
Speaker 2: register a public API endpoint maybe external claims process or process.
Speaker 2: Then a simple depth binding configuringtion file. Another yemol tells
Speaker 2: Dapper how to connect to that external Azure storage Q
Speaker 2: stored account name, qname, maybe credentials if not using managed
Speaker 2: identity for storage. Yet, when a message arrives in that
Speaker 2: external queue, the Dapper sidecar's input binding component automatically picks
Speaker 2: it up. It then invokes your registered apin point external
Speaker 2: claims processor process sending the message content as a clean
Speaker 2: JSON payload. Dapri even handles things like base sixty fourty
Speaker 2: coding if needed. Because Q messages are often encoded. Your
Speaker 2: application just gets clean BETA.
Speaker 1: So the app doesn't even need the Azure storage SDK.
Speaker 2: For queues exactly. Dappri handles the interaction now for the
Speaker 2: output binding, triggering an action on the external system like
Speaker 2: writing to that block container. Again, another configuration yamol tells
Speaker 2: Dapper how to connect to the external Azure blob storage, container, account,
Speaker 2: container name, etc. Our ACA processor back end can then
Speaker 2: invoke this output binding simply by making an HTTP postd
Speaker 2: call to its own Dapper sidecars binding end point like
Speaker 2: v one point zero bindings, external claims, blob store, or
Speaker 2: more easily using the Dapper client SDK. It passes the
Speaker 2: data it wants to write. The Dapper sidecar receives this request,
Speaker 2: uses the binding configuration to connect to the external blob storage,
Speaker 2: and performs the operation like creating a new blog file.
Speaker 2: The key takeaway again is simplification Dapper abstracts away the
Speaker 2: specific SDKs and interaction patterns. For all these diverse external systems.
Speaker 2: You use the same Dapper binding APIs regardless of the
Speaker 2: external technology.
Speaker 1: What an incredible deep dive into modern application architecture we've
Speaker 1: had today, really fascinating stuff, from simplifying container deployment with
Speaker 1: Azure container apps to really supercharging micro services with Dapper's
Speaker 1: building block state pubsub bindings. We've seen how developers can
Speaker 1: tackle these complex distributed system challenges with well surprising ease. Actually,
Speaker 1: so the key takeaways for you, our listener. You've learned
Speaker 1: you can gain the power of Kubernetes without necessarily being
Speaker 1: a K eight expert. You can build loosely coupled systems
Speaker 1: using patterns like pubsub. You can seamlessly switch underlined state
Speaker 1: stores likes to COSMOSDB with no code changes. You can
Speaker 1: integrate with external systems effortlessly using bindings, and deploy securely
Speaker 1: using managed identities. It really is all about abstracting a
Speaker 1: way that infrastructure boiler plate, isn't it, so you can
Speaker 1: focus on what truly differentiates your application, the business logic itself.
Speaker 1: So here's a provocative thought to leave you with. Imagine
Speaker 1: the possibilities when you could build complex, scalable and resilient
Speaker 1: applications without getting bogged down and all that infrastructure complexity.
Speaker 1: What kind of innovative cloud native app could you build
Speaker 1: if these complexities were just abstracted away, allowing your ideas
Speaker 1: to truly take flight. We definitely encourage you to explore
Speaker 1: these powerful tools ACA and dapriye and unlock your own
Speaker 1: next generation of applications,