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

101–110 of 117 posts

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

#101

Post by TheDong »

The comment about meltdown is wrong.

> You had to patch your containers and your instances/servers, but you didn’t have to patch Lambda functions.

This was right after talking about Fargate. Let's compare what you do and don't have to patch in Fargate / Lambda:

Kernel / host OS: Lambda and Fargate patch that for you without any work. This is the more important patch.

Container bins/libraries: some programs, like Chrome, which had JIT, could be exploited to read memory of that same process. In the case of lambda and fargate, you only needed to patch containers/zips that contained such programs.

If you were using something like 'serverless-chrome'[0] in lambda, you would have to update your zip file to get Chrome's workaround for meltdown. If you had a fargate container with headless chrome, same deal. It's practically identical in the cited case of meltdown.

There are many cases (like glibc or openssl vulnerabilities) where containers need to be patched, but lambda can patch it for you ... but in the case of kernel exploits, fargate and lambda can patch equally well.

[0]: https://github.com/adieuadieu/serverless-chrome

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

#102

Post by csallen »

breatheoften wrote: post #74
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…

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 th…

Is 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?

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

#103

Post by fapjacks »

dasil003 wrote: post #8
moondev wrote: post #6

Earlier quoted context omitted.

No doubt! It seems antiquated and repetitive

Well that's what CI/CD is for. It's not any different than building and pushing a new docker image.

I keep hearing responses like this about various aspects of serverless, but it makes no sense. If a lot of these serverless operations are "not any different" than various Docker operations, why should I be spending time and money to couple my application to AWS Lambda versus simply running the container myself? Why shouldn't I just deploy a container (pod) for my code if I'm already running kubernetes?

The more I hear people defending serverless, the more it feels like they're asking people to voluntarily increase their time and money costs, learn hyperspecialized and nontransferable skills, and make their application far less adaptable. All of this while accruing tons of technical debt for a pittance of some convenience.

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

#104

Post by phamilton »

electricEmu wrote: post #73
thinkloop wrote: post #61

Earlier quoted context omitted.

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.

Lambda support blue/green and all sorts of flexible stuff:

    aws lambda update-alias --function-name myfunction --name myalias --routing-config '{"AdditionalVersionWeights" : {"2" : 0.05} }'

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

#105

Post by dasil003 »

fapjacks wrote: post #103
dasil003 wrote: post #8

Earlier quoted context omitted.

Well that's what CI/CD is for. It's not any different than building and pushing a new docker image.

I keep hearing responses like this about various aspects of serverless, but it makes no sense. If a lot of these serverless operations are "not any different" than various Docker operations, why should I be spending time and money to couple my application to AWS Lambda versus simply running the container myself? Why shouldn't I just deploy a container (pod) for my code if I'm already running kubernetes ? The more I h…

To be clear, I'm not a proponent of serverless at all. I'm just pointing out in isolation that zipping and shipping something is not antiquated, it's just a methodology for shipping code. I guess it feels old because it's not wrapped up in a lickable CLI and online docs with great typography, but it's not fundamentally flawed.

To your point, I don't see any value of serverless over containers today. We are now at a point where container orchestration is mature enough that it's a sane default choice, but it took a while to get here. Serverless is where containers were 5-7 years ago (depending how you squint).

Will serverless ever be a credible replacement for containers? That depends on the vendors working out a whole lot of details. In theory, with the right services around it, serverless can be lighter than containers because they can fully control the baseline environment and build more into it, but that is also less flexible than containers. How much standardization will be possible between vendors? If the price comes down and the tradeoffs look good enough then I could see it eating into container marketshare, but I'm really not holding my breath. It's still 100% in the hype phase.

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

#106

Post by byronmagnusson »

nudpiedo wrote: post #78
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.

Bingo!

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

#107

Post by subway »

fapjacks wrote: post #100
nzoschke wrote: post #36

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

If you're just working with a golang binary, you shouldn't be using an Alpine container, you should be putting the binary in an empty, from-scratch container. Go binaries are typically static and don't need distro or the libs it provides in their container.

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

#109

Post by zaarn »

nzoschke wrote: post #97
mohaine wrote: post #86

Earlier quoted context omitted.

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 ab…

I can take my (docker) containers and VMs, move to an entirely different cloud provider, simply update DNS to point to the new IP and everything is up and running within 5 minutes of the host booting.

On AWS Lambda, I can't just rip out my entire infrastructure and move elsewhere. I'm stuck with AWS Lambda until I rewrite my functions to not rely on AWS Lambda and AWS Services.

If my hoster decides they don't like me anymore, I can move my business elsewhere within the hour. Can you move AWS Lambda to another provider within the hour?

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

#110

Post by gardnr »

manigandham wrote: post #51
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…

Serverless is nothing more than PaaS - just at a more granular deployment/operation/billing/analytics scale. PaaS has always had a certain amount of lock-in because it's an abstraction, as any abstraction naturally does. There are also some abstractions like Kubernetes that are neutral yet also managed with extras by all the providers which is a nice middle ground. None of this is new or groundbreaking other than the…

I agree with you about the term "serverless" being silly, especially in a time when all the various forms of decentralized architecture are beginning to come of age. It makes it difficult to find information on "serverless webrtc signalling."

While other auto-scaling PaaS exist, the granularity of the lambda pricing model is fairly new and groundbreaking. A service can be launched that may see very little use and just costs pennies to test out during its initial phases. That same service will scale exponentially rather easily in comparison to a similar deployment on a traditional server.

Post reply on HN