Sure you can do that, and that works ok in some scenarios. But there are some problems.
In a scenario like:
> Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done.
Ok, so you got AWS set up to fire your Lambda when an object is created in an S3 bucket. You decide you need another "stream", we'll call it, so you start dumping stuff into another prefix. How does one go about testing that the right function is invoked?
A smart person will probably say that they have a dev environment and they manage infrastructure with Terraform. Great! That's probably the best solution there is.
But that still leaves a massive, glaring problem: it's quite difficult to implement any sort of automating testing of this Lambda function setup. In all likelihood, you're probably just pushing a file up to an S3 bucket in dev and watching it run through.
Let's say you made a pass at automated testing, and let's continue with the example of creating resized avatar images. The end product of this Lambda resizing process is probably a different file somewhere in S3. So you fire off the automated test and it fails. How did it fail? Well, if you're lucky, the Lambda function actually had an execution that errored out. Then it's up to you, or your automation, to look up logs in CloudWatch to troubleshoot the failure. What if it didn't error out, and instead just put the file in the wrong place?
This kind of stuff is where Lambda falls over. Running Docker images on EC2 in some fashion puts way more sanity around testing as a whole. You have real Docker artifacts that you ran tests in, not just some zipfile abomination that does nothing to create a good local development environment.
I'm not gonna try and say that it should replace containerized applications (I would choose those 9 times out of 10 given the choice). Unfortunately, there are cases where there isn't a choice or Lambda is still a good choice (like maybe the grandparent's image resize thing, probably depends on a lot of things).
I tend to think of a Lambda as a custom piece of cloud infrastructure. So, in addition to unit tests, I just test them like I would any other Terraform module. I use Terratest to deploy a stack containing the resource under test and a surrounding harness. In this case, maybe the Lambda, a source bucket, a destination bucket, a DLQ, logs, etc. Then execute my test cases, poll for results, do assertions, etc. When it's done, Terratest destroys the stack.
In a scenario like:
> Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done.
Ok, so you got AWS set up to fire your Lambda when an object is created in an S3 bucket. You decide you need another "stream", we'll call it, so you start dumping stuff into another prefix. How does one go about testing that the right function is invoked?
A smart person will probably say that they have a dev environment and they manage infrastructure with Terraform. Great! That's probably the best solution there is.
But that still leaves a massive, glaring problem: it's quite difficult to implement any sort of automating testing of this Lambda function setup. In all likelihood, you're probably just pushing a file up to an S3 bucket in dev and watching it run through.
Let's say you made a pass at automated testing, and let's continue with the example of creating resized avatar images. The end product of this Lambda resizing process is probably a different file somewhere in S3. So you fire off the automated test and it fails. How did it fail? Well, if you're lucky, the Lambda function actually had an execution that errored out. Then it's up to you, or your automation, to look up logs in CloudWatch to troubleshoot the failure. What if it didn't error out, and instead just put the file in the wrong place?
This kind of stuff is where Lambda falls over. Running Docker images on EC2 in some fashion puts way more sanity around testing as a whole. You have real Docker artifacts that you ran tests in, not just some zipfile abomination that does nothing to create a good local development environment.