This article describes how a Cloud Native application should look like, it is based on the well known 12 Factors.

At the moment of writing this article, in my understanding, the Cloud Native is not only about code that developers write, but it is also a way of organizing engineering teams so that their work will be highly effective, flexible code, and at the end, you have fast time-to-market for your applications.

In articles that I read, Cloud Native is strongly related to software as a service, Continuous Integration, Continuous delivery, Zero-downtime deployments, and teams that are deploying daily.

Codebase

One codebase tracked in revision control, many deploys

This principle says that your codebase should produce one executable, you don’t produce multiple executables from one repository and you don’t maintain multiple repositories that and the end is used to produce one executable.

When you have one repository that produces multiple executables is not good because easily you may end up messing models and some of your application doing work that they are not responsible for.

Having multiple repositories that are used to produce one binary is hard to maintain and hard to evolve – after-all we are humans and we don’t have an infinite capacity to keep things in our memory, it is hard to work when multiple repositories are used to produce a single app.

Dependencies

Explicitly declare and isolate dependencies

Your application should not make the assumption that it will run in an environment where some libraries or dependencies are available, or any tool is available, or the database is available on the same host or even it has access to storage.

When writing applications for the cloud you make them stateless, they make zero assumptions about the env when they are going to run, storage/mail/database are external services that are pluggable using configurations.

The only assumption that you can make is that your application has access to CPU and memory.

The benefit of not having external dependencies is that it simplifies the application setup at different stages, developers setup the development-environment easily, the staging and production environments are easy to configure.

Configs

Store config in the environment

Configuration of an application are the things that vary between environments:

• backing services like Memcached host, database resources
• credentials to your cloud provider or Facebook app

Sometimes application store configurations in code as constants, some tools make this easy to do (example injecting a Value using Spring and providing a default value).

In the 12 Factors, an application should store the configurations in the environment variables, configurations are easy to change and they are not written in a single file and prefixed with dev., prod. etc.

There are tools like Spring Cloud Config or Netflix Archaius.

Read full article on my blog: Cloud Native