Re:New for AWS Lambda – Environment Variables and Serverless...
by boyd on Sunday November 20, 2016 @01:48PM
(#13000380)
Had never heard of apex. Looks really nice and giving it a try now!
Edit: Feedback: Really like it. One feature that would be very nice would be the ability to trigger a ping on demand, e.g., for testing auth set up on a request. Runscope implements a similar feature. Otherwise great so far!
Re:New for AWS Lambda – Environment Variables and Serverless...
by tjholowaychuk on Sunday November 20, 2016 @01:52PM
(#13000403)
Thanks! Agreed, I have that on the list, quick sanity check is always good. Taking a bit of a break to work on other products but I'll keep adding to it.
Re:New for AWS Lambda – Environment Variables and Serverless...
by tedmiston on Sunday November 20, 2016 @03:06PM
(#13000869)
I've looked at Apex a few times. I was going to ask you for a hacker plan but it sounds like you're already doing such numbers it might not be justified. It would be really nice for me to be able to have a master subscription for my contracting work for client projects.
Re:New for AWS Lambda – Environment Variables and Serverless...
by tjholowaychuk on Sunday November 20, 2016 @03:16PM
(#13000931)
I've thought about adding a smaller plan, I still might at some point but it certainly reaches a level where it's not really worth it, especially since I want to provide equal support to everyone. I'll have to experiment with that.
I had limited free plans originally but that went horribly wrong haha, free users only attract other free users, a few days later I had like 4000 free people. Maybe that works for startups, but not "real" companies.
Re:New for AWS Lambda – Environment Variables and Serverless...
by meddlepal on Sunday November 20, 2016 @10:32PM
(#13002927)
I used Apex briefly a few months back and was impressed but I didn't fall in love with Lambda so I'm not using it anymore.
Re:New for AWS Lambda – Environment Variables and Serverless...
by acid__ on Sunday November 20, 2016 @01:56PM
(#13000426)
Heads up -- Chrome is blocking is blocking a lot of your site's requests to lambda endpoints (net::ERR_INSECURE_RESPONSE) :)
Re:New for AWS Lambda – Environment Variables and Serverless...
by fosk on Sunday November 20, 2016 @07:04PM
(#13002063)
If you need an API Gateway that can work with Lambda, but with better performance and feature set, take a look at https://github.com/Mashape/kong - there is an open PR for Lambda support which will land in the next version (I am one of the core committers).
Re:New for AWS Lambda – Environment Variables and Serverless...
by markonen on Monday November 21, 2016 @02:05AM
(#13003726)
This is very interesting. Especially when you have a large volume of trivial requests, the cost-per-request of AWS API Gateway dominates overall cost (the Lambda functions themselves are cheap by comparison). Rolling one's own in EC2 can potentially be much cheaper.
Re:New for AWS Lambda – Environment Variables and Serverless...
by tedmiston on Sunday November 20, 2016 @03:07PM
(#13000873)
Can you elaborate on the slight latency you've experienced?
Re:New for AWS Lambda – Environment Variables and Serverless...
by tjholowaychuk on Sunday November 20, 2016 @03:18PM
(#13000937)
I haven't tested it extensively but if you boot up API Gateway and a hello-world Lambda function, the function itself takes maybe 1ms to run, while API Gateway seems to add roughly 150-200ms on top of that.
Conceptually I think it's great for pipelines or use-cases like this, VMs are generally a terrible level of abstraction for a lot of problems, and the Lambda style promotes better architecture because of this.
The connectivity between Kinesis/SNS and friends is great. I'd agree that Lambda is not currently a good fit for "regular" apps, APIs should be fine now that the proxy stuff is in there, though there's slight latency.
No need to worry about gracefully stopping or restarting daemons, just push new code and the old stuff goes away, it really is a great abstraction that way. Basically replace anything you'd use a Go channel for, with more Lambda or SNS->Lambda if you need retries and backoff, it'll spare you a lot of code.
I find the workflow great as well, the slowest part for me is compiling the Go binaries, the rest is virtually instant. Especially now with all this needlessly complex Docker stuff it's refreshing to use something simple.
Cost is prohibitive for sustained use, so make sure you price things out properly, it sounds very cheap until you look at say a constant 100 requests/s behind API Gateway. It's easily 300-400% what you'd pay on EC2.
Cold-start is really a non-issue in most cases, it seems to take very little to keep a function warmed, so unless you get zero traffic (which would be dirt cheap on a t2.micro anyway) you'll be fine.