This article explores the latest trend in cloud computing: serverless.
The name itself is a bit of a misnomer, as servers are a critical component of any cloud application and aren’t going away anytime soon.
However, the ways a server is deployed can vary and along with those variations come a wide range of costs.
Serverless computing aims to tackle two primary issues with cloud computing: streamlining the tasks associated with deploying a server and reducing the costs associated with running a server.
Cloud Computing: Before
Before diving into the deep end on serverless, it’s worth exploring how we got here. The first computer was connected to a network back in the 1960s. Soon thereafter, IBM introduced the client-server age by offering clients access to their OS/360 mainframe for a yearly service fee. Around the same time, computer scientists working under a U.S. Department of Defense grant began creating a network of computers called ARPANET or DARPANET, if you want to be extremely accurate. ARPANET gradually evolved into the network we all know and love today as the Internet.
Fast-forward to the late 1990s. By then most companies had deployed some form of client-server enterprise application. However, the costs of setting up, deploying, and maintaining those servers were expensive in terms of money and time. This typically involved a network administrator, a systems engineer, and a data center housing all the equipment.
A few companies realized that once the server was configured properly, deployment was relatively straightforward. Furthermore, it was possible to emulate a computer system in software, known as virtualization. So they devised a way to create a copy of a server so that it could be cloned repeatedly, following the same exact configuration steps. These copies (also known as virtual machines or VMs) could be created as needed, say for disaster recovery if a primary server failed. This allowed a server to be set up and deployed much faster and became standard practice for most corporate server deployments.
The costs came down too as the system components became commoditized and virtualization eliminated the need for specialized hardware. The task of setting up and deploying the server was still a very specific skill and required access to the data center where the server was kept.
Cloud Computing: And After
The next phase of cloud computing was characterized by a few key developments. Storage of data in the cloud became very inexpensive. Services like Dropbox, Google Drive, Apple iCloud were created and allowed users to store digital content such as music, pictures, documents, and spreadsheets up in the cloud and retrieve that content for little or no cost.
Smartphones also appeared around this same time, allowing users to access the cloud from virtually anywhere, driving the need for even more access to cloud services. As apps like Facebook, Amazon, and Twitter drove more traffic to cloud servers, developers needed to quickly create servers to process all of the traffic.
However, once those servers were created, the utilization would vary wildly. A server handling Twitter traffic might be idle for most of the day; but if a major news story hit the wire, the server would quickly spike and possibly become overloaded.
If you provisioned a server based on the high water mark or past traffic, you would likely pay for too much utilization. If you provisioned for the average traffic, you might be swamped by an unexpected event.
And finally, several cloud providers appeared, such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Services, to help make the process even simpler. All of this brings us to the doorstep of serverless computing.
What is Serverless Computing?
As is typical in technology, a crisp definition of a buzzword is often hard to come by. Serverless Computing is no different.
In fact, a lot of people drop the term “computing” from Serverless Computing and just call it Serverless, causing even more confusion. I have no doubt that my definition of serverless will be slightly different from yours.
Amazon’s Lambda service describes serverless in this way: “Run code without thinking about servers.”
All of the definitions have some of the following traits in common. Serverless is characterized by:
- Dynamically managed resources
- You don’t provision the server yourself, you simply write the code and the resources are automatically provisioned to accommodate your code
- Pricing based on the actual amount of resources used
- You only pay for what you use, not for a server that’s idle 99% of the time
- Scaling of resources done automatically
- In addition to automatic provisioning, serverless platforms will also scale resources up or down according to usage
Why Serverless?
The two main drivers for why serverless was created are cost and complexity.
First, figuring out how to provision a server, also known as capacity planning, is very difficult. Capacity planning usually results in overspending since it is easier to have excess capacity than to be hit by a surge in demand and lose customers. This means that companies are spending too much on their servers.
And second, developers don’t want to spend days or weeks configuring a server. They want to write code to create apps using those servers.
Several of the cloud providers began addressing these two issues, starting with Amazon’s Lambda service around 2014. Lambda allows developers to write (server) code that is triggered when an event occurs; but the code does not need to be always running on a server.
Instead, the server instance is created dynamically when needed (or triggered), usually in response to an event, such as a web service request. More importantly, the server instance is stopped as soon as the code finishes executing, reducing the cost in theory…more about the theory and reality in a later section.
Both Microsoft and Google have competing serverless offerings that work in much the same way as Lambda. Microsoft’s offering is called Azure Functions, while Google’s version is called Cloud Functions. Not very creative, but I’ll take function over form every time!
Who does Serverless Computing Impact?
If you’re a systems engineer and have never heard of serverless, you might be in a panic right about now; thinking that serverless will eliminate your job. Not true. On the contrary, serverless will free up system engineers to do other (read: more important) tasks rather than having to configure yet another server for that pesky cloud app.
If you’re a mobile developer, you might be thinking, “Finally, I don’t have to wait for the systems engineering team to set up my server!” This is mostly true. One of the key factors driving serverless is the simplicity of setting up the environment to run code in response to an event.
If you’re a full stack developer, you can already do everything by yourself, so serverless will be just another arrow in your quiver. Much like the previous two roles, serverless will make the life of a full stack developer easier. All kidding aside, serverless affects all three of these roles and several others.
Finance: The Unexpected Benefit of Serverless
One example where serverless will have an unexpected benefit is in the finance department of your company. More and more companies are moving their servers away from traditional data centers and onto cloud platforms such as AWS and Azure. One of the drivers for this migration is total cost of ownership or TCO for short. The TCO of a cloud platform is usually lower (and in some cases a lot lower) than hosting servers in a data center or co-location center.
Furthermore, the costs associated with data centers are treated as a capital expenditure or CapEx if you want to sound like one your finance colleagues. CapEx brings along fun concepts such as depreciation, amortization, and sunk costs, to name a few.
Whereas, most cloud costs are treated as an operational expenditure or OpEx, which is much easier to manage from a fiscal point of view, a monthly expense is essentially no different than rent for office space. This fact obviously brings a smile to the face of any chief financial officer and anyone else in within the finance department of an organization.
In short, the financial role views serverless as a way to save time and money.
How does Serverless work?
At its core, serverless frameworks work by dynamically creating resources in response to a trigger. The framework then invokes the code associated with the trigger; and, finally, the framework shuts down the resources once the code finishes running. The details of how this happens differ depending on the platform.
For example, Lambda allows a developer to associate various triggers, such as change to a database or an inbound HTTP request. Each platform also varies in terms of the programming language(s) supported and the permissions afforded to the running code.
At the time of writing, here are the languages supported on each platform:
- AWS Lambda
- js / JavaScript
- Java
- Python
- PHP
- C#
- Go
- Microsoft Azure Functions
- js / JavaScript
- C#
- F#
- Python
- PHP
- Google Cloud Functions
- js / JavaScript
- Go
When should you use Serverless?
There’s a saying among carpenters that goes something like this “if all you have is a hammer, everything starts to look like a nail.” The point of this adage is that it is just as important to know when to use a tool, as it is how to use the tool.
When applied to serverless, there are plenty of times when this technology is appropriate; however, there are times when it actually makes things worse.
Let’s look at some examples and counter-examples.
You should think about using serverless when:
- Doing a proof-of-concept; very easy to get started and fail fast if necessary
- Developing a brand new application with server needs; no legacy code to worry about
- Creating a microservice; great for small, self-contained tasks
- Capacity Planning for an application; scalable and robust
- Budgeting for cloud servers; pay for what you use, not idle time
You should think twice about using serverless when:
- Porting a large client-server app from older technology; platform may not support the programming language or technology used previously
- Supporting a long-running task; batching a large dataset may actually cost more
- Relying on “local” operations between tasks; no guarantee two tasks will be run on the same server
Bringing it all together
Hopefully, by now I’ve convinced you that serverless computing is a trend worth following. To drive the point home, let’s take a look at an example of an application I converted from a traditional server app to serverless.
My initial application is an Amazon Alexa Custom Skill. The server part of this application is a .NET web service written in C#. The web service performs a query on a database using parameters provided by the user when asking Alexa a question.
Because of the way Alexa works, the server hosting the web service must be running at all times. Otherwise, a user’s request might not be handled. The diagram below shows the flow of data within the application.
Focus on step 3, as this is where the server processes the request from Alexa.
The server code in my web service is pretty basic C# code to query a SQL database and return a string formatted for Alexa. Keep in mind, the server must be running at all times, regardless of how many customers are using my Alexa service, which in my case can probably be counted on two hands.
In other words, my server is idle most of the time, wasting valuable resources (i.e. my money). What if I could take that same C# code and process any incoming Alexa requests on demand, without a dedicated, always running server?
As luck would have it, AWS provides this capability in the form of Lambda; in fact they prefer it for Alexa skills! (An Alexa Skill is the technical term for the code that enables Alexa to interact with users in a specific way).
With the click of a few buttons in the AWS console, I can set up a trigger (in this case an Alexa request) to launch my C# code to process the request as before and return a response. No code change, just upload the code from my current server application into the Lambda container within AWS.
Here’s what that looks like in AWS:
Now, I don’t have to worry about maintaining security updates on my server, or providing a backup if the server goes down, or scaling up the resources if I get a sudden spike in traffic to my Alexa skill.
And I certainly don’t have to worry about wasting money on a server that is mostly idle waiting for an occasional request. All of that is done for me by Lambda. All I have to worry about is making sure my code works!
Serverless will continue to gain traction as companies like Amazon, Microsoft, Google, and others continue to evolve the technology. Depending on where you and your company are at with cloud adoption, there are a number of ways that Serverless can be leveraged on that journey.
Here is a Top 5 list of ways Serverless can help you:
- Run your code without thinking about servers
- Lower your total cost of ownership (TCO) for Cloud
- Decouple your applications using microservices
- Make your applications scalable and robust
- Free up your teams to innovate faster and try new things