top of page
Writer's pictureDaniel Bryant

The Future of Platforms: The Invisible Glue Between Backstage and Terraform (Webinar Recap)

In the world of platform engineering, one question consistently rises to the surface: How do you build a platform that balances developer autonomy, operational efficiency, and infrastructure complexity? In our fifth Syntasso webinar, “The Future of Platforms: The Invisible Glue Between Backstage and Terraform”, Abby Bangser and Daniel Bryant aimed to tackle this challenge head-on, exploring the need for an "invisible glue" that ties platform components together, offering a more cohesive and scalable approach to platform management.


You can download the slides via the Syntasso Speaker Deck and watch the webinar recording via LinkedIn or the YouTube embedding at the end of the article. 


How do you build a platform? There are three ways
How do you build a platform? There are three ways

Three approaches to platform building

When organisations set out to build internal platforms, they often gravitate towards one of three distinct approaches: top-down, bottom-up, or middle-out. Each approach comes with its own set of strengths and challenges.


1. Top-down, developer-led approach to platform building

This approach focuses on giving developers the best experience from day one. In many cases, companies turn to tools like Backstage or other service catalogs to centralise developer workflows, making it easy for them to deploy services, track metrics, and collaborate. A strong developer experience ensures rapid onboarding and minimises friction in creating new services.


However, the top-down approach can stumble once platforms move into the "day two" phase, which is all about ongoing operations. What happens when you need to apply security patches, update software across the board, or change organisational policies? Without built-in mechanisms for handling upgrades and maintenance, developers may find themselves bogged down by operational tasks that overshadow their core work.


"Sure, you can view some metrics, but maybe you don’t have access to do things like upgrades and updates through that same interface... what happens when a huge security risk comes out and you need to patch everything at once?" (Abby)


Daniel explained that while tools like Backstage are fantastic for starting quickly, they don’t always offer the operational flexibility that platforms need at scale. For example, Backstage offers an excellent way to visualise and manage services, but it doesn’t inherently solve challenges related to security updates or scaling infrastructure. When these day two challenges hit, teams often realise they need more than a service catalog—they need a robust orchestration layer to handle the operational complexities.


2. Bottom-up, infrastructure-first approach to platform building

The bottom-up approach, often driven by operations teams, focuses on automating infrastructure management from the ground up. Tools like Terraform, Crossplane, and Ansible are cornerstones of this strategy, offering rich infrastructure-as-code capabilities. This approach is all about automating the toil out of infrastructure management, reducing the manual tasks that traditionally weigh down ops teams.


Daniel, who comes from an ops background, highlighted the benefits of using tools like Terraform to automate infrastructure provisioning. However, he also pointed out a significant downside: infrastructure abstractions leak through to developers. When developers have to learn how to apply and manage Terraform code to deploy their services, it detracts from their core focus—writing and delivering software to solve business problems.


"The infrastructure abstractions, the information in the stanzas in Terraform... can leak through to developers, making it hard to understand what's going on, and increasing cognitive load" (Daniel)


Abby echoed this sentiment, recalling instances where developers were handed Terraform configurations and expected to manage them. It’s like "getting a puppy for Christmas," she said. While exciting at first, the responsibility of caring for it every day can become burdensome. Similarly, when developers are tasked with managing infrastructure without sufficient abstraction, it can feel overwhelming and lead to operational bottlenecks.


3. Middle-out, platform engineering-focused approach to platform building 

The "middle-out" approach has been gaining traction as the ideal way to balance the needs of developers and ops teams. This strategy, often called “Platform as a Product,” focuses on treating the platform as a service to internal users—developers, security teams, and operations staff. The goal is to automate everything as a service, offering self-service capabilities while abstracting away the complexities of infrastructure.


Abby and Daniel stressed the importance of thinking about the platform in product terms. Internal platforms should cater to different user personas within the organisation, providing tailored experiences to meet their needs. For example, an internal platform might automate specific business services, such as fraud detection for a bank, making those services easily consumable by internal teams.


The middle-out approach is particularly powerful because it allows organisations to scale while maintaining developer autonomy. Platform engineers can create APIs, abstractions, and automation layers that offer the right amount of control without overburdening developers with the intricacies of infrastructure. This is where the concept of the "missing middle" comes in—the invisible glue that holds everything together.


The platform as a product mindset

When you think of the platform as a product, you start with the users and their pain points rather than jumping straight to tools and technologies. Abby emphasised that building platforms intentionally, with a focus on APIs and automation, ensures scalability, usability, and alignment with business needs.


Treating the platform as a product also means acknowledging that different teams will interact with the platform in different ways. For instance, developers might prefer a CLI or web interface, while ops teams may need deeper control through Terraform or Ansible. Understanding these personas helps platform engineers design more effective solutions, ensuring the platform delivers real value across the board.


The platform as a product mindset also aligns with industry best practices, such as those outlined in the Team Topologies framework, which Abby referenced during the webinar. This approach encourages platform teams to work closely with their internal customers (e.g., developers, security teams, etc.,) to ensure that the platform is solving real problems.


Overcoming day two challenges with platform orchestration

One of the major challenges discussed in the webinar is managing "day two" operations, or the ongoing maintenance, upgrades, and security tasks that follow after the initial platform build. In many organisations, these tasks can become bottlenecks, especially if the platform wasn’t built with these needs in mind from the start.


Abby shared her experiences in dealing with these challenges. One example was a platform that initially thrived with a "self-service" model, using Terraform modules to allow developers to provision infrastructure on demand. However, over time, the complexity of the system grew, and it became difficult to scale and manage. Every change required multiple teams to update their Terraform code, leading to delays and friction.


"If you've been handed a bunch of Terraform as a developer, it’s like being given a puppy for Christmas, right? It’s great on day one, but then you’ve got to look after it." (Abby)


The solution, according to both Abby and Daniel, is to invest in platform orchestration—the glue that connects infrastructure automation with developer workflows. This invisible glue is what allows platforms to scale without overwhelming users or creating operational bottlenecks. Orchestration layers help manage day two tasks, such as rolling out security patches or upgrading services across the entire platform.


“If you're struggling with scaling your day two ops upgrades, policy change, security rollouts... that’s a warning sign. You might be missing that [platform orchestration] middle as well.” (Daniel)


The three layers of platforms: application choreography, platform orchestration, and infrastructure composition
The three layers of platforms: application choreography, platform orchestration, and infrastructure composition

The invisible glue for platform engineering

At the heart of the Syntasso solution to these platform engineering challenges is Kratix, an open-source platform orchestrator. Kratix aims to solve the "missing middle" problem by offering a flexible orchestration layer that connects tools like Backstage and Terraform, enabling organisations to scale their platforms more effectively.


Kratix provides an abstraction layer that lets teams offer everything as a service, from databases to internal business services. By using Kratix, platform teams can automate workflows, enforce security policies, and ensure that operational tasks are seamlessly integrated into the platform. This approach reduces the burden on developers while giving ops teams the control they need to manage infrastructure at scale.


"One of the reasons why we find people coming from the bottom up is because that’s where the tools are... but more and more tools are trying to become more interoperable, become more core to working together to be able to allow people to think in bigger blocks." (Abby)


As Daniel explained, Kratix is designed to handle both the developer and operational sides of the platform, providing the glue that makes everything work together. Whether it's managing Kubernetes clusters or automating compliance checks, Kratix abstracts away the complexities, making the platform easier to use and maintain.


Conclusion: Building platforms with intent and focus

The future of platform engineering lies in intentional platform building. As both Abby and Daniel emphasised throughout the webinar, organisations need to approach platform engineering with a clear focus on APIs, abstractions, and automation. By treating the platform as a product and using tools like Kratix to orchestrate day two operations, teams can scale their platforms without sacrificing usability or operational efficiency.


The key is to focus on solving real problems for internal users, whether they are developers, security teams, or operations staff. By doing so, platform engineers can build scalable, maintainable platforms that truly add value to the organisation.


Additional resources

The recording of the entire webinar and slides are embedded below. If you have any questions about platform engineering or Kratix, our framework for building composable internal developer platforms, please contact us!




Comments


bottom of page
Scarf