Live data from Hacker News

Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

github.com

11–20 of 133 posts

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#11
post #2

DHH mentioned they built it to move from the cloud to bare metal. He glorifies the simplicity but I can't help thinking they are a special use case of predictable, non-huge load. Uber, for example, moved to the cloud. I feel like in the span between them there are far more companies for which Kamal is not enough. I hope I'm wrong, though. It'll be nice for many companies to be have the choice of exiting the cloud.

I feel Uber is the outlier here. For every unicorn company there are 1000s of companies that don't need to scale to millions of users.

And due to the insane markup of many cloud services it can make sense to just use beefier servers 24/7 to deal with the peaks. From my experience crazy traffic outliers that need sophisticated auto-scaling rarely happens outside of VC-fueled growth trajectories.

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#12
Can someone briefly explain how ZDD works in general?

I guess both versions of the app must be running simultaneously, with new traffic being routed to the new version of the app.

But what about DB migrations? Assuming the app uses a single database, and the new version of the app introduces changes to the DB schema, the new app version would modify the schema during startup via a migration script. However, the previous version of the app still expects the old schema. How is that handled?

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#13

Can someone briefly explain how ZDD works in general? I guess both versions of the app must be running simultaneously, with new traffic being routed to the new version of the app. But what about DB migrations? Assuming the app uses a single database, and the new version of the app introduces changes to the DB schema, the new app version would modify the schema during startup via a migration script. However, the previ…

Migrations have to be backwards compatible so the DB schema can serve both versions of the app. It's an extra price to pay for having ZDD or rolling deployments and something to keep in mind. But it's generally done by all the larger companies

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#14

Can someone briefly explain how ZDD works in general? I guess both versions of the app must be running simultaneously, with new traffic being routed to the new version of the app. But what about DB migrations? Assuming the app uses a single database, and the new version of the app introduces changes to the DB schema, the new app version would modify the schema during startup via a migration script. However, the previ…

Yes, both versions must be running at some point.

The load balancer starts accepting connections on Server2 and stops accepting new connections on Server1. Then, Server1 disconnects when all of its connections are closed.

It could be different Servers or multiple Workers on one server.

During that window, as the other comments said, migrations have to be backwards compatible.

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#16
post #10

I don't understand how to use this, maybe I am missing something. Following the example, it starts 4 replicas of a 'web' service. You can create a service by running a deploy to one of the replicas, let's say example-web-1. What does the other 3 replicas do? Now, let's say I update 'web'. Let's assume I want to do a zero-downtime deployment. That means I should be able to run a build command on the 'web' service, sta…

Why would I not just do k8s rollout restart deployment?

Or just switch my DNS or router between two backends?

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#17

Can someone briefly explain how ZDD works in general? I guess both versions of the app must be running simultaneously, with new traffic being routed to the new version of the app. But what about DB migrations? Assuming the app uses a single database, and the new version of the app introduces changes to the DB schema, the new app version would modify the schema during startup via a migration script. However, the previ…

First step is to decouple migrations from deploys, you want manual control over when the migrations run, contrary to many frameworks default of running migrations when you deploy the code.

Secondly, each code version has to work with the current schema and the schema after a future migration, making all code effectively backwards compatible.

Your deploys end up being something like:

- Deploy new code that works with current and future schema

- Verify everything still works

- Run migrations

- Verify everything still works

- Clean up the acquired technical debt (the code that worked with the schema that no longer exists) at some point, or run out of runway and it won't be an issue

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#18
post #10

I don't understand how to use this, maybe I am missing something. Following the example, it starts 4 replicas of a 'web' service. You can create a service by running a deploy to one of the replicas, let's say example-web-1. What does the other 3 replicas do? Now, let's say I update 'web'. Let's assume I want to do a zero-downtime deployment. That means I should be able to run a build command on the 'web' service, sta…

Why would I not just do k8s rollout restart deployment? Or just switch my DNS or router between two backends?

You still need some warm-up routine to run for the newly online server before the hand-off occurs. I'm not a k8s expert, but the above described events can be easily handled by a bash or fab script.

Re: Kamal Proxy – A minimal HTTP proxy for zero-downtime deployments

#20

Did they mention anywhere why they decided to write their own proxy instead of using Traefik or something else battle tested?

They were actually using Traefik until this "v2.0.0" (pre-release right now) version.

There are some context about why they switched and decided to roll their own, from the PR.

https://github.com/basecamp/kamal/pull/940

Post reply on HN