Serverless Architectures • Hacker News Board

Re: Serverless Architectures

#211

Post by anthony_barker » Wed, Jul 20, 2016, 2:12 PM UTC

Sanddancer wrote: post #135

One of the big issues here that is only very very slightly glossed over is the security you give up. The only sort of security filtering you get is AWS' WAF, which is considerably weaker than a firewall like mod_security with a default ruleset, or even apache's .htaccess. Inbound filtering, you're limited to a tiny ruleset with only a few conditions, and outbound filtering doesn't exist at all. This lack of firewalli…

Did you look at Lambda scheduled events?

http://docs.aws.amazon.com/lambda/latest/dg/with-scheduledev...

Re: Serverless Architectures

#212

Post by wcummings » Wed, Jul 20, 2016, 6:59 PM UTC

sp527 wrote: post #181

rapind wrote: post #152

Earlier quoted context omitted.

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.

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…

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

Re: Serverless Architectures

#213

Post by sp527 » Thu, Jul 21, 2016, 4:11 AM UTC

wcummings wrote: post #212

sp527 wrote: post #181

Earlier quoted context omitted.

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…

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

Re: Serverless Architectures

#214

Post by theptip » Thu, Jul 21, 2016, 6:10 PM UTC

kowdermeister wrote: post #100

theptip wrote: post #39

Earlier quoted context omitted.

Adrian Cockcroft: "If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless." https://twitter.com/adrianco/status/736553530689998848

No, call them extremely fast lifcycle servers.

That's a lot more syllables than "serverless".

Re: Serverless Architectures

#215

Post by theptip » Thu, Jul 21, 2016, 6:31 PM UTC

scrollaway wrote: post #44

theptip wrote: post #35

Earlier quoted context omitted.

Parent post didn't say anything about abstracting away "serverless". Lock-in refers to (as the OP article discusses) the fact that if you use AWS Lambda, you are tied to their APIs and deploy mechanisms. If you want to move to Google's FaaS offering, you have a lot of work to do, and may need to restructure your app logic as well.

And that's wrong; a complete misunderstanding of how both serverless in general and Lambda specifically works. You provide an entry point to your application. AWS provides you with an `event` and `context` object, both of which are nonstandard. You extract, out of those objects, the data you care about... and you pass it down to whatever it is you want to run. The extraction is very simple. Here, take a look at a SNS…

I don't think your code example supports the point you're trying to make. Of 3 lines of non-logging code, one of them is AWS-specific, and so would need to be refactored to use another FaaS platform. That's what lock-in refers to. It's not saying you cannot migrate at all, it's just saying that there's a refactoring cost to swap out the platform APIs.

If you can get the same message-delivery semantics from Google's message bus, then the refactor would end there, but if you happen to be depending on a feature that's not implemented on your new platform, then you might have to refactor your application logic further.

Furthermore, you still have to get your code into production, upgrade it, monitor it, and ensure that the other functions that it, and all of that currently tends to depend on platform-specific tooling.

Much of this is also the case in the VM-based PaaS world. But, there you have projects like libcloud that can abstract some of the differences away. That feature gap is pointed out in the OP article, which makes it clear that the lock-in issue isn't a fundamental defect with the functional paradigm, just a side-effect of the FaaS offerings being young.