Live data from Hacker News

Serverless Architectures

martinfowler.com

91–100 of 215 posts

Re: Serverless Architectures

#91

Earlier quoted context omitted.

No, the idea is simple - the servers are invisible to the user, he doesn't know what or how many are in use. Since the servers are completely abstracted away, they could have just as well not be - hence serverless. An analogy escapes me but I sure there are some.

> they could have just as well not be That's a weird logical leap. Let's make the servers not be by unplugging them. How's the abstraction working now?

I think you're misunderstanding. I read it as "they could just as well not be servers". It could be Diamond Age rod logic. It could be processing implemented on quantum foam. It could be gnomes. The point is that from the user's perspective, they no longer have to think about servers.

Re: Serverless Architectures

#92
post #85

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…

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…

> So obviously there are still servers there, but they are largely invisible to the developer.

This would only be true if the abstraction were not leaky. Frankly, upon a very cursory inspection, my opinion is that AWS Lambda leaks like a sieve.

Re: Serverless Architectures

#93

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/

Re: Serverless Architectures

#94
post #85

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…

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…

I would call that a deployment strategy, not an application architecture.

Re: Serverless Architectures

#95
It doesn't seem the author knows how network programming works. This is all high level abstraction and diagrams, but no simple comparison of what are the pro/cons, what are the constraints, etc.

Re: Serverless Architectures

#98

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…

You're missing the point in that _you_ don't have servers. Just as cloud is "someone else's computer" -- serverless is someone else's server.

That's true for all types of cloud providers, but we don't call them serverless.

This is marketing bullshit for microservice architecture. It just sounds better with some added philosophy.

Re: Serverless Architectures

#99

Earlier quoted context omitted.

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…

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 use some managed/proprietary services too but I always consider it a liability/short term workaround. Most of the AWS services were successful because they are based on open source/3rd party software (i.e. the OS, DB engine etc). BaaS changes totally changes that. It's all proprietary except the programming language which may not be one of your preferred one either. Google lost a lot of ground on cloud service because it promoted a proprietary platform(GAE). The concept was great but we can see how it played out. These are the reasons why I think the current BaaS offers are dead on arrival.

Re: Serverless Architectures

#100
post #39

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

Adrian Cockcroft: "If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless." https://twitter.com/adrianco/status/736553530689998848

No, call them extremely fast lifcycle servers.
Post reply on HN