Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Guide to Serverless Architecture

simform.com

Post reply on HN
Print view View original

21–30 of 105 posts

Re: Guide to Serverless Architecture

#21

Post by hopfog »

tabdon wrote: post #16
hopfog wrote: post #13

I tried the excruciating task of building a real-time multiplayer game with server-side authority using only Firebase and Google Cloud Functions. Basically I handle all the logic in Firebase rules and lambdas. Any destructive action goes through a GCF that updates the Firebase Realtime Database. Actions that happen often (like moving) are updated directly by the client but validated with some overly complicated Fireb…

That sounds really cool. I'd like to check it out. Now that you've been through it, would you do it again? Or stick to a more traditional architecture?

You can play it at https://tombs.io/

It's pretty much a collaborative and social experiment where I wanted to explore the concept of using in-browser cryptocurrency mining as a monetization and bot fighting method (something I had a problem with in the original Ludum Dare entry it's based on). That's a different discussion though. (You need to manually start the mining and you can explore the map without doing it. It's only when digging and chatting it's required.)

I'm actually planning on rewriting the whole backend in a more traditional Node.js + WebSockets stack so no, I probably wouldn't do it again for this type of application. However, I will probably use it again for other things.

Re: Guide to Serverless Architecture

#22

Post by tyingq »

maitrik wrote: post #9

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to: * Manage/deploy servers * Monitor/maintain/upgrade servers * Figuring out tools to deploy your app to your serv…

Except for max run time limitations and recurring long startup times, sure. No free lunch.

Re: Guide to Serverless Architecture

#23

Post by twic »

maitrik wrote: post #9

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to: * Manage/deploy servers * Monitor/maintain/upgrade servers * Figuring out tools to deploy your app to your serv…

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

Re: Guide to Serverless Architecture

#24

Post by mmjaa »

hopfog wrote: post #21
tabdon wrote: post #16

Earlier quoted context omitted.

That sounds really cool. I'd like to check it out. Now that you've been through it, would you do it again? Or stick to a more traditional architecture?

You can play it at https://tombs.io/ It's pretty much a collaborative and social experiment where I wanted to explore the concept of using in-browser cryptocurrency mining as a monetization and bot fighting method (something I had a problem with in the original Ludum Dare entry it's based on). That's a different discussion though. (You need to manually start the mining and you can explore the map without doing it. It…

Nice little hack .. you get Monero, and I get .. 'tombs.io coins' that can be used to keep me playing each level while you mine .. more Monero!

Such a great idea, I think I should do it as well .. ;). But I won't use Firebase, following your advice ..

Re: Guide to Serverless Architecture

#25

Post by viraptor »

twic wrote: post #23
maitrik wrote: post #9

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to: * Manage/deploy servers * Monitor/maintain/upgrade servers * Figuring out tools to deploy your app to your serv…

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.

Re: Guide to Serverless Architecture

#26

Post by sidhuko »

What I've found having to use serverless is the local development tools are broken. You'll find cloudformation is the only way to reliable manage all the proprietary paid for services which will require you to read several documentation on various tools (kinesis, dynamodb stream or fifo, standard queues) to work out which one might work. To find out it doesn't necessarily work in your applied function (CloudWatch Insufficient Alarms I'm looking at you). So you then have a choice to use cloudformation and another deployment tool to push your services. This is more typical after you've given up trying to manage dynamodb-local across platforms for your codebase.

Re: Guide to Serverless Architecture

#27

Post by k__ »

wahnfrieden wrote: post #18
emj wrote: post #5

Earlier quoted context omitted.

More like CGI scripts with a loadbalancer that promises to run your application on a host with enough memory within at most 600ms. That solves an actual problem with CGI scripts, but I really would love to see more tiers with lower latency brackets, sub 10 milisecond should be doable for certain lambdas and costs.

The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO t…

What are good alternatives to nodejs that are better suited for this kind of architecture?

Re: Guide to Serverless Architecture

#28

Post by tehramz »

Dawny33 wrote: post #10

> grouping a bundle of functions together behind an API gateway, you’ve created a microservice Always beats me why people don't warn the readers about the almost impossible nature of logging and monitoring such systems :/

Because most devs aren’t the ones that will need to worry about how it’s going to be monitored once deployed. Not to mention troubleshooting a billion micro services when something breaks.

Re: Guide to Serverless Architecture

#29

Post by songshu »

I’m looking forward to Amazon Fargate which is less extreme than Lambda but still server less in some sense. Basically you can still write proper apps (Spring Boot apps in my case) but, so long as you containerize them, you don’t have to provision servers, just tell Amazon what resources they need and how many instances you want.

Re: Guide to Serverless Architecture

#30

Post by methodin »

maitrik wrote: post #9

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to: * Manage/deploy servers * Monitor/maintain/upgrade servers * Figuring out tools to deploy your app to your serv…

And a huge plus - not having to pay if nothing is using it (generally).
Post reply on HN