In this article by Ranga Rao Karanam, the author of the book Mastering Spring, we will see what are Cloud Native applications and Twelve Factor App.

(For more resources related to this topic, see here.)

Cloud Native applications

Cloud is disrupting the world. A number of possibilities emerge that were never possible before. Organizations are able to provision computing, network and storage devices on demand. This has high potential to reduce costs in a number of industries.

Consider the retail industry where there is high demand in pockets (Black Friday, Holiday Season and so on). Why should they pay for hardware round the year when they could provision it on demand?

While we would like to be benefit from the possibilities of the cloud, these possibilities are limited by architecture and the nature of applications.

How do we build applications that can be easily deployed on the cloud? That's where Cloud Native applications come into picture.

Cloud Native applications are those that can easily be deployed on the cloud. These applications share a few common characteristics. We will begin with looking at Twelve Factor App - A combination of common patterns among Cloud Native applications.

Twelve Factor App

Twelve Factor App evolved from experiences of engineers at Heroku. This is a list of patterns that are typically used in Cloud Native application architectures.

It is important to note, that an App here refers to a single deployable unit. Essentially every microservice is an App (because each microservice is independently deployable).

One codebase

Each App has one codebase in revision control. There can be multiple environments where the App can be deployed. However, all these environments use code from a single codebase. An example for anti-pattern is building a deployable from multiple codebases.

Dependencies

Explicitly declare and isolate dependencies. Typical Java applications use build management tools like Maven and Gradle to isolate and track dependencies. The following screenshot shows the typical Java applications managing dependencies using Maven:

The following screenshot shows the content of the file:

Config

All applications have configuration that varies from one environment to another environment. Configuration is typically littered at multiple locations - Application code, property files, databases, environment variables, Java Naming and Directory Interface (JNDI) and system variables are a few examples.

A Twelve Factor App should store config in the environment. While environment variables are recommended to manage configuration in a Twelve Factor App, other alternatives like having a centralized repository for application configuration should be considered for more complex systems.

Irrespective of mechanism used, we recommended to manage configuration outside application code (independent of the application deployable unit). Use one standardized way of configuration

Backing services

Typically applications depend on other services being available - data-stores, external services among others. Twelve Factor App treats backing services as attached resources. A backing service is typically declared via an external configuration.

Loose coupling to a backing service has many advantages including ability to gracefully handle an outage of a backing service.

Build, release, run

Strictly separate build and run stages.

• Build: Creates an executable bundle (ear, war or jar) from code and dependencies that can be deployed to multiple environments.
• Release: Combine the executable bundle with specific environment configuration to deploy in an environment.
• Run: Run the application in an execution environment using a specific release

An anti-pattern is to build separate executable bundles specific for each environment.

Stateless

A Twelve Factor App does not have state. All data that it needs is stored in a persistent store. An anti-pattern is a sticky session.

Port binding

A Twelve Factor App exposes all services using port binding. While it is possible to have other mechanisms to expose services, these mechanisms are implementation dependent. Port binding gives full control of receiving and handling messages irrespective of where an application is deployed.

Concurrency

A Twelve Factor App is able to achieve more concurrency by scaling out horizontally. Scaling vertically has its limits. Scaling out horizontally provides opportunities to expand without limits.

Disposability

A Twelve Factor App should promote elastic scaling. Hence, they should be disposable. They can be started and stopped when needed.

A Twelve Factor App should:

• Have minimum start up time. Long start up times means long delay before an application can take requests.
• Shutdown gracefully.
• Handle hardware failures gracefully.

Environment parity

All the environments - development, test, staging, and production - should be similar. They should use same processes and tools. With continuous deployment, they should have similar code very frequently. This makes finding and fixing problems easier.

Logs as event streams

Visibility is critical to a Twelve Factor App. Since applications are deployed on the cloud and are automatically scaled, it is important to have a centralized visibility into what's happening across different instances of the applications.

Treating all logs as stream enables routing of the log stream to different destinations for viewing and archival. This stream can be used to debug issues, perform analytics and create alerting systems based on error patterns.

No distinction of admin processes

Twelve Factor Apps treat administrative tasks (migrations, scripts) similar to normal application processes.

Summary

This article thus explains about Cloud Native applications and what are Twelve Factor Apps.

Resources for Article:

Further resources on this subject:

• Cloud and Async Communication [article]
• Setting up of Software Infrastructure on the Cloud [article]
• Integrating Accumulo into Various Cloud Platforms [article]