Should application developers learn Kubernetes? Let’s ask an even deeper question; should application developers even be aware of Kubernetes in their infrastructure?
I frequently hear this question being asked by DevOps, Platform Engineering, and Development teams. Of course, this is a discussion that brings very different views from different people and can result in a very long debate.
Kubernetes, without a doubt, provides far more functionality than the average developer needs. While Kubernetes is robust and provides dozens of types of objects (around 50 the last time I checked), developers don’t care how many replicas of their service are running, what roles it has, or if it’s running via StatefulSets; all they care about is getting an HTTPS endpoint that they can use to deliver their product to their users.
Alert
I know some people may be thinking, “...but Developers should learn it because everyone should learn Kubernetes. Kubernetes is the best tool in the world, and we love it within the DevOps team”. I know, I know, but a developer’s day-to-day responsibilities require them to focus and deliver other things. I’m not saying that there is no value for developers on learning Kubernetes. Still, they have a lot to deliver, and having something that allows them to do it faster and focus on what matters to them and what matters to the organization is always a win. In the end, most of us can learn how to make a pizza, but we just order it, so we can focus on what matters to us, instead of being stuck in the kitchen for hours buying ingredients, putting them together, baking, and so on
When it comes to Kubernetes, even small changes can have significant ripple effects. As a result, even if developers are experienced with Kubernetes, operators may be reluctant to give them access to a cluster.
To try and mitigate that concern, we’ve seen organizations spend anywhere between 1 and 2 years trying to build an intermediary layer between the application and Kubernetes to:
- Allow Platform Engineering and DevOps to maintain control of the cluster.
- Limit and manage the number of clusters available.
- Abstract Kubernetes away from the Developers, so they can simply push code to GitHub, and the rest is taken care of for them.
This may appear unnecessary when only a handful of developers with only a few applications or services are deployed; however, the story quickly changes as an organization’s number of clusters, applications, and services in Kubernetes begin to scale. The development team is generally to first to feel frustrated by the growing complexity, greatly increasing the chance of inexperienced AND experienced developers to become distracted, less productive, and more prone to mistakes. Developers need to deal with infrastructure more these days, so the focus should be on simplifying and not complicating.
Considering this, we decided to build Shipa to do precisely that; grow Kubernetes into a user-friendly application management framework. Shipa’s goal is to allow developers to focus on their application code while empowering DevOps and Platform engineers to better manage and control their clusters and infrastructure.
Shipa makes deployment, management, and controls of applications easy. Shipa does not treat Kubernetes as a first-class citizen; Shipa reserves that title for the applications and the teams that develop and control them. Doing so allows the developer not to worry about ConfigMaps, ingress rules, PVs, PVCs, etc. in his/her day-to-day. Even if DevOps and Platform engineering teams decide tomorrow to move from one Kubernetes cluster to another or across different providers, the way applications are deployed, operated, and controlled will not be impacted.
Software is getting complicated, and business requirements are evolving rapidly. The easier we make it for developers to deploy their applications and for DevOps and Platform Engineering teams to build controls and guardrails around it, the more value they will deliver, faster, and more secure.
Top comments (1)
What about using docker-compose?