What Is Cloud Native Architecture?
A cloud-native architecture is a design pattern for applications built from the ground up for a cloud environment.
While there are no hard-and-fast rules for cloud native architecture, most cloud native applications are organized as microservices. Microservices are used to break up applications into autonomous, loosely-coupled units that can be maintained by small teams. Each microservice is usually deployed as a container or group of containers.
In addition, cloud-native apps commonly follow the principles of the 12-factor apps framework. They are built around:
- Performance—the application is designed with scalability in mind and built to perform well at scale.
- Elasticity—the application is built using small, scalable components that can be scaled horizontally with ease.
- Resilience—the application is highly resilient to failure. Components can fail and are easily and automatically replaced, without disrupting the operation of other components.
- Security—the application is built with security in mind, operating under the assumption that an attacker has already accessed the network, and should not be able to compromise the application or its data.
In this article:
- Cloud Native Architecture Principles
- 1. Design for Automation
- 2. Be Stateless When You Can
- 3. Design for Resilience
- 4. Architect Each Component with a Micro-Perimeter
- 5. Build a Polyglot Architecture
- Cloud Native Architecture Pros and Cons
- Cloud Native Architecture with Aqua Security
Cloud Native Architecture Principles
When architecting a cloud native application, you should plan for a system that is constantly on the move in several dimensions. Cloud native systems dynamically scale out, automatically handle failure and make it as easy and possible to add and remove components. Here are several principles that can make your architecture stronger, more adaptable to change and more easily maintainable.
1. Design for Automation
Create automated processes that can deploy, repair and scale the system when needed. Instrument the system to generate meaningful logs and events, which you can use as hooks for automated activities. Build the system to automatically handle:
- Provisioning of infrastructure like machine instances
- Build, test and deployment stages in your CI/CD pipeline
- Dynamic scalability based on load or other application requirements
- Backup, health monitoring and recovery from failure
2. Be Stateless When You Can
While some cloud-native purists argue that cloud-native apps should be stateless, this can be very difficult to achieve in real world production applications. However, recognizing that managing state (for example, how many instances are currently running) is difficult in distributed applications, you should use stateless components whenever possible. Stateless components make it easier to scale (by adding more copies), repair (by tearing down and replacing with a new instance), roll back, and load balance (without complex logic about which instance is handling which transactions).
3. Design for Resilience
Build resiliency into cloud native applications by adding redundancy to the design. Cloud native applications avoid single points of failure by using clusters of self-contained instances, data replication, and multi-AZ or multi-region cloud deployments. Applications that must run on-premises should use hybrid architectures to leverage the public cloud for high availability and disaster recovery, at least for some of their components.
A few common resilience mechanisms:
- Identify transient failures, caused by temporary issues like loss of connectivity or service timeout, and simply retry the request
- Implement circuit breakers, which check the number of times an operation has been retried, and on subsequent retries, returning an error without activating the service
- Allow services to gracefully degrade if another service they depend on fails, while still providing a reasonable user experience
- Identify and limit high-volume users, using rate limiting and throttling, as appropriate for the application
- Use compensating transactions—a business transaction broken down into a series of smaller transactions, making it easier to achieve transactional consistency in a distributed system
Related content: Read our guide to cloud native infrastructure ›
4. Architect Each Component with a Micro-Perimeter
Cloud-native apps should not only be designed for security from the start, they should also be designed under the assumption that no component can be trusted. There may not be a private network between an application and its users, or even between internal components. You should aim to harden all components, encrypt data and implement authentication between components. This makes your application more resilient, and gives you the flexibility to deploy components in a non-trusted environment.
Related content: Read our guide to microservices security ›
5. Build a Polyglot Architecture
Cloud native applications do not need a strongly integrated architecture, with components written using the same language and using the same technologies and frameworks. Write each component using the language or technology that provides the most value and fastest time-to-market given your team’s skillset. Use REST APIs to expose the functionality of each component, allowing heterogeneous components to communicate and use each other.
6. Make Components Immutable
You can introduce a high level of agility and flexibility by making your infrastructure components immutable. Typically, this means configuring servers or virtual machines (VMs) in a way that does not allow modifications after deployment.
Once you deploy an immutable server, you no longer need to modify it. Instead, you need to ensure the deployed server remains intact as is, without applying any modifications. If issues occur, you can quickly and easily replace the server and keep the application running.
Here are several key benefits of using an immutable infrastructure:
- Immutable components contribute to a consistent and reliable infrastructure. This makes testing significantly more straightforward.
- Deploying immutable components is simpler and more predictable.
- Each deployment of immutable components is versioned and automated. This makes environment rollback easier and simpler.
- Configuration drifts, snowflake servers and errors are mitigated or even eliminated entirely.
- Auto-scaling is effortless when using cloud services.
Mutable servers increase costs as well as iteration time, severely delaying the time-to-market. Immutable infrastructure, on the other hand, promotes agile development. Immutable infrastructure improves the reliability, consistency and efficiency of a deployed environment. You can recreate the environment within minutes.
Cloud Native Architecture Pros and Cons
There are a number of advantages to a cloud-native architecture:
- Cost—the cloud provides low cost options for ensuring your systems are always running and can serve customers. You can also leverage a variety of cloud-delivered features that would be time-consuming and expensive to provide in-house.
- Reliability—cloud environments offer resilience and reliability options, such as availability zones, which ensure that your system will never go down. This protects you from outages so you can avoid the associated cost and reputational damage of downtime.
- Agility—agile development requires constant testing and improvements, which is difficult in a traditional monolith architecture where a small change could break the entire system. Cloud native systems are built with continuous change in mind, so you can more easily update and tweak your applications.
- Flexibility—cloud-native designs are platform-agnostic, so you can switch to a new environment if your current system isn’t working for you. You don’t have to reprogram the whole thing from end to end.
The drawbacks of a cloud-native architecture include:
- Resolving issues—in a traditional architecture, you follow a linear plan to identify issues. Cloud-native designs have containers that connect and interact with each other in a complex web, and the path between a particular set of components may not be clear. If the source of a problem is spread across more than one container, it can be harder to isolate the root cause.
- Security—cloud native architectures are more generally difficult to monitor and secure because of the large number of dynamic, distributed components that make up the system.
- Knowledge gaps—if you are new to cloud-native systems, it requires adjustment to learn to write, as with a new language. It is important to get a good understanding of new concepts to avoid making mistakes that will create havoc down the line.
When considering a new cloud-native architecture, you need to carefully weigh the various pros and cons so you can make the right decision for your business, your customers and your stakeholders. To ensure that everyone in your organization understands the new approach you want to adopt, hold meetings to plan and discuss the move before you attempt the build.
Cloud Native Security with Aqua
According to the Cloud Native Computing Foundation’s annual survey, organizations are rapidly shifting to cloud native architecture. Here are a few highlights:
- 92% of respondents use containers in production environments
- This represents a 300% increase over the past four years
- 91% of respondents use Kubernetes
- 83% of them do so in production environments
While this is reaping benefits for companies, it is introducing complexity, which can be a difficult challenge for security. Challenges such as the widespread use of open source software, a new hybrid stack of technologies, and the high velocity of DevOps makes it difficult for security teams to keep up. And these challenges encompass the full DevOps lifecycle, from build to runtime.
Attackers are already taking advantage of companies’ mistakes and misconfigurations. Research from Nautilus, Aqua’s threat research organizations, found that when a new honeypot was created, the median time it took for a threat actor to scan it was only 56 minutes. This means in 50% of the cases, adversaries found the new honeypot in less than one hour. Other research from Nautilus underscores that attackers only need a simple mistake, such as a misconfigured Docker daemon API, to wreak havoc inside a system.
To combat these challenges, organizations need protection across the entire application development lifecycle. As coined by Gartner, organizations need a Cloud Native Application Protection Platform (CNAPP). The Aqua Platform allows teams to shift-left with security in the application development process as well as detect and prevent active attacks with granular runtime policies that enforce without killing the workload. The platform also hardens the infrastructure and orchestrators used to run an application.
Aqua provides coverage for the developer with vulnerability scanning and workload assessment, for cloud infrastructure security with cloud security posture management and Kubernetes security posture management, and for security operations with cloud workload protection.
To learn more about the Aqua Platform, schedule a demo ›
