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

81–90 of 117 posts

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

#81

Post by bamboozled »

nudpiedo wrote: post #76

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

I agree with this sentiment and feel the same way. I also find this is a frustrating trend in our industry in where a lot of engineers seem to be spending more time learning about "services" from specific vendors than about things like network protocols and their workings and limitations.

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

#82

Post by nostalgeek »

djhworld wrote: post #29
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 Lambda itself isn't vendor lock in. If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers. The vendor lock in creeps in more around the surrounding services that the cloud provider o…

> AWS Lambda itself isn't vendor lock in.

Can I call my Postgres deployment on Azure via AWS lambda?

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

#83

Post by jbrambleDC »

tracker1 wrote: post #80

I use containers (Docker for Windows|Mac) to create my lambda zip for dist, isn't that close enough? lol.

I actually do the same thing. Do the dependency install inside of a docker container in order to build the .zip. This is absolutely essential for compiled libraries in python or anything that involves postgresql. If you attempt to install psycopg on mac and then deploy that on lambda it will fail. So you either need a prebuilt version for ubuntu that you keep around, or you need to build in a docker container. We just build inside a docker container.

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

#84

Post by ShabbosGoy »

nostalgeek wrote: post #82
djhworld wrote: post #29

Earlier quoted context omitted.

AWS Lambda itself isn't vendor lock in. If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers. The vendor lock in creeps in more around the surrounding services that the cloud provider o…

> AWS Lambda itself isn't vendor lock in. Can I call my Postgres deployment on Azure via AWS lambda?

This is a pretty fair point about service discovery. Without proper service discovery, Lambda is pretty useless IMO.

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

#85

Post by [deleted] »

nostalgeek wrote: post #82
djhworld wrote: post #29

Earlier quoted context omitted.

AWS Lambda itself isn't vendor lock in. If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers. The vendor lock in creeps in more around the surrounding services that the cloud provider o…

> AWS Lambda itself isn't vendor lock in. Can I call my Postgres deployment on Azure via AWS lambda?

[deleted]

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

#86

Post by mohaine »

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…

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

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

#87

Post by sedachv »

nudpiedo wrote: post #76

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

> Perhaps it is just a weird "renascence of Operating Systems"?

"Serverless" really comes down to being a fancy inetd(8). The "new" part is all in proprietary software-as-a-service to automate server deployment, cluster management and configuration, network configuration, access control, and log collection. In the next technology cycle 6-10 years from now, people will realize that having so much of your software tied into proprietary software-as-a-service is an idea that is even worse than running on proprietary operating systems (NT, Netware, VMS) was in the 1990s.

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

Consider this: in the Unix philosophy, most executables consist of taking things that should be procedures and packaging them up as programs. "Serverless" is largely about applying the Unix philosophy to SaaS - "microservices." So now you are taking things that are really procedures, packaging them up as executables, then packaging those programs up as Internet servers.

I heard or read somewhere a quip that debugging this "stack" is something like the Russian fairytale about Кощей[1]: you have to find a needle, which is in an egg, which is in a duck, which is in a hare, which is in an iron chest, which is buried under an oak tree, which is on an island.

[1] https://en.wikipedia.org/wiki/Koschei

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

#88

Post by ralusek »

nostalgeek wrote: post #82
djhworld wrote: post #29

Earlier quoted context omitted.

AWS Lambda itself isn't vendor lock in. If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers. The vendor lock in creeps in more around the surrounding services that the cloud provider o…

> AWS Lambda itself isn't vendor lock in. Can I call my Postgres deployment on Azure via AWS lambda?

Yes you can, but even that wouldn't be lock-in. Lock-in imo had much more to do with whether you have to write your code specifically to the vendor, and in the case of all 3 FaaS, the answer is mostly "not really." It is trivial to transfer the same behavior from lambda to Google cloud functions.

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

#89

Post by WhitneyLand »

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…

Then what is the point of the open source serverless frameworks our there? Or are you making that argument only within the context of aws lambda?

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

#90

Post by sedachv »

bamboozled wrote: post #81
nudpiedo wrote: post #76

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

I agree with this sentiment and feel the same way. I also find this is a frustrating trend in our industry in where a lot of engineers seem to be spending more time learning about "services" from specific vendors than about things like network protocols and their workings and limitations.

> Maybe this is just inevitable evolution of the IT industry but I've noticed two things that are alarming.

I was at the Southern California Linux Expo[1] earlier this month, and one of the really weird things was how many people from Microsoft were presenting and attending (I wasn't the only one - Bryan Lunduke, ex-MSFT, did a podcast episode about it[2]). I think the trends you point out are from a lot of Microsoft, IBM, Oracle, Java, etc people now being forced into the Linux world, because Linux is now the default for new IT projects. Unfortunately they are bringing along their "practices" instead of retraining in good software systems engineering.

[1] https://www.socallinuxexpo.org/scale/16x [2] http://lunduke.com/2018/03/10/microsoft-headlined-a-major-li...

Post reply on HN