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

71–80 of 117 posts

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

#71

Post by electricEmu »

zapita wrote: post #67
electricEmu wrote: post #55

Earlier quoted context omitted.

Why would I split, write, and deploy an vendor cloud function for every cloud provider when Docker moves between them? My team ditched serverless functions. We're better off without them.

Wouldn't it be ideal if Docker (and other independent platform vendors) added function support? In my mind "cloud functions" are easily implemented on top of containers. Then we would get the best of both worlds.

It wouldn't, to me.

I've had to answer many questions about delays in serverless functions that didn't come up with Docker. Serverless doesn't have the introspection necessary to answer performance questions.

What if Docker supported functions? I'd ask what we gain trading a main loop for only bindings. Similar bindings are made either way.

I honestly wish cloud providers would make their core SDKs as easily composable as their serverless offerings.

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

#72

Post by electricEmu »

mateuszf wrote: post #63
electricEmu wrote: post #55

Earlier quoted context omitted.

Why would I split, write, and deploy an vendor cloud function for every cloud provider when Docker moves between them? My team ditched serverless functions. We're better off without them.

Because then every single functionality will scale independently as needed. No need for orchestration.

AWS and Azure offer cloud hosted Docker support that scales independently as needed. Both can orchestrate Docker with similar interfaces to functions.

What's the difference? Scaling isn't one.

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

#73

Post by electricEmu »

thinkloop wrote: post #61
electricEmu wrote: post #55

Earlier quoted context omitted.

Why would I split, write, and deploy an vendor cloud function for every cloud provider when Docker moves between them? My team ditched serverless functions. We're better off without them.

Do you manually manage the infrastructure (keeping instances hot/cold, updates, scaling, etc.)? If so that's a lot to consider.

Containers are generally managed similar to serverless.

AWS drains connections and workloads on container deployments. I set the same rules to scale either.

Containers offer flexibility that serverless doesn't for implementing hot/cold, blue/green, n running with n+1, etc.

So, additional flexibility with the same considerstions.

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

#74

Post by breatheoften »

staticassertion wrote: post #27
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…

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…

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 ...

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

#75

Post by mullen »

dev1n wrote: post #30
Shoothe wrote: post #24

Earlier quoted context omitted.

I can second this. I wanted to write a simple provisioning tool a while ago that sets up HTTP endpoint on API Gateway and forwards the call to Lambda and the process was extremely complicated.

People (as in I) would pay good money for this tool.

Just use Zappa.

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

#76

Post by nudpiedo »

I feel it is like reinventing executables, the dumb way.

We can compare that with ELF binaries or remote procedure calls when someone else maintains the OS and makes sure that the infrastructure scales. Actual not even executables, because it is still interpreted code, instead of being "compiled" it is packed and distributed with a spec much less precise than a typical platform. Just because someone has a machine ready to be deployed on and scale ad infinitum.

Am I the only one who finds that a dumb protocol for a remote call? Could someone point on which part is this a smart badass thing? Perhaps it is just a weird "renascence of Operating Systems"?

Edit: I still think that we got here because it was too much work to learn about pre-existing technology or hire an expert and it was more fashionable/easy/cool/sexy to kick ass and move on.

P.S. Sorry for this sudden rant

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

#77

Post by etaioinshrdlu »

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.

S3 supports reading ranges of bytes. It might not always be a great idea for performance.

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

#78

Post by nudpiedo »

chapill wrote: post #64

I kept waiting for the author to say, "Surprise, it's a jar file. Jars are just zips, and lambda supports Java." Then I realized author really was reinventing wheels for the reader who probably doesn't know what Java is.

I am totally with you... I think we are going backwards in technical choices just because some people had pain-points learning pre-existing technology or did not know how to deal with infrastructure. But if people pays for it, it is a market I guess.

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

#79

Post by not_kurt_godel »

nine_k wrote: post #50

I keep being dazzled how what's basically "cloud CGI" is such a runaway success. Utter simplicity beats many considerations. (For those who did not write web apps in 1990s: CGI here is https://en.wikipedia.org/wiki/Common_Gateway_Interface )

Why is this a surprise? CGI is a great model for server programming. Lambda provides the same model packaged in a way that is enormously more convenient and powerful.
Post reply on HN