4 ms·
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
by Rauchg 8y ago
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.
- simonw 8y agoI 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.
- silverstrike 8y agoI 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.