Platform engineering has become a popular path toward DevOps efficiency and developer productivity. In 2025, organizations will realize they can achieve the goals of platform engineering with fewer lines of bespoke code.
What Is a Thin Platform?
A thin platform is one that aims to solve complex problems using existing APIs and open-source tools, operating similar to a wiki page. It simplifies the creation of deployment pipelines and infrastructures, releasing burden from developers.
Instead of trying to build a grand unifying platform, existing tools will lean on open-source and commercial tools to provide solutions that reduce fragmentation, apply standards and integrate security into software delivery.
Moving Away From Platform Thickness
The goal of platform engineering in 2025 should be to build the thinnest viable platform. An example of a thinnest viable platform is as simple as a wiki page. If the page simplifies the creation of deployment pipelines and infrastructure, it can lift a great deal of burden from developers.
This contrasts with the platforms many organizations have created over the past few years. The temptation has been to build a magnum opus, or a mega platform that does everything. Your platform must do more to achieve the “viable” label and solve more complex problems at scale.
A better choice is to combine open-source and existing APIs with code to create a set of cohesive tools with minimal code. Being the glue that turns these tools into a cohesive toolchain means aiming for the smallest surface area for your platform.
Thin Platforms Offer Sustainable Innovation
When you create a thin platform, you benefit from innovation from the open-source and commercial tools you include in your offering. Some effort will be needed to keep pace with API changes, but most of your time will be spent making the golden path easy for developers to use.
Some tricky problems must be solved along the way. It’s not easy to work out how updates to a golden path can be smoothly rolled out. Continuous improvements will be needed across all areas, especially those that traditionally get less attention than they need, like cost control, security and compliance. This is where you want platform engineers to spend their time.
If your platform engineers work on creating features that are already available in open-source and commercial tools, they will spend an increasing proportion of their time chasing feature parity while the developers are frustrated that they can’t use innovations that would be readily available if they didn’t use the platform.
Instead, a thin platform sources workload-specific innovation from external sources. This allows them to focus on the organization's specific needs instead of general needs that have already been met by the market. Tools that solve the general problem of builds, deployment automation or monitoring will do most of what the organization needs. Platform teams provide the final tailoring and integration into the toolchain that makes it easy for developers to use.
Focus on Connectors to Achieve a Thin Platform
All software teams depend on technical infrastructure. These are the tools and infrastructure used to build, test, deploy, operate and monitor the software. The tools may differ, but the slots are practically omnipresent.
In platform engineering, one of the crucial parts of a golden path is the decisions it represents. Reducing a fragmented technical infrastructure means efforts to improve the cohesiveness of the components. It also allows missing pieces, like security scanning at the build stage, to be addressed.
While developers give up some control of the technical infrastructure, they do so to access the smooth deployment pipelines and operational capabilities offered by the platform’s golden paths. For development teams struggling to balance the complexity of the technical infrastructure with the need to deliver features, an internal developer platform can be just what they need to free up time and energy.
When you look at a diagram of the technical infrastructure, the first thing you see are the boxes. Things like code, build, deploy, host and monitor. But a thin platform lives in the arrows, not the boxes. That means the platform shouldn’t have a bespoke build engine or a custom artifact repository. Instead, it should make it easy to set up a deployment pipeline and smooth the transfer of the build’s output, for example by making it easy to get the artifact from GitHub Actions into Artifactory.
The configuration and integration of tools to create a toolchain that’s easy to set up and use is where platforms shine.
The Challenges of Thick Platforms
Platform engineering received a lukewarm appraisal in research during 2024. There are myriad reasons for this, but developing a thick platform and getting caught in a race to compete with commercial products who are able to invest far more into feature development is a particularly thorny issue to resolve.
Other reasons for mixed success are easier to solve, such as the noted low maturity found in platform measurement, which is solved by considering and implementing reasonable metrics, or platform adoption, which often lacks the free-market optionality that is supposed to be core to the discipline. It’s also likely that organizations will get better results with experience, though the research suggests that might require long-term commitment to the cause.
While it will be a painful admission for platform teams, accepting that a platform is doing too much is the first step in addressing the problem. In 2025, the pain of continuing on the wrong track will be worse than trying to continue in the same vein, so we’ll see teams and organizations shifting workloads out of the platform, though the platform will still make the configuration and integration smooth.