Forem: Pietro Bongiovanni

Serverless, an introduction

Pietro Bongiovanni — Tue, 20 Nov 2018 16:04:09 +0000

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?

Liveness and Readiness Probes with Laravel

Pietro Bongiovanni — Sun, 08 Apr 2018 11:33:29 +0000

This post was first published on my blog, to see my posts when I first publish them, check it out!

Liveness and readiness probes are two of the strongest and most useful tools that the Kubernetes suite offers for orchestrating your containers. Kubernetes by itself is very good at rescheduling deployments, restarting pods and, in general, handling extreme situations.
What, with a default configuration, it is lacking is a way of solving problems regarding the state of the applications running in its pods: suppose an application is running in a pod and, due to a deadlock, it is not able to serve any more responses. Your average Kubernetes configuration has no way of detecting such a problem so if you imagine that this is a situation that might happen in one of your application, you will need to set up some tools to avoid it.
Luckily for you, Liveness Probes are designed to solve exactly this problem. Let's see how to implement a simple Liveness Probe and a Readiness Probe in your Laravel application.

First, you will need to set up a health route, a simple route that does nothing but returning a 200 OK status code. You can achieve this by simply adding the following code snippet to your routes.php:

Route::get('/healthz', function () {
    return 'ok';
});

Once you added this simple route to your code, you will need to add the following snippet to your deployment.yml:

livenessProbe:
httpGet:
    path: /healthz
    port: 80
initialDelaySeconds: 15
failureThreshold: 3
periodSeconds: 3

What the above snippet will do is tell Kubernetes to perform a request every periodSeconds seconds to the specified path. If the response has a status code between 200 and 400 the check will be registered as successful, any other status code will be registered as a failure. After failureThreshold consecutive failed checks, K8s will kill the pod and start up a new one. Finally, the initialDelaySeconds indicates how many seconds Kubernetes will wait before starting to send the Liveness Probe check requests: this will give the application time to start up and be ready to serve requests.

Readiness probes, on the other hand, are useful to disable a pod when it is not able to receive traffic, but its HTTP requests are already working. Suppose an application needs to access a database to return data: we can say that if the application is not able to access the database, it is not ready to serve traffic.
This second type of probes is useful to check exactly that: if the check fails, Kubernetes will mark the probe not ready to accept traffic and it will not be exposed to traffic neither from outside nor from inside the cluster.

Let's see how to implement a readiness probe starting from the requirement that our application needs to access a database in order to be considered "ready". First, let's create a /readiness HTTP endpoint: this route will perform a simple check on the database, if it is able to count the content of a check table in the database it will return a 200 OK status code, otherwise a 500 status code will be returned.

Route::get('/readiness', function () {
    $check = DB::table('check')->count();
    if ($check > 0) {
        return 'ok';
    }
    return response('', 500);
});

Once we have a working route, we will need to add the following snippet to our deployment.yml and redeploy our application.

readinessProbe:
httpGet:
    path: /readiness
    port: 80
initialDelaySeconds: 10
successThreshold: 1
failureThreshold: 3
timeoutSeconds: 1
periodSeconds: 15

As you can see, the syntax for Liveness and Readiness probe is quite similar, the only extra field we have here is the successThreshold parameter, which indicates how many successful checks are necessary for the pod to be considered "ready". In the above case, for example, after one successful check the application will be ready and it will start to receive traffic.

As you can see, implementing Liveness and Readiness probes for your application, Laravel or otherwise, is very straight forward: simply add a route which returns a status code between 200 and 400 for a successful check, any other status code for a failure, and add the above snippets to your deployment files and you will be up and running. Clearly, like any other Kubernetes element, Liveness and Readiness probe can be more deeply configured. To explore how to do so, I suggest you check the official documentation, which as always is very thorough.

A quick guide to creating Google Maps URLs for your applications

Pietro Bongiovanni — Wed, 11 Oct 2017 06:48:00 +0000

Having to find directions to an address that is in an app can be quite painful. Not all apps allow copy pasting the text, maybe it’s not in text format but has been added to the image and nobody ever thought about making it a simple selectable screen, there are many reasons why this could be hard.
So it’s us, when developing our applications and websites, that have to think about the users that might find themselves in the same situations as we are, trying to figure out the direction to that freaking coffee shop that everybody talks about but whose website seems to be a static image that does not allow you to select a thing.
And the solution is very easy: just make sure that under your address string you place an href tag with a Google Maps URL! It’s easier than you think and it might solve all your users problems.
How to do that? Well simply take the address you want the users to reach and simply create a link in the following form:
'https://www.google.com/maps/dir/?api=1&destination=' . $address
What this URL will do is simply redirect the user to a Google Maps page showing directions from their current location to the address stored in the variable $address or, if they are on mobile, launch the Google Maps app which will then navigate their user from their current location to the address you specified.
Note that you are not limited to simply the address! You can use almost every query you can perform on Google Maps as destination value: make it Latitude and Longitude, postcode or whatever other value you prefer, and your users will be able to reach their destination without having to struggle with copying and pasting addresses!

P.S. Remember to encode (urlencode()) the address before appending it to the Google Maps api base URL!

P.P.S. Concatenation and variable syntax here is PHP but the concept is valid for every programming language ;)

A brief history of my first OSS contribution

Pietro Bongiovanni — Tue, 29 Aug 2017 07:31:00 +0000

Originally posted on my Medium

It was a cold summer Monday morning, the first day of a new sprint, and one of my tickets stated Reseach ways to standardise GitHub usage in the development team. The reasoning behind this ticket should be pretty obvious and are far behind this blog post, but I will make sure I talk about them in a future one.

Anyways, since we use Jira to track sprints and ticket, I figured that something that it was worth investigating was Smart Commits. GitHub and Jira are pretty well integrated, and these special commits allow performing Jira actions without the need to look at its ugly and incomprehensible UI, without ever leaving your command line when you are making a commit.

I felt that integrating this kind of standard would be a nice starting point for creating an internal standard respected by everyone inside the company. There was only one single problem: a pretty steep learning curve. In order to create Jira Smart commit messages you need to follow a specific syntax and you need to remember each and every part of it correctly.

This was not something that I wanted everyone else to have to learn because I thought it would get in the way and reduce by at least an order of magnitude speed of adaption.

Enter Commitzen and cz-jira-smart-commit: a simple CLI that, via simple questions, generates complete and fully functional Jira Smart Commits. I was super enthusiastic when I first found it and I was sure that it was the perfect solution I was looking for. I immediately downloaded the two packages on my laptop and started trying them out just to find out, with much sadness, that the main package (Commitzen) had been updated to a new version that broke compatibility of cz-jira-smart-commit, thus the latter was not properly working anymore.

Not wanting to give up and go back to research phase, I decided to fork the package and take a quick look at the source code to see if I could figure out what went wrong and if there was any way I could fix it. I was a little bit scared by the fact that the package was mainly written in Javascript (I hate Javascript), but I decided I would give it a try nonetheless and, fairly enough, I managed to find what went wrong after looking at the code for around an hour.

And so I fixed, the problem (commit), and, while I was working on it, I created a simple shell script to install and setup the system so that my colleagues could just run one simple file and have everything set up for them. I helped everyone set up my renewed system and, then, I kinda forgot about it.

Fast forward a couple of weeks, I opened my GitHub profile and I saw that one of my latest edited public repos was indeed cz-ira-smart-commit and I thought: “Wait, this is an open source library which I somehow manage to fix, I should probably open a Pull Request!”; and so I did: went over to my repo and open a pull request.

After a little less than an hour I received a comment by one of the maintainers of the project requesting a couple of small changes and, after these small fixes, my first open source Pull Request was merged.

Something I thought I would never be ready to achieve had been done in little less than an hour and in a language that is as far away from my comfort zone as it gets.

Moral of the story here is, just get out there: many people are in the same position as I was a couple of weeks ago, where they want to contribute to open source projects and they want to help out, but are often scared because they have never done it and they don’t know where to start, it is much simpler than you think! Just start from the tools you use every day: it is very likely that you are using some open source tool in your everyday workflow, go on GitHub, read around the issues other people are having or look into a particular issue you might be having and fix it! It’s going to be easier than you think and the feeling you will get when you get your first pull request merged is like no other in this field!

So keep on hacking, and keep on using and contributing to open source software, it is the best way to keep advancing our fascinating and incredible industry, and it will make you grow as a software developer and as a human being!

Hack your productivity by hacking your awareness

Pietro Bongiovanni — Tue, 30 May 2017 07:01:01 +0000

Many people always seek the highest possible productivity by carefully choosing tools designed to save time, by delegating smaller tasks to others or by any other possible escamotage. Us software developers are a particular branch of the productivity-seekers population: we might be completely out of our way writing a tool that allows us to shave two seconds off a repetitive tasks because, in the long run, that will save us so much time! But often we do not realize that all the time that we will be saving, is the time we 'wasted' on thinking, designing and writing said tool and we are back at ground zero.

What I discovered recently (and what I wish I realized earlier) is that being productive is not all about cramming as much work as possible in a fixed amount of time, but rather it is based on our attention level when we are performing said task: the higher our attention level is when working on a determined problem, the more productive we are at solving it.

This might sound as bad news: one might think that there is no way that we can overcome how much our body is paying attention in determined parts of the day and, while that is true, it doesn't mean that there is nothing you can do to make yourself more productive. The key is exploiting the super-high-focus periods of the day to work on the hardest task that you need to accomplish, and leave the rest of the day for less important tasks, chores or anything else: the key is being aware of yourself and of your energy level and shape your day around it, hacking your awareness in such a way that your most high-efficiency periods are always teamed up with the most focus-requiring tasks.

This idea might seem simple to understand, but you might be thinking that it will be very hard to put in practice: how can I be sure of what my attention levels will be tomorrow? How can I plan in advance based on something that I have no idea what it is going to turn out to be?

The answers to these questions, in reality, is also easy. Our bodies are very much regular machines in that they like patterns and they like repeating them: attention levels fall in the category of the patters that our bodies like to repeat so it is enough for you to start understanding how your body behaves for a couple of days and you will be able to hack your productivity by being aware of when you are performing your most intensive tasks.

This is what allowed me to make my productivity skyrocket lately and I am sure that if you take it seriously, it will improve your daily life as well. If you want more informations on the subject (also explained in a MUCH better way) I suggest you reed this blog post from Thomas, from College Info Geek.

Start hacking your awareness and become super-productive today!

Hi, I'm Pietro Bongiovanni

Pietro Bongiovanni — Tue, 02 May 2017 09:31:47 +0000

I have been coding for 5 years.

You can find me on GitHub as pgoodjohn

I live in Amsterdam.

I work for Fixico.

I mostly program in these languages: C, PHP, Javascript, HTML&CSS, R, Java.

I am currently learning more about everything.js (it probably exists).

Nice to meet you.