7 ms·

Serverless is a bad idea, it was designed to serve big infrastructure providers as a way to increase their lock-in factor but the benefits to software developer

Serverless is a bad idea, it was designed to serve big infrastructure providers as a way to increase their lock-in factor but the benefits to software developers is negative. Serverless is simple but opaque; it's great for making demo apps but not ideal for real production systems. It narrows down integration possibilities, complicates large-scale development and deployment, and often, it makes it more difficult to keep track of backend errors... In addition to this, it makes you fully dependent on a single infrastructure provider; it takes away all your leverage when negotiating hosting costs. The control panels of some of these services have become so complex and elaborate that you'll be wishing that you could just SSH into the server directly.

sokoloff 9y ago
Serverless is (way?) over-hyped, but has valid use cases I think. As an example, for a tiny side-project, I don't care about the markup or lock-in, I just want my code to run an unknown, small number of times per day for a cost-effective total price and a low cognitive and support overhead on me.
- jondubois 9y ago
  Sure, but I've found that even some use cases that seem perfect are in fact not as good as you think. For example, I used Amazon Elastic Transcoder to do video compression/transcoding at a previous company thinking that we would save a lot of time but the API wasn't great; a lot of the default settings weren't right for our use case and the API and notification flow was way more complicated than it needed to be and prone to errors (due the the sheer complexity of input parameters it could handle). At one point, we had a problem receiving SNS notifications from the transcoder and we didn't know what was causing it because we couldn't effectively access/browse the error log and was was exposed to us wasn't detailed enough. Basically the visibility in Amazon-land wasn't great. We had to pay Amazon for special support so that they would tell us what the error was (after weeks of back-and-forth). Now that it's all running, it's fine; so long as we don't need to change anything and don't need to start scaling up/sharding the pipelines; no sure how to do this through their UI.
  - sacheendra 9y ago
    Not sure why this is being downvoted? The author seems to have faced a problem with the abstraction of these services and has described it. If anyone thinks that is wrong or has an argument supporting it or against it, just point it out. I don't think this is worthy of replyless downvotes.
  - kvz 9y ago
    If you’re still in the market for a transcoding service but fancy a better API, consider Transloadit. Disclaimer: I’m a founder :)
    - jondubois 9y ago
      The irony is that in spite of its inferiority, because we were using other Amazon services like S3 for storage, it essentially "forces" us to use other Amazon services for everything else as well.
kondro 9y ago
You need to look at some of the work iRobot has done with Serverless. AWS has tools to manage all of this and do so at scale. By the time you need to SSH into a server to solve a problem, you’ve already failed.
drej 9y ago
> In addition to this, it makes you fully dependent on a single infrastructure provider; it takes away all your leverage when negotiating hosting costs. If I JDBC into this sort of infrastructure, how does that make me dependent on AWS? It's just a different pricing model and management style. Nothing more, nothing less. (I'm not underestimating this service, quite the contrary, I think it's very neat for people without DevOps and/or frequent load.)
- arnoooooo 9y ago
  > If I JDBC into this sort of infrastructure, how does that make me dependent on AWS? It's just a different pricing model and management style. Nothing more, nothing less. Except you'll probably have different performance constraints and have to architecture your code accordingly. True decoupling is pretty hard to achieve.
leetbulb 9y ago
I built a fairly large system using the Serverless "framework" on AWS. It's been running for over 8 months now with zero maintenance and zero service disruptions, with an ingress of ~50M events per day and providing a sleek ReactJS/SemanticUI frontend that the users seem to really enjoy. Being a side project, it's been relatively stress-free. While the application is still very profitable, the cost is ~10x its implementation on traditional servers. I'm not going to argue the pro's and con's, just providing some numbers. At this point, we're working to optimize the original stack in order to reduce costs. I will say though...honestly, working with Serverless and the AWS stack is a very pleasant experience.
- dchuk 9y ago
  Mind sharing more details on the project? I'm always curious what sorts of ideas are good fits for serverless versus "traditional" web apps.
  - leetbulb 9y ago
    See above comments by me. Unfortunately I cannot go in to much detail regarding the nature of the application, but I've shared some extra details.
- mooreds 9y ago
  Always great to see numbers. The running cost is 10X a typical deployment. Does that include any time you would have spent patching traditional servers? Can you talk about the cost of your development time (one of the premises of serverless is increased developer productivity)? Again, thanks for the real world numbers--always nice to see them.
  - leetbulb 9y ago
    The cost difference is purely based on hosting a similar stack on something like dedicated servers with OVH. However, as you would imagine, it would be far less robust unless we had a team of DevOps to manage it, and clearly that's where a big cost comes in. Although, managing a somewhat similar stack for my full-time gig, it's not terribly time consuming. Development time was roughly the same: frontend work was identical to a standard enterprise-grade SPA app and backend is all Lambda functions, which would've been implemented similarly on, for example, NodeJS and Express (which is what as done anyway for testing). The primary cost (~60%) is due to the high volume of API Gateway requests. (Edit: see below comment for reason and plans to optimize) Edit: A HUGE time saving comes from being able to orchestrate AWS infrastructure easily via API and is well worth the premium in most cases. Our frontend application performs many automated management tasks of AWS resources such as S3, CloudFront, Lambda, Route53, etc... This of course does not directly relate to "Serverless," as it may be done by any application able to make API calls to AWS, however just the fact that it's possible for these resources is very appealing to a multi-hat developer with limited time on a side project.

sokoloff 9y ago

Serverless is (way?) over-hyped, but has valid use cases I think. As an example, for a tiny side-project, I don't care about the markup or lock-in, I just want my code to run an unknown, small number of times per day for a cost-effective total price and a low cognitive and support overhead on me.

jondubois 9y ago
Sure, but I've found that even some use cases that seem perfect are in fact not as good as you think. For example, I used Amazon Elastic Transcoder to do video compression/transcoding at a previous company thinking that we would save a lot of time but the API wasn't great; a lot of the default settings weren't right for our use case and the API and notification flow was way more complicated than it needed to be and prone to errors (due the the sheer complexity of input parameters it could handle). At one point, we had a problem receiving SNS notifications from the transcoder and we didn't know what was causing it because we couldn't effectively access/browse the error log and was was exposed to us wasn't detailed enough. Basically the visibility in Amazon-land wasn't great. We had to pay Amazon for special support so that they would tell us what the error was (after weeks of back-and-forth). Now that it's all running, it's fine; so long as we don't need to change anything and don't need to start scaling up/sharding the pipelines; no sure how to do this through their UI.
- sacheendra 9y ago
  Not sure why this is being downvoted? The author seems to have faced a problem with the abstraction of these services and has described it. If anyone thinks that is wrong or has an argument supporting it or against it, just point it out. I don't think this is worthy of replyless downvotes.
- kvz 9y ago
  If you’re still in the market for a transcoding service but fancy a better API, consider Transloadit. Disclaimer: I’m a founder :)
  - jondubois 9y ago
    The irony is that in spite of its inferiority, because we were using other Amazon services like S3 for storage, it essentially "forces" us to use other Amazon services for everything else as well.

kondro 9y ago

You need to look at some of the work iRobot has done with Serverless. AWS has tools to manage all of this and do so at scale. By the time you need to SSH into a server to solve a problem, you’ve already failed.

drej 9y ago

> In addition to this, it makes you fully dependent on a single infrastructure provider; it takes away all your leverage when negotiating hosting costs. If I JDBC into this sort of infrastructure, how does that make me dependent on AWS? It's just a different pricing model and management style. Nothing more, nothing less. (I'm not underestimating this service, quite the contrary, I think it's very neat for people without DevOps and/or frequent load.)

arnoooooo 9y ago
> If I JDBC into this sort of infrastructure, how does that make me dependent on AWS? It's just a different pricing model and management style. Nothing more, nothing less. Except you'll probably have different performance constraints and have to architecture your code accordingly. True decoupling is pretty hard to achieve.

leetbulb 9y ago

I built a fairly large system using the Serverless "framework" on AWS. It's been running for over 8 months now with zero maintenance and zero service disruptions, with an ingress of ~50M events per day and providing a sleek ReactJS/SemanticUI frontend that the users seem to really enjoy. Being a side project, it's been relatively stress-free. While the application is still very profitable, the cost is ~10x its implementation on traditional servers. I'm not going to argue the pro's and con's, just providing some numbers. At this point, we're working to optimize the original stack in order to reduce costs. I will say though...honestly, working with Serverless and the AWS stack is a very pleasant experience.

dchuk 9y ago
Mind sharing more details on the project? I'm always curious what sorts of ideas are good fits for serverless versus "traditional" web apps.
- leetbulb 9y ago
  See above comments by me. Unfortunately I cannot go in to much detail regarding the nature of the application, but I've shared some extra details.
mooreds 9y ago
Always great to see numbers. The running cost is 10X a typical deployment. Does that include any time you would have spent patching traditional servers? Can you talk about the cost of your development time (one of the premises of serverless is increased developer productivity)? Again, thanks for the real world numbers--always nice to see them.
- leetbulb 9y ago
  The cost difference is purely based on hosting a similar stack on something like dedicated servers with OVH. However, as you would imagine, it would be far less robust unless we had a team of DevOps to manage it, and clearly that's where a big cost comes in. Although, managing a somewhat similar stack for my full-time gig, it's not terribly time consuming. Development time was roughly the same: frontend work was identical to a standard enterprise-grade SPA app and backend is all Lambda functions, which would've been implemented similarly on, for example, NodeJS and Express (which is what as done anyway for testing). The primary cost (~60%) is due to the high volume of API Gateway requests. (Edit: see below comment for reason and plans to optimize) Edit: A HUGE time saving comes from being able to orchestrate AWS infrastructure easily via API and is well worth the premium in most cases. Our frontend application performs many automated management tasks of AWS resources such as S3, CloudFront, Lambda, Route53, etc... This of course does not directly relate to "Serverless," as it may be done by any application able to make API calls to AWS, however just the fact that it's possible for these resources is very appealing to a multi-hat developer with limited time on a side project.