It all started in 2014, when AWS launched Lambda, and promised developers a better, more hands-free way of deploying and running their systems.
Google Cloud and Azure followed with Cloud Functions and Azure Functions respectively.
The benefits are tremendous. Developers would get closer to event & microservice driven architectures, and worry less about production environments going down under intense or spiky traffic. And you get all this while paying a lot less money for it.
But in the developer world, things haven't taken off. The push was extraordinary. The pull, not so much. As the benefits are clear for both sides, why has this happened?
Developers & their companies fear closed-source runtimes. AWS and GCP and Azure each have their own internal separate implementation of the runtimes and no one really knows what it's doing.
Some cloud providers like IBM opted to run on Apache OpenWhisk which is open-source. Others like Oracle Cloud built their own runtime and open-sourced it. It's called Fn - https://github.com/fnproject/fn. Let's applaud both IBM and Oracle for doing this. Unfortunately the damage has already been done, as trust is quick to lose and hard to gain.
Because nothing is standardized, runtimes differ greatly. When you build serverless functions you're supposed to get an object containing event properties. Well, again those properties are different for each cloud vendor. This makes it close to impossible to write your code once and deploy it wherever you wish.
Providers tax you on call count and on function runtime duration. Might seem straightforward, but most providers don't allow your function to be called by HTTP directly. For example, using AWS Lambda. To call your function from outside, you must go through API Gateway, which is difficult to setup programmatically and has additional cost.
As FaaS is young, most of the developer tools are rudimentary and cause a close to horrible DX. Things are improving, but still... You have to run a separate runtime just to run your code locally, and breakpoint debugging is really hard to do, sometimes impossible.
Not all providers can run your favorite programming language.
AWS runs Node.js, Java, Python, .NET and Go.
GCP runs Node.js only.
Azure runs .NET(C#, F#), Node.js, Java. And is experimenting with Python, PHP, TypeScript, Batch, Bash and Powershell.
IBM Functions runs Node.js, Swift, Java, Go, PHP and Python. And Docker which is a huge win, because we can run anything.
Oracle Fn claims to support any programming language. That's huge.
This is actually the biggest downside. Because your functions are not always on, sometimes it will be slower to respond because it has to spin an instance with your code and respond on the fly. There are some solutions like keeping some instances warm by pinging them, but still, when new traffic arrives it will still be slower. While still ok for some situations, it's not really ethical doing this, because cloud providers can only offer low-prices if not many instances are on all the time. As soon as everybody keeps their instances warm all the time, cloud providers will increase prices inevitably.
Startup times can be anything from 500ms for Go to 6s for Node.js and Python. So definitely, your users' experience will suffer. So it's a big no-no for most companies looking to run their APIs on FaaS platforms.
Runtimes are getting better and better so we might see better startup times. Some cloud providers already support any language, and are doing it in the open. Hopefully in the next 2 to 5 years we'll be able to run everything serverless, as promised.
For now FaaS is actually good only for systems that don't have response time restrictions like background jobs, or batch processing, or internal data processing. It's actually not exactly where developers get most value from FaaS. The most important things to developers seem to be auto-scalability and reliability, which seem to be promised, but just not there yet.
Archbee provides an easy to adopt solution for documentation that is specifically tailored to software development teams. We've studied many teams and their workflows, we've identified common usecases and coded them into our software's DNA. When your team picks Archbee, you are guaranteed to see upsides like team happiness, synergy and productivity within less than 3 months of using our product.