18 ms·

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that mos

Finally reality is catching up to the hype. I was saying this 3 years ago. Tech should be about results, it should not be a religion. We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) and we should not outsource our decisions to them. To innovate, we need to start thinking independently and make our own rational assessments. Even if you make the wrong decision initially, at least it will be your own decision and you will learn from it. Moreover, when it's your own decision, you will learn from it sooner because you're not going to be getting undue reinforcement from peers. If you over-idealize thought leaders, you will tend to stick to the popular doctrine instead of listening to your own reasoning.

ecmascript 7y ago
Not only that, but it is also way harder to structure and develop than a normal application. At least in my experience.
coldtea 7y ago
>We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...
- bdcravens 7y ago
  If we really want easy, we’d all be writing ColdFusion or Visual Basic.
  - coldtea 7y ago
    If we valued productivity, and those were indeed easier, then we should. There's no real pride in not valuing easy if it's also good.
  - wolco 7y ago
    Why did we move away from VB? Great for writing for a single platform. Cold Fusion had issues that would prevent it from taking over.
- laumars 7y ago
  > That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle. Other forms of serverless might save time. However there's always edge cases where they don't and you can lose hours or even days investigating an issue that would be a quick fix if you actually managed the host and/or application. So the short answer is: not always faster nor easier. It really depends on what you're trying to accomplish. > I don't think anybody uses things like AWS or serveless services because they're faster or cheaper... Actually yes they do. But like my previous answer, it depends on what you're trying to accomplish. This is the problem with serverless (and cloud computing in general). People try to distil it down to "this is better for x" and "that is better for y" but actually the benefits and trade offs are far more granular than that. To the extent that you could have two companies in the same sector releasing competing products and still what architecture makes sense for one company might not for the other. This is also why nobody ever agrees about these topics online - by the time you've generalised the examples enough to describe them in a forum post, they lose the specificity that makes any accurate design possible.
  - fendy3002 7y ago
    Can't agree more. One example is CI/CD through docker image, building image / deploying container may take ten to thirty minutes long. It's a hindrance for quick bugfix / tempering on test server.
  - mywittyname 7y ago
    > Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle. This has not been my experience at all. Maybe because I have a lot of experience with Lambda, but I find them to be a very fast way to get code written and running. Granted, Lambda is a great tool for a specific category of task. Namely, when you need to programmatically respond to some event which was triggered by another AWS service and can do so in under 5 minutes. But it's poorly suited for tasks outside of that domain. In that sense, it's like Bash: you don't want to do everything with it, but there are situations where it's the best tool.
- goatinaboat 7y ago
  1 programmer/ops guy can do what it took 10 before. The myth: devs are expensive and hardware is cheap The reality: webdevs are a commodity and AWS is making record profits
  - coldtea 7y ago
    The real reality: not all devs required are webdevs, especially if you want to build an infrastructure that can handle millions of people worldwide. It's not like some React and CSS will get you that. The amount you'll pay for a single additional developer, even if it's "just" 70K, is already close (if not double) your whole Clould costs when you start...
    - edw 7y ago
      Yes. And there’s also the issue that even if someone would choose to work for free, incremental bodies in an org tend to increase the org’s complexity.
    - wolco 7y ago
      When you start you don't need to handle millions of customers worldwide. If all you need is to handle a million customers per month digitalocean can handle that on a single server and you wouldn't hire a single let alone many developers to manage that. If you ever reach the point where you need to handle 100s of millions of customers a month / hiring someone can save you money but perhaps serverless makes sense. 99% of businesses will not reach that level.
- NicoJuicy 7y ago
  > it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before Perhaps it's more related to the programmer than the tech stack... It's also not solely developping, but debugging too. And serverless does make things a lot harder.
  - bcyn 7y ago
    Why does serverless make things a lot harder? I'd argue that the stateless nature of serverless actually makes it much, much easier to debug.
- jbergens 7y ago
  They can be a lot cheaper. Maybe only in some cases but then it can make a difference.
avip 7y ago
There are enough results to prove that serverless is useful (may I say, correct) architecture in many use cases. Not everyone is dumb, contrary to a common belief. Don't be religious.
scarface74 7y ago
It isn’t about “reality” it’s about trade offs. Every choice you make when it comes to infrastructure, whether to build or buy, etc comes with trade offs. The trade offs and benefits of using lambda isn’t a secret.
nickjj 7y ago
Agreed. ~2 years ago I seriously looked into Serverless and very quickly discarded it after seeing a large production deployment of it. I didn't have access to the billing info but the site loaded much slower than a regular site and developer productivity was quite low. I'm going to stick with good old servers for now. If anyone is curious, a few years ago I did a write up on "Should your next project be built as a Serverless app?" which compares deployment styles in a bit more detail: https://nickjanetakis.com/blog/should-your-next-project-be-built-as-a-serverless-app https://nickjanetakis.com/blog/should-your-next-project-be-b...
- herostratus101 7y ago
  Hey nickjj, you may want to update your blog post to reflect that the Lambda timeout is now 15m, not 5m.
  - nickjj 7y ago
    Hi, thanks for the heads up. I just updated it.
tus88 7y ago
This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.
- marvindanig 7y ago
  Not a strawman, nope. Please put the React salesmen on this list of bogus hype as well. It’s all projection and propaganda—zero substance. Here’s the proof of evil intent behind React, for example: https://news.ycombinator.com/item?id=20711598 https://news.ycombinator.com/item?id=20711598
  - nocman 7y ago
    I suspect I am more wary of Facebook than most. However, unless there is something in that linked discussion that I'm just not seeing, I don't get it. Or perhaps your idea of "proof" and mine are just vastly different.
    - marvindanig 7y ago
      proof = hint. /correction i guess we’ll have to wait for the trail of destruction to appear as proof of everything else that has come from Facebook.
  - fourthark 7y ago
    Um, I couldn't find any evil in that thread, sorry.
- dave_sid 7y ago
  While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.
  - danesparza 7y ago
vectorEQ 7y ago
serverless is just servers_over_there :'). same shitty security. just a bit flexible pricing which might or might not benifit people depending on the pricing model and load averages / paterns. most excuses people give for going serverless is just handing off responsibilities to cloud providers to be able to point and blame if the shit hits the fan.
evbots 7y ago
The true cost of any product is the project lifecycle cost. There are many cases where a serverless architecture would cut down on that.
zemo 7y ago
if you work for an org that has cash on hand but not a lot of developer talent, the tradeoff is worth it. If the difference is going to cost you $50k a year but let you hire one less programmer, it's worth it.
api 7y ago
Serverless was just a lock in model pushed by big cloud vendors.
hassanjahan 7y ago
If you want something performant and cheap you just need to go with Assembly. It's expected that super flexible software platforms are very costly.
matchagaucho 7y ago
Everytime I read these types of articles, I immediately login to AWS billing console and review our costs. We switched to AWS serverless about a year ago (API gateway and Lambda) and there have been no real surprises. I've been able to increase our contractual SLA uptime to customers (and charge for it). We can kick-off more backend async processes and let the magic of auto-scaling just do it's thing. If anything, I now have a fear of getting too complacent, as we no longer have a FTE SRE monitoring infra. If something goes seriously wrong, we have to rely on our DevOps AWS console skills to troubleshoot. But similarly, if the power goes out in California, I have to rely on PGE to fix the issue. Serverless is also a cultural decision to outsource the infra.
- ownagefool 7y ago
  Those SRE infra skills pretty much crossover with knowing what your app is doing in FaaS environment. How do you know those async requests are completing? What's the percentage of failures? Are you meeting those SLAs? Who's patching the code? How do you test and deploy new versions? Those are all typically seen as ops tasks, now you're doing them. Small bit of concern around you saying you're using the console, because good testing generally requires Infrastructure as Code, but I suspect the reality is your operational readiness meets your risk profile. That or you're winging it ya big cowboy. :p
  - matchagaucho 7y ago
    AWS Cloudwatch pretty much delivers every metric imaginable. Whether leasing EC2 servers or running serverless Lambdas, the logs all rollup to the same place. We're gradually using more AWS CLI for things like deployment and policy management. But the console is sufficient for 80% of Serverless DevOps.
    - ownagefool 7y ago
      Getting metrics into the system is only half the battle; using them is arguably more important and complicated half. And well, I mean if all your guys are just trusted to directly use the CLI or Console, then what you doing for governance and insider threats? Using logs? Blind trust? As I said, how you're doing things might be fine for your risk profile, but probably not when you could suffer a $1m GDPR penalty, and actually, more than just the money, the ethical issue of fucking over your users matters to some of us. Not having a go, just saying there are reasons people use terraform, stick it in gitlab, and use CI/CD. You might be too small for that, or you might not have the data, but we aren't doing it for fun :p
brillout 7y ago
> Tech should be about results, it should not be a religion. I couldn't agree more with this. I'm trying to get a small library [1] I wrote popular and it's insane how much resistance I get because it doesn't fit the "mainstream religion" of using GraphQL. People are brainwashed to think API = REST or GraphQL. How many times did I see a RESTful (or even worse GraphQL) for an internal API where RPC would be so so much simpler... (GraphQL is great for third parties but sh*t for internal stuff.) [1]: https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api, a RPC library for Node.js server <-> Browser.
zidoo 7y ago
amen
ErikAugust 7y ago
You know what I actually like Serverless (AWS Lambda) for? Adding a script that is triggered upon a new message to an SQS queue. The cost in using AWS Lambda is actually in the use of API Gateway, and it doesn't use that, as well. Now, you're right, I didn't find this from any thought leaders, etc. In fact, I would disregard anyone who couldn't give me a concrete use-case and a cost/benefit overview for a technology. I have met a few executives that more or less were trojan horse leaders for other companies' technologies. Salesforce rings a bell.

ecmascript 7y ago

Not only that, but it is also way harder to structure and develop than a normal application. At least in my experience.

coldtea 7y ago

>We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests) That goes without saying! That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...

bdcravens 7y ago
If we really want easy, we’d all be writing ColdFusion or Visual Basic.
- coldtea 7y ago
  If we valued productivity, and those were indeed easier, then we should. There's no real pride in not valuing easy if it's also good.
- wolco 7y ago
  Why did we move away from VB? Great for writing for a single platform. Cold Fusion had issues that would prevent it from taking over.
laumars 7y ago
> That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before. Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle. Other forms of serverless might save time. However there's always edge cases where they don't and you can lose hours or even days investigating an issue that would be a quick fix if you actually managed the host and/or application. So the short answer is: not always faster nor easier. It really depends on what you're trying to accomplish. > I don't think anybody uses things like AWS or serveless services because they're faster or cheaper... Actually yes they do. But like my previous answer, it depends on what you're trying to accomplish. This is the problem with serverless (and cloud computing in general). People try to distil it down to "this is better for x" and "that is better for y" but actually the benefits and trade offs are far more granular than that. To the extent that you could have two companies in the same sector releasing competing products and still what architecture makes sense for one company might not for the other. This is also why nobody ever agrees about these topics online - by the time you've generalised the examples enough to describe them in a forum post, they lose the specificity that makes any accurate design possible.
- fendy3002 7y ago
  Can't agree more. One example is CI/CD through docker image, building image / deploying container may take ten to thirty minutes long. It's a hindrance for quick bugfix / tempering on test server.
- mywittyname 7y ago
  > Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle. This has not been my experience at all. Maybe because I have a lot of experience with Lambda, but I find them to be a very fast way to get code written and running. Granted, Lambda is a great tool for a specific category of task. Namely, when you need to programmatically respond to some event which was triggered by another AWS service and can do so in under 5 minutes. But it's poorly suited for tasks outside of that domain. In that sense, it's like Bash: you don't want to do everything with it, but there are situations where it's the best tool.
goatinaboat 7y ago
1 programmer/ops guy can do what it took 10 before. The myth: devs are expensive and hardware is cheap The reality: webdevs are a commodity and AWS is making record profits
- coldtea 7y ago
  The real reality: not all devs required are webdevs, especially if you want to build an infrastructure that can handle millions of people worldwide. It's not like some React and CSS will get you that. The amount you'll pay for a single additional developer, even if it's "just" 70K, is already close (if not double) your whole Clould costs when you start...
  - edw 7y ago
    Yes. And there’s also the issue that even if someone would choose to work for free, incremental bodies in an org tend to increase the org’s complexity.
  - wolco 7y ago
    When you start you don't need to handle millions of customers worldwide. If all you need is to handle a million customers per month digitalocean can handle that on a single server and you wouldn't hire a single let alone many developers to manage that. If you ever reach the point where you need to handle 100s of millions of customers a month / hiring someone can save you money but perhaps serverless makes sense. 99% of businesses will not reach that level.
NicoJuicy 7y ago
> it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before Perhaps it's more related to the programmer than the tech stack... It's also not solely developping, but debugging too. And serverless does make things a lot harder.
- bcyn 7y ago
  Why does serverless make things a lot harder? I'd argue that the stateless nature of serverless actually makes it much, much easier to debug.
jbergens 7y ago
They can be a lot cheaper. Maybe only in some cases but then it can make a difference.

avip 7y ago

There are enough results to prove that serverless is useful (may I say, correct) architecture in many use cases. Not everyone is dumb, contrary to a common belief. Don't be religious.

scarface74 7y ago

It isn’t about “reality” it’s about trade offs. Every choice you make when it comes to infrastructure, whether to build or buy, etc comes with trade offs. The trade offs and benefits of using lambda isn’t a secret.

nickjj 7y ago

Agreed. ~2 years ago I seriously looked into Serverless and very quickly discarded it after seeing a large production deployment of it. I didn't have access to the billing info but the site loaded much slower than a regular site and developer productivity was quite low. I'm going to stick with good old servers for now. If anyone is curious, a few years ago I did a write up on "Should your next project be built as a Serverless app?" which compares deployment styles in a bit more detail: https://nickjanetakis.com/blog/should-your-next-project-be-built-as-a-serverless-app https://nickjanetakis.com/blog/should-your-next-project-be-b...

herostratus101 7y ago
Hey nickjj, you may want to update your blog post to reflect that the Lambda timeout is now 15m, not 5m.
- nickjj 7y ago
  Hi, thanks for the heads up. I just updated it.

tus88 7y ago

This is all strawman. There are valid reasons for serverless, most people choose it for reasons other than hype, and the savings and security of not self managing servers is tangible. All technology can be misused or poorly utilized, and even the best can have pathological edge cases. For the 80% or more, serverless works just fine.

marvindanig 7y ago
Not a strawman, nope. Please put the React salesmen on this list of bogus hype as well. It’s all projection and propaganda—zero substance. Here’s the proof of evil intent behind React, for example: https://news.ycombinator.com/item?id=20711598 https://news.ycombinator.com/item?id=20711598
- nocman 7y ago
  I suspect I am more wary of Facebook than most. However, unless there is something in that linked discussion that I'm just not seeing, I don't get it. Or perhaps your idea of "proof" and mine are just vastly different.
  - marvindanig 7y ago
    proof = hint. /correction i guess we’ll have to wait for the trail of destruction to appear as proof of everything else that has come from Facebook.
- fourthark 7y ago
  Um, I couldn't find any evil in that thread, sorry.
dave_sid 7y ago
While in most cases I would agree, in this case I have to disagree. I think serverless has been a good idea implemented badly in every instance.
- danesparza 7y ago

vectorEQ 7y ago

serverless is just servers_over_there :'). same shitty security. just a bit flexible pricing which might or might not benifit people depending on the pricing model and load averages / paterns. most excuses people give for going serverless is just handing off responsibilities to cloud providers to be able to point and blame if the shit hits the fan.

evbots 7y ago

The true cost of any product is the project lifecycle cost. There are many cases where a serverless architecture would cut down on that.

zemo 7y ago

if you work for an org that has cash on hand but not a lot of developer talent, the tradeoff is worth it. If the difference is going to cost you $50k a year but let you hire one less programmer, it's worth it.

api 7y ago

Serverless was just a lock in model pushed by big cloud vendors.

hassanjahan 7y ago

If you want something performant and cheap you just need to go with Assembly. It's expected that super flexible software platforms are very costly.

matchagaucho 7y ago

Everytime I read these types of articles, I immediately login to AWS billing console and review our costs. We switched to AWS serverless about a year ago (API gateway and Lambda) and there have been no real surprises. I've been able to increase our contractual SLA uptime to customers (and charge for it). We can kick-off more backend async processes and let the magic of auto-scaling just do it's thing. If anything, I now have a fear of getting too complacent, as we no longer have a FTE SRE monitoring infra. If something goes seriously wrong, we have to rely on our DevOps AWS console skills to troubleshoot. But similarly, if the power goes out in California, I have to rely on PGE to fix the issue. Serverless is also a cultural decision to outsource the infra.

ownagefool 7y ago
Those SRE infra skills pretty much crossover with knowing what your app is doing in FaaS environment. How do you know those async requests are completing? What's the percentage of failures? Are you meeting those SLAs? Who's patching the code? How do you test and deploy new versions? Those are all typically seen as ops tasks, now you're doing them. Small bit of concern around you saying you're using the console, because good testing generally requires Infrastructure as Code, but I suspect the reality is your operational readiness meets your risk profile. That or you're winging it ya big cowboy. :p
- matchagaucho 7y ago
  AWS Cloudwatch pretty much delivers every metric imaginable. Whether leasing EC2 servers or running serverless Lambdas, the logs all rollup to the same place. We're gradually using more AWS CLI for things like deployment and policy management. But the console is sufficient for 80% of Serverless DevOps.
  - ownagefool 7y ago
    Getting metrics into the system is only half the battle; using them is arguably more important and complicated half. And well, I mean if all your guys are just trusted to directly use the CLI or Console, then what you doing for governance and insider threats? Using logs? Blind trust? As I said, how you're doing things might be fine for your risk profile, but probably not when you could suffer a $1m GDPR penalty, and actually, more than just the money, the ethical issue of fucking over your users matters to some of us. Not having a go, just saying there are reasons people use terraform, stick it in gitlab, and use CI/CD. You might be too small for that, or you might not have the data, but we aren't doing it for fun :p

brillout 7y ago

> Tech should be about results, it should not be a religion. I couldn't agree more with this. I'm trying to get a small library [1] I wrote popular and it's insane how much resistance I get because it doesn't fit the "mainstream religion" of using GraphQL. People are brainwashed to think API = REST or GraphQL. How many times did I see a RESTful (or even worse GraphQL) for an internal API where RPC would be so so much simpler... (GraphQL is great for third parties but sh*t for internal stuff.) [1]: https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api, a RPC library for Node.js server <-> Browser.

zidoo 7y ago

amen

ErikAugust 7y ago

You know what I actually like Serverless (AWS Lambda) for? Adding a script that is triggered upon a new message to an SQS queue. The cost in using AWS Lambda is actually in the use of API Gateway, and it doesn't use that, as well. Now, you're right, I didn't find this from any thought leaders, etc. In fact, I would disregard anyone who couldn't give me a concrete use-case and a cost/benefit overview for a technology. I have met a few executives that more or less were trojan horse leaders for other companies' technologies. Salesforce rings a bell.