February 11, 2022
Some reasons to build a PaaS with Kubernetes and GitOps
Foreword
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
- Introduction: Some reasons to build a PaaS with Kubernetes and GitOps practices
- Part I: Cluster setup
- Part II: Gitlab pipeline and CI/CD configuration
- Part III: Applications and the Dockerfile
- Part IV: Kubernetes manifests
- Caveats and improvements to a PaaS built with Kubernetes and GitOps practices
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 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 :
| Features | Vercel | Heroku | 👋 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:
- Package the application in a Docker image.
- 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
- 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:
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 configuredingress.networking.k8s.io/api unchangedservice/api unchangedDeployment succeeded.URL: https://7c77eb36.nodejs.k0s.gaudi.sh/versionCleaning up project directory and file based variablesJob 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. ↑
