Thoughts on the serverless development experience

In no particular order.

2 min readMay 19, 2017

This was a tweet thread that became unwieldy.

I could be doing things very wrong, so feedback to improve is very welcome.

Debugging is hard.

I write a lot of tests. My advice for everyone working with serverless platforms is to try and side-step the need to debug in “the cloud” as much as possible. Small functions with concise, testable interfaces. Nothing to see here, it’s all programming.

Even with good tests I still find that I often end up resorting to console.log to understand the flow of events through the system.

Add console.log statements, push, trigger an event, dig around in CloudWatch to find the log.

It would be amazing to be able to hook a local debugger into the function.

Reverse Engineering Events

I find myself reverse engineering the events a lot. My current side-project is a Lex app for the Chatbot Challenge, and I’ve found myself triggering events and capturing the output so I can feed them into tests and the code.

AWS does a pretty good job with API documentation, but it’s often very abstract and doesn’t have actual samples of what will be hitting your app.

Note to self: perhaps publish my library of sample events

Deployment is slow

Even with a small stack, deployment can take a couple of minutes. It helps to break resources out, but the trade off is increased dependencies between CFN stacks.

CloudWatch is slow

Minor issue, but the lag between an event and it’s appearance can really break dev flow. Hit refresh a bunch of times.

CloudWatch is not for analysis

CloudWatch is ok if you can trigger a single event and go directly to the lambda stream. If you are trying to correlate across streams, you’re are going to have a bad time. So now you need Elasticsearch/Kibana or something.

And I know x-ray is a thing, but I haven’t got there yet.