Technology and its implementation methodology evolves with time very rapidly. Cost efficiency and productivity are the key drivers of technological evolution these days. With the advent of The Cloud, infrastructure costs have been brought down significantly. Serverless technology adds icing to the cake! Serverless, or in other words “pay-as-you-go” computing, enables users to not pay for infrastructure while apps are sitting idle.

AWS Lambda and serverless computing have become synonymous to each other. But, that’s not exactly true. AWS Lambda is a compute service on the AWS cloud provider. While serverless stands for any and every service you can use to serve your app without managing your own servers. These services are numerous on AWS, like Kinesis, S3, API Gateway and of course Lambda. The same applies to other cloud providers such as Azure and Google Cloud!

Getting back to the gist of it. If you choose to use AWS Lambda to create functions or any serverless architecture based service, you will have to deal with some “trade-offs”.

To name few, you lose some flexibility. Mainly because you cannot connect to the instance, like you would with let’s say EC2. But the main issue is the difficulty to monitor issues, diagnose where they are happening and debug them. Considering these limitations, this article will cover how the health of your AWS Lambda functions can be measured and improved.

Before moving on let’s just mention some positive trade-offs. The main upside is that you do not have to manage any servers. You just deploy the code, and the Cloud provider does the rest. You don’t have to scale anything, because it will auto-scale to keep up with spikes in usage. Meaning, you can sleep at night and not worry about downtime. I like sleep. Very much.

#serverless