At Cronitor we&#x27;ve just finished building out lambda infrastructure for a fan-out where I would otherwise use a worker application and supervisord. Some of this is lambda specific but I think it might be interesting nevertheless.<p>Lambda has a lot of strengths, and it gives you solid primitives like immutable versions, version aliases&#x2F;pointers and stateless functions.
The problem I had was that it didn&#x27;t give me any more than that. Here are just a few of the things we had figure out and then build ourselves:<p>1. The development workflow. How can I get a REPL workflow going that doesn&#x27;t make me go crazy.<p>2. Deploys and Rollbacks. How can we safely deploy and rollback, especially in cases where you have the same lambda function in multiple regions and each region is at a different published version (because the version number is monotonically incrementing)<p>3. Permissions and Policies. The broad strokes are clear. But you want your S3 bucket or SNS topic to trigger lambda? Get ready to spend an hour trying to figure out what you&#x27;ve done wrong and what&#x27;s missing from the vague directions.  Hope you get that REPL flow solid first.
In the end, we built several scripts (create_build, publish_version, promote_to_prod, etc) and we use these directly during development and from a Fabric-based deploy script. When I have time I plan to release this tooling open-source.<p>If I had to do it all over again, I wouldn&#x27;t. And I wouldn&#x27;t use Cloud Functions. I would just use a t2.small instances with a simple worker.