AWS Lambda and .zip is a recipe for serverless success • Hacker News Board

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

#61

Post by thinkloop » Sun, Mar 18, 2018, 9:44 PM UTC

electricEmu wrote: post #55

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…

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.

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

#62

Post by Zelphyr » Sun, Mar 18, 2018, 9:44 PM UTC

roywiggins wrote: post #53

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 )

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 unrelated to the actual problem.

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

#63

Post by mateuszf » Sun, Mar 18, 2018, 9:48 PM UTC

electricEmu wrote: post #55

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…

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.

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

#64

Post by chapill » Sun, Mar 18, 2018, 9:48 PM UTC

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.

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

#65

Post by gkoberger » Sun, Mar 18, 2018, 9:57 PM UTC

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…

Hey! We built http://readme.build to solve these problems (logging, metrics, deploying, SDKs, etc). It's free currently, and I'd love feedback (greg@readme.io)!

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

#66

Post by Vindicis » Sun, Mar 18, 2018, 10:09 PM UTC

bthornbury wrote: post #52

reactivesearch wrote: post #48

Earlier quoted context omitted.

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

It's straightforward logic. Serverless platforms increase convenience. Throwing them away decreases convenience and increases developer time to learn and launch. Many great inventions, like writing, automobiles, all increased convenience. Throwing away inventions that increase convenience, decreases convenience.

So is this:

Humans reproduce. Trees reproduce. Humans should reproduce with trees.

Just because something is logical doesn't mean it makes sense.

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

#67

Post by zapita » Sun, Mar 18, 2018, 10:14 PM UTC

electricEmu wrote: post #55

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…

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.

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

#68

Post by zapita » Sun, Mar 18, 2018, 10:18 PM UTC

staticassertion wrote: post #40

paulgb wrote: post #31

Earlier quoted context omitted.

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.

That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways... If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using R…

> That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2.

The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't.

Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.

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

#69

Post by [deleted] » Sun, Mar 18, 2018, 10:33 PM UTC

Vindicis wrote: post #66

bthornbury wrote: post #52

Earlier quoted context omitted.

It's straightforward logic. Serverless platforms increase convenience. Throwing them away decreases convenience and increases developer time to learn and launch. Many great inventions, like writing, automobiles, all increased convenience. Throwing away inventions that increase convenience, decreases convenience.

So is this: Humans reproduce. Trees reproduce. Humans should reproduce with trees. Just because something is logical doesn't mean it makes sense.

[deleted]

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

#70

Post by np_tedious » Sun, Mar 18, 2018, 10:35 PM UTC

staticassertion wrote: post #40

paulgb wrote: post #31

Earlier quoted context omitted.

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.

That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways... If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using R…

There are a finite set of this to trigger the function and they become central to

API Gateway, kinsesis, s3 change/addition...

It definitely has more lock in potential than more "vanilla" offerings like EC2, RDS, S3.

You could name a replacement/competitor service for each of the above, but if the Lambda is triggered by S3 changes then that's a big barrier to putting your static files elsewhere