What is cloud native ?
Cloud native is an approach to build and run applications in cloud to exploit the great advantages of cloud delivery model such as unlimited computing power, cost by usage, resiliency and infrastructure automation to name a few.
Organizations that implement cloud native approach correctly, can save on cost, time to market, respond to customer demands sooner and could thrive in a cloud environment.
Cloud Native Computing Foundation (CNCF) defines Cloud Native as follows:
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.
CNCF Definition of Cloud Native.
More than that cloud native is not only an approach or rules or guidelines, it is a philosophy it is a cultural change in developing applications.
What are the characteristics of a cloud native application ?
Cloud native applications follow most or all of the 12 factors defined in 12 Factor app. Keep in mind Cloud native is more than the 12 factors. Most importantly the applications are highly distributed and should be designed stateless wherever possible. So that it can be scaled up/down, repaired, rolled back and load balanced well. The state should be stored in a persistent datastore such as a database or S3.
In addition to the 12 factors, Author Kevin Hoffman has presented 3 more factors in his book Beyond the 12 Factor app to build cloud native applications.
In most cases a cloud native application follows microservices architecture to get all the advantages mentioned above for a stateless application. In addition to that the components can be deployed independently via Continuous Integration/Continuous Delivery (CI/CD) pipelines.
Most of the cloud native systems uses containers to deploy microservices. Containers provide dev/prod parity and integrates well into the devOps practices including continuous deployment.
What is 12 factor app or 15 factor app ?
The 12 factor app methodology describes a set of rules and guidelines that needs to be followed to build a cloud native app. But keep in mind cloud native is more than these 12 factors. The 12 factors are provided below.
| 12 Factors | Description |
|---|---|
| Codebase | One codebase tracked in revision control, many deploys. |
| Dependencies | Explicitly declare and isolate dependencies. |
| Configuration | Store config (ex: URLs, Credentials ..) in the environment. Use backing services to expose configs as env variables or use Spring cloud configuration server. |
| Backing Services | Treat backing services (like db, S3) as attached resources. We should be able to bound or unbound them as needed. |
| Build, release, run | Strictly separate build and run stages and each released artifact should have an identifier. |
| Processes | Execute the app as one or more stateless processes |
| Port Binding | Export services via port binding like one port per app. (or) Only one application should be deployed per server and creation of routes can be handled by cloud providers. |
| Concurrency | Scale out (or horizontally) instead of Scale up (vertically) to run multiple, concurrent instances. |
| Disposability | Fast startup and graceful shutdown. |
| Dev/prod parity | Keep development, staging and production as similar as possible. |
| Logs | Treat logs as event streams (a sequence of events) |
| Admin processes | Run admin/management tasks (like db migration, running a batch based on a timer) as one off processes. If possible avoid running these tasks manually. For example a rest endpoint can be exposed to trigger a job based on timer as shown below. (Autosys/ctrl-m)->https://triggerjob/->RunJob |
In addition to the above 12 factors, Author Kevin Hoffman has presented 3 more factors (provided below) in his book Beyond the 12 Factor app to build cloud native applications.
| API First | All the functionality of an application should be built behind an API |
| Telemetry | Build capabilities to monitor applications running in cloud. It is not always done right and considered one of the challenges going cloud native. Some of the tools suggested by CNCF are Prometheus for monitoring, Fluentd for logging and Jaeger for tracing. |
| Authentication and Authorization | Use RBAC(Role-based access control) like oauth2 to secure all endpoints. We should be able to know who is trying to call the endpoint and if it has the roles needed to perform the operation. |
Why cloud native or What are the advantages going cloud native ?
Going cloud native has many advantages and cost savings. Some of them are provided below:
- Provisioning and maintenance of infrastructure can be fully automated.(Terraform)
- Build, Delivery and Deployment of applications can be fully automated via CI/CD pipelines.
- Scaling up or Scaling down environments based on user traffic or other metrics can be fully automated.
- Invest only when needed. No big initial investment on infrastructure. Cost Savings by Scaling down the components automatically when it is not used.
- Recover or replace the failing apps automatically by building health checks and monitoring.
- Offer modern managed data and application services for developers and organization.
What are some of the challenges going cloud native ?
Some of the challenges of a cloud native application are Security, Observability(telemetry) and Compliance.
Where can we get some of the cloud computing design patterns ?
Book: Cloud native Patterns.