Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Lambda and .zip is a recipe for serverless success

medium.com

Post reply on HN
Print view View original

41–50 of 117 posts

Re: AWS Lambda and .zip is a recipe for serverless success

#41

Post by dev1n »

nzoschke wrote: post #39
dev1n wrote: post #17

Earlier quoted context omitted.

API Gateway is the literal manifestation of the worst product I have ever had the misfortune of configuring. This is mostly due to AWS's incompetence at delivering any semblance of working documentation around the product. Looking forward to their new "open source" documentation.

Check out the Serverless Application Model (SAM): https://github.com/awslabs/serverless-application-model All of the manual configuration of API gateway vanishes because it builds up an implicit API gateway from your functions and event mapping config. You can see a boilerplate SAM config here: https://github.com/nzoschke/gofaas/blob/master/template.yml I'm hacking on CORS today and with SAM it's 2 lines of config to…

I have just finished up using SAM and it is miles better than trying to wire API Gateway and Lambda together. Setting up an authorizer with cognito took some time to find the right examples and get the swagger right but yes I am a fan of SAM.

While we're on the subject, Cloudformation could definitely use some work too. AWS, please tell me what line the template failed at. We had to use the swagger extensions to integrate cognito and those were failing because of indentation errors, but it just kept complaining about invalid swagger 2.0 definitions. That is just so gross.

Re: AWS Lambda and .zip is a recipe for serverless success

#42

Post by mankash666 »

fapjacks wrote: post #9

Cloud commoditized datacenters. People then tightly coupled their applications to cloud providers like AWS. After some time, containers came along and commoditized the cloud providers. Those applications no longer needed to be tightly coupled to a specific cloud provider. This reduced both costs and the risk of being invested in a single cloud provider. Serverless (AWS Lambda) is just the cloud's way of trying to "de…

AWS and other managed FaaS offerings allow you to go from zero to endpoint in minutes.

You can choose to deploy your own open source Faas framework (like openwhisk or open-faas) on one of these clouds, but YOU will have to:

1. Manage scaling of underling EC2s

2. Manage security patching of both the docker and underlying OS

3. Setup whole lot of configs

4 manage optimizations

With a managed FaaS you're trading ops for more dev time, but someone has to be paid for the ops - it isn't free

Re: AWS Lambda and .zip is a recipe for serverless success

#43

Post by moduspol »

paulgb wrote: post #31
staticassertion wrote: post #27

Earlier quoted context omitted.

I just don't get the "lambda locks you in" thing. You write a server the same way you always would, but like an extra 50LOC exists to make it work on lambda. So if I wanted to deploy elsewhere what would the big deal be? Lambda also provides a lot more than containerized services, as the article mentions - I no longer have to patch my system, which is a huge operational/ security burden that many companies struggle w…

I agree, but in my experience, the lock-in with using Lambda is that you become integrated with other Amazon services (like S3 and DynamoDB) that are harder to replace if you abandon AWS entirely.

To me, that's the opposite of lock-in. You can leave AWS because you can move away from any one service easily without affecting the others. There are even vendors who directly implement (for example) S3's API so you have almost no code to change.

Traditional vendor lock-in is when you can't move away from (e.g.) your Oracle database because you've got a dozen different applications that will need simultaneous rearchitecting if you ever want to get away from it.

Re: AWS Lambda and .zip is a recipe for serverless success

#44

Post by bigtunacan »

faitswulff wrote: post #22
TAForObvReasons wrote: post #18

Does anyone have experience with alternatives to AWS Lambda (like azure functions)? How hard is it to switch between serverless providers?

I played with Firebase (Google Cloud) Functions recently and the developer experience was pretty good. It's like if serverless ( https://serverless.com/ ) had first party support, in the form of the Firebase CLI. Deploying was simple, the Firebase dashboard is nice. That said, I only used it for a side project, so I don't know about any pains scaling. I would definitely use it again for another side project, though.

I will second Firebase. It has really matured as a platform over the past couple of years and is a much easier service to work with than AWS.

As to the parent’s question on switching cloud providers though I think it would be non trivial.

Re: AWS Lambda and .zip is a recipe for serverless success

#45

Post by paulddraper »

_xnmw wrote: post #4
mirceal wrote: post #2

Serverless has its upsides but it also has downsides. In an ideal, pure, world it’s awesome. The problem is that your lambda function usually needs to use some sort of external resources. (It is pretty useless if you don’t interact with anything) Now you have to worry about and understand how to do access control on the said resources, how to collect the logs, how to collect metrics relevant to your code, how do you…

Right, and one of biggest downsides to serverless: reusing database connections/pools between requests. Right now the only "standard" solution offered by serverless's biggest advocates is pretty much a hack: rely on AWS's preservation of memory across some warm invocations. Basically keep it in a global variable and if you get lucky it'll still be there the next time your functions runs. [1] http://blog.rowanudell.co…

That's not really a "hack" though. Performance of lambda depends on warm processes, generally not just for connection pooling.

DB connection pooling is simpler in node.js + lambda than php + Apache.

Re: AWS Lambda and .zip is a recipe for serverless success

#46

Post by Blackstone4 »

alexcroox wrote: post #3

I actually find zipping and uploading manually a PITA. Started using the Serverless framework [1] recently and now I just run `serverless deploy --stage dev --aws-profile profilename` from my repo (which is an npm script). [1] https://serverless.com/

When they do it for you it's awesome isn't it. I've been using Apex Up. It handles API Gateway config, the zip upload, SSL certs and deployment to AWS Lambda

Re: AWS Lambda and .zip is a recipe for serverless success

#47

Post by ec109685 »

fapjacks wrote: post #9

Cloud commoditized datacenters. People then tightly coupled their applications to cloud providers like AWS. After some time, containers came along and commoditized the cloud providers. Those applications no longer needed to be tightly coupled to a specific cloud provider. This reduced both costs and the risk of being invested in a single cloud provider. Serverless (AWS Lambda) is just the cloud's way of trying to "de…

Another issue with Lambda is that everything goes off the rails if you need to do something that Amazon hasn’t prioritized yet. Let’s say you want a GRPC endpoint, web sockets, http/2, mutual tls authentication, etc. Lambda won’t help you and you’ll be left building up your own patterns for those. Once you have those patterns, then Lambda’s use cases can be satisfied as well.

Also, Lambda doesn’t provide any sla’s on container reuse. They could restart your container multiple times per second or every few minutes. You are at their mercy to keep your containers warm.

Finally, with the meltdown example, would containers actually need to be patched if the parent OS gets patched since the kernels are shared between host and client containers? With Fargate, amazon would patch the base OS and your containers would be safe as they get rescheduled onto patched nodes.

Re: AWS Lambda and .zip is a recipe for serverless success

#48

Post by reactivesearch »

bthornbury wrote: post #33
fapjacks wrote: post #9

Cloud commoditized datacenters. People then tightly coupled their applications to cloud providers like AWS. After some time, containers came along and commoditized the cloud providers. Those applications no longer needed to be tightly coupled to a specific cloud provider. This reduced both costs and the risk of being invested in a single cloud provider. Serverless (AWS Lambda) is just the cloud's way of trying to "de…

Might as well throw away the automobiles and go back to horses, they're cheaper on gas. Forget that they take more time to care for, and to learn how to ride, and how to feed properly.

I think this is a bad analogy. Containers don't reduce convenience by a significant factor. On the other hand, what you are suggesting ...

Re: AWS Lambda and .zip is a recipe for serverless success

#49

Post by skybrian »

jlouis wrote: post #37
skybrian wrote: post #21

Earlier quoted context omitted.

Yes, you can and should use random file access to load things from a zip file. For example, Go's zip package takes an io.ReaderAt interface, not an io.Reader. Using sequential I/O for this would be inefficient.

The problem here is that you mostly have a streaming interface In s3.

I'm not familiar with s3, but it seems like if you want random access for a key-value database, you should store each file under a separate key? Storing an entire file archive as a blob (in any format) and downloading the whole thing just to access one file seems like a weird way to do it.

Apparently there is "s3 select" in preview [1], but it only supports gzipped CSV or JSON.

[1] https://aws.amazon.com/blogs/aws/s3-glacier-select/

Post reply on HN