3 ms·

There's a lot to criticize about running your own Dropwizard, Play, Spring and Java EE instances as well, including the same issue of management headaches. In f

by abalone 10y ago

There's a lot to criticize about running your own Dropwizard, Play, Spring and Java EE instances as well, including the same issue of management headaches. In fact one of the key advantages of the "serverless" approach is less devops management overhead. To consider running your own instance "management suckage free" but calling something like serverless.com a headache is definitely not an apples-to-apples comparison. Cold start time is a known issue but frankly, not that big of a problem in practice for many apps. Definitely I feel that dismissing this out of hand (I even got a downvote) is more of an emotional reaction to something really different and new than a rational one. There's nothing contrived about implementing a REST service with FaaS -- it's just simpler. It's worth giving it a serious look even as an experienced Java developer (as I am). There are a lot of benefits to the architecture, like minimal devops and tremendous cost effectiveness.

manyxcxi 10y ago
I definitely didn't downvote and I agree that there are tradeoffs with any choice- but serverless doesn't mean Ops-less. I use Lambdas for lots of things, actually a lot of my Ops use Lambdas for various tasks (like SES catch all mail forwarding for example). Don't think I'm dissing Lambdas (or anything like them in a non AWS context). There's a lot to love about them, not the least of which is that for small (in time to completion, request volume, and memory usage) units of work they are significantly cheaper. There's a config management nightmare for everything but there are known ways to answer it for a traditional server/fleet approach. Run time configuration of Lambdas is still evolving and there aren't many options to choose from that are much better than just deploying the code and config as one as part of a delivery pipeline. It's workable now, but there are gaps. There aren't any gaps with running your own applications, it's literally what's always been done. There are certainly pain points, but the problem is already well understood.

by abalone 10y ago

manyxcxi 10y ago

I definitely didn't downvote and I agree that there are tradeoffs with any choice- but serverless doesn't mean Ops-less. I use Lambdas for lots of things, actually a lot of my Ops use Lambdas for various tasks (like SES catch all mail forwarding for example). Don't think I'm dissing Lambdas (or anything like them in a non AWS context). There's a lot to love about them, not the least of which is that for small (in time to completion, request volume, and memory usage) units of work they are significantly cheaper. There's a config management nightmare for everything but there are known ways to answer it for a traditional server/fleet approach. Run time configuration of Lambdas is still evolving and there aren't many options to choose from that are much better than just deploying the code and config as one as part of a delivery pipeline. It's workable now, but there are gaps. There aren't any gaps with running your own applications, it's literally what's always been done. There are certainly pain points, but the problem is already well understood.