Fool me once...
1: https://web.archive.org/web/20181107092845/https://zeit.co/n...
2: https://web.archive.org/web/20181107092845/https://zeit.co/n...
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.
Ultimately we went another way but it is a solid project.
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.
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.
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.
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).
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.
I like to think of the builder options put in the `now.json` file as I would a webpack config.
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.
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.