5 ms·

In my opinion, one of the worst was things was going from servers to serverless for web apps. Vercel (formerly Zeit) made a complete switch from servers to serv

In my opinion, one of the worst was things was going from servers to serverless for web apps. Vercel (formerly Zeit) made a complete switch from servers to serverless for hosting and Next.js. Everyone jumped in without realizing just how much more complicated serverless architectures are compared to servers. 1. Having your APIs as lambdas now means you can't simply connect to a Postgres/MySQL without setting up a dedicated server that serve as a connection pool. So you're now "serverless" but you now have to add a server as a connection pool. /facepalm 2. Putting your APIs on the edge means absolutely nothing if your Postgres/MySQL/Redis/3rd party services is still in one location. 3. Serverless edge databases started popping up but they were significantly more expensive (because you have to replicate data everywhere) and more complicated with limited upside. 4. Cold starts on lambda APIs meant that your web app/web site often load slower than a centralized server. 5. You can't reliably share APIs between your web app and mobile app anymore. Previously, a single server could easily be made to serve both your web app and mobile app. 6. Serverless is often more expensive and unpredictable when it comes to billing. Previously, if you paid $15 for a server, you're going to be billed for $15. 7. Serverless is significantly more complicated when you're just trying to build an MVP. There's no need to try to scale like you're Google when you're just trying to create a proof of concept. 8. You're far more likely to be vendor-locked doing serverless. Serverless should not have been the default option for webapps. Serverless should have been the exotic option for companies that had a special scaling/edge need. Instead, servers should still be the default. The problem is that Next.js is so popular and so intertwined with Vercel that serverless is the default now. If Vercel/Next.js were honest, they would tell everyone to use serverless only if they're making a static website. Everything else should start out as a server.

tannhaeuser 3y ago
Of course, but this is just an instance of TFA's key observation: > Geeks think they're rational beings, while they're completely influenced by buzz, marketing, and their emotions. To which I want to add 1. that geeks young and old try also to pad their resume and eg use React and under all circumstances whether it's warranted or not (which seems at least rational from a personal career development PoV) 2. geeks think the web is about them, completely and utterly failing to understand that its entire point is easy self-publishing. As to next.js specifically, it obviously doesn't make sense to tie serverless to React. Also, it doesn't make sense, like at all, to use React for smallish trivial internal web UIs when the main app is written in another backend language and your team has no js coding experience which just invites security nightmares and endless updates, and breaks agility and job rotation for no reason. As to XML, there's a minor factual misunderstanding here in that DTDs, like XML itself, isn't a genuine inception, but rather a simplification and proper subset of SGML intended for the web where it has failed (even though it sees plenty use outside). But that should't take away from the main point: that you don't go around advertising your fscking format without checking requirements. In this case, using XML (or SGML and HTML) for something that isn't document data, or conversely, using eg JSON for text documents. Just makes you look like a one trick pony.
phendrenad2 3y ago
Right, I've come to believe that the software development world is led by the nose by snake oil salesmen. Most software developers don't have a range of experience outside of a CS degree, so they easily fall into "this is the new best practice" traps, especially if they look flashy and professional (examples: https://12factor.net https://12factor.net https://machalliance.org https://machalliance.org)
douglasmoore 3y ago
Just want to comment on the first two points as a vercel fan (1) pooling becomes the solution very early. You get massive speed benefits by keeping a connection open. Hitting connection limits is too easy without it. I feel like a push towards pooling is fine because it has great benefits for scale, speed and reliability. Services like Supabase have connection pooled postgres by default even in their free tier. (2) nextjs server side data fetching is an amazing feature that deserves it's place in future of web development (the react team agrees since they've added server components). Grabbing data before reaching the client is amazing. If you have a centralized db all the more reason to grab as much as you can in one trip. Other than that I can agree. I think the advice should generally be to not ever recommend a framework too early or without including its use case. Current recommendations for the different tiers: Static: GitHub/cloudflare pages Server-lite: render.com Serverless: vercel
- charcircuit 3y ago
  >nextjs server side data fetching is an amazing feature that deserves it's place in future of web development It was a thing in the past too. It's how almost all a CGI and PHP sites worked.
  - hughesjj 3y ago
    And jsp and asp and literally everything before ajax
- senttoschool 3y ago
  1. If you have a server, it’s trivial to setup a connection pool. For example, most Postres clients like Knex or Prisma sets a connection pool for you on your server. There’s no need to setup an external connection pool. It’s good that Supabase does it for you but most managed Postres databases don’t. In fact, it's trivial to setup many things on a server that you simply can't on a serverless function. For example, a simple cron job or a simple persistent queue or websockets. You have to use 3rd party services for these simple tasks that you could have done on your server. 2. That has nothing to do with serverless or servers.
tacone 3y ago
All true (I rented a bare metal server myself for my pet projects), but it's still quite tempting. - scale to zero, or scale to one (no cold starts) - not having to manage disk space - not having to manage quite a bit of security (ssh login, fail2ban, opened ports, unprivileged user) - in some cases, out of the box - or easier - deploy pipeline Would you feel more or less confortable taking vacations while having a server or a server less platform? Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform? I quite agree with what you say but can't deny there are lots of non negligible advantages.
- RadiozRadioz 3y ago
  > ssh login, fail2ban, opened ports, unprivileged user All of these things are extremely trivial to configure. > Would you feel more or less confortable taking vacations while having a server or a server less platform? Depends on the SLA of my provider. Most VPS providers have 3+9s these days, then the reliability concern becomes my code, same with serverless. > Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform? It is a common misconception that serverless platforms are inherently more secure. In reality, they just have different security concerns. In my eyes, it takes a practitioner of equivalent skill to properly harden a fleet of servers Vs correctly handle the eccentricities of IAM et al in a large cloud app.
lijok 3y ago
Your points do nothing to back up your claim that "serverless architectures are much more complicated compared to servers" 1. You still have to do polling with servers 2. Not a serverless problem 3. Not a serverless problem 4. This is a tradeoff, not complexity 5. Why not? What does serverless have to do with this? 6. Appears you're confusing serverless and FaaS. Regarldess, FaaS has incredibly predictable pricing. Previously if you paid $15 for a server, you're going to be billed for however many servers you had running on average throughout the month. 7. It's not. Your points here are trying to back it up, but have so far not done so. 8. Why would that be? And how does that factor into complexity? Your claim is flawed for two reasons: 1. Serverless != FaaS. FaaS is serverless, serverless is not FaaS. 2. You've not taken auto-scaling into consideration on the server side.
- senttoschool 3y ago
  1. Pooling is trivial to setup with servers. In fact, pretty much all clients like Knex and Prisma does connection pooling by default without an external dedicated server. 2, 3. The promise is that serverless APIs can be deployed on the edge for improved latency. The edge does not matter if your data is centralized. So you're adding complexity without the benefit of speed. 4. One of the most important aspects of any web app is load speed. Sure, you can say that serverless is better for scaling but who cares if your web pages are randomly adding 3-5 seconds to the loading time. 5. Try pointing your mobile app to Vercel's serverless APIs that are built inside Next.js. Makes no sense. 6. The most common way people use serverless for webapps is through Vercel's FaaS or some other similar FaaS. That's what I'm focusing on. Not confused. No, FaaS does not have more predictable pricing than servers. 7. It is. I just outlined why it is. Even if you want a simple cron job or a simple persistent queue, you can't do it with serverless functions. 8. You're building your entire stack on a FaaS like Vercel with Next.js. It's not as easy to switch hosts like using Docker. I don't know if you were doing development during the Zeit V1 days but one of the main criticisms of Vercel and newer versions of Next.js is now it makes it hard to switch hosts. Whereas, being able to switch hosts easily is default in a docker setup.
  - Solvency 3y ago
    1. Connection pooling can be set up with dedicated servers, but it doesn't mean that all clients like Knex and Prisma do it by default without an external server. Some clients may handle connection pooling internally, while others require external setup. 2, 3. While serverless APIs deployed on the edge can improve latency, it is not accurate to say that the edge doesn't matter if your data is centralized. The edge can still provide benefits such as reduced network hops and improved response times. 4. Serverless architectures can offer advantages for scaling, but it's important to optimize load speed regardless of the architecture used. Serverless doesn't inherently add 3-5 seconds to loading times. 5. It can make sense to use Vercel's serverless APIs built inside Next.js for mobile apps, depending on the specific requirements and architecture of the application. 6. FaaS pricing can vary based on usage and provider, but it doesn't necessarily have more predictable pricing than using dedicated servers. Both options have their own pricing models and considerations. 7. While serverless functions are useful for many scenarios, there are certain tasks like cron jobs or persistent queues that may not be easily achievable with serverless functions alone. However, there are workarounds and alternative solutions available. 8.Building an entire stack on a FaaS like Vercel with Next.js may have implications for switching hosts compared to a Docker setup. Docker provides portability and flexibility, making it easier to switch hosts, whereas FaaS platforms may have specific dependencies or configurations that require adjustment when migrating.
pjmlp 3y ago
The problem are the business agrements that they are putting in place, like with Sitecore where now Vercel/Next.js are the bless way to do CMS frontends, with .NET being left behind. So it is either Vercel/Next.js with the out-of-the-box development experience, or DIY integration with other stacks that are also "supported". And they aren't the only ones following such hype cycle.
hn_throwaway_99 3y ago
FWIW, after using serverless technologies in both AWS and GCP for years, I think the cloud vendors have largely fixed most of the issues you're complaining about. Few examples: 1. Amazon provides things like RDS Proxy, which is essentially a hosted version of pgbouncer, and Aurora, essentially a "serverless postgres" - no need to manage your own server for connection pooling. 2. Cloud vendors have largely fixed the cold start times through a variety of means like min scaling of 1, warming requests, and functions that can process many requests simultaneously. 3. I don't get your point about not being able to share an API between web and mobile. I do this all the time. 4. When it comes to vendor lock-in, GCP for example offers Cloud Run, which will essentially just spin up any Docker container you give to it. Managing your own servers can have a huge cost, and this can be an especially large cost for a small team. For example, does your business have any SOC 2 or other compliance requirements? Being on serverless as opposed to being on, say, your own EC2 instances, means a huge amount of work (e.g. ensuring servers are always patched, ensuring they are configured securely, ensuring you have permissions configured correctly, etc.) can be offloaded to the cloud provider, who is frankly much more likely to do it correctly than a small startup team. If anything, I think GCP's CloudRun is awesome and the real future of serverless. In my mind it has most of the benefits of something like kubernetes with about 1/50th of the complexity.
- senttoschool 3y ago
  My main points are Vercel/Next.js focused. 1. That's extra cost and complexity and it's still a dedicated server. 2. If it's a min scaling of 1 and it processes many requests, isn't that just a server? 3. In the context of using APIs written inside Next.js for your mobile application. 4. Sure, Cloud Run is nice. I remember using Docker with Cloud Run as well. But it's a bit different than my main gripe with Next.js/Vercel.

tannhaeuser 3y ago

Of course, but this is just an instance of TFA's key observation: > Geeks think they're rational beings, while they're completely influenced by buzz, marketing, and their emotions. To which I want to add 1. that geeks young and old try also to pad their resume and eg use React and under all circumstances whether it's warranted or not (which seems at least rational from a personal career development PoV) 2. geeks think the web is about them, completely and utterly failing to understand that its entire point is easy self-publishing. As to next.js specifically, it obviously doesn't make sense to tie serverless to React. Also, it doesn't make sense, like at all, to use React for smallish trivial internal web UIs when the main app is written in another backend language and your team has no js coding experience which just invites security nightmares and endless updates, and breaks agility and job rotation for no reason. As to XML, there's a minor factual misunderstanding here in that DTDs, like XML itself, isn't a genuine inception, but rather a simplification and proper subset of SGML intended for the web where it has failed (even though it sees plenty use outside). But that should't take away from the main point: that you don't go around advertising your fscking format without checking requirements. In this case, using XML (or SGML and HTML) for something that isn't document data, or conversely, using eg JSON for text documents. Just makes you look like a one trick pony.

phendrenad2 3y ago

Right, I've come to believe that the software development world is led by the nose by snake oil salesmen. Most software developers don't have a range of experience outside of a CS degree, so they easily fall into "this is the new best practice" traps, especially if they look flashy and professional (examples: https://12factor.net https://12factor.net https://machalliance.org https://machalliance.org)

douglasmoore 3y ago

Just want to comment on the first two points as a vercel fan (1) pooling becomes the solution very early. You get massive speed benefits by keeping a connection open. Hitting connection limits is too easy without it. I feel like a push towards pooling is fine because it has great benefits for scale, speed and reliability. Services like Supabase have connection pooled postgres by default even in their free tier. (2) nextjs server side data fetching is an amazing feature that deserves it's place in future of web development (the react team agrees since they've added server components). Grabbing data before reaching the client is amazing. If you have a centralized db all the more reason to grab as much as you can in one trip. Other than that I can agree. I think the advice should generally be to not ever recommend a framework too early or without including its use case. Current recommendations for the different tiers: Static: GitHub/cloudflare pages Server-lite: render.com Serverless: vercel

charcircuit 3y ago
>nextjs server side data fetching is an amazing feature that deserves it's place in future of web development It was a thing in the past too. It's how almost all a CGI and PHP sites worked.
- hughesjj 3y ago
  And jsp and asp and literally everything before ajax
senttoschool 3y ago
1. If you have a server, it’s trivial to setup a connection pool. For example, most Postres clients like Knex or Prisma sets a connection pool for you on your server. There’s no need to setup an external connection pool. It’s good that Supabase does it for you but most managed Postres databases don’t. In fact, it's trivial to setup many things on a server that you simply can't on a serverless function. For example, a simple cron job or a simple persistent queue or websockets. You have to use 3rd party services for these simple tasks that you could have done on your server. 2. That has nothing to do with serverless or servers.

tacone 3y ago

All true (I rented a bare metal server myself for my pet projects), but it's still quite tempting. - scale to zero, or scale to one (no cold starts) - not having to manage disk space - not having to manage quite a bit of security (ssh login, fail2ban, opened ports, unprivileged user) - in some cases, out of the box - or easier - deploy pipeline Would you feel more or less confortable taking vacations while having a server or a server less platform? Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform? I quite agree with what you say but can't deny there are lots of non negligible advantages.

RadiozRadioz 3y ago
> ssh login, fail2ban, opened ports, unprivileged user All of these things are extremely trivial to configure. > Would you feel more or less confortable taking vacations while having a server or a server less platform? Depends on the SLA of my provider. Most VPS providers have 3+9s these days, then the reliability concern becomes my code, same with serverless. > Would you feel more or less confortable undergoing a security assessment while using a server or a server less platform? It is a common misconception that serverless platforms are inherently more secure. In reality, they just have different security concerns. In my eyes, it takes a practitioner of equivalent skill to properly harden a fleet of servers Vs correctly handle the eccentricities of IAM et al in a large cloud app.

lijok 3y ago

Your points do nothing to back up your claim that "serverless architectures are much more complicated compared to servers" 1. You still have to do polling with servers 2. Not a serverless problem 3. Not a serverless problem 4. This is a tradeoff, not complexity 5. Why not? What does serverless have to do with this? 6. Appears you're confusing serverless and FaaS. Regarldess, FaaS has incredibly predictable pricing. Previously if you paid $15 for a server, you're going to be billed for however many servers you had running on average throughout the month. 7. It's not. Your points here are trying to back it up, but have so far not done so. 8. Why would that be? And how does that factor into complexity? Your claim is flawed for two reasons: 1. Serverless != FaaS. FaaS is serverless, serverless is not FaaS. 2. You've not taken auto-scaling into consideration on the server side.

senttoschool 3y ago
1. Pooling is trivial to setup with servers. In fact, pretty much all clients like Knex and Prisma does connection pooling by default without an external dedicated server. 2, 3. The promise is that serverless APIs can be deployed on the edge for improved latency. The edge does not matter if your data is centralized. So you're adding complexity without the benefit of speed. 4. One of the most important aspects of any web app is load speed. Sure, you can say that serverless is better for scaling but who cares if your web pages are randomly adding 3-5 seconds to the loading time. 5. Try pointing your mobile app to Vercel's serverless APIs that are built inside Next.js. Makes no sense. 6. The most common way people use serverless for webapps is through Vercel's FaaS or some other similar FaaS. That's what I'm focusing on. Not confused. No, FaaS does not have more predictable pricing than servers. 7. It is. I just outlined why it is. Even if you want a simple cron job or a simple persistent queue, you can't do it with serverless functions. 8. You're building your entire stack on a FaaS like Vercel with Next.js. It's not as easy to switch hosts like using Docker. I don't know if you were doing development during the Zeit V1 days but one of the main criticisms of Vercel and newer versions of Next.js is now it makes it hard to switch hosts. Whereas, being able to switch hosts easily is default in a docker setup.
- Solvency 3y ago
  1. Connection pooling can be set up with dedicated servers, but it doesn't mean that all clients like Knex and Prisma do it by default without an external server. Some clients may handle connection pooling internally, while others require external setup. 2, 3. While serverless APIs deployed on the edge can improve latency, it is not accurate to say that the edge doesn't matter if your data is centralized. The edge can still provide benefits such as reduced network hops and improved response times. 4. Serverless architectures can offer advantages for scaling, but it's important to optimize load speed regardless of the architecture used. Serverless doesn't inherently add 3-5 seconds to loading times. 5. It can make sense to use Vercel's serverless APIs built inside Next.js for mobile apps, depending on the specific requirements and architecture of the application. 6. FaaS pricing can vary based on usage and provider, but it doesn't necessarily have more predictable pricing than using dedicated servers. Both options have their own pricing models and considerations. 7. While serverless functions are useful for many scenarios, there are certain tasks like cron jobs or persistent queues that may not be easily achievable with serverless functions alone. However, there are workarounds and alternative solutions available. 8.Building an entire stack on a FaaS like Vercel with Next.js may have implications for switching hosts compared to a Docker setup. Docker provides portability and flexibility, making it easier to switch hosts, whereas FaaS platforms may have specific dependencies or configurations that require adjustment when migrating.

pjmlp 3y ago

The problem are the business agrements that they are putting in place, like with Sitecore where now Vercel/Next.js are the bless way to do CMS frontends, with .NET being left behind. So it is either Vercel/Next.js with the out-of-the-box development experience, or DIY integration with other stacks that are also "supported". And they aren't the only ones following such hype cycle.

hn_throwaway_99 3y ago

FWIW, after using serverless technologies in both AWS and GCP for years, I think the cloud vendors have largely fixed most of the issues you're complaining about. Few examples: 1. Amazon provides things like RDS Proxy, which is essentially a hosted version of pgbouncer, and Aurora, essentially a "serverless postgres" - no need to manage your own server for connection pooling. 2. Cloud vendors have largely fixed the cold start times through a variety of means like min scaling of 1, warming requests, and functions that can process many requests simultaneously. 3. I don't get your point about not being able to share an API between web and mobile. I do this all the time. 4. When it comes to vendor lock-in, GCP for example offers Cloud Run, which will essentially just spin up any Docker container you give to it. Managing your own servers can have a huge cost, and this can be an especially large cost for a small team. For example, does your business have any SOC 2 or other compliance requirements? Being on serverless as opposed to being on, say, your own EC2 instances, means a huge amount of work (e.g. ensuring servers are always patched, ensuring they are configured securely, ensuring you have permissions configured correctly, etc.) can be offloaded to the cloud provider, who is frankly much more likely to do it correctly than a small startup team. If anything, I think GCP's CloudRun is awesome and the real future of serverless. In my mind it has most of the benefits of something like kubernetes with about 1/50th of the complexity.

senttoschool 3y ago
My main points are Vercel/Next.js focused. 1. That's extra cost and complexity and it's still a dedicated server. 2. If it's a min scaling of 1 and it processes many requests, isn't that just a server? 3. In the context of using APIs written inside Next.js for your mobile application. 4. Sure, Cloud Run is nice. I remember using Docker with Cloud Run as well. But it's a bit different than my main gripe with Next.js/Vercel.