DEV Community: Zerops

The rise of self-hosted PaaS — is $5 VPS all you need?

Aleš — Fri, 23 Aug 2024 06:08:12 +0000

There's a little trend going on over at the developer community on X, jokingly called "$5 VPS" — every time Vercel has an oopsie and sends someone a $100k bill, people jump to replies shouting, "Stop using Vercel, just buy this $5 VPS, I use it to handle 100k visits, no problem". So let's explore this trend and see what it really means.

When hosting apps in 2024, out of the many different options for hosting, you have these four major groups — big cloud, dev-focused PaaS, "frontend" focused platforms and VPS/VDS hosting. Honorable mentions are managed Kubernetes platforms and specialized managed hosting, where nearly any open source software offers some sort of cloud managed version. Lines between these groups are blurry, as many providers branch out into multiple categories.

A little bit of history

How did we get here? The pioneer in cloud hosting was Amazon, with their AWS in 2006, followed by Azure and Google Cloud in 2010. Meanwhile Heroku launched properly in 2009, offering a fresh take on the cloud, using Amazon's infrastructure but offering a more user-friendly and focused approach. In 2013 DigitalOcean was founded, creating a mix between VPS and managed solutions. In 2014/2015, Netlify and ZEIT (eventually rebranded as Vercel) were founded, specializing in building and hosting serverless and frontend apps. Around 2019 a new generation of developer friendly PaaS started gaining traction, with Render and Fly leading the charge. Many smaller / narrowly specialized hosting platforms were founded since, many building on top of others.

Rise of the cheap VPS and self-hosted PaaS

Now self-hosted PaaS on cheap hardware is getting popular. You can get 8 vCPU + 16 GB RAM server node for yourself for about 29.99 euro, that's surely enough to run everything one needs, right?

On top of that, nowadays there are many popular open-source PaaS alternatives.

And many dev-ifluencers are promoting them over PaaS.

The perfect solution?

Sounds great in theory, you get the cheap hardware and you get all the functionality of a PaaS for free through open source software. But let's break down a couple of main differences between self-hosted PaaS and PaaS:

1. You don't have to deal with the infrastructure

PaaS providers typically run hundreds or even thousands of robust server nodes or use Amazon's EC2 infrastructure to provision resources for your containers. You don't have to monitor the infrastructure, handle the OS / Kernel updates, deal with faulty hardware, you never touch the actual underlying infrastructure.

2. You get managed databases and storage solutions

PaaS providers usually offer managed or semi-managed, production-ready services like Postgres, Redis (or open-source alternatives like Valkey), and an S3-compatible storage solution.

3. Build servers, High availability & backups

It turns out that setting up a good infrastructure isn't easy, especially if you need to go beyond simple sites or apps. Your apps should be highly available with a load balancer in front of them, running on at least two containers, your primary database should run on at least three containers (write/read/read) with proxy load balancers in front. Each of these containers and load balancers should run on a different physical server. Storage should run on a different node. Your backups should be encrypted and saved on a different node. Builds should run on a different node.

With a self-hosted PaaS you are responsible for the underlying infrastructure, scaling capabilities of the platform software don't really matter that much, because you still have to scale the hardware yourself. The database services on self-hosted PaaS will likely be nothing more than Docker Compose containers spun up on demand. While this might be fine as long as you properly handle the underlying file system, it's not the ideal solution for a production database. Database services simply require a little bit more care. You might also end up in a situation where you have too much RAM and not enough CPU, since the underlying infrastructure is not granular enough. The actual utilization of the paid resources might also vary, since you can't scale automatically on the fly or start your build servers only when you need to run builds. And the more applications you have, the messier things can get.

But, can't you just run everything on a single server? Well, yes—especially if you're hosting only a couple of small, mostly static (or server-side generated/rendered) sites, and everything might work just fine. That is, until it doesn't.

Ultimately, it comes down to whether the cost is worth the extra features and the comfort of not dealing with the infrastructure at all, while having a setup you can trust to scale with your needs.

Price comparison

Price differences might vary a little across different use cases, and you usually you wouldn't probably need to use dedicated CPU for all services. But to make the comparison as accurate as possible, let's choose a medium-sized real-life production project with a typical setup and try to configure a similar setup for each provider, considering both features and resources. And when possible, dedicated or performance CPU cores will be used to normalize performance levels, as shared CPUs can have varying overcommitting ratios across different providers.

Reference setup

Prices for different providers

You can find the configuration details by hovering over the items on Zerops' website.

Zerops, the developer first PaaS

At Zerops, we recognize the need for an affordable PaaS. In the best-case scenario, what you'd want as a developer:

the ability to create as identical as possible, but also affordable environments for each project, one environment for development, one for production, even one for each developer to use locally
platform (and unified setup) that can support you no matter if you need to host a small static app, or a large project with multiple databases and microservices and anything in between
flexibility of VPS

An integral part of these requirements is that resources should be inexpensive, with all advanced features included by default. And so our vision is the perfect mix of developer experience, flexibility, robustness, and scalability, along with a pricing model that doesn't get in the way of good development practices.

You can get all the features you'd expect from a PaaS, but also automatic scaling, unified environments and prices of resources approaching those of cheap VPS providers.

This pricing applies equally to both simple and complex projects, regardless of whether they have low or high traffic.

A 10-minute walkthrough of Zerops

Our journey integrating Qdrant in Zerops

Zerops Devs — Thu, 22 Aug 2024 21:09:13 +0000

Vector databases are revolutionizing how data is managed and stored for AI applications. At Zerops, we recognized the growing importance of vector databases, leading us to integrate Qdrant, one of the most popular options available. While it might seem straightforward to spin up a Qdrant instance using a Docker container, the reality of managing a production-ready vector database is far more complex. In this article, we'll explore the intricacies of Qdrant implementation and how we've addressed the challenges at Zerops.

Understanding Data in Qdrant

In Qdrant, data is organized into collections, which are essentially named sets of vectors. Each collection contains vectors that share the same dimensionality and are compared using a specific metric. Collections in Qdrant are further divided into shards—independent stores of vectors that can handle all the operations provided by collections.

This architecture allows for distributing the workload across multiple Qdrant nodes in a cluster, enhancing performance and reliability. To ensure high availability (HA), shards can be replicated across nodes. Understanding this structure is crucial for grasping the complexities of deployment and management.

Deployment Options: Balancing Simplicity and Reliability

At Zerops, we offer support for both HA and non-HA modes of Qdrant, giving you the flexibility to choose the configuration that best suits your needs.

Non-HA Mode: Simplicity for Non-Production Projects

The Non-HA mode is perfect for non-production projects where data persistence isn't critical. This setup involves a single Qdrant node, making it easy to install and manage. In Zerops, deploying Qdrant in Non-HA mode is straightforward:

We run the Qdrant binary in a Ubuntu container.
Port 6333 is opened for communication.

Even if a data outage occurs, our backup solution ensures minimal disruption.

HA Cluster: Reliability for Production Environments

For production environments where reliability and data availability are crucial, the HA cluster mode is essential. Setting up an HA cluster can be complex, but we've streamlined the process in Zerops:

Cluster Configuration: We enable cluster mode by adding enabled: true to the configuration file and configure peer-to-peer communication on port 6335:

   cluster:
     enabled: true
     p2p:
       port: 6335

Node Setup: Building a cluster requires careful configuration of each node:
- The first node runs with a --uri <uri> flag to let other peers know how to be reached.
- We make the address of the first peer node1.db.<service_name>.zerops available in local DNS.
- All other peers start with the --bootstrap <cluster_uri> flag to locate the rest of the cluster.
High Availability: Qdrant uses the RAFT protocol, which requires more than 50% of the nodes to be functional. We automatically set up 3 nodes per cluster to meet this requirement.
Automatic Replication: By default, we automatically create replicas of any collection across all nodes. This safeguards against data loss if a node fails and serves as a safety net for incorrect replication_factor configurations. This approach ensures data safety even if the replication_factor is incorrectly configured by the user. If desired, this feature can be disabled by setting the automaticClusterReplication parameter to false.
Failure Recovery: If a node fails, we automatically start a new node, connect it to the cluster, and create replicas of each collection and shard on the new node.
Node Cleanup: We streamline this process by utilizing the Qdrant API to identify the current cluster Leader node, which then efficiently handles the removal of failed nodes.

Overcoming Technical Challenges

During the integration of Qdrant with Zerops, we encountered and solved several complex issues. Fortunately, Qdrant offers robust tools to monitor and manage clusters through its well-documented REST and gRPC APIs.

One issue we faced was that when a new node was added to the cluster, it appeared fully operational but couldn't receive new replicas. This is often due to ongoing data transfers between nodes, which can take considerable time. To address this, Qdrant provides the POST /cluster/recover endpoint, which can be triggered on any non-leader node. This endpoint sends a request to the current leader to create a snapshot. The leader then sends this snapshot back to the requesting node for application. This snapshot captures the cluster's agreed-upon state at a specific point in time, allowing the cluster to recover and synchronize.

Data Backup: Safeguarding Your Qdrant Data

At Zerops, we prioritize the safety and security of your data by providing:

Daily, automatic backups at no extra cost
Backups in the form of encrypted disk snapshots for each collection
Secure upload to our S3-compatible backup storage
Retention of up to 100 backups per stack for a maximum of one month
Current maximum storage size per project of 25 GiB

You also have the flexibility to choose between different backup options, including one-time backups, regular backups with a customizable frequency, or even disabling backups entirely.

Our backup retention policy is designed to provide comprehensive coverage. For example, if you back up every hour, you'll have up to 4 days of backups available. This ensures that you have access to recent versions of your data in case of any issues.

The Value of Managed Vector Databases

While it's possible to set up and manage Qdrant yourself, doing so properly requires significant expertise and resources. Our managed Qdrant solution allows you to leverage the power of vector databases without the operational complexities. You can focus on developing AI features, while we ensure your vector database is running optimally, is highly available, and is protected against data loss.

Ready to harness the power of vector databases without the operational headaches? Give Zerops a try