Back to the '70s with Serverless • Hacker News Board

Re: Back to the '70s with Serverless

#231

Post by ehnto » Sun, Dec 20, 2020, 3:33 PM UTC

ehnto wrote: post #182

dragonwriter wrote: post #176

Earlier quoted context omitted.

> 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. It's not “purely fashion driven”, it's just that (1) as solutions radiate out from their point of origin understanding of the problem, how the solution addresses it, and what caveats the user should be aware of gets (on average) fog…

> a technology for which you can get people that are proficient and comfortable is better than one you can't, Hence why PHP is still the leading language for eCommerce, where fashion gives way to tight margins and hiring talent for a decade long lived piece of software is a major concern. When cost is the driving factor for most decisions, and ROI is a very real and measured metric, convincing someome to rewrite thei…

I got some downvotes for this, but look at the numbers. I'm not saying it's the best language for eCommerce, but it is the workhorse. It's the old beige cash register in the corner bodega that's still the heart of thousands of businesses. These businesses don't have the margins to replace their Magento or WooCommerce shop, hence the need for pragmatism. If you're thinking about Shopify or AWS this or that you are already thinking about the wrong part of the industry.

Re: Back to the '70s with Serverless

#232

Post by pmlnr » Sun, Dec 20, 2020, 3:40 PM UTC

sgt101 wrote: post #140

pmlnr wrote: post #135

Earlier quoted context omitted.

> virtually infinite auto scaling Ah, the bullshit. When we showed GCS engineers our hadoop workload, their eyes went really big and told us that they don't have that kind of capacity in a single AZ.

Then you are working at hyperscale yourselves already, and there are maybe 50 organisations like you out there. Maybe. Right now I don't think that there is a single telco that has the scale to break GCP, or a single manufacturing company (exempt Tesla) or a single energy company. Or bank. I agree that pharma, social media and streaming may do this. But since Netflix is on AWS I am doubtful of the last.

> or a single manufacturing company (exempt Tesla)

Tesla is TINY.

Try things like Siemens.

EDIT Besides, the point is not the whole of AWS of GCS; it's the about availability zones vs singular datacentres. Distributed computing doesn't really like to throw data even within the same AZ - in-DC will always be faster. AZ and the modern idea of distribution suit certain things - streaming, for example, benefits from it, but not everything.

Re: Back to the '70s with Serverless

#233

Post by nthj » Sun, Dec 20, 2020, 3:41 PM UTC

htormey wrote: post #226

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. 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…

I see this idea often, and it feels somewhat shortsighted for me. Company outcomes are primarily determined by product-market fit, yes, and: the tighter your feature release feedback loop, the more product-market-fit experiments you can run before you’re out of runway.

Many technology and process choices are just style and preference, absolutely. Others have a material impact on the effort and time to ship a feature. (I’ll leave examples as an exercise to the reader; I imagine any example I used could turn into discussion of “ah you’re doing $FOO wrong.” I suspect this tendency entangles with why these choices seemingly frequently impact business outcomes, from my perspective.)

Re: Back to the '70s with Serverless

#234

Post by eightysixfour » Sun, Dec 20, 2020, 3:47 PM UTC

still_grokking wrote: post #85

eightysixfour wrote: post #81

Earlier quoted context omitted.

Depends on how you define product, there are a large number of tech enabled Fortune 500s that do not sell a tech product but have built an integrated internal product for their operations that do need that scale. Airlines for example. But yes, I agree that most companies jump to this level of complexity too quickly.

Airlines? How many billions of flights and passengers do you have to manage daily as an airline? Don't forget, computers are fast. Also I think airlines do just fine on core system form the 80'ies until now. They also don't tend to have software development teams with "hundreds or thousands" of people to my knowledge. So maybe not a good example. There is only a hand full of companies globally really in need of all t…

I am intimately familiar with the software and IT organizations of multiple airlines. You are wrong, they have large distributed software development teams building very complex software to run every part of the airline’s operations.

Some buy off the shelf, others buy components off the shelf and focus on custom where they feel it gives them an advantage, and others have built the whole thing themselves.

Re: Back to the '70s with Serverless

#235

Post by teleforce » Sun, Dec 20, 2020, 3:52 PM UTC

chubot wrote: post #27

Wow, great post! I have the same complaints: (1) Languages have gotten worse as distributed back ends have gotten more powerful. The IBM JCL and XML references in this post were good! (2) Workloads that currently run on such back ends could run on a single computer, or at least with many fewer resources. This is one reason I got into shell in the first place! I wrote some shell scripts that saturated 32 cores instead…

Yes, it is one of the most entertaining and insightful articles I have read on computing and programming language for a long time.

All the best for your new Oil shell, and I agree that we need to have similar to POSIX standard for distributed systems but it must put local-first software as the first class citizen [1].

Personally I think the local-first software cannot happen soon enough given that what we have endured for the past 30 years with regard to inefficiency and drudgery of the web based applications.

Just wondering about your thoughts on SDLang [2] as the type alternative to JSON, YAML etc, and lightweight alternative to XML?

[1]https://martin.kleppmann.com/papers/local-first.pdf

[2]https://sdlang.org/

Re: Back to the '70s with Serverless

#236

Post by tyingq » Sun, Dec 20, 2020, 4:05 PM UTC

zelly wrote: post #90

You can still get "scale to 0" with cgi-bin applications. Yes, it's old (but it works). Yes, it's slow (so is Lambda). Unlike Lambda, CGI works on any web server and any OS. It's also extremely easy to mock because the input and output is stdin/stdout, not AWS API invocations that cost money every time you run. What you miss out on is "scale to infinity" (read: your bill goes to infinity too).

I recall when AWS first released Lambdas I thought of cgi-bin, especially with PHP where the deployment model is just pushing files. As you say, it has pretty much the same upsides and downsides.

That model does scale well for the web layer at least. Just lots of cheap VPS nodes. Of course, the bottleneck then is the database or whatever layer provides state and persistence.

Re: Back to the '70s with Serverless

#237

Post by dragonwriter » Sun, Dec 20, 2020, 4:14 PM UTC

ehnto wrote: post #182

dragonwriter wrote: post #176

Earlier quoted context omitted.

> 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. It's not “purely fashion driven”, it's just that (1) as solutions radiate out from their point of origin understanding of the problem, how the solution addresses it, and what caveats the user should be aware of gets (on average) fog…

> a technology for which you can get people that are proficient and comfortable is better than one you can't, Hence why PHP is still the leading language for eCommerce, where fashion gives way to tight margins and hiring talent for a decade long lived piece of software is a major concern. When cost is the driving factor for most decisions, and ROI is a very real and measured metric, convincing someome to rewrite thei…

> Hence why PHP is still the leading language for eCommerce, where fashion gives way to tight margins and hiring talent for a decade long lived piece of software is a major concern.

I don't think the forces that resemble fashion are any less applicable to e-commerce.

> When cost is the driving factor for most decisions, and ROI is a very real and measured metric, convincing someome to rewrite their money making machine to keep up with the latest in tech is a hard sell.

Convincing people to rewrite systems without (and even often with) changing needs that the old system seems to brittle to accommodate is hard everywhere, even when ROI isn't clearly measurable; that's why so much established software in government (as well as other places) still runs on COBOL.

The shifting preferences in development that look like fashion are evident, even in those domains where there is lots of established software that is sticky, in greenfield development.

Re: Back to the '70s with Serverless

#238

Post by daniellarusso » Sun, Dec 20, 2020, 4:14 PM UTC

AnIdiotOnTheNet wrote: post #219

daniellarusso wrote: post #83

Earlier quoted context omitted.

When I used to work for an MSP, we would sell Dell servers to rural banking groups. We supported disaster recovery and high availability deployments. Any failed component, Dell would send us a replacement in less than 24 hours.

24? I guess it's that long because it is rural? We use Dell servers and I sleep a bit better having seen their 4hr support replace a motherboard with a bad lifecycle controller within 2 hours of the initial call. Try calling Amazon and getting that kind of response for your problems.

Yeah, my closest Target store and major airport is over 2 hours away.

But, yeah, that is worse-case scenario.

Re: Back to the '70s with Serverless

#239

Post by mikewarot » Sun, Dec 20, 2020, 4:17 PM UTC

As an old timer trying to get back up to speed with the new stuff... I keep coming up with the answer that Lazarus/Free Pascal is a perfectly valid, powerful, and quite unfashionable tool for just getting things done.

Unfortunately, nobody is going to hire a Pascal programmer, no matter how productive. Serverless, here I come.

Re: Back to the '70s with Serverless

#240

Post by inck » Sun, Dec 20, 2020, 4:21 PM UTC

I dunno seems like 90% of this is mostly caused by a need to reduce complexity. In my old job I basically talked to alot of startups about what they were building etc... Alot of teams get free aws credits and use lambda as their process so they can serve data for low to no traffic websites, save on a devops team to get things going. It's because the scope of things you might have to do is so small and the traffic served is also really small. So in the beginning you'd probably rock such a system. When you or if you ever scale out where you are dealing with multiple concurrent requests ( most things are not like they were in early 2000s server logic heavy requests). In fact we've moved to fat clients vs. the old paradigm of thing clients. Now caching layers ship entire heavy weight clients to an app and the server does more mundane things like handle database writes that are shipped off to probably another hosted solution. Additionally actions that require a db write are probably few and far between. Login/ if you're gdocs maybe a periodic save on 15second interval.

Again probably the focus should be on scale and scope. If things are easy water will flow to the path of least resistance. I've done all kinds of deployments over the years (private data center, vps, aws, gcp, etc... with all kinds of deploy management and configuration tools. Having a well maintained permissioned, monitored up time sync'd, has the right packages on the right machine, machine has a non trivial upfront cost. That if someone is going to give me 50-125k of AWS credits (as a startup) then why not. Alternatively if I have a low traffic website and want to dogfood building a product then why not especially if the use case for a db is maybe tracking payments ocassionally handling a login.

My two cents there.