I really hope that the website itself is running serverless on AWS, because that would be a great learning opportunity!
It's quite easy and common to wreck a database when you have it hooked up to serverless infrastructure. Depending on the DB, there can be a significant amount of overhead for each client connection. Postgres is particularly bad at this, since it spawns an entire process for each client that connects. This is why connection pooling is so important for applications.
Serverless is a different beast tho; every function is isolated, so having a client pool is much harder/impossible. If you get a flood of traffic, and your function interacts with a DB, you suddenly have a ton of non-multiplexed client connections, which is all it takes to bring many databases to their knees.
If this is a serverless website, I can't wait for the author's next article, describing this issue and how they addressed it. If it's not serverless... add a client pool.
In Java you can create a shared connection pool for AWS lambda functions, e.g. using DI and initialising your injector statically when classes are loaded by the JVM
It relies on AWS using the same container/JVM for your invocations though which isn't guaranteed depending on what your load is.
On top of everything you said, if you put your database inside your VPC, your lambda function has to create a network interface inside the subnet. That increases the cold start time.
DynamoDB is a much better solution for serverless since it just uses a REST interface.
I’m a big fan of lambda but not for user facing API end points. It works well for eventually consistent event processing.
Setting up a Load Balancer and an Autoscaling group is not rocket science. Neither is automated patch management.
Aws serverless Aurora... API interface, fully mysql / postgres compatible, cheap to run - billed on a cpu minutes used basis, massively scalable, auto backup and its much faster than typical dedicated server setups. Amazon's best performing aws product ever they were saying.
Aurora is not the issue. The issue is a lack of connection pooling and the creation and destruction of ENIs when using Lambda with anything inside of a VPC.
If you want to do anything with user facing APIs, suck it up and spend $10 a month for two or three micro Linux instances set up in an autoscaling group behind a load balancer.
I find most sites can just be setup as an S3 bucket with Cloudfront as the CDN. Any special logic can then be housed in some Lambda expressions behind API gateway. That probably would have prevented this outtage. But I haven’t read the article.
So do you proxy your calls from S3 to a serverless service? And do you handle cross origin calls via CORS? Just curious because I've never used serverless before.
You can use JavaScript on the frontend to call a Lambda function that you 100% control (including CORS, etc). You can use this to do things like authentication, authorization, and rate limiting, as well, versus just giving open access to an internal datastore.
Sounds cool in theory, but my small experience with a past company's serverless API is that it made impossible to debug. It was like deploying to a black box. There's no way to hit the API locally, etc.
This is my experience. We will use Azure functions occasionally if all we need is to get data from a third party (with auth, when they can't set up CORS properly), but that's about it.
zappa (for example!) lets you produce a more or less normal flask app that you can run locally, or deploy to lambda / apigw with one command. another command let’s you stream the output of the code as it runs on lambda.
pretty sure similar tools exist for some of the other supported languages.
I've seen that situation as well. My approach recently has been to build things where running on Lambda is a feature, and not so much an architectural decision. The aws-serverless-express library basically wraps an express (or other similar framework) app to handle interfacing with the lambda, marshaling lambda "event" data into the framework request interface, for example.
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.
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.
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.
(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.
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.
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...
If you are spending that much time managing infrastructure on AWS, you’re doing it wrong. ElasticBeanstalk makes it dead simple.
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.
And you can do the same with AWS and a bunch of micro instances. But if it’s that low volume, I would just host it myself.
I swear 90% of the hate for serverless purely stems from irritation at the name.
I love serverless for everything but APIs. But 90% of my hate for serverless is with APIs and the cold starts.
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 )
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.
Why spend $5 when you could spend $1? I've got a site running without using servers and it basically costs the R53 hosted zone cost as it's very low traffic. No servers to configure, no residential connection to potentially fall over, high durability. Why wouldn't I use it?
>Or you can just run from a residential connection for effectively free if your service is _that_ small.
Been there, done that. Buy a raspberry pi, install raspbian, install nginx, node, whatever the stack is gonna be, configure port forwarding on a router, spend hours to days getting it working. Have tons of downtime--oops you don't have a static ip, oops your sd card got corrupted, hey lets update this to the latest version oh no everything is broken...and on and on and on.
Or, figure out how to use S3 buckets and lambda functions once, and from then on watch everything just work and cost virtually nothing. For small (I'm the only user) types of projects, I'll stick to serverless for now on, so I can be a programmer and not a sysadmin.
> Or you can just run from a residential connection for effectively free if your service is _that_ small.
Not gonna be possible soon, now that ISPs are starting to hand out private IPs to customers. That's going to keep happening until the world moves to IPv6.
Or you can just run from a residential connection for effectively free if your service is _that_ small.
This is very true. I’m an AWS true believer and I use most of the most popular features all of the time for work but for a low volume side project, I would host it on my own computer. I have 900Mbps upload bandwidth. If I were going to use AWS, I would use a cheap LoghtSail instance.
GAE was very much the first serverless platform. Cost is very low - most people would make savings most months, but you can set up billing alerts to help you go higher.
Also original GAE was hampered by having a product owner that didn't care about it (at the time I was working on the largest GAE app inside Google). We (as internal customers) ending up writing chunks of the AE SDK to be able to have our apps run reliably.
I don't think the 'cold-start' issue should be taken lightly. Yes, some services won't care at all, and you can mitigate it as you say by choosing a particular backend. Yet it is still a big concern for Java for example when you can not use graalvm 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.
So performance any different except for it’s a huge difference depending on the language, whether it is in VPC forcing the need to create ENIs, etc.
I’m a multi certified AWS true believer and I love lambda for everything else besides APIs, but let’s not ignore the large performance penalty of cold starts and lack of connection pooling.
You really don’t save money over just using a bunch of micro instances behind a Load Balancer and autoscaling. Elastic Beanstalk makes managing it dead simple.
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/ , which can do 100% serverless websites in two easy steps: 1) type in markdown or clojurescript, 2) click save.
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.
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.
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.
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.
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.
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.
IMHO serverless is amazing if you clearly understand the bottlenecks and still see real benefits from it. Otherwise, you may exchange one problem for another (probably even worse).
I've had a great time learning AWS Serverless. I run a financial data website where much of the data is "pre-computed" overnight and stored in a special hierarchy on S3. All other computations are pushed off to client-side JavaScript.
S3-> CloudFront CDN with Amazon API Gateway normalizing access to various endpoints (Lambda, DynamoDB). This is a great way to go and scales beautifully.
This is interesting to me because my company is right in the middle of the serverless movement. I know and work with over a dozen large companies that have moved their fairly standard micoservice-oriented architecture over to 100% serverless. Lots of people in the ops world still think this is some kind of marketing nonsense or black magic though.
Long story short, when engineering teams move to serverless, they get huge scalability benefits and essentially "squashing their stack" making team engineering velocity way faster than when they were using EC2/Kubernetes/VMs.
Imagine 10 years ago, being a LAMP stack developer. One day, you find a hosting platform lat allows you to be a much more fast/effective LAMP developer while only needing to work with M+P. This is the core benefit of serverless.
Yes, there are servers under the hood somewhere at an AWS datacenter. Yes, infrastructure still gets patched, updated, etc. Serverless is all about letting engineering team focus on building the application and making the infrastructure "not my problem".
IMO Google Cloud correctly describes its serverless platform as a place to host little one-off utilities in your infrastructure that don’t need to consume resources all the time. (Employee onboarding, deployment plumbing, etc). Not as an appropriate way to build your entire product.
If you’re using it that way, it’s really no different from Elastic Beanstalk / Heroku / ye olde shared PHP hosting. Which is fine, but not some kind of revolution. Just the pendulum swinging back.
88 comments
[ 4.1 ms ] story [ 151 ms ] threadThat's more irony than I can handle this early.
(and I say this as someone that runs a web app built on the Serverless platform that I'm quite happy with - I just think it's a dumb name)
Just speculating, but my guess is the bandwidth demand exhausted the available capacity and author wasn't willing to pay for more.
It's quite easy and common to wreck a database when you have it hooked up to serverless infrastructure. Depending on the DB, there can be a significant amount of overhead for each client connection. Postgres is particularly bad at this, since it spawns an entire process for each client that connects. This is why connection pooling is so important for applications.
Serverless is a different beast tho; every function is isolated, so having a client pool is much harder/impossible. If you get a flood of traffic, and your function interacts with a DB, you suddenly have a ton of non-multiplexed client connections, which is all it takes to bring many databases to their knees.
If this is a serverless website, I can't wait for the author's next article, describing this issue and how they addressed it. If it's not serverless... add a client pool.
Kind of defeats the point though :/
It relies on AWS using the same container/JVM for your invocations though which isn't guaranteed depending on what your load is.
It solves this exact problem and enables pooling (disclosure: I worked on related infrastructure)
"https://sinxloud.com/wp-admin/admin-ajax.php"
PHP running Wordpress. Sorry guys, it's not serverless.
DynamoDB is a much better solution for serverless since it just uses a REST interface.
I’m a big fan of lambda but not for user facing API end points. It works well for eventually consistent event processing.
Setting up a Load Balancer and an Autoscaling group is not rocket science. Neither is automated patch management.
If you want to do anything with user facing APIs, suck it up and spend $10 a month for two or three micro Linux instances set up in an autoscaling group behind a load balancer.
Elastic Beanstalk makes it dead simple.
neat :)
https://www.npmjs.com/package/serverless-offline
I have no idea if this exists for other languages but its what lets me develop and test my functions locally before deploying them to stage/live.
Edit: they have some good examples - https://github.com/serverless/examples/tree/master/aws-node-...
pretty sure similar tools exist for some of the other supported languages.
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.
That could mean ANYTHING, and result in ANYTHING, but ... it's usually what it means.
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.
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.
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.
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.
If you are spending that much time managing infrastructure on AWS, you’re doing it wrong. ElasticBeanstalk makes it dead simple.
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.
And you can do the same with AWS and a bunch of micro instances. But if it’s that low volume, I would just host it myself.
I swear 90% of the hate for serverless purely stems from irritation at the name.
I love serverless for everything but APIs. But 90% of my hate for serverless is with APIs and the cold starts.
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.
Different use cases warrant different solutions.
Been there, done that. Buy a raspberry pi, install raspbian, install nginx, node, whatever the stack is gonna be, configure port forwarding on a router, spend hours to days getting it working. Have tons of downtime--oops you don't have a static ip, oops your sd card got corrupted, hey lets update this to the latest version oh no everything is broken...and on and on and on.
Or, figure out how to use S3 buckets and lambda functions once, and from then on watch everything just work and cost virtually nothing. For small (I'm the only user) types of projects, I'll stick to serverless for now on, so I can be a programmer and not a sysadmin.
Not gonna be possible soon, now that ISPs are starting to hand out private IPs to customers. That's going to keep happening until the world moves to IPv6.
This is very true. I’m an AWS true believer and I use most of the most popular features all of the time for work but for a low volume side project, I would host it on my own computer. I have 900Mbps upload bandwidth. If I were going to use AWS, I would use a cheap LoghtSail instance.
Back then developers were dismayed about the unpredictable cost of App Engine. The same problem remains today with Lambda and others.
Is it just a solution whose time has come now, ten years later? Or is there something else to Lambda that I’m missing?
Also original GAE was hampered by having a product owner that didn't care about it (at the time I was working on the largest GAE app inside Google). We (as internal customers) ending up writing chunks of the AE SDK to be able to have our apps run reliably.
So performance any different except for it’s a huge difference depending on the language, whether it is in VPC forcing the need to create ENIs, etc.
I’m a multi certified AWS true believer and I love lambda for everything else besides APIs, but let’s not ignore the large performance penalty of cold starts and lack of connection pooling.
You really don’t save money over just using a bunch of micro instances behind a Load Balancer and autoscaling. Elastic Beanstalk makes managing it dead simple.
Unfortunately, the technology isn't there yet and serverless is actually more complex than traditional managing servers.
I co-made http://www.hyperfiddle.net/ , which can do 100% serverless websites in two easy steps: 1) type in markdown or clojurescript, 2) click save.
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.
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.
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.
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.
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.
Step 2: Get a database server that works...
Step 3: Congratulations: You've just served yourself!
S3-> CloudFront CDN with Amazon API Gateway normalizing access to various endpoints (Lambda, DynamoDB). This is a great way to go and scales beautifully.
Long story short, when engineering teams move to serverless, they get huge scalability benefits and essentially "squashing their stack" making team engineering velocity way faster than when they were using EC2/Kubernetes/VMs.
Imagine 10 years ago, being a LAMP stack developer. One day, you find a hosting platform lat allows you to be a much more fast/effective LAMP developer while only needing to work with M+P. This is the core benefit of serverless.
Yes, there are servers under the hood somewhere at an AWS datacenter. Yes, infrastructure still gets patched, updated, etc. Serverless is all about letting engineering team focus on building the application and making the infrastructure "not my problem".
If you’re using it that way, it’s really no different from Elastic Beanstalk / Heroku / ye olde shared PHP hosting. Which is fine, but not some kind of revolution. Just the pendulum swinging back.