4pres goes #serverless

Last month I felt I was a little late for the #serverless party going on all over the internet and I started taking a look at what the pros and cons would be to actually not manage any server myself. Shutting down my VPS hosting my apps I will lose my mail server, my MySQL instances and my Docker registry but: who cares? There are cloud services I can use with hundreds of times more availability and for a fraction of the cost.

Why #serverless?

We are moving more and more rapidly to a developer friendly world: all cloud providers tend to relief companies from the burden of managing complex cluster architectures and it’s not a coincidence that things like SRE at Google exist. Systadmins are no longer required where they can be substituted with far more performance by declarative syntax clusters (Kubernetes, Docker Data Center) and reliabile, consistent configuration deployment (Ansible, Puppet) in managing high volumes of phisycal or virtual machines.

This shift to a developer-centric world forces who embraces it to “trust” the IaaS, PaaS and FaaS providers but in the same time let them focus on core and valuable development processes.

That’s why.

Take the simplest app in the world: 4pres, a URL shortener. It needs a presentation, computation and data layer as most of apps. Traditionally and depending on your budget and needs, you would spin up one or more VPS and deploy software on them (containers or not, doesn’t matter here). The setup of nginx as reverse proxy to your application already requires skills that most of developers don’t have, but in first hand why should anybody have them when there is a service like AWS API Gateway that lets you deploy one in seconds? Having the possiility to do so, you may want to forget about everything not strictly related to your app, so focusing only on building and maintaining functionalities of your app.

How you can migrate your app today

In terms of cloud provider I have a lot of experience with AWS therefore my first thought is for them when trying to do something like this: they probably already have enough mature services supporting what I need. Don’t take this as a sponsorship: you can do the same with any other provider.

Traditional Architecture

NGINX terminates SSL and proxy back to app every request. The Golang app finds out what to do from a combination of HTTP Method and URL Path:

Serverless Architecture (AWS)

The API Gateway definition acts as proxy and:

Not that big change in the overall design, but the code for the Golang app only shares a function to shorten the URL between the 2 implementations: that is understandable because we no longer manage HTTP requests attributes and delegate that to API Gateway, we don’t display static content anymore and leave that to S3. At the core we only have 2 things to worry about:

and then we can focus on extending new features:

Conclusion

Thanks to this development model our craftsmen effort can be 100% dedicated to building features and forget about the rest: this can be a great advantage at large scale. Recently I have come across another interesting framework for Function as a Service called iron.io and I am willing to try it as soon as possible so stay tuned!