Serverless vs. containers: What's best for event-driven apps?

Why is event processing atypical?

Event processing is very different from typical transaction processing. An event is a signal that something is happening, and it often requires only a simple response rather than complex edits and updates. Transactions are also fairly predictable since they come from specific sources in modest numbers. Events, however, can originate anywhere, and frequency of events can range from nothing at all to tens of thousands per second. These important differences between transactions and events launched the serverless trend and also precipitated the strategy called functional programming.

Functional programming is pretty simple. A function -- or lambda, as it is often called -- is a software component that contains outputs based only on the input. If Y is a function of X, then Y varies only as X does. For practical reasons, functions don't store data that could change their outputs internally. Therefore, any copy of a function can process the same input and produce the same output. This facilitates highly resilient and scalable applications.

A function can run in a number of ways -- on bare metal, on a virtual machine (VM), in a container or with IaaS. However, event processing is usually distributed, which means function hosting on bare metal and VMs doesn't make sense since those approaches are confined to the data center. Additionally, VMs and IaaS both require the OS and middleware to be part of the machine image, which wastes a lot of resources in running a simple function. This leaves us with a choice between two remaining hosting options: serverless or containers.

Serverless vs. containers: Searching for an event processing verdict

Event processing via serverless hosting lets the number of function instances, or copies of a function, scale with the rate of event generation. A massive flood of events won't swamp a serverless system if it's set up properly. Because a function isn't tied to a specific cloud resource, serverless is also less likely to fail if some cloud resources are lost. Best of all, you don't have to buy specific cloud instances and pay for them while they sit idle waiting for an event to process.

The pay-per-use factor is the primary upside of serverless, but there are two notable downsides. The is that, if you run a lot of events, you pay a lot. Consequently, serverless becomes expensive when you underestimate the number of events. The second downside is that serverless can take more time to load and run a function, and this delay can accumulate to become a problem.

Event processing via container hosting can solve both problems. You can put a lot of event-handling functions in containers on a single host or VM. You can host containerized functions in your data center or in the cloud. Because the hosting is explicit, you know what your ceiling cost will be, and there's no delay in loading functions for use. There are also downsides to container event processing, though.

The biggest problem with container-based event processing is that resource elasticity and resiliency are limited by the commercial terms of the cloud VM or IaaS service being used. Unlike serverless hosting, which is almost infinitely elastic, you'll have to for capacity to determine the range of event volumes you will be handling, or else you risk higher costs or running out of resources. However, you should do this for serverless, too. By figuring out your app's event frequency, you can quickly determine whether serverless or container hosting would be more efficient. You'll also learn how much capacity you will need to accommodate varying event volumes.

Container-based event processing has the disadvantage of lacking a specific software framework that serverless cloud providers offer. You can write and run functional or lambda programs on containers, but instead of having a handy cloud toolkit, you'll have to pick your own middleware and design your own application. Several examples exist for authoring event-driven functional programs and running them on standard cloud services or even in the data center, and it's a good idea to review them.

Another point to consider in the serverless vs. containers event-processing debate is event correlation. AWS Step Functions can provide this sort of correlation through orchestration, but event correlation using serverless functions may require generating secondary events, which increase the cost of serverless hosting.

Another point to consider is that event-driven applications are historically based on specific event correlation tools, which are available in containers or even in cloud-based VMs. Complex event processing (CEP) software -- associated with stream analytics and predictive analytics -- is available in both open source and standard commercial forms. This software can receive events and analyze them on a timeline to find patterns and invoke processes. CEP tools, however, have specific features that may limit their value to certain kinds of events or missions, so you'll need to examine the tools to decide the best approach. If the fit is right, CEP software may tip the scales in favor of containers.

When it comes down to serverless vs. containers, the fact is that container event processing is often going to be cheaper to run than serverless. Yes, it may require some additional management of hosting resources in the cloud that serverless doesn't, but that work doesn't seem so bad once you consider the extra work that serverless would require for estimating event volumes to control costs. Serverless can be great, but it's not always the best approach. And you need to consider container event processing carefully.