15 ms·

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 managi

by 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
  Truly: I would encourage you to develop something better, then. Please put your wisdom to good use.
  - protonfish 7y ago
    How about using a server?
    - ianwalter 7y ago
      Serverful?
- hnal943 7y ago
  Sounds awfully familiar to "real socialism has never been tried" - if every attempt ends in failure, the value prop needs to be reevaluated.
  - pm90 7y ago
    Socialism is an ideology though. It might sound similar but that’s it. Every technology has a break in period where good ideas are badly implemented. It’s after you pass that initial stage and understand both the tech and how to implement and use it efficiently do you start to see the real gains of it.
- lurker458 7y ago
  If (nearly) every implementation of a good idea turns out badly, is it still a good idea ? It smells like the No True Scotsman fallacy.
PedroBatista 7y ago
I suspect if you were to put "your money where your mouth is" those 80% of yours would turn into 20 or less. ;)
188201 7y ago
I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.
- rgallagher27 7y ago
  Have been running our API on Gateway/Lambda for well over a year now, having migrated from EC2. We've spent almost no time "managing" API gateway, monitoring or logging since the initial setup and migration of our infrastructure. If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.
- cle 7y ago
  You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.
  - mbrumlow 7y ago
    >> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.
    - tapoxi 7y ago
      > Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.
jririi82zxn 7y ago
Wow everyone all excited about hosted FreeBSD jails Some of us had deploy pipelines into “containers” working like a Lambda in 2003. Nothing in software is all that novel these days, IMO. All these features that have been there for a decade plus are just wrapped in a corporate brand now. Progress.
- afiori 7y ago
  > Nothing in software is all that novel these days, IMO. There is surely truth in this. But also, almost nothing is novel if you watch at the new stuff with the same mindset of the past. It is wise to realize that most new stuff was already invented, but it is also wise to understand that the surrounding might have changed more than you realize. (Talking out of my own ass here, just in philosophical terms)
- derefr 7y ago
  The “feature” behind Lambdas aren’t the way they work; it’s the way they force you to work, exposing an ABI that forces “Lambda-compatible code” into a shape where it isn’t attempting to call into OS features of the local machine for things like state storage or IPC, but rather making calls to network-visible service endpoints to accomplish those tasks. In other words, the Lambda environment, as a development target, is the exact opposite point on the spectrum from an OS like Mosix: rather than trying to make a big cluster of specialized compute resources appear as a standardized local POSIX environment, Lambda instead does away with the POSIX environment entirely and forces your code to interface with the big cluster of specialized compute resource “where it lives.” You can’t just write to disk, because there is no disk. You can’t just talk to other processes on the same machine, because there is no (multiprocessing) machine. In fact, you can’t even cache state in process memory indefinitely, because your process isn’t indefinite like it is in POSIX. Etc. This is a big benefit for ops folks, insofar as code that’s written as “Lambda code” (but generically, using libraries like Fog) can be easily run in many more modern infrastructure environments (including on-prem ones!) than regular code can, “at scale”, without modification to the code itself. As well, these restrictions (like the one on not caching state in memory) force devs to confront what turn out to be the realities of fault-tolerance, which means far less of an ops headache later on, trying to baby along workloads that rely on never dying. I would describe Lambda as doing a very similar thing for the server, as what Google’s Native Client (PPAPI) attempted to do for the browser: to create a new, strict ABI for developers to target, that forces code written against that ABI to build its features differently (i.e. more portably, more securely, etc.) Or, philosophically, “serverless” is just a further extension of Heroku’s “twelve-factor”: it’s an approach that hobbles developers’ available toolkit, for the sake of making the workloads they produce better-behaved and more predictable at runtime.
tomcam 7y ago
> For the 80% or more, serverless works just fine. Citation?
missosoup 7y ago
> For the 80% or more, serverless works just fine. Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that looks to 'thought leaders' and Gartner to tell them what technologies to use. if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.
- ivanbakel 7y ago
  Because comment sections are not good measures of opinion - they are places for discussion. People make more effort to engage if they have strong positive opinions and minor negative opinions. Minor positive opinions, which (you hope) are the average in an audience, get unrepresented if the effort required to give feedback is great. That's why metrics measuring average opinion - like NPS - aim to require as little effort as possible.
- rmdashrfstar 7y ago
  > HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology. Source?
- badrequest 7y ago
  Odd that you demand a citation and then counter with 3rd party anecdotes.
- tgeek 7y ago
  Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless (https://twitter.com/chrismunns https://twitter.com/chrismunns). I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing. If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sharepoint, SAP, or similar) and then look at how many business applications take on a trivial amount of load over time, then the author's post becomes more of an outlier. Few folks have apps that do 100rps realistically. And so for data processing/streaming/batch or web/api workloads serverless actually does work out pretty well. Is this 80%, I am not sure. There is 100% an inflection point where if your operator cost is low enough(human work+3p tools+process+care and feeding) then the "metal to metal" costs can be comparable. Even the author admits that's leaving something on the floor and so it really comes down to what your organization values most. I would love for most of our serverless app workloads to be top-down organizationally driven but the reality of it is that it comes often from developers themselves and/or line of business organizations with skin in the game of seeing things move faster in most organizations. This will then typically require buy in from security and ops groups. If these folks you know have the trick to driving top down incompetent strategic management towards serverless I'd buy in on that newsletter. In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. I think there's also a larger number of people that represent IT vendors that would love to see AWS fail here :) Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns https://twitter.com/chrismunns
spamizbad 7y ago
The only application where I've found serverless to work well is for simple plumbing/event sourcing in AWS. They are less apps and more "tiny scripts that automatically run". 99% of the work is still done in containers on actual servers. The serverless portion is by far the least "developer ergonomic" but that's not a problem if your code is less than a hundred lines and rarely subject to changes. The idea of running your entire app as serverless sounds like pulling teeth. Thought leaders are free to pat each other on the back on that one... I won't mind being called a luddite.
tsmarsh 7y ago
The most interesting thing about serverless for me isn't 'web scale' its 'scale to zero'. My apps tend to be bursty, with trickles of data in between. I mostly concerned in reducing their 'idle' costs, so not having to manage the OS, security etc is a massive cost saving for us.
pmlnr 7y ago
> There are valid reasons for serverless Those scenarios are probably just as happy with a PHP script on Apache.
dclowd9901 7y ago
It sounds like what you're saying is for OP to have been able to leverage serverless properly, he should have fired a devops engineer?
deleted 7y ago
[deleted]
inimino 7y ago
> most people choose it for reasons other than hype [citation desperately needed]
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
andrei_says_ 7y ago
Managed servers also exist and are in quite of a sweet spot if you need the performance.

by tus88 7y ago

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
Truly: I would encourage you to develop something better, then. Please put your wisdom to good use.
- protonfish 7y ago
  How about using a server?
  - ianwalter 7y ago
    Serverful?
hnal943 7y ago
Sounds awfully familiar to "real socialism has never been tried" - if every attempt ends in failure, the value prop needs to be reevaluated.
- pm90 7y ago
  Socialism is an ideology though. It might sound similar but that’s it. Every technology has a break in period where good ideas are badly implemented. It’s after you pass that initial stage and understand both the tech and how to implement and use it efficiently do you start to see the real gains of it.
lurker458 7y ago
If (nearly) every implementation of a good idea turns out badly, is it still a good idea ? It smells like the No True Scotsman fallacy.

PedroBatista 7y ago

I suspect if you were to put "your money where your mouth is" those 80% of yours would turn into 20 or less. ;)

188201 7y ago

I really doubt not managing servers is an advantage other than initial launch for MVP or some simple webhook. The overhead of managing API gateway, monitoring and log in a more large scale serverless application is larger than managing several linux servers.

rgallagher27 7y ago
Have been running our API on Gateway/Lambda for well over a year now, having migrated from EC2. We've spent almost no time "managing" API gateway, monitoring or logging since the initial setup and migration of our infrastructure. If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.
cle 7y ago
You should work in enterprises where you have to deal with stringent security requirements, emergency CVE mitigation across multiple regions, compliance requirements, etc., and you’ll quickly gain an appreciation for why enterprise folks don’t want to manage servers.
- mbrumlow 7y ago
  >> emergency CVE mitigation across multiple regions, compliance requirements These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line. Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.
  - tapoxi 7y ago
    > Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy. It shifts blame, especially if it's in the contract with the provider.

jririi82zxn 7y ago

Wow everyone all excited about hosted FreeBSD jails Some of us had deploy pipelines into “containers” working like a Lambda in 2003. Nothing in software is all that novel these days, IMO. All these features that have been there for a decade plus are just wrapped in a corporate brand now. Progress.

afiori 7y ago
> Nothing in software is all that novel these days, IMO. There is surely truth in this. But also, almost nothing is novel if you watch at the new stuff with the same mindset of the past. It is wise to realize that most new stuff was already invented, but it is also wise to understand that the surrounding might have changed more than you realize. (Talking out of my own ass here, just in philosophical terms)
derefr 7y ago
The “feature” behind Lambdas aren’t the way they work; it’s the way they force you to work, exposing an ABI that forces “Lambda-compatible code” into a shape where it isn’t attempting to call into OS features of the local machine for things like state storage or IPC, but rather making calls to network-visible service endpoints to accomplish those tasks. In other words, the Lambda environment, as a development target, is the exact opposite point on the spectrum from an OS like Mosix: rather than trying to make a big cluster of specialized compute resources appear as a standardized local POSIX environment, Lambda instead does away with the POSIX environment entirely and forces your code to interface with the big cluster of specialized compute resource “where it lives.” You can’t just write to disk, because there is no disk. You can’t just talk to other processes on the same machine, because there is no (multiprocessing) machine. In fact, you can’t even cache state in process memory indefinitely, because your process isn’t indefinite like it is in POSIX. Etc. This is a big benefit for ops folks, insofar as code that’s written as “Lambda code” (but generically, using libraries like Fog) can be easily run in many more modern infrastructure environments (including on-prem ones!) than regular code can, “at scale”, without modification to the code itself. As well, these restrictions (like the one on not caching state in memory) force devs to confront what turn out to be the realities of fault-tolerance, which means far less of an ops headache later on, trying to baby along workloads that rely on never dying. I would describe Lambda as doing a very similar thing for the server, as what Google’s Native Client (PPAPI) attempted to do for the browser: to create a new, strict ABI for developers to target, that forces code written against that ABI to build its features differently (i.e. more portably, more securely, etc.) Or, philosophically, “serverless” is just a further extension of Heroku’s “twelve-factor”: it’s an approach that hobbles developers’ available toolkit, for the sake of making the workloads they produce better-behaved and more predictable at runtime.

tomcam 7y ago

> For the 80% or more, serverless works just fine. Citation?

missosoup 7y ago

> For the 80% or more, serverless works just fine. Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that looks to 'thought leaders' and Gartner to tell them what technologies to use. if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.

ivanbakel 7y ago
Because comment sections are not good measures of opinion - they are places for discussion. People make more effort to engage if they have strong positive opinions and minor negative opinions. Minor positive opinions, which (you hope) are the average in an audience, get unrepresented if the effort required to give feedback is great. That's why metrics measuring average opinion - like NPS - aim to require as little effort as possible.
rmdashrfstar 7y ago
> HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology. Source?
badrequest 7y ago
Odd that you demand a citation and then counter with 3rd party anecdotes.
tgeek 7y ago
Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless (https://twitter.com/chrismunns https://twitter.com/chrismunns). I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing. If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sharepoint, SAP, or similar) and then look at how many business applications take on a trivial amount of load over time, then the author's post becomes more of an outlier. Few folks have apps that do 100rps realistically. And so for data processing/streaming/batch or web/api workloads serverless actually does work out pretty well. Is this 80%, I am not sure. There is 100% an inflection point where if your operator cost is low enough(human work+3p tools+process+care and feeding) then the "metal to metal" costs can be comparable. Even the author admits that's leaving something on the floor and so it really comes down to what your organization values most. I would love for most of our serverless app workloads to be top-down organizationally driven but the reality of it is that it comes often from developers themselves and/or line of business organizations with skin in the game of seeing things move faster in most organizations. This will then typically require buy in from security and ops groups. If these folks you know have the trick to driving top down incompetent strategic management towards serverless I'd buy in on that newsletter. In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. I think there's also a larger number of people that represent IT vendors that would love to see AWS fail here :) Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns https://twitter.com/chrismunns

spamizbad 7y ago

The only application where I've found serverless to work well is for simple plumbing/event sourcing in AWS. They are less apps and more "tiny scripts that automatically run". 99% of the work is still done in containers on actual servers. The serverless portion is by far the least "developer ergonomic" but that's not a problem if your code is less than a hundred lines and rarely subject to changes. The idea of running your entire app as serverless sounds like pulling teeth. Thought leaders are free to pat each other on the back on that one... I won't mind being called a luddite.

tsmarsh 7y ago

The most interesting thing about serverless for me isn't 'web scale' its 'scale to zero'. My apps tend to be bursty, with trickles of data in between. I mostly concerned in reducing their 'idle' costs, so not having to manage the OS, security etc is a massive cost saving for us.

pmlnr 7y ago

> There are valid reasons for serverless Those scenarios are probably just as happy with a PHP script on Apache.

dclowd9901 7y ago

It sounds like what you're saying is for OP to have been able to leverage serverless properly, he should have fired a devops engineer?

deleted 7y ago

[deleted]

inimino 7y ago

> most people choose it for reasons other than hype [citation desperately needed]

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

andrei_says_ 7y ago

Managed servers also exist and are in quite of a sweet spot if you need the performance.