colinchartier

Just a rebranding! (The technology's gotten better as well, of course - we didn't used to use firecracker at all)

https://webapp.io/blog/layerci-has-rebranded-to-webapp-io/

Author here!

I think there's always been a push/pull of "fat base images" versus "install everything every time" - It's obviously subjective, but I think it's more important to run the tests on every commit than it is to start the environment from scratch.

It's also not necessarily mutually exclusive, you could have a "staging branch" where you make something that looks a lot like production and then re-run end-to-end tests there, while running the per-branch tests with this method to avoid slowing down developers.

Author here!

The three big differences are:

1. Docker doesn't deal with running processes (like postgres or redis), only the filesystem state

2. Docker doesn't have enough isolation, so you'd probably need to run it within qemu or firecracker for compliance in bigger teams

3. Docker-in-docker is still pretty painful, if you need to do anything nonstandard like change the size of /dev/shm, access /dev/kvm, or load kernel drivers, it'll take custom configuration.

Never saw that one before, incredibly unfortunate for the families that lived there

When you say "8+ seconds", is that the startup time for the postgres instance?

I went to university with these folks, they worked with Hinton and wrote the transformers paper (T in GPT) - just wanted to mention that there is real tech behind all of the marketing speak

The odds that you would exist to perceive yourself existing, however, are 100%.

Me and a friend have been working on this small framework that wraps esbuild (https://esbuild.github.io/), it adds a few javascript tags like <Router> and <Head>, then pre-renders pages with headless chrome and spits out a high performance webserver that can forward traffic to another website.

It's built so that you can do "start": "concurrently 'greenjs start -upstream-addr :8000' 'rails dev'" or equivalent for another web framework

The default postgres one, serializable (if I remember correctly?)

10ms or so

Since it's pub/sub, you just need one misbehaving client that LISTENs in a transaction to have problems, the other clients can still receive and process the NOTIFY event

I should've clarified, the database handles more than just the "regular" pub/sub, some of the tables have over a billion rows.

Ah, the database does a lot more than just pub/sub - especially since the high traffic pub/sub goes through redis. I guess my point was that we never regretted setting up postgres as the "default job queue" and it never required much engineering work to maintain.

For an example, it handles stripe webhooks when users change their pricing tier - if you drop that message, users would be paying for something they wouldn't receive.

Such a server is 400$/mo, a backend developer that can confidently maintain kafka in production is significantly more expensive!

Didn't want to deal with ramifications of statement timeouts in a complex system, the failure mode mentioned (queue filling up) happened on the scale of 6 weeks, so it was very cheap operationally to set this timeout to some high value.

Author here! A few updates since this was published two years ago:

- The service mentioned (now called https://webapp.io ) eventually made it into YC (S20) and still uses postgres as its pub/sub implementation, doing hundreds of thousands of messages per day. The postgres instance now runs on 32 cores and 128gb of memory and has scaled well.

- We bolstered Postgres's PUBLISH with Redis pub/sub for high traffic code paths, but it's been nice having ACID guarantees as the default for less popular paths (e.g., webhook handling)

- This pattern only ever caused one operational incident, where a transaction held a lock which caused the notification queue to start growing, and eventually (silently) stop sending messages, starting postgres with statement_timeout=(a few days) was enough to solve this

Previous discussion: https://news.ycombinator.com/item?id=21484215

Happy to answer any questions!

Title should say S12 instead of S21, no?

I've talked to a bunch of startups that are using rrweb behind the scenes - onboarding, product feedback, etc all need some variant of this functionality.

> Lumber tariffs had prices already rising a year ago, but then when the pandemic hit, production shut down. The expectation was that housing demand would dry up for a long time. But instead, after a brief pause, it came roaring back.

How can this be the case when lumber prices are surging in Canada as well? You'd expect that if the price was in response to tariffs then the origin country would be flooded with supply?

Hey HN,

Lots of people need help with optimizing "npm run build" time, so I built this analyzer - it looks at source lines of code (versus the bundled size for something like bundlephobia) so that you can tell what packages are causing your lint/build/install/... to take so long.

It's open source: https://github.com/layer-devops/node-dir-stat

Glad you overcame it all in the end - we're happy users, especially given the outstanding uptime for the past few years.

It must be very stressful to run a production hosting company - DigitalOcean and Cloudflare both went through similar issues in the early days.

This is really cool, I love these little tech experiments that keep the "hacker" in "hacker news" :)

I realize that the thread is even by the same author as OP as well!

My YC company is a GitHub app [1] and the "act on your behalf" thing is just a really poorly written message for the new (github apps vs oauth apps) apps interface. There's even a hilarious thread on the github forum itself about "act on your behalf" when all it requests is your email and avatar [2]

Ironically the newer apps system does have fine grained permissions, but seems more intrusive because of the strange wording

[1] https://LayerCI.com

[2] https://github.community/t/why-does-this-forum-need-permissi...

Hey, this looks really cool.

In my line of work [1] I talk to a lot of developers about productivity, here are some questions about what you've built in the context of that experience:

1. I think (as you mentioned) "number of commits" or "number of pull requests" merged are proxies for productivity at best. Most teams that I've seen care more about "are the tasks for the epic being chipped down" - is that something your tool can help estimate as well? The progress bar for the epic? It'd be nice to get a table of the metrics and where they come from.

2. In the same vein, "scrum with epics" might not always be how teams decide on units of work, do you support other methodologies?

3. You mention deployment frequency a lot, but that seems tangent to developer productivity - Isn't getting things deployed quickly mostly for the benefit of the product folks? (getting feedback faster)

4. How does maintenance work fit into this? Does a developer who spends most of their time refactoring show up with "worse metrics" than someone pushing copy changes to the landing page?

[1] CEO @ https://layerci.com (YC S20)

"picked off fast" is perhaps a bit generous - there are lots of great companies that got to series A without seeing a single "top VC" term sheet. I see angel investing as a way to connect with new founders that have a lot of potential, and help them accelerate their path to a billion dollar valuation.

For an interesting middle ground, I'd recommend one of our investors, https://fundersclub.com - they let you get in early on YC deals as an individual, and stay connected / give advice to companies you end up being an LP in

The stack I'd recommend is a mixture of containers and cloud-native "transparent" assets, so something like ECS + RDS + a CDN + DNS-based service discovery is a good middleground.

RDS is an excellent example of a cloud-hosted service that implements an open standard. Even if your production uses RDS, you could still reproduce bugs somewhat easily using a postgresql docker container seeded with something similar to production data.

Stacker is great, most polished product in this space for sure - much better than building admin dashboards.

We monitor which files are read by which steps and map that back to the changes you've made automatically!