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

Serverless Architectures

martinfowler.com

Post reply on HN
Print view View original

101–110 of 215 posts

Re: Serverless Architectures

#101

Post by happyslobro »

rockmeamedee wrote: post #93
happyslobro wrote: post #52

For my first serverless project, I built a service that manages an advertising account, by analysing ads and optimising the spend spread for a configured goal. I was surprised to find that one of the most difficult aspects, was in throttling outgoing API requests. Basically, I needed to avoid abusing a 3rd party service by hammering it with parallel or rapid fire requests. I discovered all kinds of weird solutions: -…

I'm no experienced Lambda user either, but here's a couple helpful things I've found: * I think API Gateway can throttle requests. Not sure if that was part of your pipeline or if your lambda had a different trigger. * There is a Town clock SNS event https://alestic.com/2015/05/aws-lambda-recurring-schedule/

Ah yes, I forgot about that. What I really needed from the clock was for it to somehow only trigger lambdas that actually had work to do. I didn't like the idea of them polling once per second per function, when 99℅ of the time, they would have nothing to do. I guess "town clock" was a mistake on my part.

Re: Serverless Architectures

#102

Post by prodigal_erik »

themartorana wrote: post #16
nickpsecurity wrote: post #9

Earlier quoted context omitted.

You may be misunderstanding the concept of Lockin. It says you are stuck with whichever vendor you used that created the lockin. Benefits of services always seem to increase. So, whatever benefits exist for a current service isn't worth forgoing all potential benefits of all future competitors. That's what lock-in creates. That's why it's always bad for anything meant long-term. Now, short-term projects that can disa…

I still see this as flawed. Avoiding all vendor lock-in means making every possible piece of software you write completely generic - no GIS from Postgres, no third-party queue/messaging servers/services - none of it. We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of…

Getting locked into free software like PostgreSQL is a lot less risky than getting locked into a proprietary system whose owner could gouge you or evict you at your most vulnerable moment.

Re: Serverless Architectures

#103

Post by zwily »

cyberpanther wrote: post #96

Serverless sounds like CGI evolved past needing a server anymore. Oh yeah and remember spawning CGI processes for every request never scaled well. :-)

Lambda does keep processes running and reused between requests if they're coming quickly. You do, however, only get to handle one request at a time which is not the norm with node backends.

Re: Serverless Architectures

#104

Post by zpallin »

I think a major problem with Serverless architecture, as much as it is awesome, is that to manage it you would need to be already familiar with the underlying systems that provide it. Hence, it would imperative that you already have worked with the architecture you are planning on replacing.

Unless there is some elegant factor to Serverless that I am missing. I just can't shake the feeling that at the end of the day this is just a sales tactic.

Nevertheless, I opt to use serverless BaaS solutions whenever I can afford to.

Re: Serverless Architectures

#105

Post by Sanddancer »

bobbyi_settv wrote: post #75
bronson wrote: post #59

Earlier quoted context omitted.

So my car is engineless if I never look under the hood?

Your car isn't engineless because when its engine dies, you will know about it and have to do something. S3 is serverless because if one of the servers storing my files die, I have no way of even knowing it happened.

S3's had downtime, and had data loss incidents. S3's only serverless if you believe Amazon's infallible.

Re: Serverless Architectures

#106

Post by krakensden »

themihai wrote: post #99
idunno246 wrote: post #18

Earlier quoted context omitted.

we use dynamodb heavily, among other services, and the lockin question always comes up. and its like, would you rather get to market a month earlier, or spend a month building something just in case one day it doesn't work - it seems like a no-brainer that lockin is often a cost to push off to later especially considering you may never have to pay it.

The question is how much are you willing to trade-off for the managed infrastructure benefits. The database is a level but BaaS is a totally different level. Next would be the programming language. Would you feel comfortable to base your project on a proprietary amazon programming language? (i.e See Apex of SalesForce). Maybe yes but I can't see this becoming mainstream anytime soon. It would be a backward step. I us…

GAE is a great example of the lockin problem- they changed the pricing model, bills skyrocketed, and it was super hard to get out.

Re: Serverless Architectures

#107

Post by prodigal_erik »

jakub_h wrote: post #31
themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

Then why not have standardized APIs? You could just switch implementations, then, if you stop liking your current vendor. (Or maybe the future lies in call-by-meaning architectures and automated adapter generation?)

Someday a standardized API will become popular enough that AWS will need to support it, but they aren't going to do anything to hasten it.

Re: Serverless Architectures

#108

Post by dboreham »

bronson wrote: post #59
dboreham wrote: post #55

Earlier quoted context omitted.

In this context "server" doesn't mean "entity listening on some network endpoint, providing some service to network-connected clients" (which is I think the definition you're assuming). Instead "server" here means "Unix Machine". Thus "serverless" means software and humans writing and deploying said software that do not need to know anything about /etc/ and installing packages and disk partitioning and swapping and w…

So my car is engineless if I never look under the hood?

I didn't invent the terminology. Like many many things in this business the terms used are often confusing/wrong/overloaded/re-invented-from-the-1980's and so on. Part of the landscape unfortunately.

Re: Serverless Architectures

#109

Post by golemotron »

mseebach wrote: post #6
themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.

> You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.

For a particular use you certainly can. Some problems have hard constraints. Freedom from lockin is a common one.

Re: Serverless Architectures

#110

Post by WalterSear »

mpdehaan2 wrote: post #71

One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates…

With that in mind, serverless architecture seems to be a micro-optimization that is of the greatest benefit to enterprise customers whose scale is large enough to benefit from reducing their server load to the barest minimum, at the cost of greatly increasing development costs.

I don't see how this would be much fun to work on in a team. We have enough trouble her squabbling over who gets to use the staging server next.

Post reply on HN