Focus on what you care about with Serverless Computing – the application and nothing else!
This for me feels like next-gen cloud computing. Think, greater agility, dynamic resource allocation and best of all, abstraction away from underlying infrastructure! With serverless computing, developers can focus on exactly what matters most to them, the application code.
When traditionally building applications, developers needed to consider the servers that were going to host the app. How will it be provisioned? How will the OS be maintained? What about the security of it all? Using serverless computing shifts over this responsibility of the physical infrastructure to the cloud-provider. Of course, the application code is still running on a physical server somewhere, but it is no longer the concern of the developer to locate, provision or maintain it. Instead, a third-party cloud provider such as Amazon Web Services or Google Cloud handles it for you.
Well, why not use Containers? Surely that provides you with the same shift of responsibilities. To some extent, yes, containers allow you to package and deploy regardless of the server that it sits on. But there’s far more to serverless than just abstraction of infrastructure. This is where it gets more exciting!
When using containers, scaling responsibilities also lie with the application owner. It is their choice to deploy X number of containers in order to handle demand. Whilst this is a practical approach, it would be far more efficient to have the scale adjust automatically based on user demand. Containers are very much like physical shipping containers when it comes to scale. If you know demand for your product is expected to rise in the near future, you can send more shipping containers to the stores beforehand in order to prepare. Serverless, however, is far more dynamic. A great analogy I’ve seen is that is serverless scales the same way tap water in the UK does. Need more water today? Not a problem, keep the tap running for as long as you need. It’s always available since it scales dynamically.
Just like tap water, you pay for what you use when it comes to serverless. It’s not about the number of servers or a pre-decided amount of bandwidth that determines how much you pay. It simply comes down to how much your code is being used. This could be time-based (how much time it takes for your code to be fully executed) or request-based (how many times your code is triggered).
In addition, serverless lends itself well to applications that rely on event-based triggers. An example of this is a bot that performs some specific action on behalf of a user.
Take a look at the architecture of this example, which leverages AWS Lambda as the serverless compute platform. A user would interact with the bot through Webex Teams. Using a webhook, we can create a reaction to this. The webhook will send a POST request to an API created on AWS API Gateway. This API has the sole responsibility of triggering our bot code to execute. The code itself is a python script hosted on AWS Lambda. In this simple example, it retrieves a joke and posts it back to the user that initiated this chain of events. Of course, you could create code that performs any action more relevant to your application/task.
To see a full walk-through of how you would implement the example above using AWS, take a look at this lab guide.
All in all, serverless computing can enable developers to be far more agile, to dedicate more time to the application code itself and to therefore deliver more innovative, stable solutions quicker.Tags: