A great person once said that “nothing worth doing is easy”, and that’s definitely the case with introducing an Internal Developer Platform, or IDP, to your DevOps environment.
As engineers, we know the benefits that IDPs can bring to our workflow, but the truth is that not everyone sees those benefits in the same way.
In April, Galo Navarro, Lead Software Engineer at New Relic, joined us to discuss how he built an internal Platform as a Service (PaaS) for 1500 engineers at Adevinta. In this webinar, Galo shares the problems his team faced, why they needed to build an internal PaaS, and how his team executed and measured their success.
Life as a Platform team
Platform teams come across numerous challenges throughout the working day.
From needing to support depreciated tools and internal libraries with mutually incompatible versions because each engineer has their own preference, there are a whole host of issues that are fairly common across most industries.
However, when a platform team is a central support system for twenty sub-companies, all with their own ecosystems, problems, cultures, and technology cocktails, these problems quickly become insurmountable without any additional support.
That’s exactly what Galo was facing at Adevinta, where he was responsible for helping these twenty companies - many of whom had their own platform teams - manage their online marketplaces. Each of these marketplaces has their own unique features, but also share common assets that don’t need to be rebuilt time and time again. Galo explains:
“You don’t need to have twenty different plumbing systems to build a marketplace. You can reuse the same plumbing system.”
But, how does a platform team build an internal PaaS for twenty different sub-companies while providing proven value?
Generating value as a Platform team
In every business, there are profit centers and cost centers. Profit centers, like sales teams, make money, and it’s easy for executives to understand the value they bring to the company. Cost centers, like platform teams, are the exact opposite.
Well, for the profit centers, it is. It’s easy for executives to see and understand the value these teams bring to the company, because their contribution can be directly measured in income.
However, it’s not so easy for platform teams, who are typically cost centers. Their value is more difficult to prove to executives and, as such, they’re more closely scrutinized. Galo says:
“It’s a tough position to be in because in general, the financial department for every company will be looking closely at every cost centre and looking to cut it or externalize it.”
With competing infrastructure services like AWS, Google Cloud, and Heroku being so accessible in the modern tech stack, platform teams are under more scrutiny than ever to provide value or risk being made redundant.
Strategies for building a PaaS
Galo explained that his main focus wasn’t building a set of tools to throw at engineers, but rather a fully realized product that could help engineers across the entirety of the development cycle. So, when he’s talking to other teams, his focus is this:
“You’re building a product, this product has a lot of competitors, and that’s a very tough job. Now, you have two options. You can build the car yourself, and that’s fine. But, if you want, we can do the heavy lifting for you so you don’t need to focus on the wheels, the engine, the gas, etc - you can focus on winning the race against our competitors.”
The goal for any PaaS is, therefore, building a golden path that allows engineers to use the tools they already know, or the tools that are best for the job at hand, without asking them to assemble those tools every single time they need to do something.
But, the problem is platform teams can’t stay there and expect that those engineers will follow that same path every time. Rather, they need to build “escape hatches” that let engineers use the tools that fit their workflow and plug in alternatives without needing an entirely new platform.
So, a PaaS should act as the glue between different systems, components, and tools, without being too restrictive that engineers can’t move away from the defined path. Similarly, if the PaaS is the glue that connects all of these components together, engineers need to be able to trust that this glue will hold no matter what components they need to substitute or bypass to work in the way that suits them.
Demonstrating value through impact
Because platform teams will be heavily scrutinized, it’s important to demonstrate value through impact. However, this needs to be done right.
“A lot of teams try to do something big and ambitious that will have a lot of impact straight away, but the problem is that it will take seven years. Those seven years will have seven re-organizations on average, and...the team will get cut.”
Instead of focusing on long-term impact, Galo explains that at Adevinta, his team automated one low-value activity at a time, until submitting a Pull Request looked like this:
This meant that the team could demonstrate impact in small, measurable ways more often, thereby demonstrating that the PaaS wasn’t just a set of tools, but an ecosystem that could benefit the DevOps environment in numerous ways.
Virtuous feedback loops
As any internal PaaS grows, it will inevitably generate more value through feedback alone.
In the case of the Adevinta PaaS, Galo’s team built analytics dashboards on top of the platform to monitor the real-world performance and impact this platform was having on the DevOps environment.
“What we could explore was, let’s see how many deployments we have, how many builds we have, how long those builds take, etc...this was super useful when you want to have conversations with teams and influence their behavior. What we did was show them that data and not give them any opinions.”
By having these analytics, the platform team is able to discuss the data directly with teams who will, usually, come to the same conclusion that the platform team needs to influence them towards.
What’s important, however, is to use data that’s backed up by industry standards. This gives the platform team the ability to measure the impact of the platform and present that data to executives in a way that speaks directly to their interests.
Zero friction onboarding
A systemic issue that faces most platforms, and often kills internal PaaS software, is that onboarding can feel a lot rougher than with external competitors. Even if the tool is genuinely helpful, platform teams can find themselves losing out to competing products simply because they’re too frustrating or have too much documentation to read before they can be used.
“One of the things we invested in was hiring product managers and UX designers -people that know how to design user interfaces and understand how our users are interacting with our tools”.
This led Galo’s platform team to develop a one-click onboarding system.
They also built a full help center with documentation. Plus, because they were only serving twenty companies rather than thousands, they could offer 24/7 on-call support that was more tailored to each company than external competing services.
A big part of this is because, as Galo explains, “when you’re in this type of team, you want to make things easy, but at the same time, it’s frustrating because [other] teams have to adapt and it’s a grueling process”.
However, platform teams also have to understand that even though things are difficult for them, they’re far worse for other teams who have to adapt to this software on top of their regular workload.
Because of this, the guiding principles become “you’re not putting the burden on your users, you’re putting it on your team”.
Platforms as a Service: Key Takeaways
Developing internal PaaS systems can be a minefield, which is why hearing insights from lead engineers like Galo are so valuable. Managing expectations of your platform between managers, engineers, colleagues, and executives is a hard situation to navigate.
However, by shifting the narrative to see your internal platform as a product, rather than a set of tools, you can demonstrate value and have a positive impact in a way that’s understandable by both your engineers and executives.
Thanks again to Galo Navarro for sharing his war stories with us. Make sure to catch up with the full webinar to hear the full story and hear Galo’s insights into building a platform to rival the big-name vendors. And, if you want to learn more, check out this webinar about building internal platforms for large-scale enterprises, or sign up for one of our many upcoming webinars.
