Declarative vs. imperative approach for k8s deployments


Delegating with code: declarative vs. imperative approach for k8s deployments

January 29, 2020 - by admin | appeared on better programming

The biggest difference between the declarative and imperative approaches to programming is the answer to the question: "Who does it serve?"

declarative vs imperative k8s

The biggest difference between the imperative vs declarative kubernetes approaches to programming is the answer to the question: "Who does it serve?"

The imperative approach, which outlines how a machine needs to do something, serves the machine. It aligns itself with the operational model of the machine and tells it how it needs to do something.

For instance, let’s say you are writing a program to pick out all the vowels from this sentence, calculating the sum of elements in an array, you’d write this:

int sum=Integer.MIN_VALUE;
for(int i=0;i<arr.length;i++) {
    sum += arr[i];

A declarative approach, which declares what you want, serves you, the developer. You tell the machine what you need and the rest gets done.

In this, you tell the computer the logic of computation, without detailing the control flow, or low-level constructs like loops, if-statements, assignments, and the like. Like so:

    int sum = IntStream.of(arr).sum();

In essence, it's a question of the "how" vs. "what" paradigm. But this doesn't mean one is, in any way, better than the other.

Declarative programming is easier to understand in that you can read the code and make sense of it. It is succinct, reusable, and enables referential transparency.

But declarative can be slower, taking longer for the process to be finished. In mission-critical, real-time applications like oil rigs' monitoring or radar processing, this can be too late to be useful.

The imperative approach, on the other hand, gives you more control. But, it is not very reusable, given that it’ll be closely tied to the context it is written for.

As a result, it's difficult to scale with imperative code. Depending on how focussed and cued-in the programmer was, this approach is also prone to errors.

Based on the need, programming language, and the comfort-levels of the developer, they might choose one or another to do their job. There is only one way to write your application — your way.

But deployment is a completely different ballgame. Deployment to Kubernetes, more so.

Declarative Approach to Deployment Automation

In the containerized world, a developer needs to be more than just a developer. In addition to programming, they need to understand the infrastructure their code is going to run on, and make it run efficiently.

Deploying to Kubernetes forces developers to climb a steep learning curve, up the complex environment that it is. And this is not the kind of learning developers seek.

A potential solution is a deployment automation tool using an app-centric model that lets you declare your requirements in your own lingo, while it generates the necessary manifests for you.

Instead of forcing you to write for the operational models of K8s, this tool must adapt to the developers’ mental model and work with that.

Sample Service Deployment to Kubernetes

Here's everything you need to deploy a simple service to K8s, with a declarative approach, using an automation tool.

Give your service a name

It'll act as the DNS name for service discovery and communication with other services.

Point it to service images

  • Pull from the image registry.
  • Generate and add images from source/binaries.
  • Use existing Docker images, if any.

Set up other top-level directives

Ports, volumes, environment properties, secrets, etc.

Deploy to Kubernetes

Deploy your spec — specify the path, K8s namespace, identifier for your app name.

The tool will then automatically create your Kubernetes manifests, storage classes, daemon sets, replica sets, stateful-sets, PVCs, config-maps, liveness-probes, NetworkPolicy, etc.

This way, you’ll just tell the tool what you need, and it takes care of deployment, saving you a significant amount of time and energy.

This is what we aim to do with our open-source project, HyScale. We see that development teams need app-centric Kubernetes abstraction and automation for frictionless handoff between dev and ops.

With a specific focus on user experience, we built a tool that requires minimal effort from the developer, while doing all the heavy lifting under the hood and made it available for development teams.

Try HyScale