Why the future is Function-as-a-Service not Container-as-a-Service
Back in 2014, right after we started Galactic Fog, one of the biggest arguments we were having internally was whether Container-as-a-Service (CaaS) was going to kill Infrastructure-as-a-Service (IaaS). Technically that argument made sense, but our team, having just spent the better part of a decade building a successful IaaS cloud management company, had trouble completely believing the argument.
In the end, what convinced us was that VMware had made billions virtualizing the server, but as programmers we didn’t really care much about that. It was the concept of virtualizing our apps that we were passionate about. Since there are a lot more programmers than SysAdmins, to our minds it made sense that being able to virtualize apps had to be worth a lot of money; especially if we could also run them on the cheapest cloud.
An even more interesting debate came only a few months later when Amazon released AWS Lambda. The question we then had was, “would FaaS replace CaaS?” Technically, it felt like this would be true, but pragmatically… well come on… developers have just spent the past 30 years building things like databases… are they really going to replace a database with a function?!?
Surprisingly, the answer is yes. Pretty much any database can be reduced to a library which uses object storage and then a programmer would just call functions for inserts/lookups/etc. The argument we came to believe is that with an object store and a FaaS engine a developer could more or less rebuild almost any kind of application.
There are plenty of experts who have written about why FaaS is superior to IaaS/CaaS/PaaS in terms of cost, productivity, security, reliability, scalability, and pluggability. We believe these arguments to be true. Much of Galactic Fog’s CaaS management platform Gestalt is built on top of our FaaS engine (Laser).
Indeed, we inverted the model due to the fact that the benefits of using FaaS were so significant that it was worth adopting as the standard operating procedure wherever possible. We encourage other companies to do the same. If you are in an infrastructure role deploying a CaaS solution for your company, then you should consider making your very first app deployment a FaaS engine so that your developers aren’t forced to use a tool that they may not ever need again.
The team at Galactic Fog isn’t alone in our belief in FaaS; it’s easy to find similar arguments here, here, and here. But the truth is that much like IaaS, you do still need a CaaS solution (for now). Databases won’t get re-written into serverless solutions overnight. But it will happen, and the future is going to be FaaS, not anything like what we live with today.
If you believe that there is a use case that most FaaS engines don’t (or can’t) solve for, drop us a line, as we are interested in hearing about it. And if you’re working on building your first serverless / FaaS application, check out Gestalt, which comes with Laser, the fastest and most flexible FaaS engine on the market.