The Platform Liberator: Architecting a Serverless PaaS on Kubernetes with Knative and Crossplane

Escape vendor lock-in by building a custom Serverless PaaS. Learn how to leverage Kubernetes, Knative, and Crossplane to replace Heroku.

The Platform Liberator: Architecting a Serverless PaaS on Kubernetes with Knative and Crossplane
Photo by Tyler on Unsplash

For over a decade, Heroku served as the gold standard for Developer Experience (DX). It offered a simple promise: git push heroku main, and your application was live. However, the landscape has shifted. With the removal of free tiers, rising costs at scale, and the inherent limitations of a "black box" platform, CTOs and engineering leads are looking for an exit strategy.

Enter the era of Platform Engineering. Organizations are no longer content with renting a platform; they want to own it. The goal is to build a "Platform Liberator"—an internal system that offers the ease of Heroku but runs on your own cloud terms, without the markup.

In this architectural deep dive, we explore how to combine Kubernetes (the foundation), Knative (the serverless engine), and Crossplane (the universal control plane) to build a modern, scalable, and cost-effective PaaS that puts you back in control.

The High Cost of Convenience: Why Move Away from Heroku?

Modern building with geometric cutout facade against sky
Photo by Declan Sun on Unsplash

Heroku remains an excellent tool for prototyping, but it imposes a "success tax." As your application scales, the cost per compute unit skyrockets compared to raw AWS EC2 or Google Compute Engine instances. Furthermore, you are bound by their architectural decisions. Need a specific kernel module? You can't have it. Need to orchestrate complex microservices with fine-grained networking rules? You hit a wall.

Moving to raw Kubernetes offers infinite flexibility but often destroys the developer experience. You cannot ask an application developer to write 500 lines of YAML just to deploy a Hello World API. This is where the Internal Developer Platform (IDP) comes in.

The objective is not just to use Kubernetes, but to abstract it. We want to build a layer where developers define what they need, not how to configure it.

By architecting your own PaaS, you gain:

  • Cost Arbitrage: Use spot instances and autoscaling to reduce bills by 40-60%.
  • No Vendor Lock-in: The stack we describe runs on AWS, Azure, GCP, or bare metal.
  • Granular Control: Security, networking, and compliance are defined by you, not a third-party provider.

Knative: bringing 'Serverless' to Your Cluster

a computer screen with a bunch of lines on it
Photo by Bernd 📷 Dittrich on Unsplash

The magic of Heroku is its ability to handle routing, revisions, and scaling automatically. In the Kubernetes ecosystem, Knative is the technology that bridges this gap. It sits on top of Kubernetes and provides a set of middleware components essential for building modern, source-centric, and container-based applications.

Knative solves three massive headaches for platform architects:

  1. Scale-to-Zero: If no one is using your app, it consumes no resources. Knative scales pods down to zero and spins them up rapidly upon receiving a request. This is crucial for cost savings in development and staging environments.
  2. Traffic Splitting: Want to do a canary deployment? Knative allows you to route 10% of traffic to a new revision with a simple configuration change.
  3. Simplified Manifests: Instead of managing Deployments, Services, and Ingresses separately, Knative introduces the Service resource.

Here is a comparison of complexity. A standard Kubernetes deployment might require 40+ lines of YAML. A Knative Service looks like this:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          env:
            - name: TARGET
              value: "Nohatek Reader"

This abstraction restores the "Heroku-like" simplicity developers crave while maintaining the power of K8s under the hood.

Crossplane: The Universal Control Plane

a close up of a network with wires connected to it
Photo by Albert Stoynov on Unsplash

Applications rarely live in isolation; they need databases, caches, and object storage. Historically, provisioning an AWS RDS instance or a Google Cloud Storage bucket required Terraform, Ansible, or manual clicking in a console. This creates a "workflow fracture" where app deployment happens in Kubernetes, but infrastructure happens elsewhere.

Crossplane unifies this. It extends the Kubernetes API to manage external cloud resources. With Crossplane, you can provision an SQL database using a Kubernetes manifest (YAML), just like you deploy a pod.

But the real power lies in Compositions. As a platform engineer, you can define a "Composite Resource" called PostgresDB. This definition hides the complexity of AWS RDS settings (VPC, subnets, instance types) and exposes a simple schema to your developers.

The Workflow:

  • Platform Team: Defines a standard, secure, compliant database configuration (XR).
  • Developer: Creates a claim (XRC) in their namespace requesting a PostgresDB.
  • Crossplane: Automatically provisions the RDS instance, creates the connection secret, and injects it into the developer's namespace.

This eliminates the need for developers to learn Terraform or wait for Ops tickets to be resolved. It is self-service infrastructure at its finest.

The Final Architecture: Putting It Together

Architectural drawings of a building with elevations and floor plan.
Photo by Amsterdam City Archives on Unsplash

So, what does the "Platform Liberator" architecture look like in production? It is a synergy of GitOps and Kubernetes operators.

  1. The Trigger: A developer pushes code to Git.
  2. The Build: A CI tool (like Tekton or GitHub Actions) builds the container image.
  3. The Deploy: The CI tool updates a Helm chart or Kustomize file in a config repo.
  4. The Sync: ArgoCD detects the change and syncs the cluster.
  5. The Execution:
    • Knative spins up the new application revision, handles the networking, and scales based on concurrency.
    • Crossplane ensures that any required backing services (Redis, Postgres) are provisioned and bound to the application.

The result is a fully automated, self-healing platform. Developers get the velocity they need, and the business gets the governance and cost control it demands.

Replacing Heroku is not just about saving money on your monthly cloud bill; it is about maturing your engineering organization. By adopting Kubernetes with Knative and Crossplane, you are building a Platform as a Product—one that empowers your developers to move faster while retaining full ownership of your data and infrastructure.

Building a custom PaaS requires careful planning and architectural expertise, but the ROI on agility and scalability is undeniable. Are you ready to liberate your platform?

At Nohatek, we specialize in architecting high-performance cloud platforms. Whether you are migrating from Heroku or building a new IDP from scratch, our team can guide you through the transition. Contact us today to future-proof your infrastructure.