There is always a buzz when a new design paradigm comes into being. Either the design paradigm is beaten to death or it stands the test of time as the next best thing. In the recent times we see in the horizon a slew of applications which claim them to be Serverless. In a time period where everybody is in some phase of Cloudifying their applications, the term Serverless sounds out of time and confusing.
So, what isServerless?
According to Gartner, “Serverless computing solutions execute logic in environments with no visible VM or OS.”. The takeaway from this is — your application still might have a remote server to talk to (Yes, it was misleading), but the remote server will not be managed by you.
Serverless paradigm may seem and sound similar to PaaS architecture, where every raw resource (like CPU, RAM, storage, network etc.) is abstracted out. It indeed is similar to PaaS since it is the next logical progression called FaaS (Function as a Service). In PaaS architectures we would bring together various vendor provided abstractions of raw resources into one platform and build applications over it. In contrast FaaS systems abstracts out the bringing-together part and provides with us the ability to execute some arbitrary piece of code (read function) on demand. Naturally, as in PaaS offerings, the vendors decide the choice of supported languages.
So far, this doesn’t seem to be any better than PaaS offerings. Yes, it is not. But the benefits become apparent once we understand how FaaS is implemented. Let’s assume we are building an API with endpoint
/greetTheWorld, which returns the customary message —
Hello World. In the non FaaS world there would be a remote web server, behind an API gateway, eagerly waiting for someone to hit the endpoint and serve the message. The server or cluster of servers is always up. Even the number of server instances to serve the greeting might be automatically provisioned based on traffic, but there will always be a server up and running. This is where FaaS starts to differ. If the same endpoint is implemented using FaaS there would be no server(s) waiting for a request. Whenever a request is made to the endpoint, a new container is spawned and the function written to return
Hello World is executed and the container is killed. Since every request has its own container instance spawned, the design is inherently scalable without any effort but also has a constant overhead.
The above oversimplified example would have provided a flavour of FaaS. But FaaS is not just that. A function defined in a FaaS system need not just react to a hit to an API gateway, but it can react to any event being triggered. Needless to say, the event is supported by the vendor.
Apart from being inherently scalable, FaaS provides advantages like
- Low operation costs due to what-you-use-is-what-you-pay model
- Separation of concerns among deployed functions
- No requirement of Ops
Looking at the disadvantages
- As already noted, there is a latency involved in spawning a container.
- Different FaaS vendors have different not-interoperable implementations leading to vendor lock-in post development.
- Security is also on a lower end when compared to Client-Server architecture, but this is not just unique to FaaS.
After the above overview on FaaS, it’s logical to ask whether it suits all the applications. The answer would be No and Yes. Many applications by its nature are well suited for FaaS architecture. Typical example might be an IoT device with its sporadic events. But, most applications of the yesteryear don’t, at least with their current designs. Certain effort would be required to rethink current applications to fit this architecture.
Is it worthy?
By definition functions are stateless. They operate on a stimulus and gives a output. But, most applications need some kind of a state in the backend. To alleviate this shortcoming we might have to depend on some other service for maintaining state. The point to consider here is that the service we depend upon might not be inherently scalable, hence undermining the benefits of FaaS. Already people have started drawing parallels to Stored Procedures for being similar and the challenges it possesses.
Lot many vendors are jumping in to offer FaaS based offerings. The forerunners are
Each of these products are in various levels of maturity and flavours. But the entire FaaS ecosystem itself is not mature enough. FaaS has lot of raw potential, but it still lacks good tooling, solid CI/CD process and good practices to follow, but this not so surprising. No wonder, in the recently released Gartner’s famed Hype Cycle for Cloud Computing, Serverless has been been categorized as “On the Rise”.
The next couple of years can say whether Serverless Architecture or FaaS will sail through.