Balancing Developer Autonomy with Platform Governance

Bart Farrell: Who are you, what's your role, and where do you work?

Zain Malik: I'm Zain Malik. I'm a principal software engineer at ExoStellar, and I'm working on AI/ML workloads optimization on top of Kubernetes clusters.

Bart Farrell: Now, what are three emerging Kubernetes tools that you are keeping an eye on?

Zain Malik: I'm really keeping an eye on the DRA, all the consumer device capacity that how the industry is going towards, and all the, different knobs that are being enabled by the limitation of the device plug-ins. That's what I'm working and keeping an eye on.

Bart Farrell: Our podcast guest, Ben Poland, thinks, "For a platform team, you want to empower anyone to make the changes they need rather than centralizing everything." How do you balance self-service capabilities with governance and platform engineering?

Zain Malik: self-service capabilities without a check and control is how you get outages at 3:00 AM in the morning. I think that empowering a centralized platform is related to the maturity of the platform, where we can offer a more standard interfaces to the users. Because we do have a lot of interfaces already built in, which users have no access at the kernel layer or the node layers and the DOS systems. But as they mature, there is standard way to access them and use them. So I believe in a central strong platform can actually increase the reliability of the SRE and help them achieve a better results.

Bart Farrell: Now, another guest of ours, Calin, said, "There's a fine line between restricti- restricting people and empowering them. When you build a central platform, you are codifying the view of one person or group." How do you balance standardization with team autonomy in your organization?

Zain Malik: In my opinion, the the APIs that are closer to the users, they should have more access and autonomy in doing that. Those are talking about the pod specs, deployment, high-level APIs. But lower-level things, we cannot have users write device plug-ins or scheduling plug-ins and implement that. That would cause a lot of different issues, where one team is implementing their own topology over scheduling compared to another team who want to build their own. So lower-level specs should be written by the centralized team, and they should codify the opinion of that, because we're all running in Kubernetes, open-ended platform itself. But everything that is close to the users, I think that there we should give them autonomy and give them, ability to write their own specs independent and consult the Kubernetes documentation for that.

Bart Farrell: Kubernetes turned 10 years old last year. What should we expect in the next 10 years to come?

Zain Malik: I just want it to actually disappear, where we don't have to even know about that we are running everything on Kubernetes, and become so automated and self-reliant- ... that we move to the next layer where we can everyone reliably build applications and stop thinking about Kubernetes itself.

Bart Farrell: What's next for you?

Zain Malik: I'm working on the GPU optimizations, fractionalization, all the bin packing related to that. Currently, we are living in the AI/ML workloads, hype, in which there's, there are a lot of teams that need help with that. And I find this space very interesting, and that's where I'm helping ExoStellar and we are helping other customers also to achieve that.

Bart Farrell: And how can people get in touch with you?

Zain Malik: You can reach me out on LinkedIn, Zain Malik, ExoStellar, I'm working there, or reach me out to any on the socials. It should be pretty easy to find or reach through ExoStellar also, I will be here.