4 ms·

I've heard a lot of devs have very negative comments about Now 2, but have never delved into specifics. Apparently it's way worse than 1. Anyone here has any id

I've heard a lot of devs have very negative comments about Now 2, but have never delved into specifics. Apparently it's way worse than 1. Anyone here has any idea what, exactly, is wrong with it, and whether it's really bad?

ingenieroariel 8y ago
now 1 was very opinionated but got out of the way quickly, with mini al changes to your code (in my case golang) you were up and running, did it with a Dockerfile using scratch as a base, integration with github, autoscaling, multiple data centers. I ran a production app used by hundreds of mobile users every day and it ran for a year practically unsupervised. you were up and running. now 2 requires rearchitecting your applications, in golang it means one file per server path and for our application it meant it was easier to migrate to GCP using nixops.
pcr910303 8y ago
It’s not bad; it’s a different product. Now v1 was about dead simple deployments with no configuration, as now automatically configured that for you. Now v2 is about serverless (with minimal lockin, I’d say), and is a pretty good (actually pretty awesome) product if you see it alone. The problem is that Zeit wants to deprecate Now v1 in favor of Now v2, which is super different and is incompatible (Now v1 code should be appropriately configured to use the `@now/node-server-builder` to run on the v2 platform). I believe that Zeit should keep these two products as different names, something like ‘now classic’ and ‘now serverless’.
simonw 8y ago
They're very different products. Now v1 was essentially serverless Docker: you define a Dockerfile that runs a web server on a port (along with anything else you can cram into that container), push that Dockerfile up to Now v1 and they would build the container and run it in a scale-to-zero configuration: with no traffic, the container wouldn't run at all. When a request came in it would start up and start serving - then it would shut down again a few minutes after the last incoming request. It was very similar to Google's new Cloud Run product - but better, because you didn't even have to build the Dockerfile yourself - they would build and run it for you. The biggest catch with v1 was the cold-start time: depending on the size of your image it could take quite a while to serve that first hit. Their efforts to optimize this apparently didn't work out well enough for them. Now v2 is an entirely different product. It doesn't use Docker at all - instead it compiles your code to run on AWS Lambda. This means it's MUCH less flexible: with Now v1 you could run anything that could be defined in a Dockerfile - Now v2 instead requires you to stick to the list of languages supported by their "builders" - https://zeit.co/docs/v2/deployments/builders/overview https://zeit.co/docs/v2/deployments/builders/overview - initially available for Node.js, Python PHP and Go but more have emerged over time. Now v2 also has the ability to run a single app built in multiple languages - it compiles each language to a separate Lambda. This is a neat technical trick but it's not something most people are actually keen on using in my opinion. My biggest problem with v2 is that you have to write software that specifically targets it. With v1 I could take any web application that can run in a Dockerfile and deploy it instantly with no changes. v2 requires me to write code that directly targets the Now v2 system (hence why the initial lack of "now dev" was so painful). My second biggest problem with v2 is that the AWS Lambda build of Python 3 doesn't currently ship with the sqlite3 module, which is key to many of my projects. From my perspective, Now v1 was genuinely my dream hosting environment. Now v2 is an interesting project, and it's great if your project is one that fits the AWS Lambda model well, but it's no-where near as appropriate for my projects as v1 was.
- omnimus 8y ago
  I am curious what use would sqlite3 module be in Lambda function? Lambda has no persistency so you cant really use sqlite no?
  - simonw 8y ago
    Read-only databases: https://simonwillison.net/2018/Oct/4/datasette-ideas/#Publishing_readonly_data https://simonwillison.net/2018/Oct/4/datasette-ideas/#Publis...
    - mayank 8y ago
      This is a great point. For small to medium, read-only, slowly changing datasets, this is the ultimate serverless database model, especially for lots of queries. Although I think this approach would benefit more from Cloud Run’s request multiplexing per function.
  - ecnahc515 8y ago
    I imagine you could load something from an endpoint like s3 or an API in one format, load it into sqlite, then begin processing it using SQL. Results could be posted back to another API or S3 in any format.
    - omnimus 8y ago
      Oh for sure but then you are creating what seems like very strange inefficient clouddb.

ingenieroariel 8y ago

now 1 was very opinionated but got out of the way quickly, with mini al changes to your code (in my case golang) you were up and running, did it with a Dockerfile using scratch as a base, integration with github, autoscaling, multiple data centers. I ran a production app used by hundreds of mobile users every day and it ran for a year practically unsupervised. you were up and running. now 2 requires rearchitecting your applications, in golang it means one file per server path and for our application it meant it was easier to migrate to GCP using nixops.

pcr910303 8y ago

It’s not bad; it’s a different product. Now v1 was about dead simple deployments with no configuration, as now automatically configured that for you. Now v2 is about serverless (with minimal lockin, I’d say), and is a pretty good (actually pretty awesome) product if you see it alone. The problem is that Zeit wants to deprecate Now v1 in favor of Now v2, which is super different and is incompatible (Now v1 code should be appropriately configured to use the `@now/node-server-builder` to run on the v2 platform). I believe that Zeit should keep these two products as different names, something like ‘now classic’ and ‘now serverless’.

simonw 8y ago

They're very different products. Now v1 was essentially serverless Docker: you define a Dockerfile that runs a web server on a port (along with anything else you can cram into that container), push that Dockerfile up to Now v1 and they would build the container and run it in a scale-to-zero configuration: with no traffic, the container wouldn't run at all. When a request came in it would start up and start serving - then it would shut down again a few minutes after the last incoming request. It was very similar to Google's new Cloud Run product - but better, because you didn't even have to build the Dockerfile yourself - they would build and run it for you. The biggest catch with v1 was the cold-start time: depending on the size of your image it could take quite a while to serve that first hit. Their efforts to optimize this apparently didn't work out well enough for them. Now v2 is an entirely different product. It doesn't use Docker at all - instead it compiles your code to run on AWS Lambda. This means it's MUCH less flexible: with Now v1 you could run anything that could be defined in a Dockerfile - Now v2 instead requires you to stick to the list of languages supported by their "builders" - https://zeit.co/docs/v2/deployments/builders/overview https://zeit.co/docs/v2/deployments/builders/overview - initially available for Node.js, Python PHP and Go but more have emerged over time. Now v2 also has the ability to run a single app built in multiple languages - it compiles each language to a separate Lambda. This is a neat technical trick but it's not something most people are actually keen on using in my opinion. My biggest problem with v2 is that you have to write software that specifically targets it. With v1 I could take any web application that can run in a Dockerfile and deploy it instantly with no changes. v2 requires me to write code that directly targets the Now v2 system (hence why the initial lack of "now dev" was so painful). My second biggest problem with v2 is that the AWS Lambda build of Python 3 doesn't currently ship with the sqlite3 module, which is key to many of my projects. From my perspective, Now v1 was genuinely my dream hosting environment. Now v2 is an interesting project, and it's great if your project is one that fits the AWS Lambda model well, but it's no-where near as appropriate for my projects as v1 was.

omnimus 8y ago
I am curious what use would sqlite3 module be in Lambda function? Lambda has no persistency so you cant really use sqlite no?
- simonw 8y ago
  Read-only databases: https://simonwillison.net/2018/Oct/4/datasette-ideas/#Publishing_readonly_data https://simonwillison.net/2018/Oct/4/datasette-ideas/#Publis...
  - mayank 8y ago
    This is a great point. For small to medium, read-only, slowly changing datasets, this is the ultimate serverless database model, especially for lots of queries. Although I think this approach would benefit more from Cloud Run’s request multiplexing per function.
- ecnahc515 8y ago
  I imagine you could load something from an endpoint like s3 or an API in one format, load it into sqlite, then begin processing it using SQL. Results could be posted back to another API or S3 in any format.
  - omnimus 8y ago
    Oh for sure but then you are creating what seems like very strange inefficient clouddb.