5 ms·

One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple user

One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates any kind of business logic - or anything that will need to be iterated on by more than one developer. I feel it is a massive reach to market this to anyone at this point, and if this catches on, would really make me hate programming compared to what local development in VMs feels like - where I have much greater tools. It's inefficient both for the developer and at runtime.

deleted 10y ago
[deleted]
WalterSear 10y ago
With that in mind, serverless architecture seems to be a micro-optimization that is of the greatest benefit to enterprise customers whose scale is large enough to benefit from reducing their server load to the barest minimum, at the cost of greatly increasing development costs. I don't see how this would be much fun to work on in a team. We have enough trouble her squabbling over who gets to use the staging server next.
- snom380 10y ago
  I'm pretty sure that if you're considering using Lambda, you'd want to automate creating and deploying the Lambda functions in such a way that you could create any number of them for each developer to play with. That said, the problem with debugging stands (for AWS lambda, at least).
nickbauman 10y ago
I completely agree with you regarding debugging. Especially with Lambda. But App Engine allows you to connect a python REPL directly to your app in the cloud. It doesn't get any better than that. And I've noticed that because mobile developers don't get to pick much to develop to (the device maker dictates) they seem to move much faster than your typical server-side developer who bit twiddles VMs, Dockerfiles and distributed services much more than they admit with the time left to write actual functionality much lower. Too much choice is also a prison.
inopinatus 10y ago
There's certainly a need for offline prod-like environments/harnesses for serverless development. However I don't think that's a criticism of the architecture, simply a reflection of the immaturity of the style.
wcummings 10y ago
First we need a common standard for the serverless pieces of code to talk to the app server and gateway... maybe we could call it a common gateway interface. Then maybe someone will write an apache module for it.
- rapind 10y ago
  I laughed at the CGI reference, but TBH pub/sub + microservices feels really awesome and clean so far. Combined with DB as a service it's even better IMO.
  - clebio 10y ago
    Could you expand on this a bit? Are you using Oauth for microservice authentication, or some such? How specifically does this address the parent comment. Honestly curious.
  - sp527 10y ago
    I was thinking DBaaS as well, which is the part that's usually under-emphasized. NoSQL for specific tasks and (sharded if needed) relational with stored procedures for anything complex. When you think of Postgres as its own (heavily optimized) server, it changes the game. For most apps, at that point you just need a passthrough layer exposing endpoints, which is usually a dead simple nodejs app behind a balancer. The rest of the heavy logic is then offloaded to the client. This is why full-stack makes sense now more than ever. It's getting so easy there's almost no excuse anymore.
    - wcummings 10y ago
      >This is why full-stack makes sense now more than ever. It's getting so easy there's almost no excuse anymore. There's a plenty of good reasons to avoid SPAs.
      - sp527 10y ago
        I'd like to hear one. Server side rendering if/where needed, don't overload on NPM modules, drop jQuery entirely, react lib served by a CDN. SPAs fail in the hands of amatuers. They excel as a way of instituting rigor in dynamic site development when wielded by people who know what they're doing.
bradscarleton 10y ago
I think you're right that one of the big downsides currently for AWS lambda would be dev tooling, however one of the big upsides is that the code you throw up there should run "forever". This is potentially really useful if you are simply working on frontend code, and hitting these Lambda endpoints as a client. I've set them up a few times for contact forms and other light pieces of functionality for static websites, and it fits that niche really well. Obviously, I think the serverless movement has some grander notions of the size and scale of applications that could be constructed, so we'll see.
cbsmith 10y ago
Why is serverless particularly bad for this? If anything, it is easier with serverless, because you can branch pretty cleanly down to the single function level. All you need is a level of indirection, usually at the domain and pathing level.
aleem 10y ago
Second that. There's ELB + EC2 which can give you auto-scale but data persistence needs to be handled separately. There's AWS ECS which is/was quite unwieldy but I am hopeful for GAE's Flexible Environments (beta) built on Docker containers, putting it midway between Docker and Lambda with some interesting features https://cloud.google.com/appengine/docs/flexible/ https://cloud.google.com/appengine/docs/flexible/
- scprodigy 10y ago
  check https://hyper.sh https://hyper.sh container-based cloud

deleted 10y ago

[deleted]

WalterSear 10y ago

With that in mind, serverless architecture seems to be a micro-optimization that is of the greatest benefit to enterprise customers whose scale is large enough to benefit from reducing their server load to the barest minimum, at the cost of greatly increasing development costs. I don't see how this would be much fun to work on in a team. We have enough trouble her squabbling over who gets to use the staging server next.

snom380 10y ago
I'm pretty sure that if you're considering using Lambda, you'd want to automate creating and deploying the Lambda functions in such a way that you could create any number of them for each developer to play with. That said, the problem with debugging stands (for AWS lambda, at least).

nickbauman 10y ago

I completely agree with you regarding debugging. Especially with Lambda. But App Engine allows you to connect a python REPL directly to your app in the cloud. It doesn't get any better than that. And I've noticed that because mobile developers don't get to pick much to develop to (the device maker dictates) they seem to move much faster than your typical server-side developer who bit twiddles VMs, Dockerfiles and distributed services much more than they admit with the time left to write actual functionality much lower. Too much choice is also a prison.

inopinatus 10y ago

There's certainly a need for offline prod-like environments/harnesses for serverless development. However I don't think that's a criticism of the architecture, simply a reflection of the immaturity of the style.

wcummings 10y ago

First we need a common standard for the serverless pieces of code to talk to the app server and gateway... maybe we could call it a common gateway interface. Then maybe someone will write an apache module for it.

rapind 10y ago
I laughed at the CGI reference, but TBH pub/sub + microservices feels really awesome and clean so far. Combined with DB as a service it's even better IMO.
- clebio 10y ago
  Could you expand on this a bit? Are you using Oauth for microservice authentication, or some such? How specifically does this address the parent comment. Honestly curious.
- sp527 10y ago
  I was thinking DBaaS as well, which is the part that's usually under-emphasized. NoSQL for specific tasks and (sharded if needed) relational with stored procedures for anything complex. When you think of Postgres as its own (heavily optimized) server, it changes the game. For most apps, at that point you just need a passthrough layer exposing endpoints, which is usually a dead simple nodejs app behind a balancer. The rest of the heavy logic is then offloaded to the client. This is why full-stack makes sense now more than ever. It's getting so easy there's almost no excuse anymore.
  - wcummings 10y ago
    >This is why full-stack makes sense now more than ever. It's getting so easy there's almost no excuse anymore. There's a plenty of good reasons to avoid SPAs.
    - sp527 10y ago
      I'd like to hear one. Server side rendering if/where needed, don't overload on NPM modules, drop jQuery entirely, react lib served by a CDN. SPAs fail in the hands of amatuers. They excel as a way of instituting rigor in dynamic site development when wielded by people who know what they're doing.

bradscarleton 10y ago

I think you're right that one of the big downsides currently for AWS lambda would be dev tooling, however one of the big upsides is that the code you throw up there should run "forever". This is potentially really useful if you are simply working on frontend code, and hitting these Lambda endpoints as a client. I've set them up a few times for contact forms and other light pieces of functionality for static websites, and it fits that niche really well. Obviously, I think the serverless movement has some grander notions of the size and scale of applications that could be constructed, so we'll see.

cbsmith 10y ago

Why is serverless particularly bad for this? If anything, it is easier with serverless, because you can branch pretty cleanly down to the single function level. All you need is a level of indirection, usually at the domain and pathing level.

aleem 10y ago

Second that. There's ELB + EC2 which can give you auto-scale but data persistence needs to be handled separately. There's AWS ECS which is/was quite unwieldy but I am hopeful for GAE's Flexible Environments (beta) built on Docker containers, putting it midway between Docker and Lambda with some interesting features https://cloud.google.com/appengine/docs/flexible/ https://cloud.google.com/appengine/docs/flexible/

scprodigy 10y ago
check https://hyper.sh https://hyper.sh container-based cloud