Chapter 6 - What is a Cloud Native Application?
Introduction
Simply put, the cloud is a set of computer resources hosted remotely and used by a client for storage and computing power.
Cloud-native applications are apps that are designed for and live in the cloud. These applications focus on agility, resilience, and portability across cloud environments. Cloud-native is how apps are created and deployed, not where.
One of the primary features of a cloud-native application is containerization. Containers are technologies that allow you to package and isolate applications along with their entire runtime environment - everything the app needs to run. Using containers makes it easy to move the application between environments - dev, test, production, etc - while retaining full functionality.
This containerization has many benefits, including that it lets developers focus on the apps while operations focus on infrastructure. It also allows for easier scalability of services.
These containers package up, deploy, and manage microservices.
Microservices split your application into a collection of small services. Each service implements business capabilities, runs its own processes, and communicates via HTTP APIs or messaging. Each microservice is independent of the other services in the application, and typically automated, allowing for frequent updates of live systems without impacting the customer.
With cloud-native development, apps are also made more resilient. Instead of being reliant on physical machines that can fail, cloud-native applications can handle hiccups in service without going offline.
Think of the traditional application as house pets, and cloud applications as cattle. You give house pets names, and nurture them back to health when they get sick. Cattle are given numbers so they are virtually identical and interchangeable. When one cow has a problem, you make hamburger and get a new cow. Cloud applications are cattle.
Twelve-factor App Methodology
How can I begin to build a Cloud Native Application?
One popular methodology for building cloud applications is the 12 Factor approach.
This 12 step approach was written by Heroku co-founder Adam Wiggins and is intended to solve common problems with running applications in the cloud.
The 12 factors are as follows:
I. Codebase
One codebase tracked in a version control system should be used. There is always a one-to-one correlation between codebase and application. However, there will be many deployments of the application. A deployment, or deploy, is just a running instance of the application. The codebase is the same across all deploys.
II. Dependencies
Explicitly declare and isolate dependencies. Use a package manager, and do not rely on the existence of system-wide packages.
III. Config
Store an app's config in environment variables. Config varies substantially across deployments, but the code should not. Having to repackage an app for a new deploy would be a violation of the 12-factor methodology.
IV. Backing Services
Treat backing services as attached resources. A deploy of a 12-factor app should be able to swap out a local SQL database for one managed by a third party, such as Amazon RDS, without any changes to the codebase.
V. Build, Release, Run
Strictly separate build and run stages. The build stage converts a code repository, also widely known as a repo, into an executable bundle called a build. This build is combined with the deployment's current config to form a release. The app runs in the execution environment by launching some set of the app's processes against a selected release.
VI. Processes
Execute the app as one or more stateless processes. 12-factor processes are stateless and share-nothing. Any data that must persist is stored in a stateful backing service, like a database.
VII. Port Binding
Export services via port binding. A 12-factor app should be completely self-contained, and export a service, such as HTTP, via a port.
VIII. Concurrency
Scale out via a process model. Each process should be individually scaled. The stateless and share-nothing aspect of a 12-factor app makes this process simple and reliable.
IX. Disposability
Maximize robustness with fast startup and graceful shutdown. A 12-factor app's processes are disposable, meaning they can be started or stopped at a moment's notice. Ideally, it should take only a few seconds for a process to start, or "turn on". Once "turned on", a process will be ready to receive requests or jobs. A process should also shutdown gracefully; so, the process will refuse any new requests, allow any pending requests to finish, and then exit.
X. Dev/Prod Parity
Keep development, staging, and production as similar as possible. Minimize the gap between development and production small.
XI. Logs
Treat logs as event streams. A 12-factor app is not concerned with the storage or routing of its output steam. It should not write or manage log files. The execution environment captures and collates each process' stream and manages the archival destination.
XII. Admin Processes
Run admin/management tasks as one-off processes.