In the beginning, there was bare metal, and it was good.
Single-tenant servers were fast, reliable and secure — beholden only to their master. Verily, though, also cumbersome to provision and scale. The need for agility and scalability begat VMs, and cloud providers brought unto us infrastructure as a service (IaaS), and lo self-service in the cloud was born. Upon this fertile land arose Amazon Web Services, orchestration, and infrastructure as code (IaC); then also containerization came to pass, which begat platform as a service (PaaS) architecture. And lo all was well upon the land … Except for developers crying forth in want of language agnostic endpoints, horizontal scalability and the ability to pay for the real-time consumption of services.
In response to their pleas, at last, a great gift was bestowed upon the world: serverless computing, also often known as function as a service (FaaS). Runtimes which execute applications but do not store data. Meaning, a cloud provider like AWS, Google Cloud or Microsoft Azure dynamically manages the assignment and distribution of resources.
Serverless is pay-as-you-go, based on actual consumption rather than pre-purchased services based on guesswork. This is infrastructure as it was meant to be, emerging right before our eyes in 2018.
It’s Not Moonbeams
First: The name is totally misleading. Serverless computing still requires servers. There aren’t, like, secret magical moonbeams powering everything.
The term arose because the server management and capacity planning decisions are completely hidden. Serverless is “serverless” in terms of the user/developer never needing to take care of, or even be aware of, any of the infrastructure — the servers are fully abstracted away. Serverless code can be used alongside code deployed in traditional styles, such as microservices — or, applications can be written to be purely serverless and use no provisioned servers at all.
Well, What IS Serverless, Then?
The major difference between traditional cloud computing and serverless computing is that you — the customer needing said computing — don’t pay for unused, or even underutilized, resources. Previously, we had to anticipate capacity and resource requirements and pre-provision for them, whether on in-house data center or in the cloud. In our previous example, however, this would mean spinning up a server in AWS to stand by to execute this image resizing service at any time. In a serverless setup, however, you’re just spinning up some code execution time when, and only when, the function is called.
The serverless computing service takes your functions as input, performs logic, returns your output, and then shuts down. You are only billed for the resources used during the actual execution of those functions.
Pay-as-you-play, and only for resources actually consumed, is obviously a great thing. However, Goasguen and other cloud-native pros stress that the true value of serverless is not cost efficiency, but time efficiency.
Feel the FaaS Platform Power
While Docker has simplified the packaging and dependency handling for distributed application, and Kubernetes is helping enterprise run these apps in production, they still are not yet simple or easy to use. “Dockerfile, infrastructure details, Kubernetes manifests — all of these are still too complicated for a developer-minded audience,” said Bitnami’s Goasguen.
At its core, then, serverless computing works as a Function as a Service platform. Essentially, that’s what AWS Lambda or Google Cloud Function, handling resource management, load balancing and multithreading while the devs get to just focus on their code, and enterprise orgs on their mission.
- Serverless platforms take functional code — the “function” part of FaaS — plus all its dependencies (required libraries, amount of memory, properties, etc.), and build a containerized application package, usually in the form of a Docker image.
- When another platform service, such as an object storage or database wants to trigger the function, or when there is an external HTTP request destined for that function, the serverless platform will direct it to one of the available function microservices. If there are no active microservices available, it will deploy — “cold start” such an instance.
- The serverless platform takes care of recovering micro-services upon failure, auto-scaling to fit demand, logging and monitoring function activity and conducting a live rolling upgrade when code is modified. Someone else manages the platform services so that developers can just focus on the “function” aspect.
Are There Serverless Downsides?
For all the benefits, there are some potential FaaS downsides as well. For one, experts say, cloud providers will typically spin down runtime environments that aren’t seeing much use — meaning paradoxically, they also limit the total amount of resources available to you, introducing latency and problems with high-performance. Monitoring, debugging, and security can also tricky with these cloud providers — as they would be with any cloud computing workflow — due to the fact that it all, well, runs in a public cloud that you don’t have access to or control of.
Amazon Lambda has become synonymous with serverless computing, and that is a model most people can wrap their heads around. Thus, while Lamba has blazed the serverless trail, its drawbacks have come to be perceived as the drawbacks of serverless overall: slow cold start, slow performance, short-lived functions, and a closed set of triggers. These limitations are now assumed to universally apply to all serverless platforms, when in fact those are implementation choices. It is important to note that there are newer serverless platforms, such as Nuclio, which evolved to serve a broader set of use cases. These platforms have fewer restrictions, provide high performance, and can run in multiple clouds or even on premises.
“The geeks love it, but enterprises are still testing the water — they haven’t even gotten used to Docker/K8s, and now there is serverless,” said Haviv. “Like any new technology, it needs to ‘cross the chasm’ from the early adopters — who are typically more agile, more willing to take risks — to the masses. Who need to build trust, see proof points, address concerns like performance, security…”
Obviously, given that serverless tech is emerging and evolving practically day by day, not all aspects can be comfortably known entities. While not necessarily a downside, this factor definitely makes entire boards of directors squirm in their Aeron chairs. “Enterprises simply have to become more agile and take risks, since the digital “transformation” is taking casualties in the form of incumbents who are disrupted by innovators, and Serverless (like other As A Service technologies),” Haviv pointed out.
“The interesting part is that by abstracting away much of the Docker/Kubernetes complexity, serverless can be adopted faster and more easily, even though it’s the newer tech.”