Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Lambda as a back end for a single-page app

lg.io

Post reply on HN
Print view View original

71–77 of 77 posts

Re: AWS Lambda as a back end for a single-page app

#71

Post by Maarten88 »

integraton wrote: post #54
Maarten88 wrote: post #46

> The future is now, and it's using AWS Lambda How is this different from what Azure Mobile Services and many others have been offering for the past 2 years? To me it seems the author is proclaiming Platform As A Service is entirely new (look, no spinning up AWS instances!) while this has been around for quite some time, just Amazon is getting into it more seriously recently.

Lambda is a focused, specialized service for running short-lived processes triggered by events and is one of the many services provided by AWS that have formed the foundation for many companies and other PaaS providers for many years, while Azure Mobile App Service is a packaged and branded collection of services including data storage and push notifications that is similar to backend service providers like Parse and…

I mentioned Azure Mobile Services because (as it's node-based) it can be used to implement exactly the same application as the OP, line-for-line exactly the same.

A static webpage, that calls into a javascript based service, you can register a script to run in that service without any infrastructure hassle, because, well, it's a service.

You are right that there are many comparable Mobile Services that can do many other things and might be branded differently, but this just adds to my point: I don't see what's new here, other than that the OP has seen the light on static webapps combined with platform services.

Re: AWS Lambda as a back end for a single-page app

#72

Post by mryan »

crdoconnor wrote: post #67
mryan wrote: post #62

Earlier quoted context omitted.

I don't worry about lock in in this particular case. At the platform level there is an element of implicit lock in because nobody else offers this exact service. However, the application level can be easily moved to another platform. You could host the handler function code on an EC2 instance or bare-metal server. Little would change in the app code, except the API endpoint to which requests are sent. So IMHO there i…

>At the platform level there is an element of implicit lock in because nobody else offers this exact service. That's kinda what I meant (although there seem to be some similar variants with totally different APIs). Anything similar will use a different API, as well. Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API…

> Even if you could move to an almost-identical service, there will be not-insignificant switching costs as you reconfigure everything with a different API and reimplement the glue code.

That's true. I think we're essentially on the same page here.

I guess I'm still using the old definition of lock in. Poor example: a proprietary Microsoft format that can only be understood by MS software. There is literally no alternative to using MS software if you want to access files created using this format.

Does "high switching cost" == "lock in"? I think it is a grey area. I would not consider myself locked in to Lambda if I had made the decision to host my app there, although I do see there is a high switching cost.

However, if I used RDS Postgres and Amazon decided to prevent me from creating database dumps to migrate to a self-hosted Postgres, then I would be very unhappy because that would be an arbitrary restriction with no purpose except to keep me on AWS.

> To me, it seems like the cost of moving this to some other platform is quite a bit higher than the cost of moving something from, say, EC2.

I agree completely with this. Let's say this was implemented on EC2 instances running Ubuntu, and configured with something like Salt or Puppet. The cost of moving to a Digital Ocean box would be negligible.

Re: AWS Lambda as a back end for a single-page app

#73

Post by akhatri_aus »

AWS has a couple of issues with Lambda. If you use a binary its very difficult to talk to the process. No port binding means its nearly impossible to talk to processes without prohibitive changes (named pipes are a solution but it requires extensive code changes to existing apps)

Re: AWS Lambda as a back end for a single-page app

#74

Post by pas256 »

mayli wrote: post #34
idunno246 wrote: post #7

Earlier quoted context omitted.

I like this one better because it demos using google auth to get temporary aws credentials: https://github.com/cloudnative/lambda-chat

Last message is "Peter Sankauskas Hello". I tried to send some message, and it's saying "Message sent to SNS successfully". But these message never show up in the page.

I'll be talking about this at Gluecon this week. You are right, it is a little broken right now.

Re: AWS Lambda as a back end for a single-page app

#75

Post by jsjohnst »

CMCDragonkai wrote: post #53
ranman wrote: post #50

Earlier quoted context omitted.

It is a GB x second -- I've just seen it written more commonly as GB/s. I think we need a better abbrv for it... gBs?

Then it should be GB.s or GBs. GB/s gives a different meaning. For example I could use 600 GB in the first second, then 400 GB in the second second. All together its 1000 GB.s, at an average of 500 GB/s for 2 seconds. This is not perfect because kilowatt is a rate so kWh is a quantity. But GB is already a quantity. So a GB.s doesn't make sense either. It would need to be an equivalent memory rate usage × time in orde…

> This is not perfect because kilowatt is a rate so kWh is a quantity.

You're a bit mixed up there. Kilowatt is a quantity (unit of energy), kWh is the rate.

Re: AWS Lambda as a back end for a single-page app

#76

Post by jsjohnst »

ranman wrote: post #31
codewithcheese wrote: post #29

How does the pricing compare with say X amount of tasks that run for 1 second each compared to what you could expect from 1 hour on a medium ec2 instance? EDIT: I see it offers "The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month. " What is a GB-second ;)

Re: pricing -- good question I'm going going to test that. Re: gigabyte seconds: It's how much memory (RAM) you're using: 128mb RAM (lowest possible value) for 10s == 1 GB/s 1gb RAM for 1s == 1 GB/s I think it's a pretty clever way to (somewhat) directly correlate compute cost with power (energy). If you remember what John McCarthy said when he imagined that computing would be a public utility one day ( http://www.te…

Minor quibble, but still important: 128 * 10 != 1024. Eight seconds @ 128mb is the equivalent value to using 1gb for a second.

Re: AWS Lambda as a back end for a single-page app

#77

Post by hendzen »

girvo wrote: post #66
hendzen wrote: post #33

Earlier quoted context omitted.

Why would you need to do that? Just set DT_RUNPATH when you link the binary and use the $ORIGIN variable to set a relative path.

Is there anywhere that has decent documentation on how to do that? I'm not very good with compiling and linking C, and have been trying to work out some distribution issues with a project I was working on in a compile-to-c language, where it relies on a dynamically linked shared library that I want to distrubute along with it.

I would read section 3.9 of Ulrich Drepper's "How to Write Shared Libraries" [0].

[0] - http://www.akkadia.org/drepper/dsohowto.pdf

Post reply on HN