Hacker News Reader

Comment by mpdehaan2 | Hacker News Reader

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.

View on HN

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.

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.

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).

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.

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.

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.

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/

check https://hyper.sh container-based cloud

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.

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.

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.

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.

>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.

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.

I created Lite Engine[1] specifically as an alternative for this. Being able to POST and execute queries saved on the backend enables A LOT of functionality. Sqlite because it's simple to manage and allows massive multi tenancy for very low cost. And performs acceptably well for small/medium size work loads.

[1] https://www.lite-engine.com

Reply on news.ycombinator.com