The new “serverless” age is upon us!… Or so they keep telling us. Are you building out microservice architecture? Trying to shave off some money from your hosting bill? If so, Google Cloud Functions might intrigue you!
Two weeks prior, we rolled out support for AWS Lambda. In the same vein, we now offer Google Cloud Functions. If you read that release, this might be a bit repetitive. If this is new to you, we’ll start with a quick spoiler: there’s still servers.
Despite not being as airy and ephemeral as the name implies, Google Cloud Functions provide some real benefit to those building de-coupled applications. Nothing like a list:
Elastic, Autoscaling: As demand on your functions increases, resources will be allocated to match.
Event-Driven Architecture: This philosophy suggests binding functions to specific contexts. One function, one context; clean, purposefully built infrastructure.
Cost-Per-Use: In the past, spinning up a container meant that you would be charged each moment the container exists. With Google Cloud Functions, you’re only charged when the function is invoked. If you’ve built a feature that isn’t used (aww), you won’t be charged for it.
Cost-y Optimization: Cost-y isn’t a real word, but “serverless” functions reveal a real-neat angle for optimization. When you’re looking at your app as a set of disparate functions accumulating charges, you can follow the paper-trail to see which functions need optimizations. Speed them up, save money.
API Weaving: Using the APIs available to Google Compute, you can chain your Google Cloud Functions with other products for some magnificent computations. For example, integrating a Function that calls the Google Cloud Vision API, you can apply Optical Character Recognition on images that are uploaded to cloud storage, then save the text they contain to that same cloud storage instance.
Google Cloud Functions can be powerful. But, what’s not so good?
Before going any further let’s clearly explain what Google Cloud Functions are. They are stand-alone functions that exist as part of your infrastructure. Instead of building one monolithic entity where every function is baked into one block of code, GCFs allow you to prop up each function on its own. Do you have an intensive operation like upload, compression, or data interpretation? Create a function for that operation and invoke it only when needed.
Warmup: You save money when functions aren’t in use. This is because each time it’s needed, a container is spun up that your function lives in. When usage ends, the container goes away. There is a warmup time associated with function invocation.
Control–: It’s “serverless” because you don’t need to tend to the server. Someone else still does. Your function will also be in multi-tenant environments. Is it suboptimal? Does it need a restart? You’ll have to talk to support about that.
New-ness: It’s a new approach. There might be mysterious, hidden caveats. You’ll be in a new frontier. Thrilling, yes, but is it the right time for thrilling?
There’s a missing piece, too, and that’s how you’d deliver your application. That’s where Fly comes in.
There’s two main problem areas an Application Delivery Network can help with. The first is in delivering your application securely to a global user-base. The second is having a reliable load-balancer and functional API-gateway between your user-base and your application. If you’re running Fly, you can…
- Easily discover new functions.
- Intelligently load balance and direct incoming requests to various functions and backend-types.
- Inject Middleware into requests or responses: server-side analytics, Google Authentication, Render Speed Tracking; more coming.
- Deliver your applications from the edge on one hostname.
- Serve it all through fresh and secure Let’s Encrypt HTTPS.
When used in conjunction with Fly, Google Cloud Functions are a potent compliment to your applications. With “serverless applications” and delivery taken care of, we are one step closer to the dream of truly being able to focus on application code.
Fly started when we wondered “what would a programmable edge look like”? Developer workflows work great for infrastructure like CDNs and optimization services. You should really see for yourself, though.