Comprehensive software reviews to make better IT decisions
Serverless Computing: Cool Technology With a Confusing Name
Serverless computing – a computing service based on “Functions-as-a-Service” and back-end data storage in the cloud – is one of the fastest growing methods of cloud native application development. It is part of an overall trend to ever higher levels of service abstraction in the cloud. Shame it has such a stupid name.
Serverless is hot. According to the 2018 version of Rightscale’s annual State of the Cloud Report “serverless was the top-growing extended cloud service with a 75 percent increase over 2017 (12 to 21 percent adoption).”
The best known, and most widely used, example of serverless is AWS Lambda chiefly because Amazon Web Services is the best known and most widely used public cloud service. But also getting attention and growing in usage is Microsoft Azure Functions, Google Cloud Functions, and IBM Cloud Functions (based on Apache OpenWhisk).
Rightscale is a cloud service broker, managing service across multiple clouds. Another cloud broker, Cloudability, also has a state of the cloud report based on customer usage analysis. The company notes that “serverless growth across AWS Lambda and Microsoft Azure functions continues to see a rapid quarter over quarter growth.”
Yet another survey report, this one from CloudFoundry, finds that serverless computing adoption is on “an upswing” with 46% of respondents using or evaluating the technology (up 10% from 2017). By contrast containers are further ahead in adoption/evaluation (76%) among cloud users. But serverless is on a similar growth curve and is where containers were 12 months ago.
But It’s Not Really Serverless
Let’s deal with the somewhat oxymoronic term first before we get into the real potential that exists here. A server is, essentially, a computer. “Serverless computing” is akin to calling it “computer-less computing.” It makes no sense from an architectural point of view.
Of course there are servers involved in serverless computing. It’s just that they are hidden away under layers of abstraction in the cloud. A cloud-based software-as-a-service application could also be called serverless in that when you use the app you don’t know or care about the servers the SaaS provider is using to run your app.
The term “serverless” is more about point of view than actual architecture. In serverless app development the developer can invoke functions – like looking up data in a cloud database and performing some action with it – without managing (or even knowing about) any middleware servers.
A serverless service like Lambda runs your code in the cloud and manages all the underlying compute resources for you. Though there are, indeed, real live servers running underneath it all the developer does not need to know anything about it.
So What Is All the Excitement About?
To answer that, let’s compare serverless and server-based applications at an admittedly very high and not totally accurate level. (Apologies to the developers out there for the really important missing elements in my diagram. This is for illustration only).
There is significant opportunity for cost savings in the difference between Illustration A and Illustration B.
- In A you have an application server that is needed for the client app to work. In the real world you’ll likely have several servers working together to deliver functionality (Web Server, Database Server, etc).
Important point – the server(s) are always on. The servers have to be instantiated and maintained (on-premises or in the cloud) and they are always on, essentially waiting to be asked to do something (function). - In B you have no servers on standby, only a library of executable functions that are invoked on-demand in the cloud by the client-side code (or the back-end data. More on that below).
Important point – the functions are stateless. That is they only exist as a processing entity when being executed, then poof, they are gone.
In B zero time and effort has to be invested in the care and feeding of servers (physical or virtual). The cloud provider does that. More importantly, this takes the “pay per use” economics of the cloud to a new level. Without “idling” servers involved you pay for compute in micro-second increments. The serverless application is also more elastic because there is no point where you have to add more servers (dynamically or otherwise) to increase capacity.
From the developer’s point of view, there is little change in that they are coding function calls into their application. It’s the how of function execution that changes. Here is another view that shows what the developer needs to know across different levels of abstraction.
The value proposition of greatly reduced cloud processing charges is further enhanced in AWS with a free tier account. This entry level account gives you 400,000 seconds of Lambda function execution a month for free. This article, about doing serverless image processing, notes that “based on an average of 500ms per lambda invocation, it means that you can invoke your functions 800,000 times/month completely free of charge.”
Alexa, What Is an Example of Serverless Computing?
If you think you haven’t used a serverless app, you are probably wrong. Amazon, for example, has Lamdba functions for Amazon Echo skills development. (An Alexa “skill” is an app for the Echo.) So when you ask the Echo a question pertaining to a certain skill, the processing of your question, finding the answer, and speaking the answer back to you may well be done with serverless functions.
The cost to the skill developer when your question is answered is minimal. In one example, a heavily used Alexa skill for calming sleep sounds had more than 50 million Lambda requests serving 175,000 users per day and cost the developer $30 a month. (See How serverless scales an idea to 100K monthly users — at zero cost at Freecodecamp.org).
Another example of serverless computing is event-driven processing. This is where an event triggers some function to act on data. For example, media companies and others have used Lambda functions to resize and format image files when they are uploaded to a given Amazon S3 storage bucket. An online journalist can upload their news photo to Amazon storage and it will be web ready when displayed in a story. The fetching of the photo for display can also be a serverless function.
According to the CloudFoundry report, serverless computing currently within large and midsize organizations breaks out like this:
- The majority, almost two thirds (65%), of companies said they used serverless for “cloud automation tasks that might previously have been handled by scripts.”
- Just under half (45%) said they deployed serverless as the back-end for running web sites.
- 38% are using serverless for data processing functions (like data processing from the Internet of Things).
- 38% are using serverless to provide back-end services for mobile applications.
So Why Isn’t the Whole World Serverless?
The serverless programming evangelist might answer the above question, “Well the whole world isn’t serverless, yet.” As we saw in the surveys above, serverless is a hot trend, but it is also early days. Serverless is far from realizing its full potential.
Serverless is also not a clear solution for every case. For example, where serverless is great for asynchronous, intermittent, and event-driven processing it makes less sense for high-volume multifunction applications such as online transactional programs. If you have a system in place with application servers handling the load, it makes little sense to try to break that system up into dozens of discrete functions that are firing off constantly by the millions.
The term “serverless” has been used to connote coding completely free of infrastructure and operations concern. But beyond the narrow definition of operations as being just server admins, there remains a range of operational issues that will need to be addressed. For example, how is the application secured? How are performance, responsiveness, and availability monitored?
Finally, there is the age old question of lock in. If your data is on Amazon and the serverless functions are Lambda, it’s hard to imagine how that application could be migrated to another service provider.
Recommendations
- Explore how severless may lower costs of app development.
If you don’t do a lot of application development in your organization, there is very little impact here for you. However, if you do application development for either internal operations or for customer service, you should be exploring serverless computing (as well as Platform-as-a-Service and containers) for getting the most out of cloud services at a more efficient cost. - Focus on new application/service development first.
Here is where you have the best chance of a quick win. If existing services are running well, trying to re-write them for serverless may be too expensive with little return on investment. - Look to exploit higher-level services in longer-term cloud strategy.
The value proposition of cloud services increases as you move up the stack. Your cloud migration longer term goals should be Platform-as-a-Service and other cloud native services for core applications and services. (As opposed to a straight lift and shift of server and storage instances to cloud Infrastructure-as-a-Service IaaS). - Avoid the “NoOps” trap.
Serverless does not mean NoOps, but it does mean that Operations will have to define what they need to be responsible for and for what instrumentation they will be accountable.
Bottom Line
Serverless computing is a hot trend right now with many organizations experimenting with, if not using, serverless functions for cloud native applications and services. Despite its confusing name, serverless is part of a trend in higher-level abstraction in cloud services (which also includes Platform-as-a-Service, cloud storage and database services, and containers). There is real potential here for reduced processing costs and zero operational maintenance, but we are in early days.