Serverless for private clouds (or managing the server for a Serverless (!?) app)
A couple of weeks back I was at Dockercon USA 2017, which conveniently was hosted here at Austin, Texas.
There were a lot of cool things shown, but one of my favorites was the “cool hack” “FaaS (Function As A Service)” presented by Alex Ellis. In it, Alex presented a project where, using Docker and Docker Swarm, he provisioned a clustered environment where developers can upload code for functions written in any language (as supported by Docker), and execute them. You can find the project here.
In this context, we use FaaS as a more precise term for serverless.
For me the presentation did what cool hacks are supposed to do: Get you excited and rise questions.
The first thing I thought was “Cool! You can build Serverless apps with any language you want”. With a project like that, you’re not limited to specific set of supported languages like currently happens in services AWS Lambda. Being Docker based, you can use whatever language you want to build your serverless functions.
But the biggest question I had was “how are we still talking about serverless when this project is all about the server part?”. “Isn’t this what we are trying to avoid? To think about infrastructure?”.
Maybe as developers we don’t care about projects like this. But as a software engineer, this question resonated with another I had before: Is serverless possible in a private-cloud infrastructure?
Until now, when we talk about Serverless applications, we assume we are using a service like AWS Lambda or Google Cloud Functions. We pass the infrastructure management responsibility to whichever provider we choose.
However, my day job at Accenture has shown me that some companies will want to manage their cloud infrastructure themselves. Whether it is for compliance to certain regulations, or justbecause they already have infrastructure they prefer to use, there is a business case out there for companies who might want to take the advantages of a Serverless model, while managing the server at the same time.
The value of serverless in a private cloud
In previous posts we’ve discussed the advantages of using serverless architectures in small teams or startups. Cost and ease of management are the big ones.
Good software companies are constantly looking for ways to have their developers concentrate in building applications which brings value to their clients quicker and easier. However, now days developers need to think about a lot of extra concerns in their applications besides business-based requirements: How those applications will scale, memory management, implementation of security protocols, infrastructure specs like RAM, disk space, etc. If you could find a way to abstract that away from them, you could have developers who can dedicate all their attention to bring value to your clients.
Container platforms like Docker and PaaS (Platform as a Service) in general have contributed a lot lately to abstract those concerns and making them usable by software developers: They provide small, self-contained, write-once-and-use-everywhere, pieces of infrastructure which remain constant across all your environments.
Serverless (or Function as a Service in this context) is the next logical step in this evolution. It’s not about removing the server side out of the equation, but taking it away the mind of developers and put it in the hands of more specialized DevOps teams.
What’s the value of FaaS that PaaS doesn’t provide already?
Both PaaS and FaaS have what might look like overlapping concerns: Both abstract the infrastructure away of developers, allowing them to concentrate in coding. PaaS is based in deploying full applications, while FaaS deploys only functions.
Some of the differences are:
- FaaS allows developers to prototype faster. Without having to think about full (both legacy and new) projects, developers can focus on build business value from day one.
- FaaS gives developers the freedom to use multiple languages. Does one part of the application make more sense to be written in Scala while another would be easier to be implemented in Golang? FaaS makes this possible without having multiple applications.
Obviously, taking advantage of serverless features doesn’t prevent you from adopting other solutions like PaaS at the same time. It’s not all-or-nothing. It’s just another tool in the toolbox companies can give to their developers to make them more productive.
Also, nothing prevents you from merging those functions into full projects in the future and deploy them through PaaS.
FaaS allows us to shift the process in which we build applications, by creating value first and leaving the work of structuring your project for later. Later in the process, you can have enough information about your business logic to make more informed decisions about how your project should be structured (for example, should you go domain-driven or MVC?).
How does it look like?
Assume you take a project like the one done by Alex Ellis and you implement it in your own infrastructure (assume too that the project is production ready, more on this later).
You can have multiple developers teams share a FaaS layer, which internally know how many physical or virtual nodes it needs, and manages replication and communication. All those teams do is write a set of functions which are focused in bringing value to their clients.
This looks a lot like the infrastructure provided by PaaS platforms like Cloud Foundry. And in a way, it could work in the same way, with the difference that the developers focus in building functions instead of full applications.
Considerations
FaaS in private clouds is not quite ready yet. Existing projects need to mature, a lot of considerations still need to be worked.
Projects Ellis’s could provide solutions to some of those questions. Other existing projects out there are IronFunctions, IBM’s OpenWhisk and GalacticFog.
I would strongly suggest you to contribute to projects like the one presented by Alex Ellis if you can. Most of us look at new technologies and platforms and tell ourselves “I wished I was there when it first started and help shape the future”. This could be one of those opportunities.
