Is this feasible? Would using something like AWS Lambda to accomplish this be the right choice?
Or is it more geared toward smaller high usage areas of a service?
What would be the ideal way to do this?
If these are some of the questions you've been thinking about lately, I have an answer for you. Yes, it is possible and yes people do it. It might not be a great fit for all the projects, but running a website is possibly one of the best examples of serverless for you to get started.
All of the serverless providers works fine and it mostly comes down to the ecosystem preference over functionality. My last post on How to Choose the Right Serverless Provider? can help you out. Also, if you're planning on running a FaaS infrastructure at a scale you won't likely be hard-coding your configurations, but instead using a framework like Serverless to handle deployments and composition for you.
Check out https://3factor.app for a common architectural pattern (hasura is optional). tl;dr - requests go through an API Gateway and link paths to individual functions. Depending on the API gateway, you can keep all request handling, load balancing, authentication, and logging at that level and all functions remain focused and isolated.
There's a number of patterns that come down to personal preference, but I'd suggest browsing Serverless blog's code patterns post for some ideas of how you would structure your serverless architecture.
It ends up being a good exercise in API design: how do you keep functions focused but reusable (if there's a tie, "focus" tends to get precedence in FaaS configs), what domain models and actions are needed, and who is my consumer.
Another suggestion I would have for how to structure your functions is by considering them composable units. If you need users in your comments function, then call out to your users' function with a future and pull in the necessary data.
Additionally, for security and reusability reasons it can be useful to separate "consumer endpoint functions" from "statement of record functions" (those that touch a datastore). That's a bit overkill for smaller apps but considered a good security practice as the app grows.
Want some examples?
At the recently held ServerlessConf, ‘A Cloud Guru’ gave a proof of serverless promise saying they were never required to change their architecture due to performance reasons. They are running 287 Lambda functions, 19 microservices with 3.68 TB of data at the mere cost of $580 per month. Read that again!
Bustle.com runs wholly on serverless. It manages 52 million monthly visitors powered by a serverless architecture built using 12 APIs. On any given day, they collect 100 million events that are all sent up to an API gateway endpoint. Those are processed by a Lambda function, cleaned into normalized events (for example, the server sets timestamps, user agent information, and adds device segmentation), and then written to a Kinesis stream. Then consumers of the Kinesis stream can see real-time raw counts and aggregates of content in Redis.
Sounds interesting enough? Yes! However, if you run a website with a huge amount of visitors, there is a little room for guesswork when implementing new initiatives. If running a website is something you're not sure about, here are some interesting examples of serverless.
If you're already working on any of these examples, let's discuss in the comment section.