Live data from Hacker News

Guide to Serverless Architecture

simform.com

101–105 of 105 posts

Re: Guide to Serverless Architecture

#101

Earlier quoted context omitted.

If your static site is running on a physical or virtual host that you manage, then it is not serverless. Not a difficult distinction?

Right, but we've had that since the start of the web. I get that Serverless is not a very good name, but there's a reason why it was coined now - it was meant to describe a particular kind of service that appeared recently. If we're going to apply it backwards to any web hosting service where the host was not explicitly managed, the term becomes much less useful.

> If we're going to apply it backwards to any web hosting service where the host was not explicitly managed

But that's the thing - there is no "the host" any more. In the days of yore, if the physical machine hosting your site failed, your site went down. Maybe some rare services had failover and redundancy to some degree, but they were primitive at best compared to AWS (and the other serverless providers, for that matter) today. There was simply no comparison to the ecosystem that exists today. Have you ever had to manage production hosts before? It simply boggles my mind how many people throw out these "the cloud is just somebody else's computer" comparisons - like they've never had to diagnose JVM garbage collection thrashing at 3 in the morning before, or dealt with a server that goes down due to 100% of disk space being consumed by logs, or patch a massive fleet in a matter of hours in response to a CVE, or a power outage, or a hyper-localized network event in a data center, or any of the other million+ super annoying problems that come with managing physical hosts, and to a large degree, VMs/VPSes.

Re: Guide to Serverless Architecture

#102

Earlier quoted context omitted.

Right, but we've had that since the start of the web. I get that Serverless is not a very good name, but there's a reason why it was coined now - it was meant to describe a particular kind of service that appeared recently. If we're going to apply it backwards to any web hosting service where the host was not explicitly managed, the term becomes much less useful.

> If we're going to apply it backwards to any web hosting service where the host was not explicitly managed But that's the thing - there is no "the host" any more. In the days of yore, if the physical machine hosting your site failed, your site went down. Maybe some rare services had failover and redundancy to some degree, but they were primitive at best compared to AWS (and the other serverless providers, for that m…

I can't tell if you're agreeing or disagreeing with me :) my point is exactly that: what AWS et all are offering now is not like what we used to have, so we should use the term "serverless" for stuff we already had, like fully-managed static sites.

Re: Guide to Serverless Architecture

#103
post #38

Earlier quoted context omitted.

> - 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://…

I may be naive (or just witless), but don’t you kind of end up with vendor lock-in to serverless itself? The first step in their example is “login to your serverless account”.

You have to make a choice at some level of the stack, for me, that was serverless as the deployment framework. You could probably use terraform or ansible + some custom scripts, but then you could argue you're locked into terraform or ansible ;)

The login thing isn't actually necessary (or if it is, that's new)

Re: Guide to Serverless Architecture

#104

Earlier quoted context omitted.

> If we're going to apply it backwards to any web hosting service where the host was not explicitly managed But that's the thing - there is no "the host" any more. In the days of yore, if the physical machine hosting your site failed, your site went down. Maybe some rare services had failover and redundancy to some degree, but they were primitive at best compared to AWS (and the other serverless providers, for that m…

I can't tell if you're agreeing or disagreeing with me :) my point is exactly that: what AWS et all are offering now is not like what we used to have, so we should use the term "serverless" for stuff we already had, like fully-managed static sites.

Ha, I thought I was disagreeing, but having gone back and re-read just now, I realize I must have misread because, yes, I agree with you 100%. I was also partially expressing general grist at the naivetë of some of the other commenters.

Re: Guide to Serverless Architecture

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

sub 10 ms would only work if they had an instance running and warm, ready to take requests - if they still have to look up your function, provision a machine, interpret it etc it's easy to go past that. 600ms is still respectable if it's from a "cold start". But if you've got time critical applications maybe serverless is not for you.

I know it's an edge case that doesn't fit Amazon Lambdas atm. I do it by hand ATM, so I know it can be done, but sure I run it on too many preowned servers to handle peaks. Controlling serverless resources in a more fine grained way is a way to use your servers more effectively.
Post reply on HN