I think this is great! While I'm no python expert - as much as i love flask - i get annoyed at the parts needed to setup up the uWSGI stuff. It looks like using chalice, maybe i don't have to worry about setting up the annoying uWSGI stuff?
Chalice: Python Serverless Microframework for AWS
91–100 of 101 posts
Re: Chalice: Python Serverless Microframework for AWS
#92Earlier quoted context omitted.
Well, if you look at how we've done things over the years: - We used to have our own machines in our own data centers - Then we started renting machines in data centers - We then moved to the cloud model where we would get compute capacity on demand. But the minimum unit was an hour - But what if you could deploy your code and you were only charged for the compute and memory you take for the fulfillment of that reque…
then why is it something new? Isn't this what google appengine / heroku has been doing for years ?
No, heroku and to a lesser extant appengine are running at the whole application level. Lambda and google's, and azure's functions are literally individual functions that are deployed separately. They can be piped together to make a whole app but don't need to be.
Re: Chalice: Python Serverless Microframework for AWS
#93Earlier quoted context omitted.
Well, if you look at how we've done things over the years: - We used to have our own machines in our own data centers - Then we started renting machines in data centers - We then moved to the cloud model where we would get compute capacity on demand. But the minimum unit was an hour - But what if you could deploy your code and you were only charged for the compute and memory you take for the fulfillment of that reque…
It's like running CGI on a shared server, except that it scales better.
I wonder if that's really true (that it scales better than running more-or-less bog standard CGI across a fleet of thousands of servers, behind a load balancer).
If I've understood lambda correctly, rather than spinning up a process (as with CGI), it spins up an entire vm/container. I suppose it might do the fast-cgi thing - spin up a container, and keep it running while there are requests coming in, and then kill it off.
I'm sure there are other benefits of "container-on-demand" vs "process-on-demand" -- but I'm not sure "scales better" is one of them. Well, I'm sure it "scales better" in the sense of organization (human resources), but not necessarily in terms of machine resources.
At any rate, I like the analogy.
Re: Chalice: Python Serverless Microframework for AWS
#94AWS Lambda is cool and all, but aren't people doing the math on this? Lambda seems like a really expensive way to deliver almost anything. Likewise, the AWS API Gateway is expensive, but at least provides some additional capabilities. Lambda seems like its profitable niche would be very small; limited computing environment, very high cost (relative to almost every other way to host an API), and having to learn a whol…
I've found Lambda to be really ridiculously fucking cheap. We moved image resizing onto it and saved thousands a month. Don't compare the cost of Lambda per 100ms to the cost of a virtual machine per month since Lambda only charges as you use it. You'd have to have the CPU pegged at 100% usage to make that a fair comparison. Mind you even if you took the cost of Lambda per 100ms and multiplied that out for a monthly…
Whenever I've looked half-seriously at any cloud offering, I've come to the conclusion that it's the data transfer/bandwidth that kills vis-a-vis dedicated services. If you don't need ~10TB/month, then sure - it doesn't really matter. If you do then you need to get a lot of reduced ops work for your effort.
I suppose that if while testing/starting out you use little bandwidth, and any additional bandwidth/users comes with income - it doesn't really matter that a chunk of that goes to AWS, and not to your business.
For those that actually do run non-trivial things on AWS (or other clouds) - do feel this is an accurate assessment? That bandwidth is still really expensive in the cloud?
Re: Chalice: Python Serverless Microframework for AWS
#95Serverless computing seems to just be reinventing hosted CGI. Is this not just a trade of Perl and php for Python and JavaScript?
I think one could engineer CGI to get many of the same benefits - I'm not entirely sure most people did. First, you'd want to run each process in a separate jail, as a separate user - and yet be able to (easily) use fifo's or pipes (possibly sockets) to pipe data through.
At that point, you're already a bit from ephemeral data in /tmp and your typical php/perl/cgi setup.
But I think you're right in that it borrows some of the good ideas from CGI (chief among them simplicity, assuming that you were doing stateless stuff).
Re: Chalice: Python Serverless Microframework for AWS
#96What is the recommended way of keeping the URL of the service straight? To set up a DNS pointer to the DNS name amazon generates, with a "low enough" TTL?
Re: Chalice: Python Serverless Microframework for AWS
#97Earlier quoted context omitted.
It's like running CGI on a shared server, except that it scales better.
I wonder if that's really true (that it scales better than running more-or-less bog standard CGI across a fleet of thousands of servers, behind a load balancer). If I've understood lambda correctly, rather than spinning up a process (as with CGI), it spins up an entire vm/container. I suppose it might do the fast-cgi thing - spin up a container, and keep it running while there are requests coming in, and then kill it…
The concept goes back even further. It's really transaction processing as used in the IBM Customer Information Control System, first used in 1964. Load small program image on demand, run it, discard it. (Or, optionally, reuse it for another transaction.) This is usually tied to a database, and if the transaction fails, the database changes are rolled back. This is how IBM mainframes do transactions. 48 years later, versions of CICS are still in wide active use and are supported IBM products.
Re: Chalice: Python Serverless Microframework for AWS
#98Earlier quoted context omitted.
I think this type of thing will end up being useful for special cases, but in general we'll still want to run our own servers. Their use case of creating a public API is a great one: it's a simple interface and having Lambda handle the auto-scaling is pretty awesome.
We are using Lambda to export CloudWatch metrics to another system. Haven't exceeded the free tier of Lambda yet, and CW itself was only $5 last month. Having a t2 up the whole time would have been way more, plus it would have been subject to our Chaos Monkey.
Wouldn't it be a lot cheaper if you have a dedicated box where you can run your own VMs and add and remove services as you please? So far, running one at base cost with leased hardware costs about 1/10th of any 'cloud' provider out there, with lots more resources to go around. Right now, if want to spin up a new instance, container or process, I can do it locally, in vagrant or on a VM on the dedicated box all with the same config and management ease of the configuration management stack (we use SaltStack). It also works just fine with stuff like GCE or AWS, but those simply are never ever the 'cheapest' option. At best, they are a in-between solution when we need more hardware. It's great for temporary scaling, but of nominal resource usage there is no point in using those services at all, at least for us. The cost of a dedicated box is static, no matter how much you use, and yet it is always lower than the mean cost or 95th percentile of any AWS/GCE kind of thing. For (converted currency from euro) about 100USD we get 16 E5 cores, 92GB RAM, 1TB SSD RAID10, 10TB HDD RAID10 and 8TB transfer on a dual 1Gbit link. For the life of me I can't find any combination on Amazon to match that.
Re: Chalice: Python Serverless Microframework for AWS
#99Ok, I have seen the phrase "serverless" a few times recently. Can someone explain to me what it is (as I am pretty sure it involves a server - it runs on AWS ffs) and why I should want to use it? And most importantly, is it web scale?
It's an app server. It's like PHP.
That's exactly what it is, fancy CGI only one pays for each script execution instead of a monthly subscription. The "Oh, but it doesn't use HTTP but a pubsub architecture" is meaningless, that's still CGI for hipsters. And you still need to use (and pay) for API gateway on AWS in order to execute Lambda scripts from the outside.
Re: Chalice: Python Serverless Microframework for AWS
#100Has anyone successfully and painlessly used Lambda+API Gateway in production as their main backend? It appears Lambda has many limitations, but I see rather mature frameworks such as Serverless (formerly JAWS) being promoted here, and now Amazon is also working on their standard framework. It would be great to just use CDNs and this; get all benefits of using a PaaS with IaaS-level costs only!
we use it now as the main backend for Mindmup 2, migrated from Heroku. I recently published the scripts evolved from our usage to simplify deployments as https://Github.com/claudiajs - the tool is mature, and allows teams to use API GW almost as easy as if it were a lightweight web server
So basically each end point is a function ? how do you test your whole app locally ? I mean integration tests and acceptance tests on your local machine if you depend entirely on AWS vendor lockin infrastructure