cover image

February 11, 2022

Some reasons to build a PaaS with Kubernetes and GitOps


This article is an introduction to the A Vercel-like PaaS beyond Jamstack with Kubernetes and GitOps series.

A Vercel-like PaaS beyond Jamstack with Kubernetes and GitOps

Before diving into technical details, I'd like to give some context. If you want to go straight to the how-to guide, you can skip this introduction and jump to part I.

Starting with WHY

Over the last two years of remote work as a technical leader, I've established a software development life cycle that relies heavily on CI/CD automation.

To make it easier for developers to share their work with other team members, I've set up a workflow that allows any developer to deploy any commit or branch at will.

Sharing development environments can be cumbersome. While tunneling traffic to a developer's machine can do the job, it doesn't fit well in an asynchronous process 1.

A simple solution to this problem is to deploy development environments on managed platforms, as it often requires nearly zero knowledge and configuration.

Accelerating software delivery at the development stage

Vercel, Netlify or Cloudflare Pages are popular managed hosting platforms that automate deployments with a git-centric workflow. It's a simple and easy-to-onboard user experience to solve a complex technical problem.

Beyond simplicity, one feature I like from these platforms is how they keep previous deployments always accessible from a unique URL. I also like how easy it is to promote any deployment to production or rollback to the previous deployment, with just two clicks.

Vercel deployments page

Vercel deployments interface

While it's a very simple way to deploy and rollback applications, these platforms are limited to Javascript frontends and serverless-like functions as backends, also known as the Jamstack architecture.

They are not designed 2 to host popular frameworks such as Rails, Laravel, Django, NestJS, Phoenix, or platforms such as Wordpress or Drupal just to name a few.

Many Git-centric or GitOps oriented platforms have been available long before Jamstack went mainstream. One can either pick a specialized PaaS such as Pantheon for Drupal or Wordpress, Vapor for Laravel, a less specialized PaaS such as platform.sh, or a more general-purpose PaaS like Heroku where you can run Node.js, Ruby, Python, Java, PHP, Go, Scala and Clojure applications.

But the simplicity of these platforms has a cost, and it grows rapidly.

Looking for a better trade-off

Given the current state of the job market, it's often a better option to go with a managed solution than hiring people to run and monitor production servers.

Unfortunately, managed solution configurations are often limited to a short set of plans such as "hobbyist, professional or agency".

It's part of what makes them profitable: they focus on a specific application hosting market, with limited variations from the standard configuration, and target users who have no business interests in learning to manage their own platform.

For this customer segment, wasting money on unused resources is a better option than the cost of operating a scalable production setup.

So, how customers like development teams, who operate noncritical development environments, can get simplicity without an expensive production grade level of service?

How to cut down on resources waste, and avoid paying for features like high availability infrastructure, high throughput, low latency network?

What I'd like to show here is how to build a simple and cost efficient platform :

FeaturesVercelHerokuπŸ‘‹Β Here
One-click deployment
From Web UI, GitOps workflow
One-click promote to production
From Web UI
Keep previous deployments accessible
Unique https url
Run any framework or language
Including Rust, Elixir

What does the solution look like?

Over the course of the series, I'll build a solution with GitLab that consists of three stages:

  1. Package the application in a Docker image.
  2. Deploy this image to a Kubernetes cluster and generate a unique URL to access this application instance, such as https://7c77eb36.nodejs.k0s.gaudi.sh
  3. Promote the instance to production by pointing a non-prefixed URL to it, such as https://nodejs.k0s.gaudi.sh

This is what it looks like in GitLab:

gitlab pipeline interface

A Vercel-like pipeline done with GitLab

Last lines of the deploy job output show a unique URL to access the deployment:

deployment.apps/api configured
ingress.networking.k8s.io/api unchanged
service/api unchanged
Deployment succeeded.
URL: https://7c77eb36.nodejs.k0s.gaudi.sh/version
Cleaning up project directory and file based variables
Job succeeded

Start now and get it right later

Working with development environments is a low-risk strategy that allows a development team to make some mistakes, learn the technology then shape a process that fits their needs.

Recently, Jean Yang posted this article: Building for the 99% Developers, exposing the hard reality a majority of developers faces:

β€œThese are developers who are getting work done outside of the hip companies and frameworks, who often get neglected in conversations about 'what developers want.' There's a huge gap between what 'developer-influencers' are talking about, and the daily reality of most developers.” Jean Yang, founder & CEO of Akita Software

As a regular listener and reader of tech news, I couldn't agree more with her, as I really know the gap between what's been talking about out there and the reality of development teams I've worked with.

I often find myself helping developers who struggle with basic things such as installing local development environments or misconfiguration. So, I'm aware that throwing at them this trendy technology everybody talks about, Kubernetes, doesn't sound like I've understood the problem.

The goal is progress, not perfection

In this series, I'm not describing what Jean Yang calls "an idealized process."

While I've simplified things to focus on key concepts and to improve the narrativity, this setup is part of a real process I've implemented in a development team I've worked with for two years.

It is definitely not perfect, whether because of my ignorance or because I've intentionally left room for improvements.

However, I think it gives a comprehensive starting point to anyone who's trying to make sense of Docker, Kubernetes, CI/CD, GitOps and other trendy topics.

The only fictional piece I've added is instructions to install a Kubernetes cluster with k0s (1. and 2. of part I). I wanted to provide a cheap alternative to managed clusters for people who might want to experiment with this workflow.

The series starts here:

A Vercel-like PaaS beyond Jamstack with Kubernetes and GitOps, part I: ClusterΒ setup

1 Because the person who asked for access has to sync with a developer, set up a meeting, etc. ↑

2 Back in 2018, when Vercel was still ZEIT, I successfully deployed Wordpress sites on this platform with Docker and Now.sh.Removing such capability while pushing Next.js framework was a clear shift towards the Jamstack emmerging market. ↑

4 I tried with a t2.micro with 1 GB of RAM which can be run for free as part of the AWS Free Tier offer and fits the minimal system requirements of k0s for a controller+worker node, but it ended up being pretty unstable. I don't recommend it. ↑

About me


Hi, I'm Jonathan Experton.

I help companies start, plan, execute and deliver software development projects on time, on scope and on budget.

Montreal, Canada Β· GMT -4