More than just a developer – Kubernetes deployment challenges and choosing the tools to address them

Blog

More than 'just a developer': Kubernetes deployment challenges and choosing the tools to address them

November 28, 2019 - by admin | appeared on faun

The journey from app2k8s

In the containerized world, a developer needs to be more than ‘just a developer’. In order for the cloud-native application to run smoothly and efficiently, DevOps needs to function right — which often means that developers will need to do more than just programming. They need to understand the infra and make the code work on that infra — for instance, in addition to code-level dependencies, they now need to worry about environment-level and system-level dependencies too as part of their day job.

The uphill task of upskilling

Developers — especially seasoned ones — often find this the most challenging part of adopting Kubernetes. A good developer before Kubernetes needed to know application-level coding and how to package them. But a developer today needs to understand k8s architecture, ReplicaSet, ConfigMaps; and be able to build a container image, do rolling upgrades, monitor the application in k8s, etc. Adopting Kubernetes necessitates a developer to climb a rather steep learning curve.

Even when developers are happy to learn, they are under tremendous pressure to do so quicker — so as to meet the ever-shortening deployment cycles. Add the complexities of k8s to the mix and it becomes a significant investment of time and effort, all while chasing a release deadline.

How to YAML?

Across environments and resources, accounting for storage classes, secrets, deployments, ingress, network policies, admission controls, and things, a medium-sized microservices-based app would need thousands of lines of k8s manifest files to be written manually by the developer. For every new deployment, there might be a need to edit /modify /update these files.

As the application and deployment cycles grow, it becomes proportionately complex to manage these YAML files and monitor them in motion.

Adapting to the new development culture

Containerization isn’t a minor upgrade on traditional ways of application delivery; it is a new way of doing things. So, along with it comes the uncertainty of how the new way works, how it maps to the old way, and how to transition seamlessly. For example, the developer needs to get into the habit of building on the platform, instead of building locally. Like I said earlier, developers will have to take responsibility not just for their code, but for the code to run as expected in production — which involves infra elements.

On the other hand, even minor changes to a configuration can have ripple effects across containers. Like, if you absent-mindedly push an auto-upgrade k8s version (as in your dev config) to production, it can possibly impact several nodes. As a result, ops teams tend to be wary of giving developers unfettered access to the cluster. This often ends up being a pointless tug-of-war.

Pandora’s box of tools

And then there is the story of Pandora’s box of tools. The rapid evolution of containerization technologies has brought a wide range of tools to market. Image-writing tools, portability tools, debug servers, environment emulation tools, automation tools, replication tools — there are hundreds of tools in the market. Ironically, this chokes developers before they even start!

Even with tools, developers find themselves ill-equipped. For example, developer CI/CD tools such as Jenkins, Travis CI, Bamboo, etc. aren’t integrated with the container runtime environment, forcing developers to write scripts to make them work together.

For developers who are just getting acquainted with the world of containerization and Kubernetes, this sprawling set of tools can be overwhelming, preventing them from even beginning to try. And for rookie developers, distinguishing a Kubernetes feature from a community project, contributed by another developer might also be difficult. Confusing an immature community project to a battle-tested k8s feature can have demotivating consequences.

But, Kubernetes, which might look like a behemoth of new things to an uninitiated developer, is, in fact, a gold mine of opportunity in increasing developer efficiency — 66% of those surveyed by Forrester reported some increased levels of efficiency. As I see container adoption among enterprises grow, I believe k8s will be a key skill for the future that developers can’t ignore. The balance is in knowing what needs to be learned and what needs to be automated.

Understanding the foundation — such as the fundamentals of containerization, the philosophy, and structure of Kubernetes, basic concepts that shape application delivery — will make you, dear developer, a force to be reckoned with.

For everything else, choose a tool.

  • Find a tool that is aimed at the developer — especially to minimize the learning curve.
  • Find one that can integrate with your existing CI/CD pipeline, which will keep you in a familiar environment, even as your delivery process changes.
  • Find something that can automate non-core developer activities like k8s manifest or Docker image generation, and let you focus on writing your code.
  • Look for one that enables self-service; you need an environment where you can learn without having to depend on your IT teams or raise IT tickets.

Ideally, look for one that can do all this.