Live data from Hacker News

AWS Lambda and .zip is a recipe for serverless success

medium.com

91–100 of 117 posts

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

#91
post #62

Earlier quoted context omitted.

It certainly does seem a throwback to old managed PHP environments. No need to set anything up, just provide your PHP code over FTP and off you go!

I agree with you in principal but AWS and Lambda feels significantly more complex than that. At least when I was FTP'ing my code up to some shared host I still had a lot of control over my environment (ini overrides, htaccess, etc...) With Lambda I feel like I have very little control. There is a black box running this stuff that I have no insight into. Even worse; when things break the resulting error is often unrel…

one thing that would be great would be if it was setup in such a way that the API gateway / lambda functions had really simple, file based mappings on a virtual server that then automagically took care of deployment / scaling for you.

cp -r / symlinks could take care of the whole staging / lambda version aliasing stuff.

deployment is just scp'ing a zip file to a certain defined location.

all that insane complexity of configuring API gateway is replaced with some config.json or js file export defining what lambda to call and what permissions to use.

then to back the whole thing up you could just rsync it back to your local machine ... hmm though realistically you'd probably want to invert things and develop this whole hierarchy in a git repo that could be checkouted on that virtual server, or it could just natively understand git and branches just become the stages / alias as soon as you push them so no need to ssh in and pull.

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

#92
post #67

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.

Have you looked into Cloud Foundry? From my understanding, it can operate like a FaaS provider or like a Docker container scheduler.

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

#93
post #67

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.

Exactly. This is the goal of http://FnProject.io -- power of containers + simplicity of serverless. No managed service yet but there will be, and anyone can run the bits to create a service of their own.

I do agree with Paul about containers having a greater update surface area, but we think this is also solvable and doesn't need to be a responsibility of the developer either.

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

#94
post #62

Earlier quoted context omitted.

I agree with you in principal but AWS and Lambda feels significantly more complex than that. At least when I was FTP'ing my code up to some shared host I still had a lot of control over my environment (ini overrides, htaccess, etc...) With Lambda I feel like I have very little control. There is a black box running this stuff that I have no insight into. Even worse; when things break the resulting error is often unrel…

one thing that would be great would be if it was setup in such a way that the API gateway / lambda functions had really simple, file based mappings on a virtual server that then automagically took care of deployment / scaling for you. cp -r / symlinks could take care of the whole staging / lambda version aliasing stuff. deployment is just scp'ing a zip file to a certain defined location. all that insane complexity of…

Apex Up does something very similar along these lines.

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

#95

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…

Why functions over Docker or Elastic Beanstalk? There's more than one PaaS path. On vendor lock-in, I'm moving between clouds now. Serverless did not translate well at all. We would have saved a ton of time, and frankly had an easier operational experience, if we went with Docker from be beginning. "Ok Jill, next we need to determine how Azure Storage Account bucket calls differ from AWS S3. Oh, S3 doesn't have queue…

Wait does Azure Storage finally have events? Personal project of mine I moved from Azure to AWS simply because Azure Storage didn't have events...

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

#96
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…

It’s a cycle Depending on where you start your argument, one can be the commodity or meta commodity Your point is sort of moot Cloud for next 10 to 20 years, is still about killing old it vendors and make people not worried to put everything they own on cloud. Container or serve less is but major milestones.

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

#97
post #86

Deploying .zip files is one of my favorite features of Lambda, particularly when writing Go apps. Docker always felt wrong with Go to me. Why do I need a local VM, a Linux build service, an image registry and servers with container orchestration to deploy Go software? I understand how all this helps with "legacy" Rails or Java apps, but why can't I just throw a Go binary somewhere to run it? Lambda is exactly this. I…

Your go containers don't need anything more than your static binary, root certs, and tzinfo files. Everything else is extra.

Plus a base image, Docker build system, image registry service and Docker runtime.

Not to mention the load balancer and container orchestration to run the containers.

It's not all bad. Container tools and services are ubiquitous, pleasant to use, and support literally any workload you may have.

But throwing a zip in S3 and having API gateway send it requests is far less moving parts (at least that we have to worry about).

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

#99
post #67

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.

Check out this project: https://github.com/openfaas/faas

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

#100

Deploying .zip files is one of my favorite features of Lambda, particularly when writing Go apps. Docker always felt wrong with Go to me. Why do I need a local VM, a Linux build service, an image registry and servers with container orchestration to deploy Go software? I understand how all this helps with "legacy" Rails or Java apps, but why can't I just throw a Go binary somewhere to run it? Lambda is exactly this. I…

You don't need all of that shit, though. You absolutely can just throw a golang binary into a super minimal alpine image and run it wherever you've got a Docker daemon installed. You literally don't need any of the things you listed! Plus, it is simply untrue that "everything else is taken care of" in Lambda. There is plenty of one-off configuration to do ("toil").
Post reply on HN