Understanding the benefits of serverless functions

Enter the REST API

Serverless applications create a service-centric architecture out of the box, which means that the individual features of an application are both incredibly lightweight and highly targeted. While this mindset lends itself well to dealing with business logic, it is also incredibly powerful for integrating with external APIs.

Let's say, for example, you are building an application that needs to be able to charge users. However, your chosen API provider -- for example, Stripe -- offers much more functionality than you need. In keeping with your current serverless design, you decide to create a serverless function that does one thing and one thing only: charges a credit card using the Stripe API.

Rather than deal with the bloat of customers, subscriptions and invoices, the core application you create can request a single, targeted endpoint that tucks all those elements away for us. This effectively condenses third-party integrations into the functionality you need, rather than the functionality they offer.

While the above might seem like an over-abstraction, it demonstrates that third-party dependencies can be tucked into their own corners of an application, which allows developers to create serverless functions that solely provide the features you need.

That said, not every API requires abstraction. The flip side of the coin would be small, single-serve APIs that require the implementation of server-side technologies. While this usually isn't an issue with more monolithic applications, it can end up requiring more resources than leaner projects have available.

Take, for example, an application that requires a basic Slack integration. It may be the case that because of the way the application has been developed, creating a webhook for the Slack integration's "slash" command would mean spinning up a new server. Using a serverless architecture, developers can deploy ephemeral, dedicated serverless functions without adding any additional overhead to the core application.

Keeping it DRY

"Don't repeat yourself," or DRY, is a longheld mantra of the software development industry. While this is typically used to encourage developers to keep their code clean and maintainable, it applies to serverless application design as well. Let's take our two examples from above -- integrating with both the Stripe and Slack APIs -- and add a third API for good measure.

Assuming that our application relies heavily on these three APIs, there are three different ways that we need to build in order to maintain authentication and communication among each of them. While most APIs provide clean SDKs, that doesn't do much to ease the pain of working with more than one at a time. This creates complexities that can be difficult to manage within a codebase.

If each of those API integrations were abstracted out into serverless functions, then not only would the core codebase be easier to manage, but the way the codebase works with them would be cleaner as well. Rather than managing three separate methods of communication, we can reduce that down to just one function.

Beware of the caveats

It is important to note that the above scenarios focus on a very specific type of serverless infrastructure, called function as a service. This is the infrastructure made popular by Amazon Lambda. The other type of infrastructure is the one that completely removes all consideration of servers. These serverless platforms tend to offer highly vertical functionality, such as supporting only one language or only one type of application.

Additionally, sometimes a single function just isn't enough, and the metadata of the request is just as important as the request itself. This can lead to the creation of custom workarounds to keep things consistent. These workarounds often lend themselves to provider lock-in, which can cause issues down the line when you outgrow your current infrastructure.