Whitney Lee of VMWare's Tanzu* team is a passionate advocate for cloud native technologies and appreciates the value of good developer experience and smooth application delivery.
Katherine Druckman picks her brain about Internal Developer Platforms (IDPs), and how implementation of best practices and clear communication make platform teams and developers happy. The two also explore evaluating products in the immense cloud native landscape, GitOps, and more.
This conversation has been edited and condensed for brevity and clarity.
Katherine Druckman:
What is an Internal Developer Platform, or IDP? How would you describe it to somebody less familiar with that acronym, and what problems does it solve?
Whitney Lee:
“Internal Developer Platform” seems to be the vocabulary that's emerging, but I've also heard just developer platform or development platform or cloud platform. I've heard a lot of different words to describe this concept, but the problem we're solving here is that as we've done this shift left, as with DevOps, more and more infrastructure problems are falling on developers.
Developers are now in charge of creating their own environments, choosing their own tools, and integrating those tools. And that's before they even write the code that provides value to the organization. This isn't very efficient, and developers are doing either one of two things or probably a combination of both. They're relying on experts to give them what they need. For example, they need a cluster and put in a ticket for a cluster and then some days or even weeks later they get what they need to do their job. Or maybe they need something deployed. They will add a ticket that asks, “Will you deploy it for me, please?” And someone else has to go do that. One team relies on another team to get a job done, and that team is stuck until the other team does something.
So that's one thing that happens. That's a problem that an IDP, or an internal developer platform, is solving. Similarly, maybe every different disparate application team is solving the same problem over and over again for themselves, and inefficiently. So, they're choosing what tools, how to integrate those tools, and how to implement the company's security policies. It's redundant work, and working this way has some problems. Besides being inefficient, it's hard to govern. If a developer wants to go from one team to another team, or even bring a new developer in on a certain team, it takes a long time to onboard because you're not just learning the code base, you're learning all the tools and the ways of working. Those are the problems that we're trying to solve. I know you used to be a developer. How does this jive with your own personal experience?
Katherine Druckman:
I have to say I get excited when you start talking about things like onboarding documentation and switching teams. We've all been there. We are in our little happy place and with our local environment that works, and we know how the whole pipeline is put together. Then maybe we switch, and we work on something new, which is cool because we learn new things, but there can be kind of a learning cliff just in walking through new documentation and trying to figure out how all this new stuff works together. Solving that problem is quite beneficial from the developer side. You're really easing some pain there.
Whitney Lee:
What we want is for developers to be able to access what they need to do their jobs in an autonomous and self-service way. And on the flip side, the ops side, what we want is for experts to be able to codify the thing that they are good at. So, we want database experts to be able to have those expert opinions and codify them.
Then a platform team's job is to provide the interface between the experts and the developer who is consuming the stuff that the experts make so that interface might be a custom Application Programming Interface (API) that the platform team can call. Maybe it's a web portal, maybe it's a template, maybe it's ready-to-use tools, but it's the interfaces that the platform team and the platform engineers are concerned with.
The bottom line is platform teams and internal developer platforms exist to make life easier for application teams. An IDP is unique to a specific organization. There are some IDP products that exist out there, and I'm not saying you shouldn't use them, but if you evaluate them for use, you need to be sure that you can incorporate your own organization’s opinions into that because what you're actually making for your developers is unique to your specific organization, unique to the apps that you're building, unique to the governance that you need, and unique to your particular security issues.
Katherine Druckman:
So, there is no one-size-fits-all kind of platform. I imagine key components like role-based access control and configuration management, but can you tell us the main important components of a developer platform?
Whitney Lee:
You need a service. Your developers or application team need something, maybe a database. So, one thing you need is the service that they need, and that should be probably configured by an expert, probably not by the platform team itself. The second thing you need is an interface to that service, and that's where the platform team comes in. And then the third thing you need is to be able to observe what's happening with that service. You need observability to make sure it's working as it should.
You mentioned role-based access control. That's definitely an important thing, but it's kind of like trying to add the locks to the house before you build it. So, in terms of what's important, I'd say the service you're providing, the interface to that service, and being able to see what that service is doing are the three most important things.
Katherine Druckman:
In other words, you're not inserting a solution in search of a problem. It's not about the solution, it's about really mapping out what the problem is and then approaching it from your unique perspective, as we said earlier, since it's not a one-size-fits-all thing.
Whitney Lee:
Yes. And maybe a fourth thing then would be communication. You don't want to build something for your app teams before you've talked to your app teams about what they need. Understanding their pain points, understanding what's slowing them down, and then finding the most important thing or the most high-value thing that you could provide for them.
Maybe it's taking weeks for them to get a cluster and you can build an API for them where they can provision their own cluster in a self-service way.
In that specific example, though, let's talk about how expert knowledge comes into that. The experts can say, “OK, I want the app teams to be able to provision the cluster that has all these opinions, VPC, this security group, this certain network thing.” Developers don't care about that level of detail, and they shouldn't have to, and we don't want them to have to worry about that.
Then from there, the platform team provides a simplified interface where a developer can maybe say they want a cluster, and maybe in that interface you could choose Google, AWS*, or Azure*. Maybe that's a choice, or maybe whether it's a big or a small cluster. You don't even have to necessarily say the number of nodes or how big the nodes are. Maybe that's abstracted away. But you have very simple choices that are related to the developer experience, and that's all the developer sees. Not all that's going on in the background to provision that cluster.
Katherine Druckman:
Thinking back to the various teams I have been a part of. How would you describe an organization or a team that could most benefit from the type of platform building that we're talking about here and when does it also not make sense to approach it this way?
Whitney Lee:
So, the thing about platforms is that they're not directly affecting the bottom line in terms of a company making money. But it will affect the bottom line, and very much in the end, if you can improve your developer experience and make your developers happy. That's going to make your apps be released faster. It's going to give them better governance so they're more consistent. Making your developers happy alone will increase productivity, but in the act of making the platform itself, you don't see the value immediately. That value is really going to translate when you're operating at scale. So when you have a platform team, when you have a lot of application teams that are all able to use the platform, then it's going to be a lot better than if you're a much smaller shop and you already have a lot of people wearing a lot of different hats who might need to be experts in a lot of areas.
For enterprise organizations, it's almost a no-brainer because you also have problems like your legacy apps and your infrastructure that's half over here and half over there, and it's a very custom situation that's kind of built up over all these years of navigating cloud and data centers. So, you need a very custom solution for how to make your application developers have an easier life and make them happy. Therefore you have more of a need for a developer platform as opposed to a smaller company or a company that is just getting started from scratch and can probably use a lot more off-the-shelf things because you're a sweet little baby angel and the world is your oyster.
Katherine Druckman:
There is a hyphenated word that keeps coming up, which is “self-service,” which is very appealing, especially from the perspective of a developer. Developer experience is so important, and the smallest improvements can have such a tremendous impact, like relieving bottlenecks, shortening feedback loops, and all of that stuff. How does a well-oiled developer platform improve developer experience and how much should the developers even be aware of it?
Whitney Lee:
Those are great questions. There's a term floating about. I don't know where it started, but it's called platform as a product and it's this idea that your team should treat that internal development platform as though it's a product that's made for the developers at your company. So, you should research what they need as you would a product, you should have short feedback loops and make sure it's making your “customers” (the developers) happy just like you would treat a product. You probably want a project manager for your platform team to watch what the user experience is like and to look forward to the next problem.
You can't treat a platform as a product if your developers have to use the platform, then it's a monopoly. In my world, that's like the electric company. I only have one choice for an electric company. They don't have to be a good electric company because I have to use them.
I would recommend you don't force your developers to use it. They should be allowed to roll their own if they want to. And if you're in a situation where they're choosing not to use the developer platform, then you have a problem that you need to solve. Is it because we need to create documentation for our internal platform? Is it because they don't know? Is it because it's not serving their needs? Figure it out just like you would a product that’s not selling. Let's figure out what the problem is and make sure that we're making everyone happy so we're getting the maximum benefit from our platform.
So, in terms of improving developer experience, or self-service anyway, the developer is the consumer, the user, and we want to please them and we want to communicate a lot to make sure that they're happy and we're making the best things we can for them. The most high-value things. Then the second question you asked was how much awareness should developers have about what's happening.
Katherine Druckman:
How much do they see behind the curtain? Is it hidden? Is it magic?
Whitney Lee:
I think it’s somewhere in between. We talked about provisioning a cluster. There are a lot of complex decisions that are being made and only exposing certain decisions to the developer. They should have observability around the decisions that are at their own abstraction level. But they don't need to know the security groups and all that stuff or you’re defeating the point. So, they should have enough observability to know how to fix what they can fix at their abstraction level and enough observability to know when there is a more complex situation that they need to be able to send off to the expert or get an expert opinion on.
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.