Why your platform product shouldn’t be just another library

What is a platform product?

A platform product combines people, procedures and technology to provide an attractive service to its users. It empowers teams to consistently create and run their services while reducing the amount of unplanned work that the platform generates for the rest of the organisation. This consistency delivers increased security, lower costs and faster time to value.

Platform products can be large top-level digital platforms that serve workloads such as digital services and APIs, or data platforms that serve data workloads such as MLOps or data pipelines. They aim to tackle common engineering user journeys and can often be further split into finer-grained platform products such as:

• build and deployment
• monitoring, alerting, and observability
• authentication and authorisation
• secret management

There are various methods to create an internal developer platform, and at Equal Experts, we have trialled most of them with customers. However, we have observed a common problem in several organisations where platform engineering is based on shared libraries instead of shared services.

What is platform-as-a-library?

Platform-as-a-library is an approach where a team creates a platform product consisting of various functionalities, code, config, and tools that are packaged as a reusable software library.

This library can be integrated into different products, services, or applications within an organisation, which can result in multiple instances of the platform product being created across the organisation.

The platform engineering team typically adopts a platform-as-a-library approach with good intentions. They may plan to share reusable code or they cannot commit to supporting other teams via a service due to their current workload.

Why should you avoid platform-as-a-library?

At first glance, platform as a library seems like a good idea. Creating a platform library of code and configuration that can be copied and pasted to multiple initiatives and products should save time. However, this approach has several drawbacks and should be avoided. Here’s why:

1. Higher maintenance and operational costs: Multiple instances of the platform increase maintenance and operational costs. It becomes challenging and time-consuming to identify and fix bugs, maintain multiple instances, and implement features across different instances within an organisation, especially when different product team priorities are taken into account.
2. Stifled platform product innovation: Product and platform teams become hesitant to modify the platform’s copied library of code and configuration, fearing disruption and incidents. This hampers the agility that is required for continuous improvement.
3. Diverging platform product instances and implementations: As individual products use and change their instance of the platform, the instances diverge on requirements and the platform’s implementation. This results in a lack of standardised practices, defeating the purpose of having an internal platform product aimed at promoting consistency and efficiency.
4. Dependency management hassles: Maintaining and debugging issues becomes a cumbersome task when there are multiple instances of the platform library across products. Identifying and rectifying bugs or implementing enhancements requires revisiting every product that uses the copy-pasted platform library, multiplying the workload.
5. Shared first-party library hell: It is not recommended to share libraries created in your organisation (aka first-party or proprietary libraries) between different product domains. Avoiding sharing helps to ensure the services aren’t coupled together and reduces the risk of dependency hell. The same is true for platforms – coupling services together with platform libraries creates the same dependency hell, but engineers in product teams won’t always have the right mix of skills and experience to help.

Build shared services, not shared libraries

A more effective way to build internal platform products is to create standalone services with well-defined interfaces, which are supported by a team of experts who can offer users guidance and advice. These products should be accessed through standardised interfaces, such as APIs and UIs, rather than being integrated through copying and pasting code or direct dependencies. With this approach, product teams can interact with the platform products seamlessly, and the platform product team can help with any issues, feature requests, or bug reports.

This approach offers many benefits, such as reducing the operational cost of maintaining multiple instances of the platform. This enables faster innovation across the organisation and provides flexibility in evolving the platform product independently from other products within the organisation.