DevOps and Developer responsibility when using Kubernetes

A developer needs to

1. focus on his business logic.
2. Also know where his code is going to run and under what kind of env.

The 1) is quite obvious here. The 2) is usually not implicit at times and actually I think if the dev think they do not own the runtime configuration then its like throwing the responsibility over the wall.

Lets say for example if the app is going to be exposed by an ingress controller the app-dev needs to ensure

• that app works well with http and https traffic (incase we are doing ssl passthrough).
• all the resource url/paths and the right ports are exposed and registered with the ingress.

The same argument can be extended to other resource types. say Virtual Machines or Deployment specs.

Now if the dev believes these are not their responsibility is not to write these yaml files, they still need to document the contract of what their service needs with another "person" to enable them to write the configs. But aren't the yamls themselves that contract?

The whole point of Kubernetes is to help developers develop applications as fast as possible and not to get into the weeds of how the pods are deployed.

That being said, the developers are responsible for the applications and as mentioned here, should know the environment where their apps will be run. It is up to the devops team to configure ingress, Istio, etc. Also (ideally), they should check the yamls if they were written by the developers. The developer should not worry about how many replica sets need to be there or any other K8s config.

That being said, it is always a good practice to standardize this process (who owns what) beforehand.

This is a good but difficult question.

Kubernetes has changed what the DevOps role means, as described in the article DevOps Before and After Kubernetes.

As you say, there are much Yaml to handle with Kubernetes and Istio. Now, DevOps teams need to help to automate the process of delivering apps to Kubernetes:

For an app team, containerizing a typical medium-sized, microservices-based app would require several thousands of lines of K8s manifest files to be written and managed. Each new deployment would need a rebuild of container images and potential modifications of several manifest files. Clearly, DevOps in today’s world will be different from DevOps in the pre-Kubernetes era.

These new-world DevOps teams may do well with an automation process for delivery to Kubernetes so that efficiency gains and economic benefits can be realized sooner while also maintaining reliability and speed. Such automation along with a standardized process will further enable a clean hand-off interface between the IT teams managing the infrastructure and the app teams delivering apps to K8s. For enterprises pursuing agility and frictionless delivery at scale, finding the shortest path to Kubernetes will be at the heart of DevOps in times to come.

This can be done in different ways. E.g. building abstractions or setting up CI/CD automation. In the end, how you do this, depend on how much your organization invest in this automation.

The presentation Kubernetes is Not Your Platform, It's Just the Foundation is very interesting about creating abstractions on-top of Kubernetes to be an effective platform for app developers.

In an organization with little automation, the developers will get a Namespace and do all the Yaml themself. But in an organization with high degree of automation and investment in the Kubernetes plattform, a platform team typically creata an Kubernetes CRD e.g. kind: Application and a controller that configure the Istio VirtualService and Deployment in an opinionated way to reduce the cognitive load for the Developers - so they have very few Yaml-fields to manage. An example of such solution is NAV application Yaml - they even have fields for provisioning PostgreSQL databases or Redis caches.