Live data from Hacker News

Back to the '70s with Serverless

evrl.com

111–120 of 310 posts

Re: Back to the '70s with Serverless

#111
post #103

The right answer to this, as usual, is probably somewhere in the middle. Perspectives like this are pessimistic, but important because the industry has age bias and yet we need to understand where technology might be going full circle. But instead of taking that as a bad thing and stopping there, we need to understand why and how the context is different this time and what that means. Managed services in general seem…

> Perspectives like this are pessimistic, but important because the industry has age bias and yet we need to understand where technology might be going full circle. But instead of taking that as a bad thing and stopping there, we need to understand why and how the context is different this time and what that means.

I feel like this is a critically important aspect of software engineering that we are missing. I want to say this is because the field is so young relatively speak. The fundamentals have been changing so rapidly and are truly not completely well understood enough to be captured as reliable axioms. So instead we go down this path of recreation, sometimes with improvements, sometimes without.

In a hundred more years maybe things will be better, but for now this is taking on a bit of a vicious cycle. Literally people in the wrong age group are getting "moved" out of the scene not to mention the thousands of others in the "wrong" industries, tech stacks, and culture.

Software in today's age is a fickle industry when it comes to people...

Re: Back to the '70s with Serverless

#112

> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…

From my anecdotal evidence, people are attracted to serverless because they spend way to much on aws and they hope that by turning things off they'll spend less. Not many people have the problems solved by a serverless architecture (or they need more freedom), which is why it's not as common as just running your own long running instances.

Not denying your experience, as it's probably true that the folks you've seen pursuing serverless may be misguided, but I want to contest your last point where you say "not many people" would benefit from serverless.

I would say that "literally any single person" benefits from serverless if they don't have the skills, knowledge, or time to handle the server/infrastructure responsibilities that come from running software.

If I'm a one man development shop with a sufficient budget, I'll probably find it far more productive when using serverless architecture to host my business logic than not.

Re: Back to the '70s with Serverless

#113
post #109

> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…

I totally see the advantages, but how many benefit from that? Most companies don't need to deploy on servers world-wide, and don't need infinite scaling. And cloud debugging has its issues too: I remember endless fudging with print statements, deploying once more and waiting for the changes to propagate in a AWS lambda handler, because the bloody thing simply wouldn't run locally.

> I totally see the advantages, but how many benefit from that? Most companies don't need to deploy on servers world-wide, and don't need infinite scaling.

That’s a good question. I think serverless has a lot to offer, global compute, and infinite scaling are a subset of features. I think it really comes down to your specific workload—it’s definitely not a be all end all silver bullet

One example I can think of I mentioned in another comment in this article which I have pasted below:

the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me. Deployments and system upgrades were very toilsome. The dev lead would spend a few hours deploying new code and we’d only do it around midnight in case there was a problem (our customers were almost entirely US based). I spent a lot of my time automating OS upgrades on the web servers behind our proxy. All of this work would be unnecessary for that small company if they were using serverless. Additionally, as mentioned before, the majority of their traffic was during the day so they could have scaled down automatically at night, cutting costs. Would this be cheaper than running machines 24/7? I’m not sure, but I could see why you’d be interested in at least looking into it

Re: Back to the '70s with Serverless

#114

Earlier quoted context omitted.

Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…

Yes, "the cloud" is bunk from any technical point of view. It exists to shift CapEx to OpEx for accounting. Any technical considerations are a distant third place on the list.

Leasing programs did that well before the cloud ever came along

Re: Back to the '70s with Serverless

#115

Earlier quoted context omitted.

Yes, "the cloud" is bunk from any technical point of view. It exists to shift CapEx to OpEx for accounting. Any technical considerations are a distant third place on the list.

That can happen without serverless - renting VMs is OpEx enough.

Yes, if you manage to shift the responsibility of maintaining these VMs on the developer positions you already have.

Re: Back to the '70s with Serverless

#116
post #18

> XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster. There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean…

> the only fundamental difference at that level is that XML has a built-in mechanism for metadata referring to a file's own schema, while in JSON (and I believe the others, even though I've used them less) the schema is not linked from within the file itself

As long as you're using plain DTDs for your schema, yes. Like early XML-based config languages such as idk JSPs/web-app and Jakarta (née J2EE) deployment descriptors used and still use. But later XML configs use XML Schema and namespaces, which are similarly detached from an instance document as eg JSON Schema and the others you mention [1].

[1]: http://cmsmcq.com/2005/xml2005-166.html "How schema-validity is different from being married"

Re: Back to the '70s with Serverless

#117

> You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing. I’m sorry but this absurd and blatantly ignores the reasons why people choose serverless. No mention of scale to zero, virtuall…

Why is the alternative to serverless, colocating servers in a DC? The alternative is renting VMs from those same clouds. It works fine and is cheaper when you work on software that actually has users. It also doesn't result in the cloud provider cramming a crappy under-baked programming model down your throat. Per request pricing and "scaling to zero" is just old fashioned unbundling. You are selling a smaller quanti…

>when you work on software that actually has users.

And if I don't have users? What's the number of 'users' where it becomes cheaper?

Most of the web is idle 95% of the time. Theres no reason people should pay for so much VM time that they're not using.

Re: Back to the '70s with Serverless

#118

Earlier quoted context omitted.

Everyone's chasing "scalable", mostly for no reason at all. There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. A few minutes per month is the most devops any startup would need to do in reality running their own VMs or servers, after an hour or two of setup. And that hour or two is often less than…

> There's also this enduring myth you see repeated even here of how much saving there is by not having "devops", when only very big companies needed them in the first place. I dunno, the first company I worked at was very small, under 30 people, sales included, and I was hired on as an SA. If they were using serverless, they would not have needed to hire me. Deployments and system upgrades were very toilsome. The dev…

All you needed was PaaS, which has existed for a long time. Or the even older name: managed services, offered by pretty much any decent hosting provider for decades.

I remember using companies like MediaTemplate and FullControl 10 years ago for clients and not having to worry about OS updates.

Re: Back to the '70s with Serverless

#119

Earlier quoted context omitted.

I find your quote here and the follow up seriously unconvincing. You know what a miserable workflow is? Preparing all my build scripts according to the half baked build tool that our in-house Deployment team cooked up to use fabric to spray my deployment onto a bunch of nodes in our data center, all the tests and script linting pass, so then I go push it through our CI/CD pipeline (which can’t do the above tests for…

This is the type of cultural accuracy I've been looking for. Are all the commenters in this thread just cynical engineers who really can't see past their own narrow world view? I get snake oil is snake oil, but there is such a strong brand of "anything new must be snake oil" that runs through the HN community it boggles my mind. The world is actually full of complex systems. And only once these systems are in place d…

People on this site act as if they have all the understanding and knowledgeable necessary to decry something like cloud vendors because clearly these same people know better than everyone else and these are actually simple problems if only we had their perspective and knowledge.

A 1000 times this. These are solved problems. Anything new has to be better to be taken seriously.

Re: Back to the '70s with Serverless

#120

Earlier quoted context omitted.

> Right up until something crashes or some hardware fails. Unlike the public cloud where Nothing Ever Goes Wrong (tm). There are never brownouts. There are never latency spikes. No undocumented quota limits. Documented but confusing quota limits. Unexpected performance issues caused by other customers. Forced upgrades. Forced patching. Shock bills. No siree Bob, that kind of thing just doesn't go on in the public clo…

I fail to see how this supports your claim that you can get by with "a few minutes per month" of devops. In fact, it's a classic red herring. Your original claim is quite unrealistic and you'd do well to retract it. It's bad advice both for public cloud and for self-managed efforts alike.

But it is a few minutes per month. A properly architected application won’t depend on a single server so a hardware failure will be as unimportant as it is the serverless world.
Post reply on HN