Serverless computing -- also known as function as a service -- continues to grow in popularity. But, as is the case with many emerging technologies, it also presents a learning curve. For developers, one of the biggest challenges is how to best create a function.
Google Cloud Functions is a FaaS offering that enables developers to write powerful serverless functions -- in either Node.js or Python -- that reduce infrastructure costs and provide new functionality with minimal overhead.
But it isn't easy to make a smooth transition into FaaS development. Here are a few tips that address some of the early challenges developers might encounter when they build their first Google Cloud Function.
Direct vs. event-driven invocation
A developer first needs to decide which type of Google Cloud Function to invoke: an HTTP function or a background function. The execution of each is ultimately the same; however, they are triggered differently. While the right decision ultimately depends on an organization's own goals and needs, a general rule of thumb is that HTTP functions are more versatile but lack the elegance and event-driven Google Cloud Platform integration that background functions have.
An HTTP function is a type of Google Cloud Function that is invoked via a typical HTTP request. With support for HTTP request payloads and method types, invoking an HTTP function is as simple as making a basic web request. One of its primary advantages is that it is, for the most part, on-demand, which enables immediate execution.
While traditional FaaS platforms are generally shown as on-demand HTTP functions, background functions are invoked "in the background" in response to an event. For example, certain events can execute a function, such as a user login to a Firebase application or a new file upload to Google Cloud Storage. Currently, the available event providers that can invoke a background function are Google Cloud Storage, Google Cloud Pub/Sub and Firebase.
One function, one action
Unlike a typical application, the more a function does, the less useful it can be. The command pattern in object-oriented programming encourages small, yet highly testable blocks of code, and developers should write a Google Cloud Function with that same pattern in mind. For every action an application needs, there should be a single, corresponding function to handle it.
For example, rather than have a single function create a user entry in a database, send an onboarding email and update a company's customer relationship management system, make these three distinct functions that are all called as needed. This enables a flexible and intuitive application back end, with minimal unintended side effects.
Focus on speed
The ultimate goal is to create highly focused cloud functions that also run fast. Google primarily bills for a function based on how long it runs, so the faster a function is, the more affordable it will be. When given the option, a function should prioritize speed over power. A powerful, yet long-running function can drain a budget quickly, while a handful of less powerful, but speedy ones are more cost-effective.
Developers should consider everything, from language choice to clever implementations, to shave off as many extra milliseconds as possible. While these optimizations will be specific to each individual function, it is generally a good practice to limit long-running tasks, like recursion, and prioritize efficiency over readability where reasonable.