While I’m positive I’m not the first person to ask this, I think it’s an appropriate way for us to kick off this article: “How many developers does it take to define cloud native?”
I hope you aren’t waiting for a punch line because I seriously want to know your thoughts. Drop your perspectives in the comments...but if you ask me, the limit does not exist!
A quick online search of the topic returns a laundry list of articles, e-books, twitter threads, etc. all trying to nail down the one true definition. While diving into the rabbit hole of cloud native, you will inevitably find yourself on the Cloud Native Computing Foundation (CNCF) site. The CNCF is part of the Linux Foundation and aims to make "cloud native computing ubiquitous" through deep open source project and community involvement. The CNCF has also published arguably the most popularized definition of cloud native which begins with the following statement:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds."
Over the past four years, my day-to-day work has been driven primarily by the surging demand for application containerization and the drastic adoption of Kubernetes as the de-facto container orchestrator. Customers are eager to learn and leverage patterns, practices and technologies that enable building "loosely coupled systems that are resilient, manageable, and observable". Enterprise developers at these organizations are being tasked with rapidly deploying event-driven, horizontally-scalable, polyglot services via repeatable, code-to-cloud pipelines.
While building cloud native solutions can enable rapid innovation, the transition to adopting a cloud native architectural approach comes with a steep learning curve and a new set of considerations. In a document published by Microsoft called What is Cloud Native?, there are a few key areas highlighted to aid customers in the adoption of best practices for building modern, portable applications which I will summarize below:
Cloud native applications are typically composed of microservices where each core function, or service, is built and deployed independently
Cloud native applications are typically deployed using containers as a packaging mechanism where an application's code and dependencies are bundled together for consistency of deployment
Cloud native applications leverage container orchestration technologies- primarily Kubernetes- for achieving capabilities such as workload scheduling, self-healing, auto-scale, etc.
Cloud native applications are ideally stateless workloads which retrieve and store data in data stores external to the application hosting infrastructure. Cloud providers like Azure provide an array of backing data services which can be securely accessed from application code and provide capabilities for ensuring application data is highly-available
Cloud native solutions should use deployment automation for backing cloud infrastructure via versioned, parameterizedInfrastructure as Code (IaC)templates which provide a consistent, repeatable process for provisioning cloud resources.
Cloud native solutions should make use of modern CI/CD practices and pipelines to ensure successful, reliable infrastructure and application deployment.
Azure Container Apps
In many of the conversations I've had with customers that involve talk of Kubernetes and containers, the topics of cost-optimization, security, networking, and reducing infrastructure and operations inevitably arise. I personally have yet to meet with any customers eager to have their developers getmoreinvolved with infrastructure concerns.
One of my former colleagues, Jeff Hollan, made a statement while appearing on a 2019 episode of The Cloud Native Show where he shared his perspective on Cloud Native:
"When I think about cloud native... it's writing applications in a way where you are specifically thinking about the benefits the cloud can provide... to me, serverless is the perfect realization of that because the only reason you can write serverless applications is because the cloud exists."
I must say that I agree with Jeff's perspective. In addition to optimizing development practices for the cloud native world, reducing infrastructure exposure and operations is equally as important to many organizations and can be achieved as a result of cloud platform innovation.
The ability to dynamically scale and support growing numbers of users, events, and requests is one of the core requirements for most cloud native, distributed applications. Azure Container Apps is purpose-built with this and other cloud native tenants in mind.
Dapr in Azure Container Apps
As a quick personal note before we dive into this section I will say I am a bit bias about Dapr. When Dapr was first released, I had an opportunity to immediately get involved and became an early advocate for the project. It is created by developers for developers, and solves tangible problems customers architecting distributed systems face:
How do I integrate with external systems that my app has to react and respond to?
How do I create event driven apps which reliably send events from one service to another?
How do I observe the calls and events between my services to diagnose issues in production?
How do I access secrets securely from within my application?
How do I discover other services and call methods on them?
How do I prevent committing to a technology early and have the flexibility to swap out an alternative based on project or environment changes?
While existing solutions were in the market which could be used to address some of the concerns above, there was not a lightweight, CNCF-backed project which could provide a unified approach to solve the more fundamental ask from customers: "How do I make it easy for developers to build microservices based on cloud native best practices?"
"The Distributed Application Runtime (Dapr) provides APIs that simplify microservice connectivity. Whether your communication pattern is service to service invocation or pub/sub messaging, Dapr helps you write resilient and secured microservices. By letting Dapr’s sidecar take care of the complex challenges such as service discovery, message broker integration, encryption, observability, and secret management, you can focus on business logic and keep your code simple."
The Container Apps platform provides a managed and supported Dapr integration which eliminates the need for deploying and managing the Dapr OSS project. In addition to providing managed upgrades, the platform also exposes a simplified Dapr interaction model to increase developer productivity and reduce the friction required to leverage Dapr capabilities. While the Dapr integration makes it easier for customers to adopt cloud native best practices in container apps it is not required to make use of the container apps platform.
Backed by and integrated with powerful cloud native technologies, Azure Container Apps strives to make developers productive, while reducing the operational overhead and learning curve that typically accompanies adopting a cloud-native strategy.