5 ms·

I cringe every time I read serverless, what exactly is that supposed to convey? That the code is so ephemeral that it doesn't even exist, or does the code exec

I cringe every time I read serverless, what exactly is that supposed to convey? That the code is so ephemeral that it doesn't even exist, or does the code execute on a higher plane of existence without the need for lowly hardware and dirty power? Furthermore, I fail to see what real world problems this architecture solves. It seems to offer rapid horizontal scaling at the cost of complexity, performance, and vendor lock-in.

duxup 8y ago
I just think of it as "There is some layer of software that you don't have to think about anymore because we handle it." That could mean ANYTHING, and result in ANYTHING, but ... it's usually what it means.
mavdi 8y ago
Shhhhh... bread and butter... it's just a way for us to make shit up and charge corps for failed application rewrites that are google scale from the start for their 10 customers.
kentm 8y ago
I think the first point of your rant is that it’s a misonomer and that’s correct. There’s still a server there. “Serverless” means that you don’t think about or manage individual servers yourself and let your provider abstract it away from you. You mostly understand the trade offs. The advantages are reduced ops in the happy case and modeling your software in a way that is amenable to horizontal scaling. Providers make executing the horizontal scaling pretty easy for the typical case. The disadvantages are vendor lock in the inability to do real deep diving if you have a problem with the hosting stack rather than the service logic itself.
jkingsbery 8y ago
(Disclaimer: I am an Amazon employee, but my opinions are my own. I don't work in the AWS organization, so my knowledge of AWS services isn't substantially different than other engineers outside of Amazon.) There obviously are servers, "serverless" just implies you don't own them. There's a few problems that using serverless solves: 1. It's great for low volume sites or services. You don't need to rent hardware that runs the whole month if you only get pinged a few times per day. 2. It reduces operational burden. A whole class of problem goes away - patching operating systems and application servers. 3. It provides an abstraction layer for processing events. Events could be HTTP requests to a site, data coming in from an IoT device, that a new file was uploaded to S3, etc. Performance isn't that different from using EC2 (or the non-AWS equivalents), other than cold start times, and choice of language platform can help mitigate that. In terms of complexity, for the project work I've done the complexity isn't different than running something in any other application server. Cloud providers other than AWS have a serverless offering, and there are frameworks out there for abstracting the differences, so tooling support doesn't have to come with lock-in. In addition, a well-architected serverless application has a pretty small layer interfacing with the serverless framework, so the code lock in is negligible.
- tomphoolery 8y ago
  I'm just waiting for "Serverless" to not mean "app-less" or "organization-less"...
- esotericn 8y ago
  #1 - A VPS that you can run multiple services on is 5 quid a month. I spent more than that on a single train in to the city today. Or you can just run from a residential connection for effectively free if your service is _that_ small. #2 - "Serverless" paradigms change often enough that it's essentially another form of patching. It's also obviously not true, any system you write code on needs to be patched because it has auth to this system. #3 seems to be buzzwords with no substance? As far as I can tell, the only "problem" that "serverless" (i.e. Our Servers) solves is Amazon not monetizing everything ever.
  - jnty 8y ago
    Quoting the price of a VPS totally misses the point - the cost is in finding one, setting it up with an environment somehow, monitoring it, making sure it stays patched and current over years and years... While you're busy figuring out what monitoring solution to use on your VPS to monitor the running all for the sake of a little Python script, I've already set up a lambda function and maybe set a cloudwatch alarm to look after it and can move on to the next thing and leave it running indefinitely. Depending on the usecase I might not even pay a penny during that time, either. I swear 90% of the hate for serverless purely stems from irritation at the name.
    - isomorph 8y ago
      Hi - I couldn't find a way to contact you and was unable to reply in situ for some reason. Could you please say more about why you felt I had gratuitously editorialised the title to my latest submission? ( https://news.ycombinator.com/submitted?id=isomorph https://news.ycombinator.com/submitted?id=isomorph ) I have checked the definition of the word "editorialise: To present an opinion in the guise of an objective report." - I did not express any opinion in the title - I simply added context for those who don't know about the so-called "contaminated blood scandal" in the UK. Namely the three-letter detail I added was "HIV" i.e. that the UK's government-run National Health Service infected patients as young as 8 years old with HIV. This change was not gratuitous as it added essential context to the story. I have checked the Hacker News guidelines and since the article dispels myths people have about health systems, I felt it was pertinent.
watty 8y ago
The idea is to reduce complexity as developers can simply provide code and let the service handle everything else. Unfortunately, the technology isn't there yet and serverless is actually more complex than traditional managing servers.
dustingetz 8y ago
Serverless (to me) means userland code is just functions. It is very simple. It may actually reduce lockin, because simple functions can port to any platform, even servers! (You just call the function) I co-made http://www.hyperfiddle.net/ http://www.hyperfiddle.net/ , which can do 100% serverless websites in two easy steps: 1) type in markdown or clojurescript, 2) click save.
msoad 8y ago
Just like how the cloud is "hardwareless" functions are serverless.
lostcolony 8y ago
I'll give you one where it benefits us, in the real world, where it's -not- just horizontal scalability. Almost all of my team's efforts are internal applications. They're high throughput ad related functionalities, but fundamentally another business client says "hey, we have a user, we need an ad", and all our stuff works to fill it. We are, as such, on an internal VPC in AWS. This is fine. But we sometimes need to allow for client code run outside of the network to be able to securely change out our stuff; think ad partners modifying their inventory. We can add an API on top of one of our services, but then we have to deal with authentication and proxying. We can certainly authenticate and proxy those requests into the network ourselves. But that creates some fun and interesting risks and issues; we're building something explicitly to bypass the safeguards of running in a private subnet in our own VPC, and tunnel traffic from the big wide world into the depths of our own network (which is also connected to our corporate network). We can also spin up a new service on a server that lives outside the VPC; however that has the downside that we're paying for an instance for a very low traffic service, and it still requires support. Or, we use a Serverless paradigm. The website hits API Gateway/lambda endpoints, authentication is provided via Cognito, and it all leads to the lambda executing against a single resource (S3, Dynamo, whatever) to modify data that our services read from. No entering our network, and all security relying on security primitives Amazon owns and maintains (they are far better equipped to handle it than we are). And it will cost us pennies, while leaving our existing infrastructure unaffected.
stephengillie 8y ago
Old-school serverless is a flat HTML page served by a simple host over HTTP. These days, S3 is robust enough to be the simple host.
all_blue_chucks 8y ago
As a security person I love serverless. Sometimes getting people to patch or harden servers can be like pulling teeth. These problems just go away in a serverless arc.
oogali 8y ago
I struggle with trying to understand how serverless is radically different in concepts than old-school cgi-bin. In both scenarios, you don't necessarily own the servers. Best practice dictates that your static content lives in a separate area rather than within your application (a different directory or alias, or in the serverless context: an S3 bucket) You don't worry about patching upstream OSes or applications. You front your application and static content with an "API gateway" (or in the cgi-bin case: Apache httpd w/mod_rewrite). Your application's implementation is governed by whatever interpreters are available to you (#!/usr/bin/perl vs. #!/usr/bin/python vs. Node from a drop-down) Any environment specifics are injected into your application's operating context (environment variables in the case of cgi-bin, or an argument to your entry function in the case of AWS Lambda). The one radical difference I do recognize is the independent-ish execution environment: e.g. my CPAN modules, don't intermix with your CPAN modules. It seems like the same paradigm, but with a new coat of paint.
mitchtbaum 8y ago
I think the term they're skirting is "hosted". For "serverless", I think of users downloading the whole application and running it locally. To do that, the code, content, and config need to be made portable and reusable, ie packaged.
scarface74 8y ago
I cringe every time I read serverless, what exactly is that supposed to convey? That the code is so ephemeral that it doesn't even exist, or does the code execute on a higher plane of existence without the need for lowly hardware and dirty power? Why every time someone mentions “serverless”, there is a post where people feign ignorance and “cringes”. Do you also cringe when people mention that there is a virus on their computer or a bug in their program? Words change meanings over time. From your post, you obviously know what serverless means in context. Furthermore, I fail to see what real world problems this architecture solves. It seems to offer rapid horizontal scaling at the cost of complexity, performance, and vendor lock-in. Any complex system you always have “vendor lock-in”. It’s just like all of the coders who have the nice pretty Repository Pattern just in case their business decides to rip out their multi million dollar Oracle installation. Furthermore, I fail to see what real world problems this architecture solves. It seems to offer rapid horizontal scaling at the cost of complexity, performance, and vendor lock-in. Lambdas are not just for APIs and it’s the one use case that I avoid using it for. I use it mostly to respond to events and stream processing with Kinesis.
MuppetMaster42 8y ago
I used to work at a startup which transitioned to lambda from ec2. We rewrote our backend from rest php to graphql typescript. I can tell you that it is amazing operationally. You push code to aws and it just runs. A comparison with manually managed ec2: - push code to lambda and lambda automatically handles the dns updates and VIP swaps. No need to worry about configuring multi region blue-green deployments and health checks. - no chance of a server needing manual intervention because of an errored state - because you can't store state between requests (not entirely true, but true enough). But failing that you know that the container will die soon anyways. - automatic scaling instantly. Our platform was b2b, so most of the traffic was 7-7. Instead of running load balancers and scaling the servers, we needed to do nothing. AWS starts and kills new instances to handle the load automatically. - no need to worry about the server config. Only need to specify a node version and a CPU size. It's a godsend from a dev standpoint because ultimately you don't care about that. Why bother managing the OS config, drivers, installed software + libraries. Sure it me as you can't squeeze every cycle of perf out a box, but chances are you aren't in a position to need to. - pay per call, not per second. We were serving hundreds of thousands of calls via lambda every month, and the bill came out just over a single digit. I've read articles about the crossover point cost wise but it takes some decent scale to get there. Theres no rules about how you architect a lambda function, just rules about how long it runs for. Like I said, we ran our entire graphql api via a single lambda function and it worked great. Things get a little more complicated when you need to kick off background processes, but again that can be pretty simple if you want it to be. We just pushed messages to an sns queue which triggered a different lambda off. Note though that all this code was in the same repo, sharing code within everything. The tldr of this really is: imagine running a service was as simple as pushing code to aws. That is what lambda enables.

I cringe every time I read serverless, what exactly is that supposed to convey? That the code is so ephemeral that it doesn't even exist, or does the code execute on a higher plane of existence without the need for lowly hardware and dirty power? Furthermore, I fail to see what real world problems this architecture solves. It seems to offer rapid horizontal scaling at the cost of complexity, performance, and vendor lock-in.

duxup 8y ago

I just think of it as "There is some layer of software that you don't have to think about anymore because we handle it." That could mean ANYTHING, and result in ANYTHING, but ... it's usually what it means.

mavdi 8y ago

Shhhhh... bread and butter... it's just a way for us to make shit up and charge corps for failed application rewrites that are google scale from the start for their 10 customers.

kentm 8y ago

I think the first point of your rant is that it’s a misonomer and that’s correct. There’s still a server there. “Serverless” means that you don’t think about or manage individual servers yourself and let your provider abstract it away from you. You mostly understand the trade offs. The advantages are reduced ops in the happy case and modeling your software in a way that is amenable to horizontal scaling. Providers make executing the horizontal scaling pretty easy for the typical case. The disadvantages are vendor lock in the inability to do real deep diving if you have a problem with the hosting stack rather than the service logic itself.

jkingsbery 8y ago

(Disclaimer: I am an Amazon employee, but my opinions are my own. I don't work in the AWS organization, so my knowledge of AWS services isn't substantially different than other engineers outside of Amazon.) There obviously are servers, "serverless" just implies you don't own them. There's a few problems that using serverless solves: 1. It's great for low volume sites or services. You don't need to rent hardware that runs the whole month if you only get pinged a few times per day. 2. It reduces operational burden. A whole class of problem goes away - patching operating systems and application servers. 3. It provides an abstraction layer for processing events. Events could be HTTP requests to a site, data coming in from an IoT device, that a new file was uploaded to S3, etc. Performance isn't that different from using EC2 (or the non-AWS equivalents), other than cold start times, and choice of language platform can help mitigate that. In terms of complexity, for the project work I've done the complexity isn't different than running something in any other application server. Cloud providers other than AWS have a serverless offering, and there are frameworks out there for abstracting the differences, so tooling support doesn't have to come with lock-in. In addition, a well-architected serverless application has a pretty small layer interfacing with the serverless framework, so the code lock in is negligible.

tomphoolery 8y ago
I'm just waiting for "Serverless" to not mean "app-less" or "organization-less"...
esotericn 8y ago
#1 - A VPS that you can run multiple services on is 5 quid a month. I spent more than that on a single train in to the city today. Or you can just run from a residential connection for effectively free if your service is _that_ small. #2 - "Serverless" paradigms change often enough that it's essentially another form of patching. It's also obviously not true, any system you write code on needs to be patched because it has auth to this system. #3 seems to be buzzwords with no substance? As far as I can tell, the only "problem" that "serverless" (i.e. Our Servers) solves is Amazon not monetizing everything ever.
- jnty 8y ago
  Quoting the price of a VPS totally misses the point - the cost is in finding one, setting it up with an environment somehow, monitoring it, making sure it stays patched and current over years and years... While you're busy figuring out what monitoring solution to use on your VPS to monitor the running all for the sake of a little Python script, I've already set up a lambda function and maybe set a cloudwatch alarm to look after it and can move on to the next thing and leave it running indefinitely. Depending on the usecase I might not even pay a penny during that time, either. I swear 90% of the hate for serverless purely stems from irritation at the name.
  - isomorph 8y ago
    Hi - I couldn't find a way to contact you and was unable to reply in situ for some reason. Could you please say more about why you felt I had gratuitously editorialised the title to my latest submission? ( https://news.ycombinator.com/submitted?id=isomorph https://news.ycombinator.com/submitted?id=isomorph ) I have checked the definition of the word "editorialise: To present an opinion in the guise of an objective report." - I did not express any opinion in the title - I simply added context for those who don't know about the so-called "contaminated blood scandal" in the UK. Namely the three-letter detail I added was "HIV" i.e. that the UK's government-run National Health Service infected patients as young as 8 years old with HIV. This change was not gratuitous as it added essential context to the story. I have checked the Hacker News guidelines and since the article dispels myths people have about health systems, I felt it was pertinent.

watty 8y ago

The idea is to reduce complexity as developers can simply provide code and let the service handle everything else. Unfortunately, the technology isn't there yet and serverless is actually more complex than traditional managing servers.

dustingetz 8y ago

Serverless (to me) means userland code is just functions. It is very simple. It may actually reduce lockin, because simple functions can port to any platform, even servers! (You just call the function) I co-made http://www.hyperfiddle.net/ http://www.hyperfiddle.net/ , which can do 100% serverless websites in two easy steps: 1) type in markdown or clojurescript, 2) click save.

msoad 8y ago

Just like how the cloud is "hardwareless" functions are serverless.

lostcolony 8y ago

I'll give you one where it benefits us, in the real world, where it's -not- just horizontal scalability. Almost all of my team's efforts are internal applications. They're high throughput ad related functionalities, but fundamentally another business client says "hey, we have a user, we need an ad", and all our stuff works to fill it. We are, as such, on an internal VPC in AWS. This is fine. But we sometimes need to allow for client code run outside of the network to be able to securely change out our stuff; think ad partners modifying their inventory. We can add an API on top of one of our services, but then we have to deal with authentication and proxying. We can certainly authenticate and proxy those requests into the network ourselves. But that creates some fun and interesting risks and issues; we're building something explicitly to bypass the safeguards of running in a private subnet in our own VPC, and tunnel traffic from the big wide world into the depths of our own network (which is also connected to our corporate network). We can also spin up a new service on a server that lives outside the VPC; however that has the downside that we're paying for an instance for a very low traffic service, and it still requires support. Or, we use a Serverless paradigm. The website hits API Gateway/lambda endpoints, authentication is provided via Cognito, and it all leads to the lambda executing against a single resource (S3, Dynamo, whatever) to modify data that our services read from. No entering our network, and all security relying on security primitives Amazon owns and maintains (they are far better equipped to handle it than we are). And it will cost us pennies, while leaving our existing infrastructure unaffected.

stephengillie 8y ago

Old-school serverless is a flat HTML page served by a simple host over HTTP. These days, S3 is robust enough to be the simple host.

all_blue_chucks 8y ago

As a security person I love serverless. Sometimes getting people to patch or harden servers can be like pulling teeth. These problems just go away in a serverless arc.

oogali 8y ago

I struggle with trying to understand how serverless is radically different in concepts than old-school cgi-bin. In both scenarios, you don't necessarily own the servers. Best practice dictates that your static content lives in a separate area rather than within your application (a different directory or alias, or in the serverless context: an S3 bucket) You don't worry about patching upstream OSes or applications. You front your application and static content with an "API gateway" (or in the cgi-bin case: Apache httpd w/mod_rewrite). Your application's implementation is governed by whatever interpreters are available to you (#!/usr/bin/perl vs. #!/usr/bin/python vs. Node from a drop-down) Any environment specifics are injected into your application's operating context (environment variables in the case of cgi-bin, or an argument to your entry function in the case of AWS Lambda). The one radical difference I do recognize is the independent-ish execution environment: e.g. my CPAN modules, don't intermix with your CPAN modules. It seems like the same paradigm, but with a new coat of paint.

mitchtbaum 8y ago

I think the term they're skirting is "hosted". For "serverless", I think of users downloading the whole application and running it locally. To do that, the code, content, and config need to be made portable and reusable, ie packaged.

scarface74 8y ago

I cringe every time I read serverless, what exactly is that supposed to convey? That the code is so ephemeral that it doesn't even exist, or does the code execute on a higher plane of existence without the need for lowly hardware and dirty power? Why every time someone mentions “serverless”, there is a post where people feign ignorance and “cringes”. Do you also cringe when people mention that there is a virus on their computer or a bug in their program? Words change meanings over time. From your post, you obviously know what serverless means in context. Furthermore, I fail to see what real world problems this architecture solves. It seems to offer rapid horizontal scaling at the cost of complexity, performance, and vendor lock-in. Any complex system you always have “vendor lock-in”. It’s just like all of the coders who have the nice pretty Repository Pattern just in case their business decides to rip out their multi million dollar Oracle installation. Furthermore, I fail to see what real world problems this architecture solves. It seems to offer rapid horizontal scaling at the cost of complexity, performance, and vendor lock-in. Lambdas are not just for APIs and it’s the one use case that I avoid using it for. I use it mostly to respond to events and stream processing with Kinesis.

MuppetMaster42 8y ago

I used to work at a startup which transitioned to lambda from ec2. We rewrote our backend from rest php to graphql typescript. I can tell you that it is amazing operationally. You push code to aws and it just runs. A comparison with manually managed ec2: - push code to lambda and lambda automatically handles the dns updates and VIP swaps. No need to worry about configuring multi region blue-green deployments and health checks. - no chance of a server needing manual intervention because of an errored state - because you can't store state between requests (not entirely true, but true enough). But failing that you know that the container will die soon anyways. - automatic scaling instantly. Our platform was b2b, so most of the traffic was 7-7. Instead of running load balancers and scaling the servers, we needed to do nothing. AWS starts and kills new instances to handle the load automatically. - no need to worry about the server config. Only need to specify a node version and a CPU size. It's a godsend from a dev standpoint because ultimately you don't care about that. Why bother managing the OS config, drivers, installed software + libraries. Sure it me as you can't squeeze every cycle of perf out a box, but chances are you aren't in a position to need to. - pay per call, not per second. We were serving hundreds of thousands of calls via lambda every month, and the bill came out just over a single digit. I've read articles about the crossover point cost wise but it takes some decent scale to get there. Theres no rules about how you architect a lambda function, just rules about how long it runs for. Like I said, we ran our entire graphql api via a single lambda function and it worked great. Things get a little more complicated when you need to kick off background processes, but again that can be pretty simple if you want it to be. We just pushed messages to an sns queue which triggered a different lambda off. Note though that all this code was in the same repo, sharing code within everything. The tldr of this really is: imagine running a service was as simple as pushing code to aws. That is what lambda enables.