Part 1

In this blog post, we’ll explore serverless computing.  This will be the first in a short series, exploring the technology and getting “hands-on” by developing some basic serverless functions.

What is Serverless?

Wikipedia gives us a nice starting point definition for serverless computing.

Serverless computing is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.
Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.
– Wikipedia

In other words you worry about the functionality and let the cloud service provider worry about the servers. The bonus is that since they are managing the servers, you don’t need to pay for time that your function is not being used at all. Furthermore, you don’t need to worry about adding more servers when your function is being used a lot – that is the job of the cloud provider, too.

Although serverless computing is offered by many cloud service providers, this article will focus primarily on the services available from Amazon Web Services (AWS). You can learn more about these services here: https://aws.amazon.com/serverless/

Browsing the AWS serverless website, you can see that they offer several services that fall under this serverless category. We’ll primarily be focused on the computational service Lambda, but will also make light use of the serverless storage service S3.  The code for the Lambda functions themselves, are stored in S3, as well.

Getting started with serverless framework (npm)

Serverless compute services, like AWS Lambda, can execute functions written in a variety of development languages. We’re going to start with Node.js and a useful npm package, aptly named serverless. This utility helps you build and deploy serverless compute functions. It is compatible with AWS Lambda, and is highly configurable. We’ll go over the steps to get a sample Lambda function deployed, but if you want a good quick overview video, this one is useful.




To keep things interesting, it seemed best to choose an initial Lambda function that did more than just say “Hello World.”  However, our focus will still be on the use of Lambda, instead of diving too deep into some unrelated business logic. For that purpose, we’ll look at some logic from an existing application and how we might move that to a Lambda function.

Let’s start with an internal tool that we have built to retrieve and convert OpenStreetMap (OSM) data. It is a simple Node.js based web application that allows users to request GeoJSON data describing airports of their choice.  Here’s a look at the user interface.

serverless computing airport viz 3

The logic is fairly simple. A user enters an airport code and it is submitted to a server side API function over HTTP. The server side code interacts with a third party API provider that serves up OSM data for that airport. Once that data is received, the server side code converts it to GeoJSON and returns it as a response to the client, where it is then displayed on the map. It is worth pointing out here, that this may not be the ideal candidate for a Lambda function since it could probably be done entirely in client side JavaScript and the third party API can be a little slow, which increases execution time (and cost). There are a number of ways one might change this to make it more efficient, but the goal here is just to show how to deploy it as a Lambda function. Given that it is not used at a high frequency, there should still be a significant savings over running it on a dedicated machine – for which we would mainly be paying for idle time.

Deploying to AWS

The serverless npm tool bases its actions on the serverless.yaml file included in our project.  We can have it setup a basic project structure for us, including this file, by running the serverless create -t aws-nodejs command.  Once we edit the file to meet our needs, it looks like this:

serverless computing code 2

In summary, we specify that we are using aws and node.js and provide the name of the S3 bucket in which we’ll store our lambda function code. In the functions section, we have added an “osm” function, specified it’s handler name, and configured it to be triggered on HTTP GET requests.  We also specify a path parameter {airport} which will be passed in from the client.  

As for the handler code, we adapt a simple hello world handler that was provided into something that will make use of our osm library.

serverless computing coding 3

Most tutorials show a handler returning a simple “Hello, World!” string, but in an asynchronous world, returning a string feels very limiting. Fortunately the handler can also return a Promise.  This makes the code much simpler. You’ll probably also want to include the CORS header in the response, so that it could be used from client side Ajax requests.

With all this in place we can then use the serverless deploy command to publish our function to AWS. This provides an endpoint URL that we can open in a browser to make sure we get the expected results. 

Troubleshooting Tips

New Lambda developers may need to spend a little extra time on permission configuration and debugging as they try to get their first functions working correctly.  Here are some tips for both.

Permissions

Most tutorials online basically have you grant yourself nearly unlimited access.  This isn’t really practical in the real world, for most corporations. Security is a part of life on the internet.  It is more likely you’ll want to start with the most limited access first and then add permissions as needed. The good news is that the alerts returned from the serverless deploy process are mostly clear and descriptive, and after a few adjustments you should have things working properly. Just plan to spend a little time here on your first attempt, to make sure you work out permissions in a way that accommodates your function and also works within your company’s security requirements.

Function Debugging

A first time lambda developer may have to get used to the idea that their code will be dynamically deployed on servers they don’t control. This means that it is ideal that it be as fully tested as possible, prior to deployment. Fortunately, the serverless utility includes means by which you may invoke your function locally for testing purposes. If you find it necessary to use full step-through debugging, that is possible, using tools provided by aws. Here is their documentation on the subject. Once deployed you can check log results in AWS CloudWatch – which of course also requires the associated permissions.

Considerations for Going Serverless

There can be a lot of advantages to going serverless, afterall someone else deals with most of the non-development work. This means more time to get your logic right, and less time required to manage the hardware and traffic volume. However, that doesn’t mean it is magic. You may not have to set up servers, but you do have to wade through a variety of configuration options and permission settings to allow AWS to properly manage things for you. There are good tools to help in this process, though, and it should become fairly seamless once you have things figured out and become comfortable with the process. In general, for development teams, there is still work to do outside the function itself, but the payoff on the production deployment side can make it worthwhile.

Interested in working with a partner who can help you navigate serverless computing? Contact Mosaic today!