Watch SKE Lift Turn Existing AWS Infrastructure Into a Platform
When we introduced SKE Lift last week, we talked about discovering the platform hidden in your existing infrastructure.
Most organisations already have repeatable infrastructure patterns. They just aren't necessarily expressed as platform capabilities yet. They might exist across Terraform, cloud resources, scripts, pipelines, and years of operational knowledge.
SKE Lift is designed to find those patterns and help turn them into governed, reusable Kratix Promises, without requiring you to rebuild the infrastructure you already have.
But what does that actually look like?
In the demo below, Syntasso Engineering Manager Shane Dowling takes SKE Lift from discovery through to provisioning a new application using a capability derived from an existing AWS environment.
Start with what is already running
The demo begins with an existing AWS environment rather than a blank canvas.
SKE Lift discovers the resources running within that environment and starts reasoning about which resources belong together. In this example, it finds 14 resources and identifies the applications and patterns they support.
Two existing applications, a storefront and an admin portal, both use the same combination of a storage bucket, database, and AWS Lambda function. Instead of treating those as six unrelated cloud resources, SKE Lift recognises the repeated pattern as a potential web application platform capability.
It also discovers a separate event-processing pattern.
This is an important distinction. Inventorying cloud resources is relatively easy. The more interesting challenge is understanding the relationships between them and identifying the higher-level capabilities your organisation has already built.
Turn patterns into platform APIs
Once SKE Lift identifies the patterns, the platform team can decide which ones are worth turning into reusable capabilities. In Kratix, those capabilities are represented as Promises. SKE Lift helps generate the API and pipeline code behind each Promise, including what a developer can request and how to create the underlying infrastructure.
Crucially, discovering and defining a capability doesn't mean immediately changing the infrastructure that led to it.
In Shane's demo, the existing applications can be represented as requests against the new Promises, but those requests remain unapplied. The platform team can review what SKE Lift has produced before deciding what should happen next.
That gives teams a path from brownfield infrastructure to a managed platform without requiring a big-bang migration.
Review discovered capabilities before you scale
AI can accelerate the work of discovering and codifying infrastructure, but speed isn't much use if you can't trust the result.
Before installing the generated Promises, Shane runs SKE Lift's checks. The review check blocks unresolved critical or high findings, while the structural check validates the Promise and its example requests. Only after those checks pass does he review the target platform and the changes the installation will make.
The result is two new platform capabilities with APIs that are ready to consume. Importantly, installing them doesn't modify the existing AWS resources that SKE Lift originally analysed.
You've gone from discovering an infrastructure pattern to defining a governed interface for creating more of it.
Now consume the capability
The final part of the demo closes the loop. Shane asks Claude to create a new development application called Checkout Web using the newly created web application capability.
Claude prepares a request using the platform defaults, but it doesn't provision anything immediately. The request waits for human approval.
Once approved, the platform executes the Promise pipeline and creates the required bucket, table, and function. Shane then verifies the resources are associated with the request and invokes the function to confirm everything works.
The developer didn't need to know how to provision each AWS resource individually. They requested the higher-level capability the platform team had made available.
And that capability wasn't designed from scratch. It was discovered from patterns the organisation was already using.
From brownfield infrastructure to governed self-service
That's the workflow we're exploring with SKE Lift:
For platform producers, SKE Lift reduces the work of finding and codifying useful abstractions.
For the consumer, those abstractions become simple APIs they can request without needing to understand every underlying infrastructure component.
For the maintainer, capabilities become something that can be governed and evolved centrally rather than remaining duplicated patterns scattered across an infrastructure estate.
The goal isn't to ask AI to rebuild your platform. It's to use AI to help uncover the platform your organisation has already built, then put a governed platform interface around it.
Discover your platform today
SKE Lift is currently in private preview and is already enabling customers to rapidly discover their hidden platform and start evolving it. We're looking for more organisations with substantial existing infrastructure estates to help us shape where it goes next.
We're particularly interested in teams dealing with infrastructure spread across different tools, delivery approaches, and generations of automation, and teams exploring how AI agents can safely interact with their platform.
If you're looking at your existing estate and thinking, “there's probably a platform hiding in there”, we'd love to hear from you.
Check out the SKE Lift docs and reach out to the Syntasso team to learn more about SKE Lift or become an early design partner.
Comments