We interview Platform Summit speaker Viktor Farcic on why API-first matters for platform engineering.
Although the API community may be obsessed with API-first, this idea hasn’t permeated throughout the rest of the software development sphere. Take platform engineering, for instance. Many internal developer platforms (IDPs) are built UI-first, without much thought as to how the backend is developed or accessed by engineers.
At Platform Summit 2025, Viktor Farcic will explain why internal developer platforms should be dumb.
In the world of platformform engineering, a lack of programmable developer interfaces could stunt areas like supporting multiple clients simultaneously, or providing universal policies regardless of the endpoint or UI.
At The Platform Summit 2025, we’re thrilled to feature Viktor Farcic, developer advocate at Upbound and host of the AI & DevOps Toolkit YouTube channel. At the event, Farcic will be presenting Developer Platform Consoles Should Be Dumb.
Ahead of the Platform Summit, we caught up with Viktor to learn more about his upcoming talk and thinking on latest trends. We drilled deep into why platforms need APIs, why MCP servers shouldn’t be one-to-one reflections of APIs, what he’s looking forward to in Stockholm this year, and beyond.
Interview with Viktor Farcic
For an internal developer platform, what are the possible negative side effects of not having an API, and how does that limit platform engineering?
I can’t imagine somebody not wanting to have an API. It’s been twenty years since AWS was born on the idea that everybody, humans and processes, talk to each other through APIs. And we are so used to APIs. Anybody using AWS, Google, Azure, and almost anything else is using it with an API.
Now, where things get confusing is that quite a few people don’t understand that that’s what’s happening. They have Terraform, or use AWS Console, so they think they’re not using an API. But what’s really behind all that is always an API. Like all those services that we love and use, they’re API-first. That’s the first interface. And then everything else is a cherry on top of that.
And if you dive into building your own platform, which is what many companies are doing right now, they’re building some internal developer platform and so on and so forth. Why wouldn’t you want to use the architecture and design that has already been proven over and over again? So I see API-first as a critical part of creating a developer platform.
In the context of internal developer platforms that companies are building themselves, why do you think some aren’t going that extra step and are just using a GUI kind of console?
Oh, there can be many reasons. It depends from one company to another. One sinister way to explain it is that, perhaps, people involved in building those platforms don’t yet understand some of the software engineering principles.
Let’s say that you’re building an application (ignore developer platform for a second) and you start with the UI first. Well, what is that UI going to do? I don’t know. What is it going to talk to? I don’t know. Is there a backend? I don’t know. Is there an API? I don’t know. But I’m going to bake everything in that UI. There is hardly any engineer who would make such a decision.
If you would start with the backend, that backend would do some business logic, and it would expose that logic to the API, and then you would build a user interface in the form of, say, a web page that would consume that API. There is hardly any argument against that among developers.
Yet somehow, if you move into platform engineering, it seems to have never reached such a wider acceptance. You start with the Backstage as a frontend, let’s say. Then you start putting logic into Backstage, what it does, how it does it, and you end up creating a complex mashup of everything inside of that front end, instead of making it very, very simple.
If you go the API route, you provide information that the API asks you for, you get some output, and you put it on a screen. That’s how every mature web UI is working. I can’t explain why we don’t do that as often as we should in platform engineering.
Last year, you gave a talk at KubeCon in which you discovered that even many of the vendor-supplied internal developer platforms are lacking good APIs. Is that still the case?
I think that we are getting there. We are getting to the point where Kubernetes is recognized as a sort of orchestrator of everything. It’s not only, ‘Hey, I can run my containers in a cluster.’ It’s much more than that. It’s very normal and natural to extend a Kubernetes cluster with third-party applications like Argo CD, Flux, or whatever you’re using.
Now we’re getting into a stage where we’re realizing the potential of that, extending it with our own. And that’s very beneficial because Kubernetes gives us all the building blocks to create those APIs I was talking about before. You just enter some YAML, and you have a new API endpoint. You need a bit more work to define what will happen when API requests get into the cluster, what would be controllers, but we are getting there.
I’m deeply involved with Crossplane, which is one of the projects in that area, and it’s gotten quite a big adoption. But it’s definitely not the only one. If you look at Cluster API, it’s widely adopted for managing Kubernetes based on the same principles — create your APIs, controllers that will do whatever needs to be done. There is also KubeVela and Terragrunt, which emerged recently.
Could you give an example of a specific situation you’ve encountered in which an IDP lacked extensibility, and what kind of roadblocks does it present?
The roadblocks for not starting with API usually come later. You typically begin doing something mishmash, using Terraform or Ansible, or creating scripts to solve problems. That tends to work at the very beginning, until you start seeing the limitations.
Now I have this thing that works like this, but people would like to have it in some different format, such as a web user interface. Or they would like to use it from their IDE, and so forth. Once you start realizing that there are many potential user interfaces for that something that you build, then you usually come back to, okay, it should be an API.
You should have this one thing that multiple entities can talk to. Because if you’re limited to a single tool, there are many other reasons why you might not want to use those tools. From the API perspective, if you’re always going to be using that shell script that you created, it’s probably fine. But if you’re building a web app, and then tomorrow you need a mobile app, you realize you should not duplicate everything. I should put that back in the API so that I can have those two interfaces.
For an internal platform, one example could be policies. You’re going to create something that does whatever that does, and you will want to have policies that will guide people towards doing the right thing, such as you cannot use this region, you need to use that region.
That’s another thing that will lead you to that API-first design, because you have two options. You can put those policies in your Jenkins. Or you can say, I’m going to put those policies behind that API and say, I don’t care how you get here. And that’s the important part of APIs: Those policies will evaluate every single request every time, regardless of the endpoint or UI.
Let’s get to your Platform Summit talk, Developer Platform Consoles Should Be Dumb. What will you be covering this year, without giving away too many details? What key takeaways are you hoping the audience will walk away with?
The premise of the talk is that, whichever interface you’re building for the platform, to begin with, it’s only an interface. It’s not the platform itself. And that those interfaces should not contain logic. They should be very dumb.
If you do it from the right direction and start with backends, we call them controllers and APIs, then everything else falls into place with almost no effort. Because your web interface, if that’s what you choose to use, can be really dumb.
You can create those interfaces in a way that they don’t contain any logic, and they’re universal, and you don’t have to really do any additional work later on when you update something or create a new service.
Like, hey, yesterday, we didn’t have the ability to serve databases through our platform. Well, I did a database as a service. And that console, that interface, just picks it up. Because it follows exactly the same logic, and detects what it needs to detect, from the API.
And, let’s let users choose what they want from the available services and fill in whatever needs to be filled in. And just click whichever button there is to be clicked. So, it makes sense to decouple things like that.
You’re somewhat new to the Nordic APIs community, but are there any insights or knowledge you’re hoping to gain as an attendee?
I’m a hallway track type of person. To be honest, this is probably awful, but I rarely go to other people’s talks, which is probably a horrible thing to do and say, but I really enjoy the hallway track. Whenever I go to events, to me, that’s the most valuable part of the event. I can meet people that I know or have never met before. We can just talk about stuff and figure something out.
Since the last time we connected, there wasn’t as much of this AI agent craze. Do you think the rise of agents or automation changes how we’re thinking about platforms and API development?
I think it changes everything. Some things have completely changed already. Some things will be changed very soon. I think that the state we were in with AI, until this year, was bad. Demos were impressive, but tools actually made you do more work, not less.
But this year, especially with the emergence of agents and MCPs, I think that now we’re on the other side of that equation. We can see patterns emerging, and we can see how they’re helpful. Nobody can truly say what will happen next year, but it’s evident that this will be a major shift. This will probably be equivalent to the dot-com boom and then multiplied by a lot.
In the past, things were moving fast but much slower than today. You easily had five years to accept, acknowledge, and adopt Kubernetes. You had ten or so years to jump into AWS when it emerged before you rendered yourself obsolete. But now we’re talking about much shorter periods.
There are people who are still reluctant, maybe defensive. And there are good reasons for that because not everything is perfect. But I’m also afraid that the time it takes to make something obsolete is going to be much shorter than it was before. And that also includes human expertise.
You mentioned Model Context Protocol (MCP). Is that something you’re actively following? In the API industry, there is much excitement about MCP, but success stories are few. It still seems like it’s still in its very early days. What’s your take?
I mean, the vast majority of MCP servers are a waste of time. And that’s normal because the MCP spec is only months old. People jump into it, and they start building for MCP without really thinking it through or understanding what it should be.
The vast majority of MCPs that you can see now are reflections of APIs. I think that’s a complete waste of time. This might be offensive, but let’s take Kubernetes. As an example, Kubernetes is an API-driven platform of sorts. Now let’s say you have a Kubernetes MCP server that basically allows you to get resources, to describe resources, and to see the logs and so on and so forth. They’re basically reflections of the Kubernetes API, just as kubectl is a reflection of the Kubernetes API.
Now, does an AI agent really need that MCP server? Absolutely not. It’s perfectly capable of using kubectl directly. And even if there weren’t a kubectl CLI, it’s perfectly capable of talking to the API as is. And it’s not hard for an AI backed by an agent to execute the URL commands to go to some API, and effectively do the same thing that that MCP server is doing.
What we need is MCPs that are actually providing additional value around user intents. Instead of having a Kubernetes MCP server that is a reflection of its API, have a Kubernetes MCP that will have certain logic or workflow or this or that, that will help you combine resources to get an application up and running. So, something beyond just a one-to-one reflection of an API.
Instead of a one-to-one reflection of an API, could MCP servers also describe common workflows? Essentially connecting the output of one API call to the input of another call?
Just stick with my example. Help me deploy an application. Can I do that with an agent alone with kubectl or whatever? Of course I can. But the agent does not know that out of the box, backed by a model, right?
If there is an MCP that has a tool called deploy_application, and has some additional logic beyond a reflection of the API, then that’s helpful. That helps the agent use a tool that will do something. And that’s the key: MCPs enable agents to use tools. The differentiation is that it should be tools that are not already known and used by agents anyway.
Thinking beyond platform engineering, what about commercial APIs, open data APIs, or APIs for public software as a service? Are MCP servers more valid in that context because they are providing that external connectivity?
They definitely are. But, again, they shouldn’t be reflecting those APIs because those APIs are complex. That kind of agent is likely to make mistakes. Let’s say that agent doesn’t have the model and actually doesn’t know the ins and outs of that API.
Now, if it’s going to do the mental calculations that you usually do to figure out, oh, so I need to call this endpoint and then chain that to that endpoint and then do those two together and do all that process that is usually already wrapped in your applications that you use, then it’s not going to be very successful.
But if you have clear intents, it’ll be successful. Let’s say it’s a banking API with a function like withdraw_funds. Not ‘call 57 of those endpoints and pass the values between each other, and then somehow maybe your funds will be withdrawn.’
Think of MCP servers as helpful tools for agents, just as UIs and desktop applications are helpful tools to you. And in both cases, it’s not a one-to-one reflection of an API. If you, as a person, go to the Amazon website, I can guarantee that what you see there is not APIs exactly as they are constructed. It’s more simplified and task-oriented.
