Does nobody else look at this and worry about the vendor lock in implications?
If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.
AWS Lambda as a back end for a single-page app
61–70 of 77 posts
Re: AWS Lambda as a back end for a single-page app
#62Does nobody else look at this and worry about the vendor lock in implications? If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.
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 is no lock in in the traditional sense, but there is a switching cost if you want to move to another platform.
Re: AWS Lambda as a back end for a single-page app
#63The real question here is still: why doesn't Amazon offer a GET interface to Lambda? It's so, so, so close. So almost. They offer POST (through a work-around with S3), why not GET? That is the real destination. With lambda serving GETs, we can remove the "for a single page app" from the title. AWS is so close to fulfilling the promise of its cloud: let developers worry about code.
It is a bit slow still. Jitsu[1], which starts unikernels is fast enough to do per request image booting, but Amazon seem to have a 1s cold start which is just a bit slow. [1] https://github.com/mirage/jitsu
Ah, so there is a 1s cold start. I couldn't understand how they managed to get a container (which I imagine they are using?) running "within milliseconds". I guess the millisecond claim only holds for concurrent requests then?
Re: AWS Lambda as a back end for a single-page app
#64"the future is now, and it's down because somebody used the secret key to drain the poster's bank account" To be sure, the author specifies that the IAM role being exposed here is only allowed to invoke the function. That's great for the security of the other resources on the account, but still allows a reasonably determined attacker to run up a Bill of Unusual Size quite rapidly. For instance, the rate limiter curre…
...and that's why CloudWatch allows you to set billing alerts. You could even route a billing alerts (via SNS) back to a Lambda function, use it to set a flag, and run in a reduced capacity mode if this is a concern. I always tell my audiences (I work for Amazon) that it should be possible to build a system where you know the actual cost of every web page you generate and every request you serve, and to make sure tha…
An official example repo (or, less ideally, a tutorial) of how to automate the cost-control would probably go a long way.
Re: AWS Lambda as a back end for a single-page app
#65Earlier quoted context omitted.
All of those limits are typically to protect users from being over charged if they fat-finger something. Most limits like that can be lifted with a support ticket. I'm not sure if this is one of them but I think it's likely.
You are correct; that limit can be raised. Just ask!
Could the limit also be lowered, for damage control?
Re: AWS Lambda as a back end for a single-page app
#66Earlier quoted context omitted.
Thanks for the links! If my executable relies on .so files in a lib directory, is it possible to set env variables to point to a local path?
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.
Re: AWS Lambda as a back end for a single-page app
#67Does nobody else look at this and worry about the vendor lock in implications? If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.
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 and reimplement the glue code.
>So IMHO there is no lock in in the traditional sense
Lock-in doesn't mean that it's impossible to move to a different platform, it just means that there's a high cost. 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.
Actually, it seems like this is Amazon's real business strategy with things like this. They want you to use all of their different services like this, SQS, SES, Elastic beanstalk, their hosted database thing. Individually the costs of moving away from all of them is not that high, but add them all together and it becomes immense.
Re: AWS Lambda as a back end for a single-page app
#68Does nobody else look at this and worry about the vendor lock in implications? If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.
I wouldn't say that's a big concern. Because you control the binaries that run on AWS Lambda, it wouldn't be too hard to move the event-based logic of invoking a function to your own custom task queue.
Other AWS services are a bigger concern for lock-in, like the DB stuff, EBS and so on.
Re: AWS Lambda as a back end for a single-page app
#69Earlier quoted context omitted.
It is a bit slow still. Jitsu[1], which starts unikernels is fast enough to do per request image booting, but Amazon seem to have a 1s cold start which is just a bit slow. [1] https://github.com/mirage/jitsu
Ah, so there is a 1s cold start. I couldn't understand how they managed to get a container (which I imagine they are using?) running "within milliseconds". I guess the millisecond claim only holds for concurrent requests then?
Seems so for the measurements I have seen yes. Concurrent or close before it has been shut down.
Re: AWS Lambda as a back end for a single-page app
#70Does nobody else look at this and worry about the vendor lock in implications? If your app is dependent upon a technology like this, it's much harder to move to a different platform than if just used, say, EC2.
I wouldn't say that's a big concern. Because you control the binaries that run on AWS Lambda, it wouldn't be too hard to move the event-based logic of invoking a function to your own custom task queue. Other AWS services are a bigger concern for lock-in, like the DB stuff, EBS and so on.
Configuring this thing is not that trivial even if everything run on it does belong to you. All of that configuration is stuff that you'd have to re-implement when moving to a different platform.