Serverless Series Part 1/3 – Give me code or Give me death (by infrastructure)

Serverless technology represents a seemingly monumental shift in computing. Let’s get you dangerous.

By Ravi Lachhman
September 5, 2019

Patrick Henry’s famous outburst “Give me liberty or give me death” in 1775 might not have much to do with technology but was instrumental in getting Virginia into the Revolutionary War. With Virginia joining the battle represented a shift in the tides towards forming the United States and the start of the Revolutionary War. For those unfamiliar with America’s story, like so many other nations wanted autocracy and to be free of tyranny. Since this is a technology blog, what if modern day developers wanted to be free of the tyranny of infrastructure?

Free me serverless!

The big allure of serverless is that as software engineers we do not have to worry about infrastructure. Knowing where hard work is running has been historically important as what you are running. If you look at the evolution in the JAVA/JEE market, years gone by you would build to an application server. The tunings of that application server would be important and as a software engineer have to take this into account and also iterate on items on a specific schedule because of the gatekeepers. 

To get your application into production there historically has been gatekeepers which requires you to be in lock step with those teams. Those who keep the infrastructure running and tuned. In the JAVA/JEE world this would be your Middleware Engineers. There has been a lot of strides making workloads more generic and with the advent of containers and cheaper compute infrastructure, scaling workloads with generic infrastructure is becoming easier. Still there is a lot of infrastructure to get our code into some consumable fashion for example Kubernetes if we are deploying a container. 

With serverless or functions, you are able to run your code whenever you want. Imagine you are always on your local machine / laptop and don’t have to wait for a lengthy build to run what you just wrote. The low overhead of serverless implementations means that you typically spin up a serverless invocation per user or system request. Stretch your imagination a little further, what if you can have multiple people access your code you just wrote and just run your code; that my friend is serverless.

Your first serverless

There are certainly options in serverless / function-as-a-service providers but for our example we will use the very established Amazon Web Services Lambda. Serverless functions typically have a three party lifecycle; trigger, work, and output. The trigger is what calls / invokes your code. In our example we will just hit a URL. The work is all your hard work, aka the magic or function that you want to execute. The output is the result of your hard work; could be triggering something else or persisting items into a database for example. 

Like always can watch this video or go through the blog, or both!

Navigate to AWS

Don’t worry, our example will be in the free tier of AWS Lambda. If this is your first time using AWS, this example is pretty easy. Head to the AWS Console (this is how Shadow IT rises) and log in or sign up. Like buying everything off of Amazon.com? Your Amazon.com credentials can be used on Amazon Web Services. Note that spinning up AWS services is pretty easy. You might inadvertently start something that costs money. Reeling in cloud cost is a challenge for lots of organizations and by how easy this example is can certainly see why folks reach for the public cloud.  If you stay to the example and spin down the resources you will be ok and be cost free.

Fire up the AWS Example

Once you are in the console, can check out the Serverless Microservice Example. We will leverage the quick start.

AWS Management Console

Though if that example leaves the console quickstart area, can always browse to the Lambda Service under Compute and search for blueprint when creating a new Lambda.

Lambda blueprint search

The path of least resistance to your Lambda

We can use the defaults in the quickstart when we are learning.  We can call our first function “my-first-function” and fill out some defaults. The DynamoDB policy [the example Lambda interacts with DynamoDB] should be selected by default. 

Create Lambda from blueprint

The Trigger

Using the defaults to be wired through Amazon API Gateway which will be created for us. We will use the “Open” security for now. With the quickstart we could lock down with an API Key or IAM. Make sure to delete your function when you are done and you should be ok with “Open”.

API Gateway trigger

Some Node.JS

The quickstart template is a NodeJS Lambda. If you have not used NodeJS before, this is an easy way to learn without having to set up NodeJS on your machine and instantly see your results.

NodeJS Lambda

Hit the orange button

Hit “Create function” and you are off to the races.

Click to let the magic start

Inspect with your first function!

Within a few moments your function and a few backing services [Amazon DynamoDB and Amazon CloudWatch] should be spun up also. Sweet!

Lambda Designer

You can click on the API Gateway Box and get your endpoint address.

Your Serverless URL

Interact with your first function!

With your trusty API endpoint up and running, you can start to interact with your first serverless function. Can interact in a few ways by sending HTTP requests. You can leverage your favorite API testing tool of choice such as Postman or SoapUI

Below I am using Postman. Simple to sign up and use. Can wire a GET request to your endpoint. Add the query string “TableName” and a table name which is the below line of NodeJS in the Lambda.

Line of NodeJS we are testing

Enter your Lambda’s API address, add the “TableName” query parameter to the Get request and hit send. Bam there you go. 

Though we get a 400 response?  That is fine, we don’t have any tables in DynamoDB. Can inspect the NodeJS code on how the HTTP Puts work. Congratulations, you just interacted with your first Lambda! 

Postman 400 Success!

You can certainly can have fun adding database entries with your new NodeJS to DynamoDB Lambda. If you want to get really fancy can learn how DynamoDB Streams wire to Lambda to deconstruct how the example was created. Can validate in AWS CloudWatch that we had an invocation. 

 

CloudWatch

Clean up

Making sure we don’t get an AWS bill, can navigate to the services that were spun up and delete items. Go to the AWS Console and select each service. In this case will be Lambda, API Gateway, and IAM. 

The Lambda:

The API Gateway [click into the API name]:

Delete API URL

The Lambda IAM Role:

Delete IAM

That should get rid of the attached resources of your first Lambda and API Endpoint. Like the serverless ninja you are now, you created a Lambda and deleted a Lambda in minutes.

Up your serverless game with Harness

Now that you have created your first Lambda, you can up your game with Harness. Having a Lambda as part of your pipeline is critical. Lambdas are easy to change and re-deploy so could be easy to forget our SDLC discipline. 

Doing something cool with serverless? We would love to hear how creative you are on the Harness Community. Check out our Lambda Documentation and see how Harness can supercharge your and your team’s experience with serverless. If you don’t have a Harness Account, can sign up for a free one forever. 

Cheers!

-Ravi

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of