*In this episode of *[*Kongcast*](https://konghq.com/kongcast)*Kongcast**, I had the pleasure of speaking with *[*Viktor Farcic*](https://twitter.com/vfarcic)*Viktor Farcic**, developer advocate at *[*Upbound*](https://www.upbound.io)*Upbound**, about why empowering developers to manage the full application lifecycle helps app development teams increase efficiency.*

*Check out the transcript and video from our conversation below, and be sure to *[*subscribe*](https://konghq.com/kongcast)*subscribe** to get email alerts for the latest new episodes.*

**Kaitlyn: **Why are we talking about enabling developers to manage all aspects of what they’re doing?

**Viktor: **I believe that we need to break the vicious cycle of me asking you to do something and then that something goes in a queue until you’re available to do that something. There is data to back it up that self-sufficient teams are always more efficient than teams that depend on each other. Being self-sufficient means you need to write the code of your application, test your application, create the infrastructure, deploy your applications and so forth. Teams should take control of the full lifecycle of their applications from having an idea.

**Kaitlyn: **In the series, we’re talking about how the different problems and topics we’re chatting about relate to common connectivity challenges that teams face. Can you give us a little overview of how that relates to really what you’re doing with extending the Kubernetes API?

**Viktor: **It's actually a combination of Kubernetes API and scheduler. Or, to be more precise, it’s the whole idea that when we want to do something, we should propagate information about what we want to do to some API and let the scheduler manage or figure out what needs to be done. It’s very similar to the operating model that we have in Kubernetes. We do not necessarily say, “Hey, run this application for me.” Instead, we say, “Hey, I have this application, and I would like it to run successfully inside of a cluster.”

### ***Whether that means that you should scale up or scale down, running it in this node or that node is not our job. We are no longer imperative in that sense. We are more defining the desired state. ***

And when we translate that to infrastructure, we get something similar. We are defining the state of what we want to do instead of executing commands that will create something, destroy something or scale something.

It’s a conceptually very different approach between being imperative and being declarative, and more importantly than that, letting some other process somewhere - in this case, scheduler - make sure that those desired states are fulfilled and continue to be fulfilled.

**Kaitlyn: **I’m going to use Kubernetes as an example here. Kubernetes itself can be complex, and not everyone at a company will be a Kubernetes expert. Can you talk a little bit about how the people at the company who are the Kubernetes experts can enable those developers or folks who maybe aren’t to manage that without having to submit a ticket for every request?

**Viktor: **Yes. So it’s all about creating services that others can consume instead of fulfilling requests from others. If you take, let’s say, AWS, Google Cloud or Azure as an example, they’re doing precisely that. They're considered almost like a team that provides services to people in a company. And they do not provide those services by you saying, “Hey AWS, can you create a node or server for me?" Instead, they create a service that we can consume. And those services are much easier to use than if you would try to figure out all that by yourself. Even people deep into infrastructure often do not understand how hypervisors work because that is simplified.

Now, if we move towards developers, the job of experts, let’s say, those experts can be security experts, networking experts, infrastructure experts and so forth.

### ***The job of those experts is not to do stuff for others but to create a service that is consumable by other teams, with the trust and enough details to cover the needs of those teams. ***

If you say, “I'll allow the developer to create a Kubernetes cluster." That developer doesn’t care about subnets and probably doesn't even know what subnets or VPCs are. That developer cares about whether or not they need a big cluster or small cluster or to run in the U.S. or Europe. Some relatively basic questions, which are not necessarily basic for that developer but basic from the perspective of a person who spends all his life every single day dealing with infrastructure.

So we want to enable developers by giving them services with just the right level of abstraction. Then those developers have the freedom to do what they want without going completely crazy. They don't have to spend a year figuring out how that something works because we don’t have that amount of time.

**Kaitlyn: **One of the things we’ve been talking a lot about at Kong is that it’s not a great experience for a development team or an ops team when someone makes a technology decision without the team having any say over it. Then, the team has to manage it or use it. I’m really curious, how does this influence how developers and ops teams can pick technology?

**Viktor: **It’s a bit complicated, right? Because you want developers to pick the technology because you want them to be self-sufficient. They cannot be self-sufficient if they can't take control of their life, situation or project without making those decisions.

But on the other hand, they're not equipped to make those decisions very often. Like if you ask a developer, “Hey, should you run it in Zone A or Zone B?” They don't usually know and cannot make those decisions, but they should still have the right to make those decisions if they do know.

### ***We should have different levels of abstraction, and then the developers can choose which layer of or level of abstraction suits them. ***

If I just want a cluster, I don’t care where it runs, how big it is, so on and so forth. You want to go deeper? Excellent. There always needs to be a choice. I'm a pro-choice person. If you want to create a cluster from scratch by yourself, great, do it because it’s your application. You’re responsible for it. You will suffer the consequences or reap the benefits.

If you want to use the service I prepared to simplify things, that's even better. Because then you benefit from my work. As long as it is clear that I am not responsible for your decisions. Using my service, creating your own or anything in between does not remove responsibility from the team consuming the product.

**Kaitlyn: **When you’re creating these services, how are you defining these options? How do you enforce them? How do you make sure that you’re putting all this power in the hands of the teams? How do you ensure that nothing goes awry and we’re not creating more work for the team at the end of the day, providing those services?

**Viktor: **It’s complicated, right? You employ many policies and say you can do this, you cannot do that, and you combine those policies with some kind of abstractions.

So, like what I mentioned before, and in our case, we call it composite that combines those 57 different types of resources into something very simple for you to consume. And I’m going to create policies in parallel with that that will prevent you from going crazy. So let’s say if I have an abstraction or composite that says, “Hey, pick how many nodes you want in your cluster,” I would have a policy that says it cannot go above six. If you create it and it goes above six, then you will get a warning.

I have a young daughter, and sometimes we go bowling. I do not throw the ball for her, right? That completely ruins the fun element, but I lift the rails so she cannot go outside the lane. So it’s completely OK. She can do anything she wants with the ball. She can miss all the pins or have a strike, but she cannot go outside of the lane because I lifted the rails for her, right? So it’s a choice with the guardrails in a way.

**Kaitlyn: **Yeah, I love that analogy.

## **Demo: Empowering Developers With Crossplane**

In every Kongcast episode, we ask our guests to show a cool tech project they've worked on lately. Check it out in the below video:

## **Thanks for Joining Us!**

I hope you'll join us again on November 1 for our next Kongcast episode with Ben Greenberg from Orbit.Love called "Building With the Coding Language You 💗."

Until then, be sure to [subscribe to Kongcast](https://konghq.com/kongcast)subscribe to Kongcast to get episodes sent to your inbox (and a chance to win cool SWAG)!