The latest buzz in cloud computing is Serverless Computing. All public cloud vendors have raced away announcing their Serverless Computing solutions, with Amazon Web Services announcing the Serverless Computing product, AWS Lambda, a couple of years back. Things have not been the same since with Serverless Computing being touted as a preferred architectural model for multiple use cases.
For those of you who have been invested in public Cloud Computing, you are aware of two popular models i.e. Platform As a Service (PaaS) and Infrastructure As a Service (IaaS). The SaaS model is not relevant to this discussion at this point because it is a service that we use and is often not about development to the end user.
When the PaaS model came out, it was felt that this was ideal since it let the developers focus on the application, while the task of running and managing the infrastructure was left to the PaaS provider. Google App Engine was first off the blocks and since then there have been multiple providers like Azure, Heroku, Cloud Foundry and more. As developers got access to newer languages, programming stacks and frameworks, the PaaS model could not keep updated with all the runtimes and many developers were constrained by the lock-in and restrictive programming model that made it difficult to migrate your apps to their programming model. Developers wanted more flexibility.
The gradual movement from PaaS to IaaS started happening where you had to take control of your compute, storage and network but in return you got a lot of flexibility. While managing an IaaS setup can quickly get complex, more organizations felt that this was the way to go in the cloud. But often for some architectures, it ends up becoming an overkill from a management perspective when all you have to do is execute a well encapsulated functionality that needs to be invoked based on some trigger.
Enter the function as a compute unit and which is the core of the Serverless computing model. In this model, you encapsulate your code functionality into functions and then orchestrate their execution via triggers like HTTP invocation, publishing of an event to a message queue, adding/updation of a cloud storage entity and more. The IaaS vendor behind the scene takes care of executing your functions in a stateless manner by provisioning resources and billing you typically by the number of invocations and execution time.
All public cloud vendors have now set their goals on this frontier and as always, Amazon Web Services was first off the blocks with AWS Lambda. Google followed suite with Google Cloud functions and recently at the Build Conference, Microsoft joined the bandwagon via its Azure Functions.
Interesting applications have already been built via AWS Lambda by companies and we should see more models migrating to this architecture. Internet of Things (IoT) applications, media file processing in an asynchronous fashion, processing events and sending alerts are some of the ideal use cases for Lambda Architecture.
While it is still early days yet, the movement to Serverless computing has begun and it would pay to see if you could visualize your applications as a set of discrete functions that could be connected to achieve the larger functionality. There are concerns about this model too. The concerns raise from developers comparing this to a vendor lock-in as PaaS was along with difficulties in effectively monitoring your functions and their executions.