By Milind Borate
While there are many benefits of public cloud, metered billing is one of the key ones. It’s just like electricity; the meter starts running only when you turn on a heater and you pay for only what you use. With public cloud, unlike on-premise data centers, you can bring up virtual machines and bring them down at will, while paying only for the time when your machine is running.
Software development has evolved to take advantage of metered billing by running stateless, scale-out services that spawn more virtual machines only during peak load. In other words, you could scale out your service, be it an e-commerce site or a music delivery platform, when there is load surge and you don’t have to pay for the hardware when the load is lean. It’s a step in the right direction but there are two challenges with this model. First, the system load may not consume all resources available on a machine and hence, you could be paying for unused capacity within the machine. Second, when there is a surge in load and you want to bring up more machines, it may take a few minutes for boot up. Generalizing this concept, the granularity at which you can add compute capacity and the time to bring up additional capacity are two important factors when dealing with scale-out services.
Containers is the next step towards granular compute capacity and quick boot time. Container services (Container instances by Azure and Fargate by AWS) allow smaller sized instances and faster boot times. For example, AWS Fargate lets you have containers with as small as 500MB of RAM and could boot a new container within a few minutes. The SOA (Service Oriented Architecture) paradigm stays the same whether you use virtual machines or containers for scale-out. Once a service comes up in a virtual machine or a container, it would serve multiple requests (typically REST calls). Now, since the request rate is not constant, you may still have some unused capacity on your container. How about spinning up compute only for the request duration? Yes, you can do it. Azure Functions, AWS Lambda, GCP Functions let you run a single function (or request) and charge only for the duration of the function. That’s serverless programming and most public cloud providers support running functions without spawning a server.
There is more to serverless programming paradigm beyond simple functions. Public cloud providers support serverless storage, databases, email service, API gateway, messaging, ML services, big data ETL, big data query processing, and the list is growing. In other words, you do not need an NFS server or a Kafka server or a Spark setup. Neither do you need to worry about scaling up these servers. With the foundational stacks made available as a service, one could practically develop an entire application without running a single server.
One interesting facet of serverless is democratization of software development. You do not need a deep software development background to build a small application using a set of node.js functions. For example, you could bring up a small interactive web application with static pages rendered from S3, node.js code running as AWS Lambda functions, database stored in Aurora serverless, and exposed through API gateway. (AWS is used only as an example here and similar capabilities exist in other public cloud solutions.) As another example, you could do sentiment analysis for a twitter feed by writing a small function that reads a tweet and calls ML service for sentiment analysis. The possibilities are endless. Welcome to the new world of serverless software development!
(The author is the Co-founder & CTO, Druva)
