Internal developer portals in real-life

Internal developer portals in real-life

Companies from different industries, different backgrounds, and with completely different make-ups of technology stack and teams, are all trying to solve the same problem with platform engineering and internal developer portals.

At Portal Talks 2024, leaders from three organizations answered some of the key questions about how internal developer portals are used in real life. They included:

• Tiffany Grafton, technical product manager at property and casualty insurer Great American Insurance Group (GAIG), a company with over 7000 employees.
• Pavel Pikat, technical product owner at AMCS Group, a provider of business management software for the resources, waste, recycling, transportation and utilities industries in more than 80 countries.
• Louis Bailleul, chief enterprise architect at PGS, a leading energy data and intelligence company, with nearly 1000 employees. 

If you’d prefer to watch the session, you can do so on YouTube, here. 

Why choose platform engineering?

For AMCS Group, the need for platform engineering arose after following DevOps practices for five or six years. While this drove engineering excellence, the company experienced rapid growth - from 200 to 1200 employees, and l Pikat says that the company needed to recognize that the central DevOps team had challenges with scaling.

“We were operating with ticketops, where we’d have requests raised by different business units or teams, such as requests for building a pipeline or standing up a service in the cloud. As we grew, this became a backlog, where we couldn’t satisfy the demand on time. We were effectively a bottleneck for the organization,” said Pikat.

After looking at industry trends, Pikat realized that platform engineering was what AMCS needed to ensure scale. 

For PGS, the need for platform engineering came about from an entirely different perspective. It too had embraced DevOps when it began its move to cloud native technologies back in 2018. And it found this empowered both developers and software engineers, but in 2020 the company had to downsize due to the pandemic. 

“The organization, on the IT side, was left with a huge number of systems and services that had a much smaller workforce to actually maintain them,” said Louis Bailleul. 

“This was compounded by the transition to the cloud, and so it was necessary for us to find a better way to distribute the workload in order to have more hands on the actual machinery - and this is where we ended up with the platform engineering concept; making sure we can provide a product that can be consumed by the rest of the organization in order to build and maintain IT services,” he added.

Why choose an internal developer portal? 

Ultimately, platform engineering is about ensuring the software development process is as efficient and effective as possible, and that the developer experience is great. And this is why GAIG decided to use Port to build an internal developer portal.

“We wanted to empower the developer and move the needle ultimately on our company’s profitability,” said Tiffany Grafton. 

Bailleul explained that the first platform engineering implementation PGS undertook was for Kubernetes, but the resulting complexity led to the company seeking an internal developer portal. 

“It was based on a GitOps approach, where we had a bunch of repositories that people needed to manipulate in order to do whatever they wanted - that was great and worked fantastically well but the cognitive load in order to use this was insane - and for those who just wanted to get a namespace and deploy their application, it was just too much,” he said.

“We realized we needed that hidden away, but building a UI or a new product to abstract this - that’s not our job - it’s for us to consume. So this is why we searched for a solution that solved that problem,” he added.

AMCS Group’s Pikat said that they had some success in using regular pipelines in its version control system to run self-service tooling, albeit only for simple scenarios. The need for a portal was clear as the platform team wanted to establish more difficult self-service actions and build an enterprise software catalog, while other stakeholders in other business units wanted to be able to view security and compliance metrics. All of these items were possible via an internal developer portal. AMCS’ initial research focused on Backstage.

“Most platform engineering teams will look at Backstage initially, but the first thing that comes to mind is complexity because you have to deal with it yourself, and we have a very small team, so after trying to run it locally it was clear we didn’t have the resources to explore it, and so we explored SaaS alternatives instead,” Pikat said.  

Using portal-as-product

When GAIG decided to select Port to build a portal, they took on the portal as a product approach - effectively treating the developers as customers.

“We factored in our high level goals, our scoping and what we were aiming to go after first, really honing in on what we can understand about our developers’ needs and gathering all that feedback we can upfront and along the way,” said Grafton. 

This meant conducting sessions with around 20 team members, several IT executive sponsors and various stakeholders, to ensure developers’ needs were being met and that the project aligned with the business’ goals. 

Pikat has taken on the same approach at AMCS Group.

“We're building a product for our internal people; and you’re naturally going to think of it like a product by building it like any other product development team builds products - with a scrum team, a product owner and scrum master, and with sprints. You get feedback and work on the low hanging fruit that people have or requests that come in and then you release what they need, which increases value incrementally,” he said.

GAIG also carried out a team topologies exercise to map the organization and understand the current way developer teams worked. This included, for example, the UX team running proto- persona workshops so that those creating the portal could establish what developers’  needs were from a UX perspective. 

Focusing on developer pain points and golden paths

For GAIG’s initial portal launch, the focus has been on discoverability and search in a software catalog, providing developers with a single pane of glass to understand all of their services and resources. This was because they found during their scoping sessions that developers had issues with visibility into available services and there was an over reliance on other developers to find the right information, or difficulty in piecing together documentation from multiple tools.

“We knew we would have a strong starting point if we could start solving those needs first,” said Grafton.

And based on GAIG’s initial observations, there have been some early signs of benefits.

“Within a small initial control group, we observed a reduction in the time spent identifying who supports a particular service from 30 minutes to two minutes for a few of our developers,” said Grafton.

The team hopes they can reduce developers’ time spent on numerous tasks going forward.

While the portal as a product approach tends to yield the best results in gaining the trust and adoption of the portal, there are some pain points which may be more obvious to the team building the portal. For instance, at PGS, the team were aware that developers were missing a way for people to understand best practice on how to do things, despite having a lot of documentation and tutorials at hand.

“We had a lot of services that were built kind of the same way, but not in the same way and that caused a lot of frustration, so teams that were working on different products or services had issues with compatibility or consistencies,” said Bailleul. 

The team decided that as part of embracing platform engineering, it needed golden paths. 

“It’s the preferred way to do something, an easy way to achieve what you want, and you lower the barrier to entry to achieve your goal by making it your preferred way - this has been one of the core foundations of how we put the vision forward for all platforms,” he said.

The introduction of an internal developer portal has enabled PGS to use golden paths, and Bailleul believes the company is already reaping the rewards.

“When we started to have good golden paths and a number of good self-service actions, it became a force multiplier; we’ve seen people who weren’t willing to go through the ticketops or take care of creating something new that were enabled and capable of doing it, and that has been great for us as an organization to increase our efficiency and deliver more,” he said.

This realization of golden paths with self-service actions has been revolutionary for AMCS Group, too. 

“The development team have a lot of complexity to deal with, so telling them to go and do tasks like creating good repositories or giving them access to do cloud resources to do troubleshooting, without any golden path, you’re leaving it to them to take a course in their own time, and still have to deliver all of those things,” Pikat said.

This is why Pikat wanted to enable self-service in a way that took into account governance as well as abstracting away complexity. With Port, the company can do this via simple self-service forms that developers have to fill in to gain access or take an action, providing them with autonomy with golden paths and guardrails baked in.

“Not only can we enable people to get the things they want in an intuitive way and reduce that 85 minutes task involving multiple people to do it yourself in five minutes, but we can sleep at night knowing that they will follow our golden path that we designed for them - we’re not going to break any rules, we’re not going to create a Git repo in the wrong project in our version control system, they won’t forget to put branch policies that we require, etc,” he said. 

Feedback and iterating on your internal developer portal 

The team at GAIG is conscious of ensuring they continue to collect feedback as they roll out the portal to more teams. The soft launch involved a rollout to a smaller team of about 50 app developers to get initial feedback, and changes were incorporated into the portal before it launched again to a broader group of around 300 developers. 

For AMCS, the feedback has been hugely positive for its internal developer portal.

“The first and most frequent feedback we’re hearing from our stakeholders, which are not necessarily just developers but support, professional services, and the entire engineering community is how freaking fast they get the task and job done - and they just love it because it enables them immediately,” said Pikat.

“It makes us proud of our work too - because it’s such a nice feeling to help your colleague be productive, to be a driving force for the team and to help the business,” he added. 

At PGS, many of the initial developers that were onboarded with the first iteration of their portal, were those that had the pain of manual GitOps processes. 

“They went into the portal and were blown away by how simple it became,” said Bailleul.

 Meanwhile, the second wave of developers who used the portal had no complaints - and this, Bailleul explained, was significant in itself.

“You know it’s effective and you’ve done a good job when your team uses the new service and you don’t get any bad feedback,” he said.

The company has been able to compare mean time to resolution (MTTR) between tickets and self-service actions, and Bailleul said that the difference was “pretty impressive”.

Now, for all three organizations, the developers and other stakeholders that are using the portal are asking what else is possible with the portal, and coming up with suggestions for new ideas or features to make the portal even more impactful for the organization.