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

Keep Reading

  • A Dev’s Guide to Cloud Cost

    A Dev’s Guide to Cloud Cost

    CI/CD Evangelist Tiffany Jachja demonstrates our Cloud Cost Management solution, […]
  • Cloud Cost 101

    Cloud Cost 101

    CI/CD Evangelist Ravi Lachhman demonstrates our Cloud Cost Management solution, […]
  • Breaking Down the Continuous Delivery Ecosystem

    Breaking Down the Continuous Delivery Ecosystem

    Achieving Continuous Delivery allows us to enable the DevOps lifecycle where we can continuously deliver value while empowering teams, reducing errors, and lowering stress. This blog post shares a playbook for CD.