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 adopting a cloud native mindset and approach to application architecture can optimize and expedite the rate at which companies can innovate and create new solutions, the transition is not free of challenges and learning curves. 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 infrastructure
- Cloud native applications leverage cloud infrastructure and make use of Platform-as-a-service offerings
- Cloud native applications depend on highly-elastic infrastructure with automatic scaling, self-healing, and monitoring capabilities
Modern application design
- Cloud native applications should be constructed using principals outlined in the 12 factor methodology
Microservices
- Cloud native applications are typically composed of microservices where each core function, or service, is built and deployed independently
Containers
- 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.
Backing services
- 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
Automation
- Cloud native solutions should use deployment automation for backing cloud infrastructure via versioned, parameterized Infrastructure 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.
Enter 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 overhead would inevitably arise. I personally have yet to meet with any customers eager to have their developers get more involved 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 personally 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.
In May of 2022, Microsoft announced the general availability of Azure Container Apps. Azure Container Apps provides customers with the ability to run microservices and containerized applications on a serverless platform. It provides many of the benefits of the Azure App Service experience in terms of Azure integrations and managed features, while running on top of Kubernetes. Therefore, customers are now able to leverage many of the benefits Kubernetes provides without the complexity.
The ability to dynamically scale and support growing numbers of users, events, and requests is a core requirement for most cloud native, distributed applications. Container Apps is purpose-built with this and other cloud native core tenants in mind. In addition to running on Kubernetes behind the scenes, Container Apps provides other managed open source projects embedded directly into the platform: the Kubernetes Event Driven Autoscaler (KEDA), the Distributed Application Runtime (Dapr) and Envoy.
We touched on a few key concepts for cloud native, so let's revisit them briefly in the context of container apps:
Cloud infrastructure
Modern application design
Microservices
Containers
Backing services
Automation
Enter 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 with the customers I worked with. It is 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?"
Enter Dapr! The formal explanation of Dapr is found on their website as follows:
"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."
Top comments (0)