"What exactly is cloud-native?".

In this blog post, I will try to share my understanding of that confusing terminology using some real life analogies.

So let's begin our journey with a story.

"Once upon a time, applications were first deployed on self hosted servers, then on virtual machines and during the early 2000s, with the birth of cloud, they started to transition gradually toward the cloud environment."

More years later, the cloud native paradigm emerged due to a need for a vendor-agnostic platform, which will leverage the benefits of the cloud, and also because of a shift towards a more declarative approach to building and deploying applications.

"Are you hungry, how about some McDonald?" Just call your nearby McDonald and order your favourite, the Spicy Grand Chicken. Following a declarative approach, you don't have to instruct the cashier how to prepare the patty, at which temperature to fry the fries, or even in what packaging to put the burger. Instead, you only declare what you desire and fill in any required information and expect that system, I.e McDonald, to handle our declared state and deliver our heaven. Very different from the imperative where we have to call out everything. While declarative systems like this existed before cloud-native became a buzzword, it is now fundamental to how we build and design software like, Kubernetes.

Enough of McDonald, else I will find myself ordering more today. Let's use cars specifically what people commonly call the seat belt. You might not think it but the seat belt is an interesting concept explaining about micro-services. Its individual components, the belt, the tongue and the buckle, are all manufactured separately and when installed together properly, makes an invaluable safety tool. Any improvements to the belt don't actually require any changes to the buckle or the tongue. So as long as the "seat belt API" is up, they can come back together and function properly.

Cloud Native applications are very complex beasts, just like modern car, they are an interconnected system of micro-services. That's not taking into account the new electric vehicles (EVs) which are essentially giant computers. Cars are complex distributed systems that respond to the demands of the user and its environment. They are constantly judging dozens of different things; maximizing traction, balancing fuel economy with performance.

Similarly in Kubernetes, when the load on your application increases, the cluster respond with things like the horizontal and vertical pod autoscalers.

Just like car listen to telemetry, your application can scale to right size up or down to balance the load. You can also fine-tune it, you know like flipping on sport mode. Got to go fast vrooommm vroooom! So yes there are a lot of moving parts. And yes, it is more complex. But that gives you a lot of flexbility in customization.

And we cant talk about cars without talking about assembly lines. In the early days of the automotive industry, the need to produce more cars led companies to adopt the assembly line pattern, which each station focus on a single assembly task before passing the in-progress car to another station, quite super effective. As car assembly got faster, new bottlenecks appeared like the time it took for paint to dry. But innovation continues, now if you walk into a modern automaker's factory, you will see less people and more automated machines. People are there, usually for monitoring the automation lines, sounding kind of familiar. Software engineers need to ship software as fast as possible, which led to streamlining process and automation.

In the old days software engineers specialized in core components and deploy them manually. Think like a basic PHP app, and make them run in production by hand. With automation,less people became involved in making them run and more involved in monitoring CI jobs and debugging why build failed. Even now these processes are becoming more automated. Shipping software with Dockerfile and YAML, it bring less worry about things like dependencies or an execution environment. Dependencies do still matter but just as automation became the norm in the automotive industry, automation is a standard in the cloud native world when shipping a cloud native application.

And that's why the cloud-native paradigm emerged.

Next we will see the different components that make up the "car".