Overcoming the Challenges and Costs of Serverless

Since its inception in the late 1990s, the cloud has always been about reducing undifferentiated heavy lifting in IT. Services like AWS EC2 manage server hardware and give users elastic scaling to match demand automatically. These systems allow for finer-grained planning by renting instances by the minute, but there’s still room for optimization.

Serverless technology realizes this potential with on-demand pricing and virtually infinite scalability. As a result, customers only write business logic for a function that uses queues, object storage and databases to handle their workloads. There’s no need to manage OS updates manually and the instance type selection is reduced to the question of how much memory my workload requires.

So, what exactly is serverless architecture? What are its limitations, and how can the benefits of serverless technology be enjoyed?

Comparing IaaS and FaaS

In recent years, cloud services have become increasingly sophisticated, increasingly moving from basic infrastructure-as-a-service (IaaS) to higher-level function-as-a-service (FaaS) solutions.

IaaS

IaaS is all about providing customers with basic infrastructure building blocks—servers, block storage, object storage and more. It also includes built-in automation tools to scale these resources automatically, along with managed services—or servers—that are pre-installed and configured with software like databases or search services.

FaaS

FaaS forms the core of serverless computing. It takes the IaaS approach a step further, letting customers pay per execution. This is key, as while servers can scale up and down on demand, sometimes a server runs but doesn’t actually handle any work.

What is Serverless Computing?

Serverless computing is cloud computing with managed services paid for based on granular work units that scale down to zero cost when not in use. This eliminates undifferentiated heavy lifting so companies can focus on business problems—instead of getting caught up in details like managing OS software or matching demand by themselves.

AWS Lambda is one example of serverless computing. As a managed FaaS product, Lambda is the function engine that handles critical tasks like updates and security fixes for the underlying operating system. Lambda runs on top of Firecracker, a micro VM and VM scheduler that runs short-lived VMs to host your function invocations; it also handles on-demand scaling of your functions to replace faulty VMs automatically.

And the cherry on top? You pay for each execution based on how many milliseconds it runs and how many resources it uses. So if there are zero executions, you don’t pay anything! And if your system receives a traffic spike, Lambda will scale automatically to accommodate it.

How Does It Work?

Serverless computing works by cutting down on VM requirements. A usual VM is a generic computer capable of handling almost any workload, given enough resources. But this flexibility comes at the cost of startup time: Booting a VM from scratch with an OS plus all the software it needs to do its job can take anywhere from several seconds to minutes.

Serverless computing uses restricted VMs, known as micro VMs, which take just a fraction of a second to boot up. AWS Lambda, for example, comes with a 15-minute runtime limit, allowing AWS to rotate the instances that run the VMs. This limit makes the end of a function invocation part of the application architecture, forcing developers to think in terms of time frames for smaller tasks.

Serverless Use Cases

While serverless practitioners may choose to use serverless computing for all their workloads, it’s especially suited to specific use cases like service integration.

For example, you’ll often have two incompatible services you need to integrate, possibly requiring an entire server running between them to handle their communication. One service saves several records as CSV files to S3, and the other requires each record as an HTTP request in JSON format. A serverless function executed by an S3 trigger can solve this integration with just a few lines of code.

Another good example is image or video processing. Resizing, converting, cropping or adding watermarks are usually clear-cut tasks perfectly suited for serverless computing. A few lines of code and a function endpoint are all you need to add these features to any application that can call an HTTP endpoint—without having to deploy a server.

Challenges of Serverless Computing

While serverless computing offers benefits over traditional cloud computing, it’s not always a walk in the park.

Architectural Constraints

As noted above, serverless computing works because it limits what a VM can do. While FaaS platforms are flexible regarding scaling and costs, they can have severe limits on execution time and computing resources.

Remember, AWS Lambda limits function executions to 15 minutes. If your functions are close to or even exceeding that limit, you should either drastically optimize your implementation or reconsider running your workload using FaaS.

The same is true for resource requirements. AWS Lambda, for example, has an upper limit of 10 GB of memory per invocation. Serverless best practices suggest you keep functions small and only have them service a single task so the resulting solution will fall within this limit. But not all workloads benefit from separation into multiple functions, and many become hard to maintain with all the inter-function communication going on.

Application Testing and Debugging Issues

Running a server on a local machine is pretty straightforward. The same applies if you’re just testing the function’s business logic. After all, it’s just a function, and if you designed it correctly, you can execute the code locally to check for correctness.

But replicating a serverless architecture for testing and debugging can become problematic because many FaaS products are closed-source. Tests and debug sessions usually have to be done on the cloud provider’s infrastructure, which incurs additional costs and requires an understanding of different tools and services.

Observability Limitations

Again, the most popular serverless computing platforms are closed-source, limiting visibility. While serverless providers offer monitoring services, they often come with only basic metrics and logging. This makes root cause analysis challenging and more expensive. Several third-party services are available to help with this, but they also cost money.

Then there’s the issue of additional complexity. Serverless architectures are event-based and consist of multiple services communicating with one another. Obtaining a consistent image of a request’s steps across a system requires distributed tracing. AWS and other companies provide distributed tracing for serverless infrastructure, but it’s yet another tool a developer has to understand to get the most out of their serverless architecture.

Security Concerns

Each serverless function is a separate endpoint that lends itself as an attack vector. Maintaining security in a system that consists of hundreds of functions spread across multiple VPCs and regions is a complex endeavor.

Function permissions must be locked down to only the services required to do their work. Even then, a function can be a liability if it’s not protected against event data injections. If a function doesn’t validate the content and size of a request, it can also become the target of a denial-of-service attack since it will stop execution after reaching its memory limit.

Latency Problems

While the micro VMs that power FaaS are highly optimized, they can still take a while to start up. Solutions like Lambda warmers or provisioned concurrency can help here, but it’s not just “deploy and enjoy.”

There was also an issue with functions that accessed VPCs, as they needed to initialize and attach network interfaces—a notoriously slow process. But in 2019, AWS refactored its networking scheme to handle multiple invocations faster, making ENIs much less of a problem.

Increased Costs

An execution on a FaaS platform costs around 45% more than on a traditional server. Serverless proponents say it’s cheaper than servers, so how can both statements be true?

If you have a workload that utilizes a server at nearly 100% capacity, depending on the type of instance you choose, you may pay 45% less per execution than if you would run it using FaaS. You know your workload exactly, and it’s constant over a specific period, so you can save money on execution costs.

If you have a workload that runs way under 100% capacity, meaning your server idles most of the time, it might be better to run the workload as a FaaS because then you don’t pay for idle time. Your costs per execution might be considerably higher than on a server, but since your execution rate is low, you might still save money.

Ultimately, the decision to go serverless (and whether or not the extra expense is worth it) boils down to your use case and workload type.

Get Serverless Advantages With the Full Power of Servers

By unburdening DevOps engineers from many operational tasks, serverless can be a good option for new projects. If things don’t work out, it won’t incur any costs; but if demand goes through the roof, it’ll scale with your users. FaaS is especially useful for replacing on-off proxies between integration boundaries.

While predictable, long-running workloads are well suited for servers, many short-running workloads with highly varying execution rates are better suited for serverless. Nonetheless, there are drawbacks—limited flexibility in architecture and implementation, harder testing, debugging and observability and surprisingly high costs when poorly managed. Many workloads lie between the above two extremes, and then there are the ever-changing requirements that can move a workload from one side of the spectrum to the other.

By leveraging the slew of automated tools the market offers, companies can greatly facilitate this process by drastically lowering idle time costs, making servers more useful for unpredictable workloads and boosting performance by increasing access to burst capacity.

Omer Hamerman

Omer Hamerman is a Principal DevOps Engineer at Zesty.co. After earning his BS in Computer Science from Ben Gurion University and a BSc in Industrial Engineering and Management from Shenkar College, Omer began his career in DevOps and never looked back. Omer loves learning about new technologies and better approaches to merging Dev and Ops. He currently lives in London with his wife and daughter and enjoys climbing, hiking, and other outdoor activities. In his spare time, he writes about his experiences with various technologies on Medium and https://omerxx.com/. Follow him at @0merxx to learn more.

Omer Hamerman has 2 posts and counting. See all posts by Omer Hamerman