Guide to Serverless Architecture • Hacker News Board

Re: Guide to Serverless Architecture

#91

Post by cryptonector » Thu, Dec 21, 2017, 9:33 PM UTC

icebraining wrote: post #65

neya wrote: post #63

For me the BIGGEST gain of using serverless architecture is security. For example, this year I started two ecommerce platforms. One's a digital delivery e-shop - selling ebooks, training and stuff and the other is a physical delivery e-shop. Normally, I'd write my own Phoenix/Rails app, but this time, I decided to go serverless for my furniture shop and wrote it all in Jekyll. Yes, the static site builder. I use netl…

If static sites are now also Serverless, the word has lost all meaning. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.

"Serverless" is itself a bit of a misnomer. The point seems to be to distribute stateless sub-computations. Whoop dee doo. At some point you need a "server" to modify application state. A static site has no state modifications, so it actually is serverless in this sense of having stateless computation.

Re: Guide to Serverless Architecture

#92

Post by Turbots » Thu, Dec 21, 2017, 9:40 PM UTC

I hate calling it serverless... Just call it function-as-a-service because of course there's gonna be servers involved. You just don't have to care about them.

Also here to point out one of the latest FaaS frameworks based on Kubernetes: https://github.com/projectriff/riff

Re: Guide to Serverless Architecture

#93

Post by neya » Thu, Dec 21, 2017, 10:41 PM UTC

cryptonector wrote: post #91

icebraining wrote: post #65

Earlier quoted context omitted.

If static sites are now also Serverless, the word has lost all meaning. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.

"Serverless" is itself a bit of a misnomer. The point seems to be to distribute stateless sub-computations. Whoop dee doo. At some point you need a "server" to modify application state. A static site has no state modifications, so it actually is serverless in this sense of having stateless computation.

Thanks, that was exactly what I was going to reply. Perfectly explained, thank you.

Re: Guide to Serverless Architecture

#94

Post by cryptonector » Thu, Dec 21, 2017, 10:43 PM UTC

Hnrobert42 wrote: post #77

Be more concise.

TFA is unintelligible mumbo jumbo describing an architecture that amounts to (I think!) minimizing statefulness and moving all stateless computation out to a cloud.

Well, OK, but how about some examples? How about some advice as to where to draw lines? E.g., if the computations take less time to do on a server than to distribute, then maybe don't?

Re: Guide to Serverless Architecture

#95

Post by wahnfrieden » Thu, Dec 21, 2017, 11:09 PM UTC

Cthulhu_ wrote: post #45

buf wrote: post #2

> Drawback of Serverless: Vendor lock-in, statelessness, local testing, cold/warm start perf, security, deployment, execution, monitoring, remote testing, debugging. Excuse me? Let's use lambda for what it was meant to do, not replace your entire stack.

I'd expect a lot of those are things that should be supplied by AWS, especially things like providing a service that runs the code exactly as it would on AWS itself (which should fix the testing / debugging); monitoring and security should mostly be builtin.

AWS does have solutions to many of these: SAM Local, X-Ray, Codestar, for instance.

Re: Guide to Serverless Architecture

#96

Post by gitgud » Fri, Dec 22, 2017, 4:56 AM UTC

viraptor wrote: post #25

twic wrote: post #23

Earlier quoted context omitted.

This is exactly what PaaS's like Heroku have been doing for years, right? Isn't Lambda just an even more locked-in PaaS?

Heroku is a bit higher level. If you're using heroku, you're using their blocks and their methods of passing traffic, logging, etc. With lambda, it's just a function. You have to connect everything yourself, not you can do it exactly the way you want.

You can redeploy a Heroku app to many other servers and platforms relatively easily.

However, I'm not sure you can do the same with AWS Lamda Functions. To mean, this means it is like a lock-in.

Re: Guide to Serverless Architecture

#97

Post by not_kurt_godel » Fri, Dec 22, 2017, 7:40 AM UTC

icebraining wrote: post #65

neya wrote: post #63

For me the BIGGEST gain of using serverless architecture is security. For example, this year I started two ecommerce platforms. One's a digital delivery e-shop - selling ebooks, training and stuff and the other is a physical delivery e-shop. Normally, I'd write my own Phoenix/Rails app, but this time, I decided to go serverless for my furniture shop and wrote it all in Jekyll. Yes, the static site builder. I use netl…

If static sites are now also Serverless, the word has lost all meaning. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.

If your static site is running on a physical or virtual host that you manage, then it is not serverless. Not a difficult distinction?

Re: Guide to Serverless Architecture

#98

Post by viraptor » Fri, Dec 22, 2017, 8:02 AM UTC

gitgud wrote: post #96

viraptor wrote: post #25

Earlier quoted context omitted.

Heroku is a bit higher level. If you're using heroku, you're using their blocks and their methods of passing traffic, logging, etc. With lambda, it's just a function. You have to connect everything yourself, not you can do it exactly the way you want.

You can redeploy a Heroku app to many other servers and platforms relatively easily. However, I'm not sure you can do the same with AWS Lamda Functions. To mean, this means it is like a lock-in.

It's just code with basic function entry point. You may get your parameters and configuration in a different way, but not much else changes. There are only so many ways to call some code.

Re: Guide to Serverless Architecture

#99

Post by icebraining » Fri, Dec 22, 2017, 8:47 AM UTC

not_kurt_godel wrote: post #97

icebraining wrote: post #65

Earlier quoted context omitted.

If static sites are now also Serverless, the word has lost all meaning. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.

If your static site is running on a physical or virtual host that you manage, then it is not serverless. Not a difficult distinction?

Right, but we've had that since the start of the web. I get that Serverless is not a very good name, but there's a reason why it was coined now - it was meant to describe a particular kind of service that appeared recently. If we're going to apply it backwards to any web hosting service where the host was not explicitly managed, the term becomes much less useful.

Re: Guide to Serverless Architecture

#100

Post by icebraining » Fri, Dec 22, 2017, 8:49 AM UTC

cryptonector wrote: post #91

icebraining wrote: post #65

Earlier quoted context omitted.

If static sites are now also Serverless, the word has lost all meaning. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.

"Serverless" is itself a bit of a misnomer. The point seems to be to distribute stateless sub-computations. Whoop dee doo. At some point you need a "server" to modify application state. A static site has no state modifications, so it actually is serverless in this sense of having stateless computation.

I get it, but while the name is not very good, there's a reason why it came about now, despite the fact that we've had static website hosting for decades. It was coined to describe a particular kind of service, and retrofitting it makes it less useful and more prone to confusion.