In IT and software development circles, there has been a lot of talk over the past couple of years about a computing model known as Serverless Architecture. Severless, as it is referred to for short, is something of the new kid on the block in cloud technology, a young upstart to rival the more established cloud models of Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).
As a matter of fact, to understand what Serverless is and how it works, it is useful to imagine it in relation to these three doyens of the cloud computing world. If you picture cloud approaches as a continuum of relationships between client and cloud service provider, serverless would sit somewhere between SaaS and PaaS. Let’s unpick that a little further.
From the end user’s perspective, SaaS is by far the most popular cloud model out there. Most of us use it every day, whether we use Microsoft Office 365 or Google G Suite, Salesforce or Slack, Facebook Messenger or Netflix. What the SaaS model offers isuse of a software-based service, in return for a subscription fee. It is simple, convenient and cost effective – as long as use of a service is all you want.
What SaaS does not provide is any significant control over the application, its functions, and beyond that the operating system or server it runs on. That is all controlled by the cloud provider, and you essentially get what you’re given. In business IT, that is not always desirable. You might want to play around with a piece of software and configure it to your own purposes. You might want to build and run your own application. That’s when you need to look beyond SaaS.
In the world of cloud computing, IaaS and PaaS have to date served as the main models supporting custom software development. With IaaS (think AWS EC2 or Rackspace, for example), you buy access to server resources, which the provider controls, and then can do whatever you like in terms of building and configuring operating systems and applications. With PaaS (think Windows Azure, Google App Engine), you get an operating system thrown in, so from a development point of view you only have to worry about the applications.
With Serverless Architecture, you get even more than an OS on which can build and run your apps. You get an entire application layer on which will build and run your functions. You can think of it as the last post in the cloud continuum before you ask the service provider to build and run the apps for you (which is what SaaS is).
So why would you want to switch to a serverless model? From a development perspective, serverless carries two key attractions. One, it removes as much responsibility for the background IT resources that support applications as possible. You don’t have to worry about configuration and management of server resources, OS, app layer, none of it – you can focus attention purely on function design and management.
Two, serverless is a highly efficient model. With PaaS and IaaS, you’re buying platform and infrastructure resources in blocks. Regardless of whether you use all of those resources of not, you pay for them. Severless introduces a different, more dynamic subscription model. By controlling the application layer, the service provider can oversee how resources are allocated as and when functions are called upon. The end user therefore pays per execution, not by block, which offers considerable cost and efficiency savings. Some developers have reported reductions in operating costs of up to 90% and 10-fold increases in speed of delivery.
There are, however, some drawbacks to serverless migration that developers should also be aware of. One is that serverless architectures can be considerably more complex to manage – you are effectively moving from running an application as a single entity to a network of interrelated tasks. Development might be faster and cheaper, but monitoring the product is trickier. Also, while the dynamic nature of resource allocation means services run on a serverless base are highly scalable, it can be hard to predict performance, because of the complexity of the sum of all the different tasks involved.