4 ms·

> Perhaps it's just because I'm familiar with setting up and provisioning servers I'd be inclined to say that may be the case. Our codebase leans heavily on La

> Perhaps it's just because I'm familiar with setting up and provisioning servers I'd be inclined to say that may be the case. Our codebase leans heavily on Lambda, primarily as a wide stage in our data pipeline. And I love it. Using a configuration file in S3 - or any other means of dropping a text file on AWS - is barely more complicated than open("file.txt"). The true frustration is when you need to work with files beyond your memory limits, but even that can be mitigated by divide and conquer approaches. That said, the API Gateway is annoying in that it makes complex things impossible and simple things more configuration than they need. Yet, I'd still take it over actually standing up a server.

falcolas 10y ago
> is barely more complicated than open("file.txt") Well, that depends. First, you have to set up the IAM roles to access the bucket which owns file.txt. Then you have to ensure that "file.txt" is properly shared between accounts if you separate production from staging from development. Then there's three lines of code to set up a client, pull the file, and read the contents. If it's an encrypted file, you also get to do a bit more setup work to ensure that you're using the v4 signature in the library, since it defaults to v3 signatures. There's also the additional error handling and points of failure to account for. The requests are far from instantaneous as well, so you need to set up an out-of-band cache for the contents of the file if you plan to use it with every call of the lambda function. Is it obtusely hard? Of course not. Is it as simple as `open("file.txt")` (or more appropriately `os.environ["FOO"]`)? Not by a long shot. I have a feeling that our differences in opinion have more to do with the environment in which we run our lambda functions than what the lambda functions are doing. Once you move beyond a single region on a single account, things get a lot harder.
- noobiemcfoob 10y ago
  I may be overly simplifying working with a file, but I'd still argue you're over-complicating it :P You're hitting on a good point with Lambda though, namely the stateless aspect. To get the most out of Lambda, you have to adopt a more Functional-based programming model. > Once you move beyond a single region on a single account, things get a lot harder. I could see that. I'm working in IoT, primarily connecting lots of dumb devices to small translation layers with minute data massaging along the way. In this type of low-intensity environment, the flexibility Lambda (AWS in general) gives you is tremendous. The second performance(/latency) becomes a primary concern, it's easy to see that trade-off become untenable.

falcolas 10y ago

> is barely more complicated than open("file.txt") Well, that depends. First, you have to set up the IAM roles to access the bucket which owns file.txt. Then you have to ensure that "file.txt" is properly shared between accounts if you separate production from staging from development. Then there's three lines of code to set up a client, pull the file, and read the contents. If it's an encrypted file, you also get to do a bit more setup work to ensure that you're using the v4 signature in the library, since it defaults to v3 signatures. There's also the additional error handling and points of failure to account for. The requests are far from instantaneous as well, so you need to set up an out-of-band cache for the contents of the file if you plan to use it with every call of the lambda function. Is it obtusely hard? Of course not. Is it as simple as `open("file.txt")` (or more appropriately `os.environ["FOO"]`)? Not by a long shot. I have a feeling that our differences in opinion have more to do with the environment in which we run our lambda functions than what the lambda functions are doing. Once you move beyond a single region on a single account, things get a lot harder.

noobiemcfoob 10y ago
I may be overly simplifying working with a file, but I'd still argue you're over-complicating it :P You're hitting on a good point with Lambda though, namely the stateless aspect. To get the most out of Lambda, you have to adopt a more Functional-based programming model. > Once you move beyond a single region on a single account, things get a lot harder. I could see that. I'm working in IoT, primarily connecting lots of dumb devices to small translation layers with minute data massaging along the way. In this type of low-intensity environment, the flexibility Lambda (AWS in general) gives you is tremendous. The second performance(/latency) becomes a primary concern, it's easy to see that trade-off become untenable.