In the past couple of years, there is a buzz about cloud-native applications.
In this series of posts, I will review what exactly is considered a cloud-native application and how can we secure cloud-native applications.
Before speaking about cloud-native applications, we should ask ourselves – what is cloud native anyway?
The CNCF (Cloud Native Computing Foundation) provides the following definition:
"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."
Source: https://github.com/cncf/toc/blob/main/DEFINITION.md
It means – taking full advantage of cloud capabilities, from elasticity (scale in and scale out according to workload demands), use of managed services (such as compute, database, and storage services), and the use of modern design architectures based on micro-services, APIs, and event-driven applications.
What are the key characteristics of cloud-native applications?
Use of modern design architecture
Modern applications are built from loosely coupled architecture, which allows us to replace a single component of the application, with minimal or even no downtime to the entire application.
Examples can be code update/change or scale in/scale out a component according to application load.
- RESTful APIs are suitable for communication between components when fast synchronous communication is required. We use API gateways as managed service to expose APIs and control inbound traffic to various components of our application. Example of services:
- Event-driven architecture is suitable for asynchronous communication. It uses events to trigger and communicate between various components of our application. In this architecture, one component produces/publishes an event (such as a file uploaded to object storage) and another component subscribes/consumes the events (in a Pub/Sub model) and reacts to the event (for example reads the file content and steam it to a database). This type of architecture handles load very well. Example of services:
Additional References:
- AWS - What is API management?
- AWS - What is an Event-Driven Architecture?
- Azure - API Design
- Azure - Event-driven architecture style
- Google API design guide
- GCP - Event-driven architectures
- Oracle API For Developers
- Oracle Cloud - Modern App Development - Event-Driven
Use of microservices
Microservices represent the concept of distributed applications, and they enable us to decouple our applications into small independent components.
Components in a microservice architecture usually communicate using APIs (as previously mentioned in this post).
Each component can be deployed independently, which provides a huge benefit for code change and scalability.
Additional references:
- AWS - What are Microservices?
- Azure - Microservice architecture style
- GCP - What is Microservices Architecture?
- Oracle Cloud - Design a Microservices-Based Application
- The Twelve-Factor App
Use of containers
Modern applications are heavily built upon containerization technology.
Containers took virtual machines to the next level in the evolution of computing services.
They contain a small subset of the operating system – only the bare minimum binaries and libraries required to run an application.
Containers bring many benefits – from the ability to run anywhere, small footprint (for container images), isolation (in case of a container crash), fast deployment time, and more.
The most common orchestration and deployment platform for containers is Kubernetes, used by many software development teams and SaaS vendors, capable of handling thousands of containers in many production environments.
Example of services:
- Amazon Elastic Kubernetes Service (EKS)
- Azure Kubernetes Service (AKS)
- Google Kubernetes Engine (GKE)
- Oracle Container Engine for Kubernetes (OKE)
Additional References:
Use of Serverless / Function as a Service
More and more organizations are beginning to embrace serverless or function-as-a-service technology.
This is considered the latest evolution in computing services.
This technology allows us to write code and import it into a managed environment, where the cloud provider is responsible for the maintenance, availability, scalability, and security of the underlining infrastructure used to run our code.
Serverless / Function as a Service, demonstrates a very good use case for event-driven applications (for example – an event written to a log file triggers a function to update a database record).
Functions can also be part of a microservice architecture, where some of the application components are based on serverless technology, to run specific tasks.
Example of services:
Additional References:
- Serverless on AWS
- Azure serverless
- Google Cloud Serverless computing
- Oracle Cloud - What is serverless?
Use of DevOps processes
To support rapid application development and deployment, modern applications use CI/CD processes, which follow DevOps principles.
We use pipelines to automate the process of continuous integration and continuous delivery or deployment.
The process allows us to integrate multiple steps or gateways, where in each step we can embed additional automated tests, from static code analysis, functional test, integration test, and more.
Example of services:
Additional References:
- DevOps and AWS
- DevOps solutions on Azure
- Google Cloud DevOps capabilities
- Oracle Cloud DevOps Overview
Use of automated deployment processes
Modern application deployment takes an advantage of automation using Infrastructure as Code.
Infrastructure as Code is using declarative scripting languages, in in-order to deploy an entire infrastructure or application infrastructure stack in an automated way.
The fact that our code is stored in a central repository allows us to enforce authorization mechanisms, auditing of actions, and the ability to roll back to the previous version of our Infrastructure as Code.
Infrastructure as Code integrates perfectly with CI/CD processes, which enables us to re-use the knowledge we already gained from DevOps principles.
Example of solutions:
- AWS CloudFormation
- What is Azure Resource Manager?
- Google Cloud Deployment Manager
- What is Terraform?
Additional References:
- Automation as key to cloud adoption success
- AWS - Infrastructure as Code
- Azure - What is infrastructure as code (IaC)?
- Want a repeatable scale? Adopt infrastructure as code on GCP
- Oracle Cloud - What Is Infrastructure as Code (IaC)?
Summary
In this post, we have reviewed the key characteristics of cloud-native applications, and how can we take full advantage of the cloud, when designing, building, and deploying modern applications.
I recommend you continue expanding your knowledge about cloud-native applications, whether you are a developer, IT team member, architect, or security professional.
Stay tuned for the next chapter of this series, where we will focus on securing cloud-native applications.
Additional references
- AWS - What Is Cloud Native?
- Azure - What is Cloud Native?
- Google Cloud - What is cloud-native?
- Oracle Cloud - What is Cloud Native?
- What is a cloud-native application?
- What Modern Cloud-Native Apps are Made Of
About the Author
Eyal Estrin is a cloud and information security architect, the owner of the blog Security & Cloud 24/7 and the author of the book Cloud Security Handbook, with more than 20 years in the IT industry.
Eyal is an AWS Community Builder since 2020.
You can connect with him on Twitter and LinkedIn.
Top comments (0)