Disclaimer #1: this blog post was first published on my personal blog, follow me on Twitter to know when my new post go live!
Disclaimer #2: everything in this article is the result of working with Google's Serverless proposition, Google Cloud Functions. Findings of this article might not apply to other Serverless providers.
Yesterday, after it being in my to do list for way more than I would like to admit, I decided to actually try the new world of Serverless computing, building a simple product that would help me in my everyday life. The coverage of Serverless computing on the internet is overwhelmingly positive or, at least, that is what it seemed to me, so I went into this experiment with a positive mindset and expecting to be blown away.
Well, maybe I miss-interpreted the tweets and blog post I read, maybe I still don't really "get" Serverless computing, but I was not completely blown away as I expected. Don't get me wrong, the idea by itself is genius: the ability to attach functions to a HTTP end point and have them simply run every time a request is made to them, with only literally two choices of infrastructure to make (memory and location) would be the best proposition on the market. Unfortunately, I feel like the tooling is not yet mature enough for this kind of technology to become mainstream.
Serverless technology, let it be Google Cloud Functions, AWS Lambda functions or whatever other company's version we are talking about, might not yet be ready for enterprise production deployments, but you know what it is great for? Personal projects!
That was the proposition that mostly interested me about this stack, so I decided to build a small personal project using Google Cloud functions. After one afternoon of tinkering around, let me go through what I discovered.
A big disclaimer that needs to be made is that I am by no means a Node JS developer: I know some Javascript syntax, I can mostly understand what a snippet of Javascript code does but there are some moments in which I am hopelessly looking at a series of parentheses and equal signs without being able to make much sense of them. That said, I still developed my first Cloud Function using a Node JS environment because that was the stable one and it looks like everyone at one point in their life will have to learn some Javascript so I might as well take advantage of the situation. All this to say that maybe some of the problems I encountered during my testing were due to my lack of knowledge of the language itself. I guess you will have to let me know if that's the case!
Let us talk Cloud Functions then. The first interaction you are going to have with cloud functions will be amazing: just a couple of clicks and you will get your HTTP end point which you can cURL and it will return "Hello World!". The premises are simply amazing. You also get a small editor in Google Cloud's online console which allows you to perform changes and test them straight away, it even resolves your package.json
,downloading and importing any dependency you might require for your function to run. Everything looks great.
Everything becomes a little less great when you want to move the development to your local machine. After all it's just one Javascript function, I thought, how hard will it be to build a mock server to try it out. Well it turns out to be very hard, at least it was that way for me and my limited knowledge of the Javascript environment.
After wasting some time trying out different possible solution and Googling around, the first interesting resource I found was from Serverless Inc. who realised a very interesting looking quick start project. Very excited by this I downloaded the CLI interface and created a project using their template. This "template" project, however, contained the same index.js
that returned "Hello World!" as from the Google Cloud Console, and one extra file, called serverless.yaml
which contained the "recipe" to deploy to GCP by simply running serverless deploy
in the command line. So in the end I was still without a way to run my functions locally for development, but I was given a one line deployer which, unfortunately, did not allow me to choose the deployment region of my functions, which ended up always being in us-central1
, which is not ideal if you live in Europe. Maybe I simply missed it in the documentation, but I do believe that if such important information is not easily found in your project's documentation (in the examples you give out for example), then the fault is not in the user's hands, bu tin the provider hands.
So I went back to googling, and I found out about Google's own Google Cloud Functions Emulator. This sparked enthusiasm in me: they make the platform, if they made and emulator for developing specifically for the platform it will work great! The fact that it was more or less hidden in the GCP documentation, however, made me a bit skeptic from the beginning about this particular piece software and I was, relatively, right.
Following the documentation of the Emulator for installing and starting it up was pretty much straight forward:
$ npm install -g @google-cloud/functions-emulator
$ functions start
And the software started without any problems.
Deploying a function from your project was also very easy and done with the syntax in the documentation:
$ functions deploy helloWorld --trigger-http
The problems, however, started rising with the rest of the commands listed in the README of the project. At the moment of testing it out (HEAD is ca9200bae8fa707e25cc025c998236de26f4fb89) the following commands do not work:
$ functions call helloWorld
$ functions logs read
$ functions --help
$ functions status
$ functions config set verbose true
$ functions restart
Well, you get the idea. The good thing about this was that I managed to get a localhost url to test out my functions. I did not get any logs or anything so I could not really do much debugging, but it was good enough to make it work out in the end.
I finally managed to work through all these difficulties and I managed to create a Cloud Function I am happy with and I can start using right away without having to think about much else. Also, I can take what I learned from today and apply it to more ideas I will come up with in the future, I actually feel like I became a proponer of the Serverless technology, even though there are still some problems that need to be solved before this can become a more widely used product.
What decides if a product for developers will survive in the infinitely evolving landscape of anything as a service is often its documentation: how hard is it to go from an idea to a deployable product? The idea behind Serveless is, basically, removing all the intermediary steps you have to go through to deploy your code, but it still is too much of an infant to achieve this feat. The documentation that can be found on the internet still feels incomplete and too young, it does not guide the user from the "Hello World!" to the deployable code through every step of the way, but rather it lets the user figure out most of what is happening.
What this gives us is a technology in its infancy, which is very rare to encounter nowadays, and given that many parts of this new technology are Open Source, this allows us developer to not only tell these big companies what we want from them, but it invites us to build the features we are interested in and implement them in the future.
From the GitHub page is clear that Google's Cloud Functions Emulator is in alpha development (pre-1.0.0, as they call it), but it is still on GitHub: one command does not work? If I feel like it I can dive through the source code and figure out why, and maybe help out Google fixing it, thus making the world a little bit better for the next developer that will come along this new journey.
All in all, I am very excited about this new computing category. I think it could help many people to become less reliant on some tech giants while becoming, at the same time, more dependant on FaaS vendors. Right now this market consists of Amazon, Microsoft, IBM, Google and Cloudflare, as well as a few smaller companies.
I will keep you updated with my Serverless world findings in the upcoming weeks, and we will see together whether this technology is here to disrupt everything we know about how we write software or not. Who can tell?
Top comments (0)