API-Based Web Service as Serverless Function
Serverless architecture is a method of decoupling server maintenance, scalability, and availability from the development process.
Join the DZone community and get the full member experience.
Join For FreeWhat is serverless architecture and how does it affect the development process and help to unlock several benefits for an enterprise? Simply put, serverless architecture is a method of decoupling server maintenance, scalability, and availability from the development process. It is one of the best ways to build and run applications and services without having to manage their underlying infrastructure. It is also a powerful way to reduce toil and deliver engineering excellence.
Serverless architecture can be implemented in two ways: 1.) Serverless functions and 2.) Serverless databases.
This article focuses on the serverless function, which is nothing more than a logical entity running only in the cloud infrastructure that is focused on business logic. There are various providers available in the industry that offer serverless functions. To name a few, AWS Lambda and Fargate, Microsoft Azure Functions, and Google Cloud Functions.
A few ideal use cases for serverless functions could be (but are not limited to):
- Task invocation based on specific triggers (e.g. — Triggering alert functions based on usage threshold).
- Building scalable RESTful APIs by leveraging Amazon API G/W.
- Back-end application tasks (e.g. - Invoking back-end functions in parallel to other front-end applications).
- Applications or processes that can be invoked on demand to perform behind-the-scenes work.
Though there are various ways to host an API-based application in the cloud platform, the level of infrastructure abstraction varies depending on the cloud technology. As mentioned earlier, the goal is to unlock better performance and significantly reduce the infrastructure cost. AWS Lambda and Fargate are two major compute-based serverless services offered by Amazon.
The level of infrastructure abstraction is significant enough for the Lambda function to completely decouple the server maintenance, scalability, and availability aspects from the development process. Developers are then required to focus only on the business logic of the application, leaving the rest of the underlying infrastructure details to the cloud service providers.
Based on the above analysis, one of the best use cases for the serverless architecture is the handling of notifications from the Network. The asynchronous notifications coming from the network shall trigger the Lambda function through the exposed APIs.
Moving toward the serverless architecture will enable one-click code deployment, decrease infrastructure costs, automate scaling, improve the performance of the application, and eliminate the underlying server maintenance.
A serverless Lambda function can be invoked by various choices of execution. In case of migrating an existing application to a serverless function from On-prem or other cloud platforms when the API is already hosted in APIGEE, a simple integration between APIGEE gateway to Lambda function is sufficient to successfully migrate to a serverless system without impacting API clients.
The life cycle of a Serverless Function (Lambda) typically involves several key stages, such as creation, invocation, execution, monitoring, completion, scaling, and retention. Understanding the concept of warm-start and cold-start in the serverless function will help fine-tune the serverless function configuration and attain better performance.
The implementation of a Serverless Function for an appropriate use case shall benefit an enterprise with significant infrastructure cost savings. Unlike non-serverless cloud platform types where cloud providers charge based on the size and the number of instances, charges for the Serverless Lambda function are on a per-invocation basis, which saves cost on unused servers and virtual machines.
Published at DZone with permission of Madhan Muralimanohar. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments