William Jimenez May 11, 2017
One of the more novel concepts in systems design lately has been the notion of serverless architectures. It is no doubt a bit of hyperbole as there are certainly servers involved, but it does mean we get to think about servers differently.
The potential upside of serverless
Imagine a simple web based application that handles requests from HTTP clients. Instead of having some number of program runtimes waiting for a request to arrive, then invoking a function to handle them, what if we could start the runtime on-demand for each function as a needed and throw it away afterwards? We wouldn’t need to worry about the number of servers running that can accept connections, or deal with complex configuration management systems to build new instances of your application when you scale. Additionally, we’d reduce the chances of common issues with state management such as memory leaks, segmentation faults, etc.
Perhaps most importantly, this on-demand approach to function calls would allow us to scale every function to match the number of requests and process them in parallel. Every “customer” would get a dedicated process to handle their request, and the number of processes would only be limited by the compute capacity at your disposal. When coupled with a large cloud provider whose available, on-demand compute sufficiently exceeds your usage, serverless has the potential to remove a lot of the complexity around scaling your application.