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

Back to the '70s with Serverless

evrl.com

Post reply on HN
Print view View original

221–230 of 310 posts

Re: Back to the '70s with Serverless

#221

Post by rightbyte »

PaulDavisThe1st wrote: post #42
echelon wrote: post #14

"Cloud is the new mainframe" This is the message we've needed. Cloud is an expensive, overly complicated, lock-in boondoggle. Open source needs to rally hard to prevent cloud providers from running their tech.

TFA is talking about serverless, not cloud computing in general (e.g. rent a VM, run stuff in it). I don't love that I pay aws to run my open source domain(s), but the extent of their job is: keep my VM up, provide me with outbound email that works, offer backups. For now, I can live with that.

"Serverless" has to be the most confusing misnomer ever. How about calling it "Stored procedures" or something.

Re: Back to the '70s with Serverless

#222

Post by TheColorYellow »

bob1029 wrote: post #185
qz2 wrote: post #161

Earlier quoted context omitted.

What I find frustrating is that if you are in a high stake environment it’s increasingly fashion driven too. I am in one of those environments where we can get prosecuted, big time. I tend to opt for a conservative engineering approach with maturity and security considerations being a key part of the design process. But no, fuck that, someone went to a conference, bought everything shiny and started a death-march of…

I dont understand why business leaders cannot see this for what it is and take back some control. Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality. At no point should "fun" be a line item when determining what technology to select in a high stake environ…

> Investors need to start asking more probing questions about how organizations develop and deploy applications.

Does this even matter though? Shitty technology choices don't always translate to poor business outcomes.

Re: Back to the '70s with Serverless

#223

Post by studius »

> telling the computer how to run it took pretty much the same amount of typing, this time not in a programming language but in a structured markup language.

The myopia of "how much code and config is in my app" is inefficient for code reviews, but weigh that against what you gain.

Plenty of people use languages and frameworks without understanding the massive inefficiencies involved.

With configuration, you get insight into some of that inefficiency. It's also more inefficient during code reviews to have to review N changes in configuration.

But, is the end result fast enough for users and is the time needed to develop and maintain it sufficiently low?

If the answer is yes, assuming you're a foot soldier in the dev brigade, you keep going.

It's good to reduce the noise. Chuck Yeager started as a mechanic and worked on his own planes when he became a pilot. That made him a better pilot.

But, James Hart Wyld was the one concerned about the efficiency of the engine. Chuck just needed to break the sound barrier without dying.

Re: Back to the '70s with Serverless

#224

Post by reader_1000 »

aflag wrote: post #201
reader_1000 wrote: post #181

Earlier quoted context omitted.

Rate of change may matter when your monolith application takes too long to deploy (i.e a big war application with lots of initializations at start), although rolling updates may help here. It will also be easier to rollback if things go wrong. On the other hand, I agree with your point of multiple teams. I tried to mean same thing with "used by other applications"

How long are you talking? I can't think of a process I've ever worked on that took more than a few seconds to start. As you say, if you have any sort of rolling deployment mechanism the start time of your application is somewhat irrelevant. Unless your application takes a massive time to start, it seems like the wrong thing to optimise for. Surely you only deploy things a few times a day, if that, and hopefully most…

> How long are you talking? There were some Spring applications that took more than 5 minutes to start in my old job. However, things are most probably improved now with lazy initializations of beans and maybe developers of that applications could have done better at that time. I don't know it is still the case now.

> Also, with the current network speeds and memory availability, it's hard to imagine the war size to be a bottleneck in web development.

Network speed was not the problem, decompression / expansion of the application was. There were war files about 100-150 MB size. Also I saw one with size of 1.5GB however it was an exception. These may or may not be a concern depending on your CPU utilization, disk speed, memory, etc.

Most decisions depends on environment. For some environments, as you said, deployments are not a concern for microservices, for some they are.

Re: Back to the '70s with Serverless

#225

Post by 0x445442 »

memetherapy wrote: post #145

One thing that surprised me as a latecomer to software development coming from a visual arts background is how much choice of technology and working practices are purely fashion driven. The thing about fashion is that the way if develops is largely arbitrary. Changes in fashion resemble a drunken walk through possible design space with the drunkard receiving regular shoves from "influencers" who are usually trying to…

It's an astute observation, especially if you have not heard Alan Kay's thoughts on the subject. He calls our industry a Cargo Cult and explicitly compares it to fashion and pop culture.

Keeping with the anology I'm sure there are software engineering equivalents to Jeans and T-Shirts and it would be an interesting study to compare organizations that opt for these fashions to those that do not.

If you're reading PG, it seems like a great topic for an essay.

Re: Back to the '70s with Serverless

#226

Post by htormey »

bob1029 wrote: post #185
qz2 wrote: post #161

Earlier quoted context omitted.

What I find frustrating is that if you are in a high stake environment it’s increasingly fashion driven too. I am in one of those environments where we can get prosecuted, big time. I tend to opt for a conservative engineering approach with maturity and security considerations being a key part of the design process. But no, fuck that, someone went to a conference, bought everything shiny and started a death-march of…

I dont understand why business leaders cannot see this for what it is and take back some control. Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality. At no point should "fun" be a line item when determining what technology to select in a high stake environ…

“ Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality”

Why? Most companies fail due to a lack of product market fit not because they picked the wrong software stack. Hence investors time is better spent on company outcomes and not micromanaging whether the backend team is building using Java or Rust or whatever’s trendy.

Re: Back to the '70s with Serverless

#227

Post by htormey »

TheColorYellow wrote: post #222
bob1029 wrote: post #185

Earlier quoted context omitted.

I dont understand why business leaders cannot see this for what it is and take back some control. Investors need to start asking more probing questions about how organizations develop and deploy applications. Perhaps if the money becomes contingent, people will start to give a shit about the engineering quality. At no point should "fun" be a line item when determining what technology to select in a high stake environ…

> Investors need to start asking more probing questions about how organizations develop and deploy applications. Does this even matter though? Shitty technology choices don't always translate to poor business outcomes.

You are totally correct. Beyond a certain level of due diligence it doesn’t matter.

Re: Back to the '70s with Serverless

#229

Post by davedx »

heipei wrote: post #196
bob1029 wrote: post #191

Earlier quoted context omitted.

I love the scalability "argument". The capabilities of a single thread of processing in a modern x86 CPU are underestimated by several orders of magnitude in most shops. The unfortunate part is that the more you chase the scalability with the cloud bullshit, the more elusive it becomes. If you want to push tens of millions of transactions per second, you need a fast core being fed data in the most optimal way possibl…

Judging by the occasional post on HN, even a lot of experienced software engineers (the "experienced" being my take) seem to have no good handle on what a single thread and a single machine should be capable of handling, what the latency should look like and what it should cost as a result. The posts that I mean are about "look how we handled the load for a moderately active web-app which is 90% cacheable with only f…

Yup. At the last place I worked me and a colleague would joke that given the traffic our ecommerce platform actually had, we should be able to run the whole thing on a single Raspberry PI. I think he even ran some numbers on it. What we actually had was two containerized app servers and a separate large RDS instance and SES, SQS, SNS, ELB and all the other bits and pieces AWS buy in gets you. The cloud bills for the traffic we handled were ridiculous.

Re: Back to the '70s with Serverless

#230

Post by cumwolf »

I've been working with serverless projects for about 2 years now and I'd agree a lot of these gripes are valid. The slow feedback loop is the most painful. Building new features in serverless apps is going to almost always require multiple pushes in order to get what you want. It's very challenging to get it "right" the first time.
Post reply on HN