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

51–60 of 105 posts

Re: Guide to Serverless Architecture

#51

Post by test1235 »

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…

I get this from your site:

Security risk detected: Trojan.Gen.NPE

Re: Guide to Serverless Architecture

#52

Post by Blackstone4 »

abd12 wrote: post #34
Vinnl wrote: post #17

Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…

* Disclosure: I work for Serverless, Inc. > it was relatively easy for me to write a really simple Express server, transform the Express requests into the API Gateway format, and convert the API Gateway response format back into Express format. For those interested in this route, there's a plugin[0] for the Serverless Framework that handles this conversion for you. Honestly takes 1 minute to convert an existing Expre…

If you need to make a disclosure, please could you do it at the start of your statement. That way the user has context on what you write :)

Re: Guide to Serverless Architecture

#53

Post by Vinnl »

alien_at_work wrote: post #31
Vinnl wrote: post #17

Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…

>- Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. I feel like this is the most overstated draw back in cloud computing by far. I don't know how most people write their code but me and most people I've ever worked with have a natural tendency to seperate out abstractions to protect you from "likely to change" parts of your application. In fa…

I mostly share your view, and hoped not to overstate it: it's clearly a drawback, but in all, not enough to turn me away from it. By being aware of this drawback and keeping an eye on where the lock-in is, it would not be _that_ much work to rewrite the pain points to work with another provider. That said, it's still a good idea to be aware of the drawback.

Unfortunately I can't edit my post anymore, but I should've noted that I'm overall happy with my serverless setup.

Re: Guide to Serverless Architecture

#54

Post by Vinnl »

abd12 wrote: post #34
Vinnl wrote: post #17

Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…

* Disclosure: I work for Serverless, Inc. > it was relatively easy for me to write a really simple Express server, transform the Express requests into the API Gateway format, and convert the API Gateway response format back into Express format. For those interested in this route, there's a plugin[0] for the Serverless Framework that handles this conversion for you. Honestly takes 1 minute to convert an existing Expre…

If you want to use Serverless (the package, not the architecture) and are converting an existing Express app, that might indeed be a good idea. I was greenfielding, and neither of these conditions were true for me.

Re: Guide to Serverless Architecture

#55

Post by Vinnl »

nickjj wrote: post #36
Vinnl wrote: post #17

Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…

Funny thing is, I just wrote about this the other day[0] and I shared some of your drawbacks too. Personally I'm staying away from Serverless for now. [0]: https://nickjanetakis.com/blog/should-your-next-project-be-b...

It's too bad I can't edit my post anymore, as I should've added that overall, the drawbacks are not enough to draw me away from the advantages. I also should've noted that I'm not using Serverless (the software).

Re: Guide to Serverless Architecture

#56

Post by Vinnl »

sudhirj wrote: post #46
Vinnl wrote: post #17

Drawbacks I experience: - Vendor lock-in: although I try to minimise this and have a clear picture of where the lock-in lies, it is very much present. - Cold/warm start: this is somewhat annoying. I haven't set up keepalive requests yet, but they feel like an ugly hack, so I'm not sure if I'm going to or if I will just suck it up. - Security/monitoring: having fewer functions make this less of a worry, but it's still…

> - Vendor lock-in Try something like https://github.com/apex/up - write the code as regular servers, and it'll convert your entire server into a function. > - Cold/warm start Should be a temporary annoyance - I'm sure all the providers are already hard at work on fixing this. > - Security/monitoring Easier to do than regular servers - most FaaS systems have monitoring built in, and collect whatever you write to STDO…

I didn't really feel like the benefits of packages like Serverless and Apex were worth it for me, as they're not solving that big of a problem, and you'd replace it with lock-in to even less mature products. That said, the current lock-in is not that bad, just good to be aware of and keep an eye on.

I hope that the annoyances are temporary indeed, but that doesn't buy me anything today :) That said, I think for almost all my drawbacks it holds true that they're likely to grow less and less significant, so if serverless is not worth it for you today, it's still worth it to keep an eye on.

Edit: I should perhaps also link the shim that I'm using. It's slightly longer, also specific to my relatively loose configuration of API Gateway, and also simulates S3's client-side file upload functionality. As you can see, it's really not that bad: https://gitlab.com/Flockademic/Flockademic/blob/dev/app.ts

Re: Guide to Serverless Architecture

#57

Post by abd12 »

Blackstone4 wrote: post #52
abd12 wrote: post #34

Earlier quoted context omitted.

* Disclosure: I work for Serverless, Inc. > it was relatively easy for me to write a really simple Express server, transform the Express requests into the API Gateway format, and convert the API Gateway response format back into Express format. For those interested in this route, there's a plugin[0] for the Serverless Framework that handles this conversion for you. Honestly takes 1 minute to convert an existing Expre…

If you need to make a disclosure, please could you do it at the start of your statement. That way the user has context on what you write :)

Noted and updated! Thanks for the tip.

Re: Guide to Serverless Architecture

#59

Post by fuball63 »

dpweb wrote: post #3

CGI scripts with a new name. Lambda and the like are interesting but any system is a composable set of components. You can say the same about Object oriented programming or func programming. separation of concerns but on the network. Server functions arent a panecea cause you still have to manage all the other pieces. An elegant thing would be your entire app is in that single lambda but without state there goes your…

I'm actually working on this concept; a serverless platform utilizing the CGI standard. I call it bigCGI. It addresses a lot of the drawbacks another user mentioned:

Vendor lock in: The CGI standard is supported by almost every server technology. Plus bigCGI is open source and can be self hosted.

Security/Monitoring: one of my biggest challenges, but separate processes, by their nature, offer separation of resources.

Debugging: CGI scripts are super easy to run locally. I've also configured bigCGI to collect STDERR from apps.

Statelessness: CGI is a stateless standard.

If anyone is interested in this, I'd love extra eyeballs on it, especially for security. https://github.com/bmsauer/bigcgi (Please excuse the bad README, I'll update it next chance I get)

Re: Guide to Serverless Architecture

#60

Post by fuball63 »

One thing I would like to see in articles like this are more concrete use cases for using serverless. The article begins talking about the concept as though you should write your entire app in serverless, and then in their case study, use serverless as a background process to convert image types.

The other use case I always come across is image scaling.

I'd be interested if anyone would like to share their use cases as entire apps or background processes.

Post reply on HN