Eliminate Friction in App Delivery to Kubernetes

The last two decades have seen a sea change in the way software is written and delivered. Waterfall to iterative to agile, native to hybrid to responsive interfaces, monoliths to microservices, installed to pay-as-you-go SaaS, data centers to private and hybrid clouds, and virtual machines to containers.  As the market constantly evolves, enterprises are facing a ton of choices with increasing complexity.

When microservices came along to break up huge monoliths into manageable parts, it meant teams still had to manage those individual parts, each with their own life cycle. Containers (you know where that metaphor came from) solved some of that complexity by packaging each part and all dependent information into self-contained, repeatable units. This is where our story begins.

With the advent of containers as an economical portable solution, software began to be packaged along with its stack dependencies as an immutable “container image.” Once you have an image, you can launch any number of identical containers. This guarantees outcomes that are predictable and consistent overcoming the familiar software challenge — the “works for me” syndrome.

Microservices and containers are typically hand in glove. With container images being “immutable,” any change to the service code or its dependencies entails building a new image. This means refreshing images built from the new code and replacing the relevant containers. In an enterprise with hundreds of apps, each containing multiple services, this means hundreds of new images & container replacements in a cycle of change. This demands a massive collaborative effort among developers and IT/DevOps. The situation is in desperate need for automation and process standardization.

Automation would help enterprises auto-containerize hundreds of services without having to write manual scripts, custom code or lots of configuration files. It would also lead to process standardization in order to prevent a proliferation of custom methodologies across teams and to reduce dependence on specific people for know-how.

With Kubernetes (k8s) emerging as the de facto container orchestration platform for hosting containers, a good process and automation would also facilitate a clean hand-off interface between those managing the k8s cluster/infrastructure and the app teams who are doing app delivery to the cluster.

Only then can app teams develop, test & deliver apps with the least amount of friction enabling rapid updates of enterprise applications while also helping the enterprise realize the benefits of containers and k8s.

Container DevOps is becoming all about ensuring Frictionless delivery. Here are a few overarching goals for this to become a reality. Foremost is speed. If a dev team’s need for a new test environment involves putting a ticket and waiting a day or two, that’s friction. The lack of a well-defined hand-off interface between application & IT teams, for information to be shared and collated in an error-free way, also leads to friction. If making changes to a couple of services and deploying them to staging or production environment involves manual intervention and takes a couple of hours or a day, making it an event, then that’s friction too.

An enterprise’s best bet at eliminating friction is to adopt an automated self-service experience that enables app development teams to input service-related information and trigger delivery on demand. Such a delivery platform must combine pieces of information from the various owners in a reliable way.

At the same time, black box automation may not win the confidence of app development teams who want to track changes made to service configurations and dependencies, visualize & identify configuration changes between different environments of an app. Most teams are already using CI scripting mechanisms and tools. It would be ideal if the automation leverages as many existing investments around CI as possible with minimal disruption to the roles and workflows in the organization.

Enterprises today would, therefore, be well served by moving away from a script-based & people dependent approach to delivery, and towards a platform-based approach.