It all started in 2014, when AWS launched Lambda, and promised developers a better, more hands-free way of running their systems.
Google Cloud and Azure followed with Cloud Functions and Azure Functions respectively.
The promised 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.
Still, within the developer community, adoption hasn't really taken off. The push has been exceptional; the pull, far less so. Given that the benefits are clear for both sides, why has this happened?
Runtimes are proprietary#
Developers & their companies fear closed-source runtimes. AWS, 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 from the beginning.
In 2018 AWS open sourced their serverless runtime (Firecracker) and this made it possible to support any language as long as somebody builds an adapter for it.
In 2019 Google Cloud launched Cloud Run which allows us to build Docker containers with our functions and this lets us pick and choose our specific runtimes.
Google and AWS have made impressive moves, but the other issues outlined below remain.
Runtime Fragmentation#
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.
Costs are unpredictable#
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.
Seems like a freemium model with VERY expensive premium. If you have an app or API with low to medium traffic you could be paying nothing. If you have very high traffic, you'll get charged an arm.
Development experience lacks#
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.
Language fragmentation#
Not all providers can run your favorite programming language.
AWS runs Node.js, Java, Python, .NET, Go and a bunch of other languages people have built adapters for.
GCP runs everything with their new Cloud Run product .
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.
In 2019 it seems language fragmentation is not an issue anymore. Unless you're using very niche programming languages.
WebSockets don't work#
Because serverless is stateless, stateful stuff like WebSockets doesn't work and there is no promise it will in the future.
There are alternatives like AWS API Gateway which provides WebSocket functionality through keeping state in a DynamoDB table, but it seems rather expensive and still proprietary.
Other solutions involve getting a 3rd party realtime provider like Pusher or Pubnub, but the same problems arise there.
Startup times#
This is actually the biggest downside. Because your functions are not always on, sometimes the system 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 for those users.
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.
The future#
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 the technology is just not there yet for most use cases.
How can Archbee help with a Serverless system?#
TURN STATIC DOCS INTO INSTANT ANSWERS
Build beautiful knowledge portals that are easy to navigate, search and share
Archbee Wiki 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.
Frequently Asked Questions
AWS launched Lambda at re:Invent 2014. It mattered because it flipped the model from managing servers to simply running code on events.
Why it was a game-changer:
- Per-request auto-scaling: Handles bursts and spikes without capacity planning.
- Pay only when it runs: You’re billed for invocations and duration, not idle time.
- Less ops toil: The provider handles patching, scaling, and resiliency.
- Event-first thinking: Encouraged microservices and decoupled, event-driven designs.
Impact: Lambda kicked off the modern serverless era, inspiring Google Cloud Functions and Azure Functions, and later advances like microVM isolation (e.g., AWS’s Firecracker, 2018) and container-based serverless (e.g., Cloud Run) that broadened language/runtime choices.
When the workload fits, serverless can be a big win:
- Elastic scale, no capacity plans
- Lower operational overhead: No servers to patch or babysit
- Natural fit for events: Works well with microservices, queues, and streams
- Pay-for-use economics: Often cost-effective for low-to-medium or spiky traffic
- Built-in resiliency: High availability and fault tolerance from the platform
- Faster iteration: Teams focus on business logic over infrastructure
You’ll feel these benefits most when traffic is intermittent or unpredictable, workloads are event-driven, and strict low-latency SLAs aren’t required.
Teams still hit a few consistent snags:
- Proprietary runtimes and lock-in: Implementations differ and are often opaque. Open options (e.g., Apache OpenWhisk, Oracle Fn) and tech like AWS’s Firecracker plus container-based platforms help—but fragmentation persists.
- Inconsistent event models: Event payloads and trigger semantics vary by cloud, hurting portability (emerging standards like CloudEvents can help, but aren’t universal).
- Cost surprises for public endpoints: You pay per invocation and duration, and exposing HTTP often adds components (e.g., API Gateway) that bring extra setup and cost.
- Developer experience gaps: Local emulation, debugging, and tooling can be clunky; auth/IAM and testing add friction.
- Uneven language/runtime support: Coverage has improved (containers via Cloud Run help), but consistency across providers isn’t uniform.
- Stateful protocols are hard: WebSockets and similar patterns are possible but tend to be proprietary, complex, or pricey.
- Cold starts: Startup latency can degrade user experience, especially with sporadic traffic.
Bottom line: portability, predictability, and latency remain common hurdles. If these are critical, consider containers or a hybrid approach.
Cold starts add extra latency because the platform must allocate compute, start the runtime, load dependencies, and run initialization before your handler executes. Depending on provider, language, memory, and package size, this can range from hundreds of milliseconds to several seconds (e.g., Go is often faster; Node.js/Python can be slower).
Why it matters: That variability can break SLAs and frustrate users—especially for public APIs, real-time interactions, and rarely invoked endpoints.
Mitigations (with trade-offs):
- Provisioned concurrency / min instances: Pay to keep instances warm for predictable latency.
- Keep-warm pings: Periodic invocations reduce cold starts but add noise and cost.
- Optimize startup: Use faster runtimes, right-size memory (more CPU can lower init time), trim dependencies, lazy-load modules, avoid heavy global initialization.
These help, but they chip away at the simplicity and cost advantages that make serverless appealing.
FaaS shines when consistent ultra-low latency isn’t mandatory:
- Background jobs and task queues
- Batch/ETL and data processing
- Scheduled/cron tasks
- Internal automations and glue code
- Media processing (e.g., image/video transcoding)
- Event ingestion and webhooks
You get auto-scaling, high availability, lower ops overhead, and pay-per-use economics.
When to think twice:
- Latency-sensitive APIs
- Real-time interactions
- Stateful protocols (e.g., WebSockets)
For these, consider managed containers (e.g., Cloud Run, AWS Fargate) or a small, always-on service for predictable low latency—and offload asynchronous or bursty work to FaaS.