Enabling developers to collaborate better, ship faster, work more independently, and reduce cognitive load, internal developer platforms (IDP) have seen a meteoric rise in popularity in the last year or so.
A staggering 85% of developers said they will use a developer platform in 2024.

That’s why we have asked Michael Coté of VMWare to explain what is an internal developer platform at three levels of experience – to a junior developer, a senior developer, and a CTO.

An IDP, Coté explains, is a set of tools and processes that make software development easier and faster for engineers by taking care of the underlying infrastructure. But simplified – it’s thinking about your infrastructure as a product.

While the internal developer platform is a developer tool and a tech platform, at a more senior level, the real question is how to drive adoption and communicate to developers the value the platform provides.

This video is a part of ShiftMag’s new video series, Engineer Explains.

We’ve asked experienced engineers to share how they would explain some basic and some less basic tech terminology to different job tech job titles or at three levels of experience – from junior developer to CTO.

More:
How would you explain APIs or software architecture at three levels of experience?

The post Engineer Explains: What junior/senior developers and CTOs need to know about internal developer platforms appeared first on ShiftMag.

Last year, I took the initiative to build a new internal developer portal with several other great engineers. We were all very enthusiastic, but there was one fundamental thing missing. Altogether, we had 0 to no experience with TypeScript and MERN stack, on top of which Spotify’s Backstage platform was built. 

All of us were passionate backend engineers with a few years of experience working in the infrastructure department. Our tech stack consisted of more traditional technologies like Java’s Spring and SQL databases. Naturally, the biggest concern was how we would handle technologies we weren’t familiar with and build user-friendly and intuitive interfaces. After all, we were backend developers who preferred writing command-line instructions, deprived of a sense of good user experience. 

 On the other hand, we had an ace up our sleeves – a deep understanding of how our platform works. 

 Contrary to popular belief, we pulled off deploying Backstage in our platform and integrating it with the existing tools without any major challenges. The biggest issue was (and still is) its adoption. 

So, where is the catch?

Backstage has its set of core features, but it is also possible to extend it with your own or 3rd party plugins.  Core features or 3rd party plugins usually work without much hassle – your custom configuration gets injected in premade modules through YAML files.  

You can build interactive forms with multiple steps without writing any React code. This core feature is called Software Templates. We wanted to facilitate the bootstrapping of the Redis cluster. We had the define form which accepts configuration and actions that will be invoked on submission. The form was again defined through YAML. We had to write those simple actions in TypeScript, but after all, which developer doesn’t know how to write a function in any language? 

  When we decided to improve Search, another core feature, the biggest effort was to optimize the PostgreSQL search engine and decide if it was worth going a step further and experimenting with Elasticsearch – in the end, it was.   

While setting up authentication and SSO, the challenge was to explore all existing methods used throughout our company and unify them under one. Again, a task better suited for a platform engineer. 

With custom-made plugins, there was a little bit more React / TypeScript work. You have to figure out React fundamentals and start writing code. Backstage already provides out-of-the-box React components that follow their design principles, so you won’t have to think about colors and paddings. If those components are not enough, you can use MUI components from which the Backstage components are derived. Don’t worry, the internet is brimming with code examples. 

In the end, our knowledge of the platform and underlying infrastructure played a major role in our experience with developer portal integration. Lack of experience with frontend frameworks surely slowed us down a bit, but we learned along the way. 

The struggle

The biggest challenge, however, was yet ahead of us. It was (and still is) transitioning users from the old toolset they’ve been accustomed to. Despite the significant improvements in user experience and the addition of new functionalities, most users remain hesitant. 

To illustrate, we have a 10-year-old application management dashboard that is extensively used, but also notorious for its bad user experience. We modeled the new one after it, with a better user experience in place, but our developers still prefer the old one. When we asked them why they were not switching to the new one, their answer was simply – we don’t trust it. 

We also developed several nice and shiny plugins, a few features based on user requests, and resolved bugs we introduced on the way. Despite these efforts, our Backstage has yet to catch momentum. 

We acquired most users when we organized a two-day hackathon, where each of the 9 teams built a plugin they needed. Only one plugin is extensively used, but it brought around 40 daily active users, which is only 5% of our engineering organization.  

Despite the struggle, I believe that with good marketing, workshops, and constant improvements, we will bring most of the engineers to use and contribute to Backstage. When that happens, I’ll make sure to let you know how we managed to do it. 

The post You don’t need frontend developers for Backstage integration. But you do need adopters. appeared first on ShiftMag.

You’re in a DevOps, wait, I mean SRE… nope, scratch that… “Platform Engineering” team. People are coming at you to get Kubernetes up and running and then build some kind of platform on top of Kubernetes. Kubernetes may be new, but building and running developer platforms has been going on for at least 10 years.

That’s how Michael Coté, a senior member of technical staff at VMware, introduces the talk he will deliver at the Main stage of the Shift conference titled Lessons Learned from 7 Years of Running Developer Platforms.

Are DevOps, SRE, and Platform Engineering the same thing?

Of course, the first question we had to ask him was a follow-up to his first sentence. Is DevOps dead or alive and kicking, and are DevOps, SRE, and Platform Engineering actually all the same thing? Michael admits even he is not sure:

“I go back and forth on this a lot. The sum total is helpful – they’re all espousing helpful practices and changes that organizations can follow and make to get better at how they do software.

It’s fair to say that the first wave of platform engineer thought leadership was harsh on DevOps, but I think that the early “DevOps is Dead” take has dissipated.

The platform engineering community is doing a great job promoting the idea of product managing platforms, the notion of a platform itself.”

PaaS is for platform-as-a-service

However, Michael adds that it isn’t exactly sorted out yet what platform engineering means. He admits being unsure if he’s even part of the core platform engineering community, so he has given up on defining terms strictly.

When pressed for the definition of developer platform, Coté says he defines it as “everything above IaaS, what we used to call PaaS.“

“For whatever reason, people don’t like to use PaaS anymore, but it pretty much perfectly defines what a “platform” is. I mean, it’s right there in the name of Platform as a Service.

You could also throw in developer tooling like CI/CD pipelines and the collaborative sites/consoles/dashboards developers use. Internal developer portals are another category figuring itself out). If those tools are tightly integrated with the platform to make building, deploying, and running the applications better, it’s probably worth including them in the definition of “platform.”

How platforms work at companies with thousands of developers

Platform engineering and developer platforms have been in the spotlight for the last couple of years, but according to Coté, they have been a thing for at least 10 years. They’ve come to the spotlight now because most organizations have finished their first round of putting Kubernetes in place.

“It took several years to figure that out and start seeing more use in the mainstream. Once you get Kubernetes up and running, you need to start building a platform on top of it: you have to add all that other stuff developers use.”

What Michael is particularly interested in is how big companies with thousands of developers and usually operating in pretty regulated industries have been running developer platforms in the last five, seven, or even ten years:

“Companies like Mercedes-Benz, JP Morgan Chase, several militaries, and others have been running platforms like those for 5, seven, ten-plus years.

What I like to do in my talks is catalog the practices they’ve learned over those years and what works and doesn’t.

I’m especially interested in what very large, usually 30 to 50 or more years old organizations are doing with their platforms: how they make it work for thousands of developers.

As a community, we tend to dismiss the wisdom of teams like this because they’re not using the next great technology. But, the ways to run a platform are pretty much constant over time, especially in larger organizations.”

The developer platform is a product; developers are your customers

One of the most important lessons he learned from working with such companies and their developer platforms for years is to treat the developer platform as a product. And develop it as any company would develop a product by gathering user requirements, developing what they want, getting feedback, and iterating on it.

If you want to have a good platform you have to immediately start product managing it and think of application developers as your customers.

Whatever team is building the platform should be talking with application developers all the time (weekly or so) and getting feedback on what works well for them, what doesn’t work, and if recent changes to the platform have improved things.

You’d think this is what operations people who run this kind of thing do, but they’re usually more focused on the state and status of the system – if it’s running, if it’s secure, etc., rather than the platform’s usefulness to developers.

The post Michael Coté, VMware: Developer platforms have been a thing for at least 10 years appeared first on ShiftMag.