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.

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 :-)

Hey, I'm curious about your migration. Can you contact me via my profile?

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

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.

Oh damn. This is awesome, will have to give it a go.

This looks great!

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.

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.

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.

So, where do you host? What data store do you use?

I host data on firebase db use firebase cloud functions for "serverless" compute. I just do android development and never mess with AWS/k8s/whatever.

Firebase is my favorite at the moment. I like that it combines functions & db. And has a simple DB viewer.

Last thing we needed was a simple unsubscribe service for a database hosted on AirTable, a few lines of code. It totally makes sense to me to host such glue on Now.

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.

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.

Nhost (https://nhost.io/) is another option for Hasura.

have you used this in production ? any recco ?

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.

I use Wordpress for many clients because it's the simplest solution that also ensure they can find other developers to take over if I'm not there.

Wordpress is a dumpster fire and I hate it with a passion, though. Like, viscerally, almost as much as I dislike Drupal and Joomla. I'd use the term PTSD but that strikes me as insensitive.

But I still use it for many clients, because it's the simplest, easiest solution that other (and crucially, cheap!) developers can take over when I'm not there anymore.

I don’t know if this would meet your needs, but I recently built a gated static site for personal use using Gatsby + Firebase for Auth and Hosting. Firebase Auth took 10 minutes to set up. I didn’t need a DB but I will use Firestore if needed in the future. All of it was quite easy and enjoyable to do.

Ghost? They recent rolled out inbuilt memberships. Wont work if you are selling one time access though.

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).

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.

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.

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.

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

> 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.

No horse in this race, but isn't "serverless" via containers on AWS done with Fargate?

Serverless is just zoomer Common Gateway Interface for venture capitalists

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.

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.