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

121–130 of 215 posts

Re: Serverless Architectures

#121

Post by freyr »

matthewaveryusa wrote: post #63
SNvD7vEJ wrote: post #45

What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hoste…

I think Fowler tends to do this in general. Here's a comment from 2 years ago I posted along the same lines: https://www.reddit.com/r/programming/comments/2051mx/microse... (And yes, 2 years ago I was a little more violent with my wording. Time has taught me things.)

This article wasn't written by Fowler.

Re: Serverless Architectures

#122

Post by beat »

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…

But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about?

For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.

Re: Serverless Architectures

#123

Post by beat »

spriggan3 wrote: post #36
davidw wrote: post #13

Earlier quoted context omitted.

Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.

> Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event. The difference is one doesn't have access to Lambda infrastructure itself. IF I write an entire app in XYZ lang, I can still run it on my own server or make it an executable and call the code through RPC. If I base all my work on a third party vendor infrastructure I can't replicate it requires…

Why would you have to re-write your app from scratch? I'm assuming most of your actual business logic is in the Lambda code and the data model. Lambda wraps things pretty tight anyway, so just write a shim layer, and lift-shift your code to a new platform.

Re: Serverless Architectures

#125

Post by inopinatus »

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…

There's certainly a need for offline prod-like environments/harnesses for serverless development. However I don't think that's a criticism of the architecture, simply a reflection of the immaturity of the style.

Re: Serverless Architectures

#127

Post by moezb »

srcreigh wrote: post #117

One issue people are talking about is vendor lock-in. I would like to note that this drawback is only valid for non-prototype software. For prototypes, hackathons, or "one time use" websites, these BaaS tools (such as Firebase) are essential. Here is a case study: Last year I was working on an SMS app, QKSMS [1]. We offered a premium version for $2. We did a promotion on reddit where we gave away 10k free premium ver…

We got around 15,000 downloads that day (compared to the usual 300-500), and 10% converted to paid users

Re: Serverless Architectures

#129

Post by inopinatus »

rhinoceraptor wrote: post #15

Aren't 'serverless' PAASs just a reinvention of PHP hosting?

No. For example, Lambda has no service endpoint for call/response. The platform starts a function container, and passes events to that function instance until the queue is drained.

It is not at all a client/server model unless you wrap API Gateway around it as an event source.

Re: Serverless Architectures

#130

Post by snom380 »

WalterSear wrote: post #110
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 ne…

I'm pretty sure that if you're considering using Lambda, you'd want to automate creating and deploying the Lambda functions in such a way that you could create any number of them for each developer to play with.

That said, the problem with debugging stands (for AWS lambda, at least).

Post reply on HN