<p>I'm working with microservice architecture using Azure AKS with Istio.</p>
<p>I configure all, and developers work with microservices to create the web platform, apis, etc.</p>
<p>But with this, I have a doubt. There is much yaml to configure for Istio and Kubernetes, e.g. <code>Ingress</code>, <code>VirtualService</code>, <code>Gateway</code> etc.</p>
<p>Is this configuration, part of the developer responsibility? should they create and configure this? or is these configuration files part of the responsibility for the DevOps team? so that developers only is responsible for creating nodejs project, and the DevOps team configure the nodejs project configuration to execute in k8s architecture?</p>

<p>This is a good but difficult question.</p>
<p>Kubernetes has changed what the DevOps role means, as described in the article <a href="https://thenewstack.io/devops-before-and-after-kubernetes/" rel="nofollow noreferrer">DevOps Before and After Kubernetes</a>.</p>
<p>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:</p>
<blockquote>
<p>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.</p>
</blockquote>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>The presentation <a href="https://www.infoq.com/presentations/kubernetes-adoption-foundation/" rel="nofollow noreferrer">Kubernetes is Not Your Platform, It's Just the Foundation</a> is very interesting about creating abstractions on-top of Kubernetes to be an effective platform for app developers.</p>
<p>In an organization with <em>little</em> 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 <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/" rel="nofollow noreferrer">Kubernetes CRD</a> e.g. <code>kind: Application</code> and a controller that configure the Istio <code>VirtualService</code> and <code>Deployment</code> in an <strong>opinionated</strong> way to reduce the <em>cognitive load</em> for the Developers - so they have very few Yaml-fields to manage. An example of such solution is <a href="https://doc.nais.io/nais-application/nais.yaml/min-example" rel="nofollow noreferrer">NAV application Yaml</a> - they even have fields for provisioning PostgreSQL databases or Redis caches.</p>
