Awfully Thorough Guide to Choosing the Best Serverless Solution, Part 1.3: Google Functions & IBM Cloud Functions

Ilya Kritsmer
Jul 28 · 8 min read

In previous blog post we’ve examined AWS Lambda and Azure Functions. In this final FaaS series blog post we’ll thoroughly review Google Cloud Functions and IBM Cloud Functions and will summarize the whole FaaS series.

Previous Post in a FaaS Series

Google Cloud Functions

Google quietly launched its own Functions beta version in September 2016, and, as with the rest of its cloud businesses remains in shadows of AWS Lambda and Azure Functions.

Google Functions went out of beta and became generally available just last year, in July 2018. In April 2019, Google announced Google Run, a hybrid solution that mixes up the serverless paradigm and containers and “lets developers run stateless HTTP-driven containers on a fully managed serverless execution environment.” Since Google Run is too fresh and not yet widely adopted, not to mention it’s not pure FaaS, we’ll examine it in a future post that compares “not-so-serverless” solutions.

As you can see, the function creation form combines elements that are typically kept separate in Azure and AWS. A newly-created function is publicly accessible by default, and on the Advanced tab there are more parameters to set, like number of mx function instances. There is an option to upload code as either a local .ZIP file or a .ZIP from CloudStorage and also from as a source from the CloudSource repository, an option is unique to Google. An inline source editor is also accessible. The offering is fully integrated with Google’s own CloudBuild CI/CD infrastructure and also with some other popular solutions like Gitlab.

Event Triggers

Event triggers are fairly limited and include the default HTTP, CloudStorage, Pub/Sub, FireStore, FireBase and StackDriver Logging. Google distinguishes between functions that can be invoked via HTTP request with the appropriate trigger and so called “background functions” are triggered in response to an event. Official documentation about events and triggers states it is possible to bind triggers to a function both with CLI Gloud tool and GUI, but the GUI option seems to be missing as of July 2019.

Supported Languages

Google Functions supports Node.js, Python and Go (announced in January 2019, but still in beta).

Tooling and Debugging

Google has developed what it calls a Functions Framework, which “lets you write lightweight functions that run in many different environments, including your local development machine.” Unfortunately, it currently only supports Node.js 10 which prevents it from being seen as a mature tool. In any event, here is its official Github page.

Monitoring and Logging

There is an easily accessible Logging Dashboard for Google Functions, as well as some basic monitoring parameters, like number of invocations. Each looks like a Kibana dashboard with cosmetic changes.

Performance and Scaling

Google says its scaling feature is still in a pre-release state (event though the GA was announced a year ago) and “might change or have limited support.” Company documentation does not unveil much, but refers to function idle states to minimize cold starts and a “max instances limit” which isn’t guaranteed. More details are available here.


Security is another feature in pre-release state. In general, the Google Functions security model leverages access control IAM model. More on that here.


As official documentation states, Google Cloud Functions are priced according to how long your function runs, how many times it’s invoked and how many resources you provision for the function. In addition to the number of requests and GB-SECONDS it also defines GZH-SECONDS, which relate to CPU time consumed by the function invocation as well as inbound and outbound traffic. A Free Tier allows 2M requests, 400,000 GB-seconds, 200,000 GHz-seconds of compute time and 5GB of Internet outbound traffic per month, while inbound traffic is free.

Wrap Up and Further Reading

With many must-have features still in a pre-release state, very limited language support and a poor tooling capability, Google Functions is the step child in the Google family. We’ll see if the recently announced Cloud Run will have a better fate.

Google Cloud Functions Tips and Tricks and official documentation are recommended for further reading.

IBM Cloud Functions

IBM jumped into the emerging paradigm of serverless computing in February 2016 with an event-driven programming service called Bluemix OpenWhisk based on the open source Apache OpenWhisk.

Unlike other vendors, IBM thought about serverless applications rather than standalone stateless functions, which may be why the company always talks about its FaaS, called IBM Cloud Functions, in the broader context of OpenWhisk. Since we are concentrating on reviewing standalone functions solutions, we’ll only examine IBM Cloud Functions and wait to review OpenWhisk in future posts that deal with serverless applications.

The function creation form has the most minimalistic design of all offerings: neither memory to allocation, ACL or URL endpoint are presented. Instead, an “Enclosing Package” is available is related to the OpenWhisk platform. Very Spartanic of you, IBM.

Event Triggers

Unlike any other platform, IBM does not see HTTP request as a triggering event, but rather defines it as a separate category called “Endpoints.” The number of available out-of-the-box triggers are limited to Kafka streams, IBM’s own Cloudant DB and others, but again, more are available through OpenWhisk.

To expose your function to the word, you need to add and configure an endpoint

It looks like IBM tried to add a functionality of the API Gateway without calling it API Gateway, but hey, an API key is created by default, so no complaints here.

Supported Languages

IBM Cloud Functions support Node.js, Python, PHP, Swift, Ruby, and Go, Java and .Net.Core via Docker. To see the full list of supported runtimes, read this official IBM documentation.

There is no option to upload a .ZIP file in the GUI. It is possible to deploy a code via Bluemix Devops, as this post explains. There is also a so-called Whisk Deploy technology, but it sticks to IBM Cloud platform which suggests an obvious vendor lock-in that does not help to a widen adoption of IBM Cloud Functions.

Tooling and Debugging

Developer Tools for OpenWhisk uses an open source framework to develop and test OpenWhisk actions (which IBM Cloud Functions actually are). There is also the official GitHub repository. Eclipse IDE is the recommended option to use when working with Apache OpenWhisk, but any IDE will suffice[IK1] [AE2] . IBM does not invest any effort in this direction, as everything is done by the Apache community and the enthusiasts.

Monitoring and Logging

IBM Cloud Functions logs are shown in the dedicated full-blown Kibana dashboard, which is opened in a new window when the “Logs” button is pressed. It’s very impressive, but a shame it stops being a free service very soon. The service is also integrated with a relatively new IBM Monitoring Service, as this blog post explains. Great job, IBM — the best among all the vendors!

Performance and Scaling

Official IBM documentation is somewhat lacking and does not provide too many details about scaling behavior. The FAQ section specifies maximum function runtime as 10 minutes, without specifying maximum concurrent invocations. No blog posts examining scaling behavior are out there, so it is kind of a mystery.


API keys for IBM Cloud Functions endpoints and OAuth user authentication for Facebook, Google and Github accounts — that’s all, folks! There is also a highlighted call to use IAM access control, but the link leads to the account home page and a search for “IAM” in the dashboard gives literally nothing. Far away from the industry highest standards, to say the least.


The pricing model for IBM Cloud Function leverages the same GB_SECONDS units and charges $0.000017 per GB_SECONDS. The Official pricing calculator shows that 5M executions of 500 ms each with 128 MB memory consumption per invocation will cost you nothing, which is pretty neat and much better than any other offer from the other big four vendors.

Wrap Up and Further Reading

While the language support and logging and monitoring infrastructure are among the best in the industry, IBM Cloud Functions falls short in all the other categories. It looks like IBM feels comfortable in its own closed ecosystem and is not interested in investing too much to make itself accessible to a wider developer audience.

You might want to take a look on official FAQ section for further reading.

The Summary and What’s Next?

If you’re still not convinced which FaaS best fits your needs best, check out the Serverless Cost Calculator to compare FaaS prices in an approachable way and this academic whitepaper that explores the performance characteristics of leading offerings.

You can also open a free account for any of the big four vendors to play with their FaaS services.

So, what’s next? Obviously not all serverless applications are just event triggers, there are plenty of more sophisticated scenarios where serverless computing might be useful. In the next blog post we’ll review serverless applications, or workflows, a higher level of abstraction for serverless computing that allow you to leverage FaaS for much more interesting use cases.

Stay tuned!

Ilya Kritsmer

Written by

Seasoned CTO, owner of a consulting company, mentor. Acid jazz,single malt whisky and cats lover.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade