Skip to main content

Serverless applications should be debugged without... Servers!

St Augustine with the child, who was trying to empty the ocean into the small hole
image source
"The child had dug a little hole in the sand, and with a small spoon or seashell was scooping water from the sea into the small hole. Augustine watched him for a while and finally asked the child what he was doing. The child answered that he would scoop all the water from the sea and pour it into the little hole in the sand." [Story]

Trying to mock the vast AWS cloud on your laptop?

I feel that trying to mock the vastness of the Amazon Web Services (AWS) Cloud, or the Google Cloud Platform (GCP) on a tiny laptop of a developer, is similar to what the child in the story was trying to do.

Modern problems require modern solutions. The way software was built on developer computers, and then bundled with command line build tools and pushed to remote application servers is now history. People still try to find ways to put lipstick on pigs, and work with traditional build-locally, push to remote style command line tools when working with the cloud.

"Containers enable you to take the existing paradigm and move it forward, whereas serverless is an entirely new paradigm" [Link]. I do not find fault with people who still work with containers taking the traditional / legacy approaches to debugging. But I strongly believe that:

Serverless applications should be debugged without... Servers!

Locally debugging Lambda functions

Earlier yesterday, I noticed a tweet from Forrest Brazeal about "stackery local invoke"

Reading through the article, I was wondering why would I want to install docker and multiple other tools, just to be able to debug a serverless application posting to SQS on the AWS Cloud?

Since the code used was not complicated, I thought its best to take [almost] the same code, to show how you could debug it - while its executing live on AWS. Best of all this is without installing a single piece of software to bloat your computer! You will only need the Chrome web browser if you want to debug, or can use any other standard web browser for using all other functions of the Sigma IDE for Serverless computing. Yes, it is the age of the cloud, and we shall not try to empty the sea into a hole.

Getting started with Sigma

Just create an account for free at, and provide your AWS keys to get started. Since you will save your code to GitHub or BitBucket etc, you could link them in too for a seamless experience. But for this live debugging demo, I am not even going to commit the code. I do have a SQS queue created in my AWS account named 'sqs' to begin with. So I create a new project SQSDemo as follows.

The magic of Drag-and-Drop, but with the full power of code

Then I am presented with a new Lambda function, and I define a variable messageBody to hold the text I want to write to my SQS queue. I select SQS from the resource palette and choose the existing queue named 'sqs' and select the operation as Put message and inject. 

No need to remember cloud APIs or keep looking up reference documentation

Thus I do not have to remember the SQS APIs as Sigma injects the necessary code - which I can update and customize further, as the full power of code is available to me, instead of some graphical set of drag-and-drop icons. This is true for all of the supported resources of both AWS and GCP in addition to a few other APIs. A couple of our white-labeled Enterprise deployments - both for the fintech industry - included dynamic support to include third party API's via drag-and-drop, with dynamically generated UIs presented based off the Swagger definitions of the APIs.

Running a Serverless function without local build and remote deploy

I put the callback line where its supposed to be, and create an empty test event through Sigma IDE itself and execute the function. Note that there is not even a delay of a few seconds for my Lambda function to execute.. I didn't even have to save it yet - but it executes on my own AWS account and inserts the payload into my SQS queue.
The Sigma Test mode is instantaneous! Just write code and run without wasting even seconds

Testing code as you type!

The Sigma IDE is a Serverless application itself! So there is nothing between you and your code in your web browser and your target cloud platform AWS or GCP. So what you see is what you get, and what you type is what you execute - where you want - in AWS or GCP! Code changes does not need you to rebundle, redeploy or nothing to "re-" do.. just change the code and run while in Test mode.
I can see the console log output right at the bottom of my IDE under the Sigma Trail, and I do not need to open up the AWS console and keep looking for cloudwatch logs. To check the payload of the SQS queue we posted, I'll show it on the AWS console.

Now its time to debug a Lambda function live on AWS!

Next I debug the Lambda function and I'm presented with the Chrome Developer Tools link to copy into another tab of my Chrome browser, and the Lambda function is presented to be live debugged with all that I can ask for. I create a break-point just before I publish to SQS, and resume program execution. At the break-point, I change the text of the payload to "Hello Live Debug!" and let the rest of the program execute.

Step-through debug of Lambda function live on AWS
I can see the output on my Sigma Trail, and I can verify the message in SQS via the AWS console.

So that's it! If debugging Serverless functions live on the cloud is not the future, I do not know what the past is :)


The SLAppForge Sigma IDE announced first class support for live debugging of Lambda functions on AWS earlier in July. Our work was based on the excellent research of Rob Ribeiro and the team at Trek10. Thank you guys!


Popular posts from this blog

Write a Lambda function, Test it instantly and Debug it.. [Video 10mins]

I just published a 10 minute YouTube video about debugging Lambda functions live on AWS. Check it out below. I'm walking you through an example where we show that you do not need to follow the legacy approach of building locally, bundling and pushing to the remote cloud - that was what you did when you create a J2EE application ages back! The cloud is not just a different machine, but a living collection of live resources. You do not need to download docker images and loads of applications to use the cloud - just use your standard web browser!