101 on Cloud and Kubernetes: Cloud-native is not Cloud

This is the third article on a series explaining what is cloud and cloud native, without unnecessary details, if you are just not really interested about technical details.

You can see the previous article on this series here:

[embed]101 on Cloud and Kubernetes: VMs vs Containers Second article on my series about Cloud and Kubernetes without unnecessary details.medium.com

An AI-generated image for “cloud native”

Cloud native leverages cloud, but it is not a synonym for it. Cloud is not cloud-native and cloud native is not about using cloud, but about the way you build and run your application.

[embed]toc/DEFINITION.md at main · cncf/toc ⚖️ The CNCF Technical Oversight Committee (TOC) is the technical governing body of the CNCF Foundation. …github.com

The Cloud Native Computing Foundation (CNCF), the ones that steward Kubernetes (one of the hottest technologies in the world right now for cloud native) has a definition for cloud native that is widely accepted:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

The definition clarifies many things: it is not a technology like cloud, but a practice, centered on software creation and deployment on cloud environments, that allows for automation and scale.

If you think that there is no difference between that and your legacy application running on physical or virtual hardware, think twice. Legacy applications were designed to be running as-is forever. Sizing consisting in guessing the right processor and number of cores in your CPU, the amount of GB in your memory, and the TB of storage required to run smoothly for a few years.

Redundancy was included in the architecture. You designed active-active or active-passive frontends and backends, worked on the database, put there a load balancer, but everything designed with a goal in your head: to serve x number of clients per minute or hour. If your traffic varied a lot (i.e. you generate all bills the first day of the work), you were simply paying for idle resources the rest of the time. Maintenance was manual, with very complicated processes to stop components, update them, and verify that everything was back online.

But if your server can change in minutes, or seconds, and you don’t have to wait 8 weeks for a new server to arrive, you could do better, and that is when the concept of ‘12-factor apps’ emerged (https://12factor.net/)

We won’t go in details about the methodology, but a few core ideas are central to the cloud-native mindset:

1. Declarative setup and automation: Where the standard was a book of manual steps (run this, then edit that file, restart that service), you declare the desired state (e.g. ‘I need a web server with these settings’). Automation takes care of the “how”.
2. Explicit Dependencies & Automation: The application declare and isolate its dependencies. This makes them self-contained and portable, able to run on any environment without relying on pre-installed software on the OS.
3. Stateless, disposable processes: Applications are designed as stateless processes that can be started and stopped at any moment. They don’t store any persistent data internally, so you can create new copies that use the configuration.
4. Externalized configuration: Configuration that varies between deployments (like database credentials, hostnames or addresses for other services) are stored in the environment, not the application. Updating the configuration allows you to run the same artifacts in development, testing and production.
5. Post-mortem analysis: the application writes logs to the standard output, and the cloud environment is responsible for capturing, collecting, and storing them.

It is not my intention to go into detail about the technical details about how to achieve this (you can go to the 12factor web page to see that). But basically it asks to split your application into small chunks that are configured dynamically and independently of each other, called microservices.

Microservices allow for dynamic scaling up. If you can serve ten customers per second with a server, and the configuration can be given to the server, and there is no state — so all copies behave the same — you can serve 50 customers with five servers working in parallel. You just need to know how to create the 5 servers, add the configuration, and make sure that requests reach all the servers evenly.

This opens the door to the last article of this series to talk about Kubernetes, that uses containers to run cloud-native applications on a cloud environment