30 ms·

These are good answers but nowadays we would be remiss not to mention so-called "serverless" frameworks. Dropwizard et al are good suggestions for running your

by abalone 10y ago

These are good answers but nowadays we would be remiss not to mention so-called "serverless" frameworks. Dropwizard et al are good suggestions for running your own instance, but more and more the serverless approach is an attractive alternative to implementing a web app. AWS Lambda now supports Java, so perhaps we could consider API Gateway, Cognito and DynamoDB/Aurora as one of the new "frameworks". Google has their own competing offering as well, e.g. Cloud Functions. Firebase deserves a special mention as a rapid development framework, although at the moment it only supports Node.js. Like many frameworks it has pros and cons, but in my opinion full-on websockets support OOTB is a pretty cool pro.. especially since Lambda/Cloud Functions/FaaS can't do websockets on their own.

manyxcxi 10y ago
RE: AWS Lambda, there are a lot of shortcomings, the biggest is latency when it's cold. Another is duration, if your process takes too long and you can't break it into smaller steps (probably not a good sign, but still...) Lambda is no-go. Configuration generally kind of sucks to manage, you don't get some of the role inheritance you can get from standard EC2/IAM, and forget running inside a VPC. The idea behind using something like API Gateway + a Lambda for the various end points sounds awesome in theory, but going beyond contrived examples shows that we're a long way out.
- 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

RE: AWS Lambda, there are a lot of shortcomings, the biggest is latency when it's cold. Another is duration, if your process takes too long and you can't break it into smaller steps (probably not a good sign, but still...) Lambda is no-go. Configuration generally kind of sucks to manage, you don't get some of the role inheritance you can get from standard EC2/IAM, and forget running inside a VPC. The idea behind using something like API Gateway + a Lambda for the various end points sounds awesome in theory, but going beyond contrived examples shows that we're a long way out.

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.