What is Cloud Native?
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.
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
A cloud native application is designed to run on a cloud native infrastructure platform with the following four key traits:
- Cloud native applications are resilient. Resiliency is achieved when failures are treated as the norm rather than something to be avoided. The application takes advantage of the dynamic nature of the platform and should be able to recover from failure.
- Cloud native applications are agile. Agility allows the application to be deployed quickly with short iterations. Often this requires applications to be written as microservices rather than monoliths, but having microservices is not a requirement for cloud native applications.
- Cloud native applications are operable. Operability concerns itself with the qualities of a system that make it work well over its lifetime, not just at deployment phase. An operable application is not only reliable from the end-user point of view, but also from the vantage of the operations team. Examples of operable software is one which operates without needing application restarts or server reboots, or hacks and workarounds that are required to keep the software running. Often this means that the application itself should expose a health check in order for the infrastructure it is running on to query the state of the application.
- Cloud native applications are observable. Observability provides answers to questions about application state. Operators and engineers should not need to make conjectures about what is going on in the application. Application logging and metrics are key to making this happen.
The above list suggests that cloud native applications impact the infrastructure that would be necessary to run such applications. Many responsibilities that have been traditionally handled by infrastructure have moved into the application realm.
In this article, you will learn:
Cloud Native Infrastructure Flavors
The ephemeral nature of the cloud demands automated development workflows that can be deployed and redeployed as needed. Cloud-native applications must be designed with infrastructure ambiguity in mind. This has led developers to rely on tools, like Docker, to provide a reliable platform to run their applications on without having to worry about the underlying resources. Influenced by Docker, developers have built applications with the microservices model, which enables highly focused, yet loosely coupled services that scale easily with demand.
Application containerization is a rapidly developing technology that is changing the way developers test and run application instances in the cloud.
The principal benefit of application containerization is that it provides a less resource-intensive alternative to running an application on a virtual machine. This is because application containers can share computational resources and memory without requiring a full operating system to underpin each application. Application containers house all the runtime components that are necessary to execute an application in an isolated environment, including files, libraries, and environment variables. With today’s available containerization technology, users can run multiple isolated applications in separate containers that access the same OS kernel.
In the cloud computing world, it is often the case that the cloud provider provides the infrastructure necessary to run the applications to the users. The cloud provider takes care of all the headaches of running the server, dynamically managing the resources of the machine, etc. It also provides auto scalability, which means the serverless applications can be scaled based on the execution load they are exposed to. All these are done so that the user can solely focus on writing the code and leave worrying about these tasks to the cloud provider.
Serverless applications, also known as Function-as-a-Service or FaaS, is an offering from most of the enterprise cloud providers in which they allow the users to only write code and the infrastructure behind the scenes is managed by them. Users can write multiple functions to implement business logic and then all these functions can be easily integrated to talk to each other. Such a system that involves the use of the above model is known as serverless architecture.
Does Cloud Native Introduce a Cultural Change in Organizations?
Cloud Native is more than a tool set. It is a full architecture, a philosophical approach for building applications that take full advantage of cloud computing. In this context, culture is how individuals in an organization interact, communicate, and work with each other.
In short, culture is the way your enterprise goes about creating and delivering your service or product. If you have the perfect set of cloud platform, tools, and techniques yet go about using them wrong—if you apply the right tools, only in the wrong culture—it’s simply not going to work. At best you’ll be functional but far from capturing the value that the system you’ve just built can deliver. At worst, that system simply won’t work at all.
The three major types of culture within enterprises are Waterfall, Agile, and Cloud Native. A quick primer:
Waterfall organizations are all about long-term planning. They deliver a large, solidly built and tested project bundling many separate services into one deployment every six months to one year (perhaps even longer) timeframe. They are risk-averse, with a long decision-making chain and rigid hierarchy. There are a lot of managers, including project managers. Waterfall organizations tend to have specialist teams handling very specific skills—security, testing, database administration, etc.
Agile organizations recognise the limitations imposed by monolithic long-term releases, and have adapted to deliver faster by using an iterative, feature-driven approach to releasing in two- to four-week ‘sprints’. Agile development breaks applications into their functional components, each of which is worked on, start to finish, by a single team.
Cloud Native organizations are built to take optimum advantage of functioning in cloud technologies (clouds will look quite different in the future, but we also build to anticipate this). Applications are built and deployed in a rapid cadence by small, dedicated feature teams made up of developers who also know how to build in networking, security, and all other necessities so all parts of the distributed system become part of the application.
Cultural awareness also grants the ability to start changing your organization from within, by a myriad of small steps all leading in the same direction. This allows you to evolve gradually and naturally alongside a rapidly changing world. ‘Long-term direction’ is literally the definition of strategy. So small steps towards this direction are strategic steps. Strategy is setting a long-term direction and taking steps on that direction.
Challenges of Cloud Native Apps
Below we cover a few challenges, which any organization should carefully consider before, and during, the move to cloud native.
Managing a CI/CD Pipeline for Microservices Applications
Microservices applications are composed of a large number of components, each of which could be managed by a separate team, and has its own development lifecycle. So instead of one CI/CD pipeline, like in a traditional monolithic app, in a microservices architecture there may be dozens or hundreds of pipelines.
This raises several challenges:
- Low visibility over quality of changes being introduced to each pipeline
- Limited ability to ensure each pipeline adheres to security and compliance requirements (see the following section)
- No central control over all the pipelines
- Duplication of infrastructure
- Lack of consistency in CI/CD practices – for example, one pipeline may have automated UI testing, while others may not
To address these challenges, teams need to work together to align on a consistent, secure approach to CI/CD for each microservice. At the organizational level, there should be a centralized infrastructure that provides CI/CD services for each team, allowing customization for the specific requirements of each microservice.
Cloud Native Security Challenges
Cloud native applications present tremendous challenges for security and risk professionals:
A larger number of entities to secure
DevOps and infrastructure teams are leveraging microservices – using a combination of containers, Kubernetes and serverless functions – to run their cloud native applications. This growth is happening in conjunction with a constantly increasing cloud footprint. This combination leads to a larger number of entities to protect, both in production and across the application lifecycle.
Environments are constantly changing
Public and private cloud environments are constantly changing due to the rapid-release cycles employed by today’s development and DevOps teams. As enterprises deploy weekly or even daily, this presents a challenge for security personnel looking to gain control over these deployments without slowing down release velocity.
Architectures are diverse
Enterprises are using a wide-ranging combination of public and private clouds, cloud services and application architectures. Security teams are responsible for addressing this entire infrastructure and how any gaps impact visibility and security.
Networking is based on service identity
Unlike traditional applications that use a physical or virtual machine as a stable reference point or node of a network, in cloud native applications different components might run in different locations, be replicated multiple times, be taken down and then get spun up elsewhere. This requires a network security model that understands the application context, the identity of microservices and their networking requirements, and builds a zero trust model around those requirements.
Learn More About Cloud Native Applications
Open Policy Agent: Authorization in a Cloud Native World
The Open Policy Agent (OPA) is a policy engine that automates and unifies the implementation of policies across IT environments, especially in cloud native applications. OPA was originally created by Styra, and has since been accepted by the Cloud Native Computing Foundation (CNCF). The OPA is offered for use under an open source license.
Learn about Open Policy Agent (OPA) and how you can use it to control authorization, admission, and other policies in cloud native environments, with a focus on K8s.