8 ms·

I gave up on Zeit when Now v2 came out because, besides it being more complex and a pain to migrate to, they went back on their promises about no vendor lock-in

I gave up on Zeit when Now v2 came out because, besides it being more complex and a pain to migrate to, they went back on their promises about no vendor lock-in. Up until late 2018, their site had a very different philosophy that they abruptly abandoned. [1] [2] Fool me once... 1: https://web.archive.org/web/20181107092845/https://zeit.co/now#future-proof https://web.archive.org/web/20181107092845/https://zeit.co/n... 2: https://web.archive.org/web/20181107092845/https://zeit.co/now#why-not-aws-lambda-azure-google-cloud-functions https://web.archive.org/web/20181107092845/https://zeit.co/n...

DagAgren 6y ago
Same here. Migration path to Heroku was easier than migration path to Zeit v2, and Heroku hasn't fucked me over by forcing me to migrate to an entirely new model yet.
- sholladay 6y ago
  I also went to Heroku. Icing on the cake was when I discovered that even on Heroku's free plan, we were getting significantly better performance than on Zeit's paid plan. Response times were more stable and had far less latency. Made me really happy and almost made it worth the frustration of having to migrate in the first place. Almost. Heroku has definitely improved over the years.
baxuz 6y ago
I honestly don't understand this fetishization of "serverless" functions. It leads to so much vendor lock-in, tooling complexity, and straight-up lack of features.
- zoul 6y ago
  For me as a noob with very simple requirements, it’s very refreshing not having to care where and how my server code runs. Just add to a repo, push and forget. And if my code is written against some simple HTTP request interface, there shouldn’t be much trouble to move it elsewhere.
  - baxuz 6y ago
    I've recently had a simple requirement. To build a site with content gated behind a paywall. There's no way to have SSR'd gated content without paying a gazillion bucks to either netlify or next for role-based redirects. Even if I would go for CSR'd content for the gated part, I'd have to fiddle with JWT tokens. To handle users, I'd have to use a 3rd party service such as oauth, since zeit doesn't support users, and netlify's model is severely limited. For a CMS, I'd have to again go for a subscription model. Data and APIs are also another issue. There is no way to use something like Strapi since that needs to have a real DB behind it. Now, to orchestrate the users for role-base redirects, oauth, payment gateaway data and everything else... I've no idea where to even start.
    - inapis 6y ago
      Ghost? They recent rolled out inbuilt memberships. Wont work if you are selling one time access though.
    - searchableguy 6y ago
      Don't. Just use a real backend. btw, Hasura can work with Google cloud run and heroku. Check it out. It's similar to strapi.
      - nunopato 6y ago
        Nhost (https://nhost.io/ https://nhost.io/) is another option for Hasura.
        lucasverra 6y ago
        have you used this in production ? any recco ?
    - rpeden 6y ago
      Wouldn't WordPress with a couple of plugins solve the content with a paywall problem in about 15 minutes? I'm not asking that flippantly. And I know there are plenty of reasons not to use WP, so I apologize if this is a dumb question. It just seems like WP might solve that particular problem for you without much work. And it solves other problems too, like managing users and tracking revision history for every piece of content. I think Digital Ocean has a one click setup for WordPress. WP isn't my favorite software to work with as a developer, but I use it when it's the right took for the job because for the most part, I've been able to deploy it and forget about it because it has just kept chugging along and getting the job done without any intervention from me.
- danharaj 6y ago
  Serverless is just zoomer Common Gateway Interface for venture capitalists
- dfee 6y ago
  You trade known deployment problems for unknown infra management problems. You reduce the complexity of contribution significantly. If you’re at a company that wants to manage K8s, and you’ve chosen to invest in that direction, then serverless doesn’t make a lot of sense. If your customers aren’t buying compute, then you should be wary of large investments that are outside your core focus. Sure, there are quite a few problems with lambdas. But the abstraction you’re working at is much more atomic. And you don’t need FTEs to manage K8s and introduce a completely new set of problems. Less is more (is the argument).
  - manigandham 6y ago
    You don't need serverless/FaaS for that. PaaS has existed for a long time, and many providers will now let you run any container image which is a lot more portable than custom frameworks. Zeit v1 actually did this.
- wpietri 6y ago
  I think there are legitimate use cases. E.g., I needed to help somebody with a little glue between Twilio and a SaaS tool. It was really nice to take a couple of functions, turn them into endpoints, and know that Amazon was going to worry about keeping them always available. I agree it's so far wildly overblown, but I get that too. A lot of people are scared by ops, and "serverless" promises they don't have to think about it. For those of us comfortable with ops, even the name is an obvious lie. But for people who just have some code they want to run, getting it usefully deployed is still too hard. Right now I feel like we're in a transitional era. The old model of individual single-purpose or multi-purpose servers is obviously inadequate. "Virtual server" is like "horseless carriage"; we know that the old paradigm is wrong, but we haven't found the new one. There are lots of contenders, but it seems like none of them have nailed it. The similar era for automobiles was circa 1900, where steam, electric, and internal combustion were all duking it out, with dozens of small manufacturers. I'll be very interested to see what we consolidate around.
  - deleted 6y ago
    [deleted]
- minieggs 6y ago
  To offer another perspective... I've migrated services to/from Now v2 (never used v1). While recently moving a Go service off (to a regular server) all that was changed was some bash that executed in a pre-deploy hook and the `now` command was swapped for a `scp`. `sed 's/package main/package handler/g'`. Of course, this is much simpler if the services are created with migration in mind. I like to think of the builder options put in the `now.json` file as I would a webpack config.
- dzonga 6y ago
  people are in love with engineering but not shipping paid products. a rails | django | laravel developer is busy shipping. while someone is busy developing 1000s microservices. n that's before the complexity of react, redux n graphql
- justrudd 6y ago
  I built an ETL on top of AWS Lambda. I had to pull data from Facebook/Instagram, YouTube, Twitter, and Pinterest on a schedule - once an hour. The pipeline took about 3 minutes to run. I used a CloudEvent cron to kick it off, a few lambdas, stored the raw data in S3, had another lambda massage that data, stored the final data into S3, and put a message into SQS letting my OLTP system know that it could bring it in. Worked great. Were there other ways to build it? Sure. Could have done it on the same hosts that my OLTP system was running on. But the amount of memory it used for that 3 minutes doubled the amount that was needed on the host normally. Yes I could have optimized it. But my time was better spent figuring out other issues (I was sole developer on the project). So I just broke it into a bunch of different parts and kicked up to Lambda. Worked great. Never had any issues with it. Never worried about not having resources. I think it cost .2 to .8 USD each run? So ~600 USD a month at the high end. And it took me less than a day to break it up and get it running vs who knows how long to optimize. So it definitely solved a problem I had in a very efficient way, and allowed me to speed it up just by spending money.
- yencabulator 6y ago
  > It leads to so much vendor lock-in Only if your chosen vendor designed for that lock-in. Google Cloud Run is serverless that just runs whatever container serving HTTP you throw at it, no "lambda functions" needed.
  - richardkmichael 6y ago
    No horse in this race, but isn't "serverless" via containers on AWS done with Fargate?
snow_js 6y ago
Now v1 was such an awesome abstraction, I was inspired to recreate the CLI on top of Kubernetes, to avoid any vendor lock-in. I also needed v1 capabilities like websocket support that went away with the v2 lambdas. This CLI utility has support for a few major cloud Kubernetes providers. https://github.com/snowjs/cli https://github.com/snowjs/cli
- lewi 6y ago
  Oh damn. This is awesome, will have to give it a go.
- RonanTheGrey 6y ago
  Concur, if you're looking for a replacement for the old Now v1, snowjs is a great option. Haven't used it extensively since we moved away from Now, but when I was investigating alternatives I came across this and gave it a go and was very pleased. Ultimately we went another way but it is a solid project.
- palmdeezy 6y ago
  This looks great!
RonanTheGrey 6y ago
I was an early adopter of Now v1 and loved it. I evangelized it to all my clients, used it on every project - it was such a breath of fresh air that deploying a server was now so easy. Ok, I get that serverless is a different paradigm. And I understand the arguments for it. But I refused to use Now v2 precisely because they violated their promises they had made -- but worse, turned it into "just another AWS". If I want serverless, I'll use AWS because frankly Zeit/Vercel's visibility into what is going on is just abysmal. And FWIW we now have several projects running on serverless -- using Next.js -- on AWS. Using the severless component, it requires NO special considerations and could easily be redeployed on a standard server in minutes. No vendor lock in, funny how that worked out? I expected to be locked in on AWS serverless. That didn't happen. The icing on the cake was when they didn't officially deprecate v1, but made it so unstable, so unusable, that I got to the point of spending DAYS per week deploying and redeploying and redeploying our docker containers because their servers would randomly decide that the hosting server no longer had a network connection. If I see E_AGAIN one more time I'm going to spit. And then they upped the price from $20/mo that we were paying for 4 containers, to $150. Thanks guys. It left such a bad taste in my mouth that I spent a day, redid everything to deploy on AWS EB, and haven't looked back since. That was the LEAST amount of time I'd spent on that, in a given week, for about a 4 month period prior. To be fair, the guy running Zeit/Vercel's support is pretty solid. He did try to be helpful. My experience with the technical leadership has been left lacking. We tried several times to contribute to Next.js and were treated like idiot children because how dare we trample on their kingdom. If you're not a tech bro, stay in your lane! Look I'm just sharing my experience over there. It has been roundly negative. I'm sure others can come with anecdotes of it being roundly positive, good for you. Mine is just another anecdote but it's the only insight I have. Although, the 1500+ comment thread on Spectrum when they announced v2 strongly suggests I'm not alone.
- arist0tl3 6y ago
  Hey, I'm curious about your migration. Can you contact me via my profile?
- travltalk 6y ago
  Also felt the pain of daring to ask a 'stupid' question and being firmly reminded I'm not a techbro. Rather I'm a proud techhoe :-)

DagAgren 6y ago

Same here. Migration path to Heroku was easier than migration path to Zeit v2, and Heroku hasn't fucked me over by forcing me to migrate to an entirely new model yet.

sholladay 6y ago
I also went to Heroku. Icing on the cake was when I discovered that even on Heroku's free plan, we were getting significantly better performance than on Zeit's paid plan. Response times were more stable and had far less latency. Made me really happy and almost made it worth the frustration of having to migrate in the first place. Almost. Heroku has definitely improved over the years.

baxuz 6y ago

I honestly don't understand this fetishization of "serverless" functions. It leads to so much vendor lock-in, tooling complexity, and straight-up lack of features.

zoul 6y ago
For me as a noob with very simple requirements, it’s very refreshing not having to care where and how my server code runs. Just add to a repo, push and forget. And if my code is written against some simple HTTP request interface, there shouldn’t be much trouble to move it elsewhere.
- baxuz 6y ago
  I've recently had a simple requirement. To build a site with content gated behind a paywall. There's no way to have SSR'd gated content without paying a gazillion bucks to either netlify or next for role-based redirects. Even if I would go for CSR'd content for the gated part, I'd have to fiddle with JWT tokens. To handle users, I'd have to use a 3rd party service such as oauth, since zeit doesn't support users, and netlify's model is severely limited. For a CMS, I'd have to again go for a subscription model. Data and APIs are also another issue. There is no way to use something like Strapi since that needs to have a real DB behind it. Now, to orchestrate the users for role-base redirects, oauth, payment gateaway data and everything else... I've no idea where to even start.
  - inapis 6y ago
    Ghost? They recent rolled out inbuilt memberships. Wont work if you are selling one time access though.
  - searchableguy 6y ago
    Don't. Just use a real backend. btw, Hasura can work with Google cloud run and heroku. Check it out. It's similar to strapi.
    - nunopato 6y ago
      Nhost (https://nhost.io/ https://nhost.io/) is another option for Hasura.
      - lucasverra 6y ago
        have you used this in production ? any recco ?
  - rpeden 6y ago
    Wouldn't WordPress with a couple of plugins solve the content with a paywall problem in about 15 minutes? I'm not asking that flippantly. And I know there are plenty of reasons not to use WP, so I apologize if this is a dumb question. It just seems like WP might solve that particular problem for you without much work. And it solves other problems too, like managing users and tracking revision history for every piece of content. I think Digital Ocean has a one click setup for WordPress. WP isn't my favorite software to work with as a developer, but I use it when it's the right took for the job because for the most part, I've been able to deploy it and forget about it because it has just kept chugging along and getting the job done without any intervention from me.
danharaj 6y ago
Serverless is just zoomer Common Gateway Interface for venture capitalists
dfee 6y ago
You trade known deployment problems for unknown infra management problems. You reduce the complexity of contribution significantly. If you’re at a company that wants to manage K8s, and you’ve chosen to invest in that direction, then serverless doesn’t make a lot of sense. If your customers aren’t buying compute, then you should be wary of large investments that are outside your core focus. Sure, there are quite a few problems with lambdas. But the abstraction you’re working at is much more atomic. And you don’t need FTEs to manage K8s and introduce a completely new set of problems. Less is more (is the argument).
- manigandham 6y ago
  You don't need serverless/FaaS for that. PaaS has existed for a long time, and many providers will now let you run any container image which is a lot more portable than custom frameworks. Zeit v1 actually did this.
wpietri 6y ago
I think there are legitimate use cases. E.g., I needed to help somebody with a little glue between Twilio and a SaaS tool. It was really nice to take a couple of functions, turn them into endpoints, and know that Amazon was going to worry about keeping them always available. I agree it's so far wildly overblown, but I get that too. A lot of people are scared by ops, and "serverless" promises they don't have to think about it. For those of us comfortable with ops, even the name is an obvious lie. But for people who just have some code they want to run, getting it usefully deployed is still too hard. Right now I feel like we're in a transitional era. The old model of individual single-purpose or multi-purpose servers is obviously inadequate. "Virtual server" is like "horseless carriage"; we know that the old paradigm is wrong, but we haven't found the new one. There are lots of contenders, but it seems like none of them have nailed it. The similar era for automobiles was circa 1900, where steam, electric, and internal combustion were all duking it out, with dozens of small manufacturers. I'll be very interested to see what we consolidate around.
- deleted 6y ago
  [deleted]
minieggs 6y ago
To offer another perspective... I've migrated services to/from Now v2 (never used v1). While recently moving a Go service off (to a regular server) all that was changed was some bash that executed in a pre-deploy hook and the `now` command was swapped for a `scp`. `sed 's/package main/package handler/g'`. Of course, this is much simpler if the services are created with migration in mind. I like to think of the builder options put in the `now.json` file as I would a webpack config.
dzonga 6y ago
people are in love with engineering but not shipping paid products. a rails | django | laravel developer is busy shipping. while someone is busy developing 1000s microservices. n that's before the complexity of react, redux n graphql
justrudd 6y ago
I built an ETL on top of AWS Lambda. I had to pull data from Facebook/Instagram, YouTube, Twitter, and Pinterest on a schedule - once an hour. The pipeline took about 3 minutes to run. I used a CloudEvent cron to kick it off, a few lambdas, stored the raw data in S3, had another lambda massage that data, stored the final data into S3, and put a message into SQS letting my OLTP system know that it could bring it in. Worked great. Were there other ways to build it? Sure. Could have done it on the same hosts that my OLTP system was running on. But the amount of memory it used for that 3 minutes doubled the amount that was needed on the host normally. Yes I could have optimized it. But my time was better spent figuring out other issues (I was sole developer on the project). So I just broke it into a bunch of different parts and kicked up to Lambda. Worked great. Never had any issues with it. Never worried about not having resources. I think it cost .2 to .8 USD each run? So ~600 USD a month at the high end. And it took me less than a day to break it up and get it running vs who knows how long to optimize. So it definitely solved a problem I had in a very efficient way, and allowed me to speed it up just by spending money.
yencabulator 6y ago
> It leads to so much vendor lock-in Only if your chosen vendor designed for that lock-in. Google Cloud Run is serverless that just runs whatever container serving HTTP you throw at it, no "lambda functions" needed.
- richardkmichael 6y ago
  No horse in this race, but isn't "serverless" via containers on AWS done with Fargate?

snow_js 6y ago

Now v1 was such an awesome abstraction, I was inspired to recreate the CLI on top of Kubernetes, to avoid any vendor lock-in. I also needed v1 capabilities like websocket support that went away with the v2 lambdas. This CLI utility has support for a few major cloud Kubernetes providers. https://github.com/snowjs/cli https://github.com/snowjs/cli

lewi 6y ago
Oh damn. This is awesome, will have to give it a go.
RonanTheGrey 6y ago
Concur, if you're looking for a replacement for the old Now v1, snowjs is a great option. Haven't used it extensively since we moved away from Now, but when I was investigating alternatives I came across this and gave it a go and was very pleased. Ultimately we went another way but it is a solid project.
palmdeezy 6y ago
This looks great!

RonanTheGrey 6y ago

I was an early adopter of Now v1 and loved it. I evangelized it to all my clients, used it on every project - it was such a breath of fresh air that deploying a server was now so easy. Ok, I get that serverless is a different paradigm. And I understand the arguments for it. But I refused to use Now v2 precisely because they violated their promises they had made -- but worse, turned it into "just another AWS". If I want serverless, I'll use AWS because frankly Zeit/Vercel's visibility into what is going on is just abysmal. And FWIW we now have several projects running on serverless -- using Next.js -- on AWS. Using the severless component, it requires NO special considerations and could easily be redeployed on a standard server in minutes. No vendor lock in, funny how that worked out? I expected to be locked in on AWS serverless. That didn't happen. The icing on the cake was when they didn't officially deprecate v1, but made it so unstable, so unusable, that I got to the point of spending DAYS per week deploying and redeploying and redeploying our docker containers because their servers would randomly decide that the hosting server no longer had a network connection. If I see E_AGAIN one more time I'm going to spit. And then they upped the price from $20/mo that we were paying for 4 containers, to $150. Thanks guys. It left such a bad taste in my mouth that I spent a day, redid everything to deploy on AWS EB, and haven't looked back since. That was the LEAST amount of time I'd spent on that, in a given week, for about a 4 month period prior. To be fair, the guy running Zeit/Vercel's support is pretty solid. He did try to be helpful. My experience with the technical leadership has been left lacking. We tried several times to contribute to Next.js and were treated like idiot children because how dare we trample on their kingdom. If you're not a tech bro, stay in your lane! Look I'm just sharing my experience over there. It has been roundly negative. I'm sure others can come with anecdotes of it being roundly positive, good for you. Mine is just another anecdote but it's the only insight I have. Although, the 1500+ comment thread on Spectrum when they announced v2 strongly suggests I'm not alone.

arist0tl3 6y ago
Hey, I'm curious about your migration. Can you contact me via my profile?
travltalk 6y ago
Also felt the pain of daring to ask a 'stupid' question and being firmly reminded I'm not a techbro. Rather I'm a proud techhoe :-)