Build a 100% Serverless Website with AWS in 7 Easy Steps

(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)

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.

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.

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.

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.

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.