colinchartier

Postgres can be tuned to 10k inserts per second, Kafka is definitely overkill for 200/s

Reminds me of this video about the origin of the name Tiffany: https://m.youtube.com/watch?v=9LMr5XTgeyI

"I didn't fly across the Atlantic to... Of course I did"

Reminds me of the ghost Unicode character saga: https://www.dampfkraft.com/ghost-characters.html

Nested virt doesn't work with some things like OS snapshot/restore, so they might not support it to allow those features.

We got around this at my company by just pooling all of the LISTEN/NOTIFY streams into a single database connection in software, here's a sample implementation:

function software_listen(channel, callback):

  if not channel_listened(channel):

    sql("LISTEN " + channel)

  listeners[channel].append(callback)

function on_message(channel, data):

  for listener in listeners[channel]

    listener(channel, data)

function unlisten(channel, listener):

  listeners[channel].remove(listener)

  if len(listeners[channel]) == 0:

    sql("UNLISTEN " + channel)

Here's the actual go implementation we use:

https://gist.github.com/ColinChartier/59633c1006407478168b52...

As far as I understand, that's 100 shared queries across all users.

Paul Graham would say for exponential growth, 10x better is the bar

Sure, I meant "docker" here as a simplification for the OCI format.

Will add those to the landing page - they got lost in the Figma design

It looks like all of the auth data is empty - maybe you logged into an account which doesn't have permission to install on that repository?

If you email me at colin@webapp.io with your GitHub account name, webapp.io account (if any), and the name of the repository, I can take a look for you.

Practically - We don't actually require you to use Docker, and we don't use it under the hood. The configuration (which looks like a Dockerfile) can run multiple containers in the same VM:

FROM vm/ubuntu:22.04

RUN (install docker)

RUN REPEATABLE docker-compose build

RUN BACKGROUND docker-compose up

EXPOSE WEBSITE localhost:8080

You can also just run entirely non-docker services:

RUN BACKGROUND redis-server

- The DSL will watch which files are used for each build step to skip everything you haven't changed, so builds are much faster - You can use us to clone VMs and run Cypress tests in parallel, then promote one of the clones to a preview environment, and another to a production environment - We're more declarative (in my opinion), we don't have a CLI. Everything is done by editing a Layerfile and git pushing it

TL;DR, we focused on a declarative configuration format to quickly build, fork, and hibernate VMs, where Fly is more focused on building/shipping docker containers (though the products do fill a similar niche)

We do have a caching anycast proxy like fly, render, and other webapp-focused PaaS providers.

We don't actually host docker containers - the configuration DSL is based on Docker, but has crucial differences

In particular, you can do things like

RUN BACKGROUND docker-compose up

EXPOSE WEBSITE 8080

This is super important for most use-cases, since otherwise you have to deal with networking and version control.

It's two environments per unique account - though you can email support to prove you're a real person and get this moved up.

We haven't had to formalize any policies, but they'll be similar to other cloud free tiers:

- HTTP only (no terabytes of videos or images exclusively)

- No crypto mining

- No phishing sites

- No sending emails, attacking others, etc

We currently do about a million builds a year, so 99% of projects shouldn't cause problems for us.

We actually just migrated to NextJS this week - so there's still a few hairy bits with the frontend. Thanks for the report, should be fixed now.

Webapp.io's money making part (which facilitates this) is a DevOps company (CI/CD, preview environments, etc) which is already hammered with that sort of thing - see this post (from when we were called LayerCI) discussed by TravisCI for context: https://blog.travis-ci.com/2021-10-20-mining

Hey HN,

We recently finished our firecracker-based webapp hosting platform.

It's like if Vercel and Docker had a baby: You write VM configurations in a language that looks like a Dockerfile, and every commit creates a preview environment which can be "promoted" to a production site.

Here's an example configuration:

``` FROM vm/ubuntu:18.04 RUN curl -fSsL https://deb.nodesource.com/setup_12.x | sudo -E bash RUN apt-get install nodejs COPY . . RUN npm install RUN npm run build RUN BACKGROUND npm run start EXPOSE WEBSITE localhost:3000 ```

This product combines our firecracker-based hypervisor (200ms cold starts) with a global CDN written in Go (using Caddy for TLS termination)

We can offer everything for free because we charge for the DevOps side (CI/CD & preview environments) - we have no intention of getting users and then upselling people for hosting.

We're obviously very excited about this launch, and would love to hear your feedback.

This was the idea behind https://webapp.io (YC S20):

- Run a linear series of steps

- Watch which files are read (at the OS level) during each step, and snapshot the entire RAM/disk state of the MicroVM

- When you next push, just skip ahead to the latest snapshot

In practice this makes a generalized version of "cache keys" where you can snapshot the VM as it builds, and then restore the most appropriate snapshot for any given change.

Hey, yeah this looks somewhat similar to what we're building at https://webapp.io (nee LayerCI, YC S20)

We migrated to a fork of firecracker, but we're a fully hosted product that doesn't directly interact with GHA at all (similar to how CircleCI works), so there's some positioning difference between us and OP at the very least.

Always happy to see innovation in the space :)

Another benchmark by maintainer of Vue and Vite, Evan You: https://github.com/yyx990803/vite-vs-next-turbo-hmr

He seems to imply that Turbopack is very close in performance to existing tooling like Vite in his benchmark, and not 10x better in common cases

Edit: his thoughts as of this hour: https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussi...

Just sends me to a login page?

Everyone talks about NFT volume crashing, but how about prices?

It doesn't use a Dockerfile, Kata is a docker-compatible runtime that gives more isolation, Layerfile isn't compatible which lets you have `RUN BACKGROUND` and other VM-only logic that wouldn't otherwise be possible

It'd be nice to see historical trends too, in Canada banks will often raise their rates for ~3 months as a "promotion" before lowering them back down, which requires a lot of micromanagement

When I talked to prospective users, the big two that people wanted were:

1. Replacement for Vagrant / docker desktop - you'd hibernate your VM, check out someone else's branch, and start a new environment to avoid breaking your own

2. Run acceptance tests in a reproducible way, RUN docker-compose up // RUN ocker-compose run --rm acceptance-tests for example

GitHub: https://github.com/webappio/layerfiles

Single binary download (linux x64 only for now): https://github.com/webappio/assets/raw/main/lf

How does this compare with existing access control solutions like https://aws.amazon.com/cognito/ or auth0 rbac?

I tried to get docker layer caching working within GHA for a second benchmark, but it seems like none of the approaches work particularly well for a "docker-compose build" - I'd happily amend the post with a second benchmark if you wouldn't mind opening a PR based on the existing one [1]

https://github.com/webappio/livechat-example/blob/be7c9121c1...

The point still stands for 2c - you can super easily parallelize with firecracker (by taking a snapshot of the state right before the test runs, then loading it a bunch of times)

> Why do you need to snapshot live processes?

Often times there are long-living processes which rarely change but take a long time to warm up. The Bazel [1] agent for C++ projects, the buildkit [2] state for docker, or the running Postgres or Redis server for a cloud native app for example.

It's why running "docker build" twice on your laptop is so fast, but running "docker build" in CI seems glacially slow.

> why is docker-in-docker a requirement, and how is that easier than qemu in qemu or qemu in docker or whatever?

The example given was running "docker-compose build", so you'd need either docker-in-firecracker (this post), docker-in-docker, or docker-in-qemu. You'd almost never run docker-compose build on bare metal in practice, because you'd immediately need to send the images you built somewhere else in order to use them.

[1] https://bazel.build/ [2] https://docs.docker.com/develop/develop-images/build_enhance...

QEMU takes much longer to save/restore snapshots, and it's much harder to do via the API