Comment by simonw | Hacker News Reader

Comment by simonw | Hacker News Reader

This is a really cool product - but it's a very different beast from Now 1.0.

Now 1.0 really was my perfect deployment tool: you can HTTP POST it a Dockerfile and it will build that container for you, start it running and start routing HTTP traffic to it.

This means you can use it for essentially anything that can be expressed in a Dockerfile. And the Dockerfiles you use work anywhere that runs Docker, so local development is really simple.

Now 2.0 is a totally different thing. It's a way of running HTTP fronted lambda-style functions written in Go, Node, Python or PHP. It looks like you can add other platforms by writing a new builder but there aren't any community-driven examples of that just yet.

It's cool, but it's a completely different product from Now 1.0 - and for my particular use-cases (my Datasette project and serving machine learning models) it sadly doesn't appear to be suitable.

I kind of wish this was called something else - "Zeit Lambda" perhaps - and old Zeit Now with the Dockerfiles could live on as a separately named project (rather than being the legacy earlier version of Zeit Now).

We are quite confident that 2.0 can meet all the customer needs of 1.0, but going far beyond in terms of scalability, at a much lower cost.

A great example of this is "doing work in a loop". Sure, you can spin up a process and try to schedule work yourself. At that point you're responsible for monitoring, and addressing all its failure modes.

In the 2.0 world-view, you can delegate a lot of the tough synchronization and scalability problems to the platform instead.

I think the main problem I'm having is that 1.0 was already cheap enough and scalable enough for my specific use-cases.

I totally understand how 2.0 is cheaper and more scalable, but the trade-offs are that it's much less suitable for serving occasional requests for data that depends on large server-side files (in my case machine learning models and SQLite databases, both which can be 100s of even 1000s of MBs).

I guess what I'm saying is that for my specific use-cases I don't need a Now that's cheaper and scales more easily - 1.0 already had the performance and price that I needed.

Now 2.0 (or Now Lambdas) do look amazing for cheaply handling a vastly scalable amount of incoming requests that don't need to work with a large blob of data on the server. Now v1 remains my perfect environment for hosting scale=1 persistent servers that can serve those large data blobs. I'm finding it hard to imagine a platform that can combine the best of both worlds - but I'm exciting to see if you can indeed pull it off with 2.0.

I loved Now 1.0, disappointed in 2.0. It's not accurate that all customer needs of 1.0 can be met. There are size limits deploying to AWS lambdas. Web sockets don't work in lambda. Caching is a different game if your functions can spin up and down often, not to mention no sticky sessions. DB connection limits become more relevant if you have a bunch of endpoints and put them all on their own lambdas since they can't share connections.

There's value in distributed architectures, but there are already lots of ways to add that complexity when you need it. I really liked what Now 1.0 was doing (more user-friendly than hyper.sh), so this makes me somewhat sad.

There are very cheap competitors such as Apex Up for managing AWS lambdas if people want to go that route.

I hope I'm wrong about some of the above and you have plans I'm simply not foreseeing to address these issues.

Running docker daemons that handle arbitrary code in a multi-tenant scenario is a security and scaling nightmare. I don't blame them for trying to get out of the morass.

Reply on news.ycombinator.com