Serverless computing allows organizations to architect and deploy cloud applications on a more granular level....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Compared to a traditional application, built with monolithic code, a serverless application breaks down a workload into discrete functions that only run when called or triggered by a certain event.
Despite its name, serverless computing does not eliminate the use of servers completely. Instead, it only employs a server when a function loads and runs. This minimizes resource use and can potentially save money in the public cloud.
Major public cloud providers now offer some form of serverless computing, such as Amazon Web Services (AWS) Lambda, Microsoft Azure Functions and Google Cloud functions. Let's take a closer look at serverless computing and how to get the most from this emerging technology.
What skills do developers and admins need to use serverless computing?
Serverless computing represents a radically different way to architect and manage applications, so both developers and cloud administrators should make adjustments to make the most of this technology.
The major change developers face is the structure of a serverless application. Traditional, monolithic applications often rely on routines that exchange data through variables. The shift to microservices advanced this idea and broke software into functional components that scale independently and employ APIs to exchange data. Serverless computing takes this to the extreme; it breaks software features into individual, discrete functions that organizations only spin up when needed. This means the core application can be considerably smaller, and use a smaller and less expensive cloud computing instance.
Serverless computing also impacts cloud administrators. For example, admins must oversee the availability and performance of dozens or more functions. This means, for each function, they need to monitor performance, troubleshoot, track the usage and cost and then aggregate those costs into the greater application cost. Admins can employ monitoring features from their public cloud provider, such as the Monitor tab from Azure Functions, to analyze and assess each function.
Administrators must also implement a mechanism to share ongoing management information with developers. This allows for continuous development of a serverless application to optimize performance and cost.
Which apps are best suited for serverless?
Serverless computing is best suited for small, stateless functions that have light resource needs, minimize dependencies and run without requiring extended time. The function should start, run and exit as quickly as possible. Tasks with more substantial resource or time requirements are better suited for more conventional VM or container deployment.
Functions typically have limits on resources, concurrency and deployment sizes, because cloud providers need to spin up instances quickly and provide the resources to load and execute a function's code. AWS Lambda, for example, currently imposes 512 MB of temporary disk capacity, 1,024 file descriptors, 1,024 combined total processes or threads and a maximum execution duration of 300 seconds.
Can a serverless application help me save money in public cloud?
One advantage of serverless computing is cost savings -- depending on an application's design -- compared to on-demand VM instances in the public cloud. The amount of savings depends on the nature of each application, how much of it is architected and deployed as a series of event-driven functions, and how frequently users call those functions. If much of the application remains idle until events occur, an organization incurs fewer costs.
Still, there is no guarantee that a business will realize any savings compared to on-demand VM instances in the public cloud. Except any applicable free tier, every function call costs money. The cost of a function-based application is roughly the sum of costs for each function. The cost for each function is basically the number of calls multiplied by the cost per call.
However, suppose the serverless application is composed of 50 or 100 different functions and it services an enterprise mobile user base that numbers into the tens or even hundreds of thousands. This can add up to an astonishing number of function calls over the course of a public cloud billing cycle. Such an application might cost a business more than if it were designed with a more traditional architecture. Part of the problem is uncertainty; most developers just aren't sure how often functions may be called -- making cost analysis difficult.
To predict the cost of a serverless application, perform a careful assessment of function utilization and user base size. Consider how variations to the application design might impact those operating costs. It may be possible to lower costs if a developer changes the application's design to mitigate heavy use of some functions.
What are some other best practices?
The notion of serverless computing is compelling, but there are some important considerations that developers and administrators should evaluate carefully before adoption:
Performance: Consider the impact of function latency and performance. Since a function is loaded before every execution, there is small, but inevitable, latency to its response time. Latency may also vary with traffic demands. These factors can make functions less attractive for latency-sensitive applications.
Complexity: Functions can complicate application design, performance monitoring and troubleshooting; admins must monitor dozens or even hundreds of individual functions. Consider more granular management tools and policies than you may have today.
Fast, tight and stateless: The fast, ad hoc nature of functions suits stateless software design. Assign a state to the data rather than the function, if a state is handled or passed between functions. However, there are usually severe limitations on the size of messages passed between functions.
Plan to fail: Functions often depend on other functions, storage, back-end applications and network availability -- all of which can fail. Design functions to handle errors, complete unfinished tasks on a subsequent run and ensure functions are as bullet-proof as possible.
Portability: Functions are typically not portable between public cloud providers. AWS Lambda functions won't work in Azure or Google and vice versa. This could create vendor lock-in and complicate multicloud initiatives.
Step away from traditional server management
Build a cost optimization plan for cloud
See what providers have to offer for serverless computing