A serverless future

This post is more than a year old. The contents and recommendations in this blog could be outdated.
Florian Forster
Florian Forster

Founder and CEO

  1. Definition of serverless
  2. Why we think serverless is a thing
    1. Easier global scaling
    2. Easier deployment for developers
    3. Kubernetes compatibility
  3. How we are (working on) harnessing serverless
  4. The challenges
  5. The gains
  6. What will improve with ZITADEL v2
  7. When is v2 due to release
  8. What's next

Definition of serverless

When people talk about serverless it is oftentimes not clear what they mean exactly. So let's begin with shining a light on what we think of when we talk about serverless.

For us, serverless is the possibility to run ZITADEL without the need to manage the underlying computing, networking and storage.

From our perspective there are two options we would classify as serverless: Firstly, function as a service (FaaS) offerings and secondly container as a service (CaaS) or you can call the latter serverless containers. Some serverless containers are run on top of managed Kubernetes offerings with the help of Knative.

Why we think serverless is a thing

Since our early days we committed ourselves to containers and Kubernetes to run and deploy ZITADEL. Be it with customers or our public cloud offering. In the last few months three points, which needed to be addressed, did come to our attention because we asked ourselves how we could reduce our operation expenses while still being able to scale.

Easier global scaling

As mentioned earlier, we run ZITADEL distributed across the globe to give our customers the best latency available. But with the rising need for new points of presence, we experienced that the management (updating, scaling, …) of multiple Kubernetes clusters gets quite annoying. Not even taking into account that we also needed to deploy our observability toolings and ZITADEL at scale as well.

Easier deployment for developers

Many of our users did ask us, if it is possible to run ZITADEL without Kubernetes, especially for small deployments or developers who want to run ZITADEL locally. We totally understand that it is not feasible for many people to operate Kubernetes. Even with platforms like Ranchers k3s and kubeadm, alongside the hyperscalers offerings from Google's GKE over Amazon's EKS to Microsoft's AKS.

Kubernetes compatibility

While we want to provide alternatives to Kubernetes usage we still want our customers to have the option of running ZITADEL on their existing clusters.

With those three points in mind we set off to create a solution that can improve the way somebody can run and scale ZITADEL to new heights.

How we are (working on) harnessing serverless

Although we are not yet running our production with a serverless service, we have been testing one for many months with our internal environments. We chose to thoroughly test Google's serverless containers offering which is compatible with Knative which is called “Google Cloud Run”. This, because it allowed us to address all of the three goals which triggered this journey.

Scaling: We can deploy ZITADEL across the globe (> 26 Regions) with a few lines of Terraform within mere minutes

Deployment: We can run a dedicated ZITADEL with little fixed cost with “Google Cloud Run” and “CockroachDB Cloud serverless” offering

Compatibility: While being fully serverless, ZITADEL still stays completely compatible with Kubernetes

Customers that wish to self-host ZITADEL can either choose to leverage the Google Cloud Run setup, as we use it in our cloud service, or use any of the alternatives, namely running on any CNCF-compliant Kubernetes or even as binary.

The challenges

To make ZITADEL run great on serverless offerings we needed to address some challenges.

Scheduled Tasks: Some of the processes of an IAM happen on a scheduled basis and we need a way to address this without relying on an external system. So as of today we recommend keeping at least one instance of ZITADEL running. With Cloud Run this can be easily solved by setting the “minimal instance” property to something like > 0.

Async Tasks: When ZITADEL is invoked some of the requests are run asynchronously. To cater for this it makes sense to tell the serverless platform to allow CPU usage after a request finished. With Cloud Run you can enable “always-on” CPU allocation. This allows ZITADEL to finish certain tasks. For example writing traces, calculating read models and so on.

The gains

Observability: Although not serverless specific, the integration of Cloud Run in Google's observability stack is impressive. For example out of the box opentracing works and provides the traces from the load balancer towards ZITADEL.

Scaling: Cloud Run allows you to scale horizontally (more containers) and/or vertical (more CPU/Memory) in combination with the cloud load balancer it even allows to create multiple deployments in parallel to even further scale either inside or across multiple regions.

Worldwide: As already mentioned with a few lines of Terraform it is possible to run ZITADEL across multiple regions with ease. All of this without the need to manage the deployment target.

Testing: Cloud Run already allows A/B testing where a percentage of requests are steered towards a newer version. While this is useful we use this feature in conjunction with the load balancers capabilities to route certain domains to a specific release.

Cost: Even though ZITADEL is configured to be always running with at least one container, Cloud Run makes for a cost effective solution. This is because the initial cost of running a new datacenter is relatively low (less than $60 per region).

What will improve with ZITADEL v2

As you might be aware, we are currently working on a major update of ZITADEL. Some of that work is specifically geared towards improving ZITADEL for serverless containers as well as the option to run it locally without any containers as self-contained binary.

With the release of v2 we will add support for the following features:

To improve the life of developers who want to run a local ZITADEL we also release the following improvements

  • Self-Contained Binary so that ZITADEL works without running in a container
  • Additional CPU Architectures (ARM64)
  • Additional OS support (MacOS, Windows)

When is v2 due to release

The initial release of v2 is just around the corner and is aimed towards the end of April - early May.

If you are interested in participating in our early adopter program and the new pricing, please send us a message.

What's next

We will soon publish the new pricing and some more blogs and information about the v2 of ZITADEL on our website that we will also link in this section. So stay tuned.

If you want to catch us live you will find us at the following events in the near future:

Of course if you want to get in touch, feel free to contact us or join our chat.

Liked it? Share it!