Platform as a product: why an internal developer portal is key to your success

Treating your platform like a product requires a concoction of tools and principles - and a portal is one of the most important

What is Platform as a Product

When you consider a product built for a consumer - take the iPhone - it’s clear that Apple has considered exactly what its user base wants to see in the smartphone, and each iteration works on improving and overcoming pain points of previous versions. In platform engineering, although engineering teams may be tempted to first think about building a mega platform or focusing on the architecture, the Platform as a Product approach is about thinking of developers using the platform just as Apple thinks about its consumers, or any consumer-oriented software for that matter.

The internal developer platform encompasses everything from the software development lifecycle (SDLC): infrastructure, CI/CD pipelines, git, Appsec, microservices architecture, and more. The intention of the platform is to make everything within the SDLC easier to access and use, removing the need for developers to work directly within third-party tools, abstracting information for them and providing them with autonomy to work without submitting DevOps tickets to set up a temporary resource or scaffold a service. 

The platform is about enabling developer autonomy and self-sufficiency, but to provide the accessibility, intuitiveness and scalability that developers crave, platform engineers need to think less like architects and more like product managers. Otherwise, they will invest in the platform but adoption will be low, meaning that the developer experience won’t be improved 

The Platform as a Product approach aims to help organizations overcome these issues as platform teams can ensure they’re taking into account the needs and requirements of the platform users when they build or improve their existing internal developer platform. In other words, it’s a platform that developers will actually use.

Platform teams therefore become like product teams; establishing roadmaps to ensure the platform delivers value to the business and improves developer experience.

The rise of internal developer portals have allowed platform engineers to better implement the Platform as a Product approach, because portals force platform engineers to clearly define what the developer experience will be, instead of focusing on the platform, they need to define what the developer will see in the catalog when they investigate a Kubernetes issue, what the developer self-service form shows (and doesn’t show), and what dashboards they will use. The portal helps you visualize, like defining wireframes, what the developer experience will be.

Product Management Principles in Platform Development

While every platform will look different, there are a number of product management principles that platform teams can always refer to in platform development. These include:

• Always asking yourself ‘who is the portal actually for?’. While platform teams may have a sense for the issues that users may be experiencing, they should be cautious that the project isn’t about validating their own assumptions. This means gaining feedback from the intended users without using leading questions or prioritizing based on their own preference. You also need to consider different teams - for instance cloud-native developers will have different needs to developers that are migrating away from a monolith, and therefore if you have both developers as part of your team, your portal needs to factor in both of their needs.
  
  
• Stakeholders - that is all of the users who will be using the platform - should be driving the project and not just being informed. That means using short feedback loops throughout the development process. In addition, managers and subject matter experts should also be involved throughout.

• Conduct user research. This can be through both qualitative (in-depth interviews) and quantitative approaches (surveys). Here, tools like DX and Miro can be valuable for surveying, monitoring and whiteboarding. You can also write your own survey, using questions like:
  1.  Are you satisfied with the time it takes to get a response to a request you made of DevOps?
  2. Please rate your agreement or disagreement with the following statements (scale of 1-5):
     - It is easy to follow appsec requirements and initiatives
     - It is easy to find API information
     
• Steer away from focusing on individual elements or features and instead think about driving end-to-end experiences for each of the following: 
  - Planning your day (eg. see all Jira tickets assigned to me)
  - During development (eg. scaffolding a new service)
  - Ship features (eg. manage canary)
  - Operate production (eg. notify service owner of incident)
  

• Use a minimal viable product (MVP) approach by selecting a specific persona and a smaller subset of use cases that cover the real needs of the organization. You can also consider how this will impact other personas, including managers.
  
  
• Use a ‘Jobs to be Done’ framework to identify, define, categorize and manage developer needs as a way to ensure the product adds value and will succeed.
   
• Continuously refine the portal, just like a consumer-facing application. This can include roadmapping, usage metric data-gathering and quality monitoring.
  
  
• Identify workflow interdependencies by clarifying the team structure.
  
  
• To encourage adoption, rather than using a big bang approach, customize the rollout to align with the goals and structures of your teams.

Benefits of Treating the Platform as a Product

Not all developers want to, or think they should - touch operations. But the introduction of DevOps as a practice, meant some organizations pushed their developers to take responsibility for operational tasks. And this has been one of the issues that has stuck around for many years, increasing the cognitive load on developers. 

It has put engineering teams in a tough spot; they want to provide their developers with better developer experience through self-service capabilities, but they want to do this in a way which is easy for developers, and secure for engineering teams.

This is where platform engineering was born. By using a product approach, the platform team can ensure they balance this need for self-service with the right level of abstraction. They can do this by asking (both themselves and other platform users):

• What do developers need to know to ship software safely, while using golden paths? 
• What functionality does a platform need to facilitate this?

By knowing the answers to these questions, platform teams can build the most effective platform. This avoids the pitfall of building an underutilized platform but more importantly improves developer experience.

The knock-on effect of better developer experience isn’t just limited to developers being happier and at less risk of burning out, but of increasing developer productivity. Recent research by GitHub and DX found that a focus on measuring and improving developer experience can enhance productivity and profitability for developers, teams and organizations as a whole. 

Key Components of a Platform as a Product

Platform teams need to carefully consider the technology stack and reference architecture. Below are some of the essential components and tools needed to establish an internal developer platform that empowers developers to work autonomously. This should act as a great starting point.

1. A Control Plane to manage all resources, whether they are applications running in a K8s cluster or infrastructure and services running in various cloud providers. It is an entry point API and acts as the central point where resources are managed in the platform. As applications use multiple resources,  using a control plane alone means it’s difficult for developers to track where everything resides and what the dependencies are.
   
   
2. A Control Plane Interface
   A user-friendly interface can be provided using an internal developer portal. Platform teams can decide which details to abstract away so that unnecessary details such as database storage information aren’t displayed. Direct interaction with the cluster or control plane should be avoided - users should instead store their desired states in Git.
    
3. Git: for storing desired states in a Git repository and then synchronizing with the control plane using GitOps.
   
   
4. Databases are an essential part of the internal developer platform. To ensure efficient management, a method for handling schemas within these databases - preferably as part of application definitions stored in Git - is required.
   
   
5. A secrets manager is recommended for sensitive information that cannot be stored in Git, such as passwords.
   
   
6. The Internal Developer Portal portal can help organizations to implement Platform as a Product. The portal enables developers to gain visibility and using the software catalog helps them to understand what’s going on in the platform - information such as who owns a service, where it’s deployed as well as the quality and standards with regards to anything in the SDLC. It should enable developers to execute processes that create new resources and store them in Git.  In addition, developer portals provide developers with self-service actions, enhancing autonomy and reducing or removing the need to use email or Slack messages to request DevOps support.
   
   A portal is effective when used together with the platform’s existing APIs. The portal is also the best option as an orchestrator - in other words a unified interface for developers where they can consume and find everything they need, and the interface that can trigger the desired behaviors (run, schedule, monitor) using the platform tools.
   
   
7.  CI/CD Pipelines: to execute actions such as creating repositories based on templates or building images with updated release changes to manifests.
   

Product Approach with both the Portal and Platform

When you’re taking a product mindset to your platform, an internal developer portal can be a huge part of your success. It’s worth noting that the portal should also be considered with the same product-centric perspective. This means rather than focusing on particular features like the software catalog or scorecards, users should think about the numerous use cases that will benefit organizations, and consider driving an end-to-end experience for the user. That may entail using one or more components of the portal.