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