What is Cloud Native?
As the Cloud has evolved, smart organizations have rethought their application development and delivery models to best use the advantages of cloud architectures. First-generation cloud workloads in Amazon AWS, Microsoft Azure, Google Cloud Engine and other clouds were primarily a “lift and shift” exercise. These efforts moved on-prem apps and infrastructure into a commodity unmanaged platform for cost savings in both hardware spend and IT overhead.
This “Cloud Native” approach takes advantage of the architecture of the cloud, in combination with microservice architecture and container technologies to rethink what’s possible with application architectures in a cloud-based world. Cloud native app strategies has created a revolution in IT, but requires a new way of thinking to best take advantage of the power of the cloud.
The Three Pillars Of Cloud Native Applications
The common definition of a cloud native application involves three core pillars: that the application is packaged with container technology such as Docker, that it consists of series of microservices providing data and logic processes in discrete components, and that they are dynamically managed by a supervisor that orchestrates and confederates processes for both functionality and scale. These three characteristics of cloud native-ness solve a number of issues for IT organizations.
1. Reducing Friction in Application Delivery with Containers
Standardizing on containers moves teams past a number of sources of friction found in traditional application development and delivery models. Technologies like Docker smooth the intersection of Dev and Ops teams by providing a consistent way to package and manage infrastructure and platform components in an isolated “container”. Barriers to the cloud for both developers and IT teams are reduced and removed in a container-based world.
IT teams can create standardized images of OS, database, and networking configurations that can be easily discovered and consumed by developers. As developers build against these images, they can also package applications with these images in mind. So as they finish functionality and deliver it to operations for deployment in a test or production environment, the ops team doesn’t have to do forensic work to understand what the developer did on their end. And apps can be packaged with dependencies for the container image to streamline the deployment process.
2. Moving Past Monolithic with Microservices
The next characteristic, microservices-based architectures, decouples application functionalities, data streams, and interfaces from being features of a monolithic application to a series of confederated services brought together in an application. This deconstruction of an application model into small discrete units of functionality gives developers and ops teams flexibility and power to approach big problems in a lean and agile fashion. Specific functionalities or data sources are exposed through an API and are consumed by the application developer. Functionality can then be added, updated or repaired without requiring a rewrite, retesting and redeployment of the entire application. Applications can then evolve quickly to respond to business needs, technological changes or innovations in a high-velocity manner.
3. Dynamic Application Management with Supervisors
With composed and connected microservices running across a containerized infrastructure, it’s important to manage these for predictable results. The third characteristic, dynamic management, provides a supervisory layer on top of the services to give operations teams a view into the inner workings of the applications. A cloud native supervisor looks at the components of an application infrastructure, across both the cloud platform, container status and contents, and service state to understand both current configuration state, service status and other critical elements of the ecosystem. Defects found in the current state can then be identified and corrected by the appropriate dev or operations team for remediation.
Anatomy of a Cloud Native Architecture
A cloud native architecture consist of five different layers, from the high-level application code, down through required runtimes and connected services. These applications and services are managed by consistent scheduling and orchestration and supervision, all of which runs on a low-level infrastructure hosted by the cloud provider.
Successfully Delivering Cloud Native Apps
At Chef we believe the success of delivering cloud native applications hinges on four core facets:
- Composability: Components can be easily composed and connected with specific service requirements
- Flexibility: Not limited (or appears to not be limited) from the perspective of the Developer.
- Programmability: API first approach to provisioning, deployment, and management
- Frictionless: The infrastructure is hidden from the perspective of the Developer.
These four characteristics of cloud native applications are key to not only a successful initial code deployment, but enable the agile and continuous delivery of value to customers.
As teams begin to envision applications that are cloud native at birth, the next question to answer is “how do we actually build these things?” Teams need to think about how to build, deploy, and manage cloud native applications differently from traditional applications. Cloud native architectures are well suited to the DevOps practices of lean and agile, where new discrete features are built quickly, deployed and tested frequently, and delivered to customers as rapidly as possible. Every day is “Day 1” in a cloud native organization, with innovation and velocity the keys to success.
Ready to start? We’re here to help.
Set your team up for cloud native success with Chef. Chef Automate supports the entire cloud native journey, from app development with Habitat Builder, to compliance and configuration automation with Chef InSpec, and cloud and container management with Chef Infra.Contact Sales