3 ms·
If anything — 50 LoC seems like it might even be an overestimate. I use a wrapper function around all my lambdas that deals with translating from the aws http
by breatheoften 9y ago
If anything — 50 LoC seems like it might even be an overestimate. I use a wrapper function around all my lambdas that deals with translating from the aws http headers to an application standard, asynchronously retrieves a config object, and converts promise based business logic to the aws callback format. The actual business logic
is then written almost entirely in terms of the business domain. The wrapper is less than 50 lines and extremely easy to write. Making an equivalent wrapper for another cloud function provider would be easy ...
Someone thinking the need to adapt the input parameter format to achieve provider portability is by itself enough reason to add docker to the application stack is making a huge mistake in accessing the relative cost of these components ...
I don’t think deploying containers to different providers is anymore standard than the differences involved in deploying cloud functions to different providers so it’s not as if using docker would actually give a more uniform multi-provider deployment model ...
- csallen 9y agoIs your wrapper code open source? If so, mind sharing a link? EDIT: I'm actually less curious about the code, and more curious about how you're sharing code between different Lambda functions. Did you publish an npm package? Are you just repeating the code? Symlinks?
- breatheoften 9y agoThe wrapper isn’t open source. The project is node (typescript) and uses serverless [serverless.com] for packaging and deployment. Serverless allows deploying multiple lambdas with entry points exposed from an npm package using cloud formation with standard code sharing practices applying — that is it’s easy to share code between entry points if all the entrypoints are defined in one serverless config file (one serverless config file corresponds to one cloud formation stack)... It’s a bit more work to share code between stacks with serverless tho ... You either have to put shared code into a separate npm module and depend on that module everywhere you need the shared code (often incidental complexity for simple or unstable code!) or use symlink patterns that work with the grain of how the serverless bundling process works... I actually created an issue suggesting a serverless feature to ease this a few months ago https://github.com/serverless/serverless/issues/4124 https://github.com/serverless/serverless/issues/4124. In that somewhat long feature request I describe the symlink pattern I’m using for easily sharing code and compilation contexts between stacks... I’m still using that pattern — it’s not terribly fun to explain to new developers on the project but it works well without a lot of gotchas so far ...