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

31–40 of 105 posts

Re: Guide to Serverless Architecture

#31

Post by alien_at_work »

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 fact, if you use Spring boot in Java it already abstracts away a lot of the differences for various cloud scenarios.

Further, in the worst case you have to rewrite some stuff. Before you skip a solution for fear of vendor-lock-in you should attempt a cost analysis: how much will you save on these platform-specific advantages and how does that offset your cost of rewriting when some other solution becomes more desiable? How long will it take to reach break even and how does that time compare to how often software is just rewritten or abandoned in your organization anyway?

Re: Guide to Serverless Architecture

#32

Post by printf_kek0 »

not_kurt_godel wrote: post #11
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…

> CGI scripts with a new name "Electric lightbulbs: candles with a new name"

Weak argument from analogy given the (lacking) degree of relevant similarity. See: On Analogy, A System of Logic by John Stuart Mill for a thorough analysis of analogical reasoning:

https://ebooks.adelaide.edu.au/m/mill/john_stuart/system_of_...

Re: Guide to Serverless Architecture

#34

Post by abd12 »

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 Express app to serverless.

Shameless plug but I wrote a blog post walkthrough for anyone interested --> https://serverless.com/blog/serverless-express-rest-api/

[0] - https://github.com/dougmoscrop/serverless-http

Re: Guide to Serverless Architecture

#35

Post by mirko22 »

tehramz wrote: post #28
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.

How do you figure that? Who else should worry about it?

Re: Guide to Serverless Architecture

#36

Post by nickjj »

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

Re: Guide to Serverless Architecture

#37

Post by bpicolo »

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…

Which will never accumulate a backlog because it is happy to kill your task. ;)

Re: Guide to Serverless Architecture

#38

Post by dschep »

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.

The post isn't loading so I don't know exactly what it's in reference to (AWS lambda, the framework, the more generic idea?). But, the serverless framework[0] supports all major cloud providers (AWS, Google, & Azure) as well as self-hostable options like OpenWhisk and Kubeless.

[0] https://github.com/serverless/serverless

Re: Guide to Serverless Architecture

#39

Post by bonesss »

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.

All those issues can be postfixed with "... on Lambda". They're specific challenges that will come up when using Lambda as advertised in production :)

As with most system improvements we're not really talking about removing complexity, just reshuffling it into a new and more pleasing form. Lambda will let you wildly simplify some things, but pain points otherwise accounted for in larger deployments will get moved onto your lambda services to compensate.

Cold starts, for example, aren't generally an issue at the function level in web applications as the application itself is/isn't warmed up. By introducing a Lambda back-end you get to take a stance on that per-function while caring less about it in your webapp front-ends.

The OP is trying to highlight where these new and less obvious challenges arise in the new stack, not pushing Lambda as the end all of app dev.

Re: Guide to Serverless Architecture

#40

Post by blowski »

methodin wrote: post #30
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).

The downside being that you pay a lot more if it gets used a lot.
Post reply on HN