[laumars]

I don't disagree with you that serverless is a step backwards if you want control about your running platform but your debugger example can be argued away by the fact that you shouldn't really be debugging a live platform. If your code is portable enough to run "serverless" then you should be able to spin up a docker container or whatever and run the same tests in there.

I think the issue is some people see "serverless" as an all or nothing scenario which it really isn't. Some problems are solved well with serverless and some are not. It's like the container vs virtual machine argument. One isn't designed to replace another - they're just different tools for solving different problems; each have their own strengths and weaknesses.

[Zelphyr]

How do I debug locally/on Docker with services like SNS and ElasticTranscoder? I know there are emulators but those have gaps in services that providers like AWS offer. Not to mention, I'm debugging with an emulator and not the real thing.

[scarface74]

I can’t speak for ElasticTranscoder, but there is nothing stopping you from running your lambda function locally and still connect to all of the AWS services.

Just like people have been calling their controller actions from test harnesses for ages to test their APIs. You can call call your handler the same way.

At the end of the day, AWS is just passing you a JSON message. You can call your lambda function manually with the same JSON payload locally.

[laumars]

This is exactly how we test our lambda code that call AWS media encoders

[laumars]

You could run the docker container on an EC2 instance or have an SSH bastion / VPN tunnel between yourself and your AWS VPC.

I tend to opt for the SSH tunnel route for personal projects but use OpenVPN with a secrets management (eg Vault or AWS's new key store) for professional projects (ie when you have several people on your team).

AWS is versatile enough that you do actually have several options available to you.