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

Re: Back to the '70s with Serverless

#301

Post by FpUser » Mon, Dec 21, 2020, 7:19 AM UTC

jacquesm wrote: post #300

FpUser wrote: post #291

Earlier quoted context omitted.

Companies are lying to each other and to customers on a regular basis. Most of those lies are framed in a certain way and are not fraud from a legal point of view (the one where you go to jail).

The context we're talking about here: acquisition or investment there is a duty to research and a duty to inform, the two should theoretically meet in the middle, there is always some give and take but that's the basic idea. Failing your duty to inform is very close to fraud and in many cases crosses right over into fraud. This can get you in very hot water depending on the jurisdiction and the willingness of the cou…

>"Failing your duty to inform is very close to fraud and in many cases crosses right over into fraud."

Cutting down the fluff you've just confirmed what I said. Basically when it does not cross into legal criminal fraud as defined by law you can't call it a fraud. Same as with taxes, especially corporate. One can be and idiot, creative, fraudster. The middle one is subject to interpretation and the amount of money involved. "Doing very best" does not necessarily mean not lying.

Re: Back to the '70s with Serverless

#302

Post by jacquesm » Mon, Dec 21, 2020, 8:32 AM UTC

FpUser wrote: post #301

jacquesm wrote: post #300

Earlier quoted context omitted.

The context we're talking about here: acquisition or investment there is a duty to research and a duty to inform, the two should theoretically meet in the middle, there is always some give and take but that's the basic idea. Failing your duty to inform is very close to fraud and in many cases crosses right over into fraud. This can get you in very hot water depending on the jurisdiction and the willingness of the cou…

>"Failing your duty to inform is very close to fraud and in many cases crosses right over into fraud." Cutting down the fluff you've just confirmed what I said. Basically when it does not cross into legal criminal fraud as defined by law you can't call it a fraud. Same as with taxes, especially corporate. One can be and idiot, creative, fraudster. The middle one is subject to interpretation and the amount of money in…

I can call it whatever I want. Whether a judge will agree with that is another matter, but the common layperson's definition of fraud is not the same as the legal one that could lead to a criminal conviction, if only because they both have a different standard for evidence. Splitting legal hairs is what may make you decide to pursue a fraud case or letting one go, doesn't mean that it wasn't fraud.

You can see this happen every day, plenty of cases that are fairly obviously - to a layperson - fraud end up not being prosecuted because it is hard to prove the facts and then there is the matter of intent. Still, nobody is fooled.

Re: Back to the '70s with Serverless

#303

Post by em500 » Mon, Dec 21, 2020, 10:44 AM UTC

sgt101 wrote: post #187

vntok wrote: post #142

Earlier quoted context omitted.

Total & Aramco come to mind.

Ok I buy that one. Oil and gas have some big problems..

I worked for one of the top-10 ecommerce shops (by transaction value) in the world. It was interesting for me to find out that the aggregate CPU power of our hadoop cluster seems comparable to what an F1 teams uses to simulate air dynamics to tune their cars.

There's a big world out there, there are probably tons of big computer users that we are largely unaware of.

Re: Back to the '70s with Serverless

#304

Post by abcxjeb284 » Mon, Dec 21, 2020, 12:35 PM UTC

Bit of a miss on why “serverless” (though author & I have different definitions), possibly because of language / toolset.

Lambda / Step Functions make for an easy combo for easily understandable units that you can use without a bunch of servers. Combine it with AWS CDK and you end up with a low boilerplate, auto-completeable environment (with types!) that’s actually easy to unit test locally!

I agree that yaml config and figuring out how to wire things up sucks. I’m open to Smalltalk being better.

But we’ve been using Lambda / Step for a few years now and it’s been highly robust, easy to understand, monitoring / logging essentially free and - best of all - we haven’t had to manage any server upgrades / patches / etc the whole time. (And super easy to spin up stack per user)

Have a queue of items to work on? Combine lambda + sqs (just a few lines with cdk) and now you have code that auto scales linearly with how many entries are in your queue.

We did write our own tool to handle boilerplate of linking python functions to their lambda handlers (but again this is the beauty of actually being able to use programming language to define your stack)

Re: Back to the '70s with Serverless

#305

Post by twh270 » Mon, Dec 21, 2020, 2:08 PM UTC

mlthoughts2018 wrote: post #258

kortilla wrote: post #134

Earlier quoted context omitted.

Cool story, but the majority of that is not related to serverless. You still need a CI/CD pipeline with serverless and I’ve dealt with just as many miserable setups there. > I can’t give the cloud providers my money fast enough People run VMs and k8s on the cloud as well and run into every one of the problems you just described (aside from literal hardware failures). Your rant seems to mainly be about having a good C…

I think you completely miss the point. With cloud tooling, my team is unblocked to spin up the resources we need, manage CI / CD in our unique way that solves our problems, quickly try out serverless if it’s a good model for a given use case, change logging or alerting, get new compute resources like GPUs, etc., all without being blocked by a choke point of in house engineering limitations and staffing limitations an…

This has nothing to do with technology or tooling, this is your team having the autonomy to do what works for you.

At my current client, my team is dependent on the "Platform Team" for _everything_ that isn't directly related to the code we're writing. Do we need a new Azure queue? That's a Platform ticket in JIRA. Do we need a new tool in our CI/CD pipeline? That's a Platform ticket in JIRA. Do we have a build failing for something other than tests? That's a Platform ticket in JIRA. Do we have an issue in production? We need to engage with Cloud Ops because we don't have access to anything in prod.

Plus, it takes six weeks to get a feature from development to production because horrible workflow and manual processes.

Plus, development teams are prevented from implementing anything without the approval of Solution Architects who are too far removed from the business to understand what's needed and too far removed from the technology to be able to design a working solution.

It's all fucking horrible, and yet we're using all the modern cloud tooling: Spring Boot, Azure, containers, K8S, Gitlab pipelines.

In contrast, a couple clients ago my team had full autonomy to do what we believed was the right solution. Stories would often be groomed, implemented, and delivered into production all within a 2-week sprint. No muss no fuss. When they weren't, it was normally due to us having to wait on another team to deliver their work.

Re: Back to the '70s with Serverless

#306

Post by deanCommie » Mon, Dec 21, 2020, 5:58 PM UTC

grishka wrote: post #285

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…

As a software developer since my early days, I wholeheartedly agree with you. It's honestly ridiculous to see how people invent "revolutionary new ways" of doing the exact same thing that could be done in a dozen ways already. And they invent those by piling more and more unnecessary complexity on top of existing technology stacks. Electron is a revolutionary new way of making desktop apps. Except they look like they…

You made some bold statements without any details.

Kotlin to me solves most of my Java pain points. In what sense is it not predictable?

Electron allows a company with web developers to be able to build cross platform desktop clients without hiring desktop developers. That's incredibly compelling and powerful regardless of the compromises with the final product for the end user. (which are not guaranteed. Something like VSCode is indistinguishable from a rich desktop client)

Re: Back to the '70s with Serverless

#307

Post by htormey » Mon, Dec 21, 2020, 8:12 PM UTC

nthj wrote: post #233

htormey wrote: post #226

Earlier quoted context omitted.

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

Well I imagine it’s a function of the stage of companies the VC’s are investing in.

If you are an early stage investor and you are writing lots of checks to cast a wide net do you really have the time to do that level of due diligence? Presumably a quality founding team and a decent demo is enough to tick that box.

If you are a series A or above investor, does it really do anything to provide this advise after the fact?

I image that the assumption is that if the company is successful you can afford to bring in more seasoned people to fix things. At least that’s what I’ve seen on my travels in the Bay Area.

Re: Back to the '70s with Serverless

#308

Post by jiveturkey » Tue, Dec 22, 2020, 5:16 AM UTC

true and should hit home with most, but still flawed. especially the biting conclusion.

> Not by going back through our history and figuring out what caused the Personal Computer Revolution. Which is a shame.

the thing is, these aren’t the days of the PC revolution. there is a baseline complexity which is easily an order of magnitude greater than the most complex systems of that day. to stick with the concept of a single machine, just the ME in a PC today is more complex than the entire machine back then. mostly to our benefit.

Re: Back to the '70s with Serverless

#309

Post by blablabla123 » Tue, Dec 22, 2020, 11:33 AM UTC

tatersolid wrote: post #295

blablabla123 wrote: post #199

Earlier quoted context omitted.

It's a fine line to use recent frameworks and at the same time to be productive and actually solve problems. That's ultimately why good frameworks are developed. When React came out many called it a fad but it solved really nasty problems in Web development, that's why it stayed. Also I'm quite sure K8S is here to stay because it removed this whole VM complexity layer and makes integration and testing of services a b…

> Also I'm quite sure K8S is here to stay because it removed this whole VM complexity layer and makes integration and testing of services a breeze. Kubernetes does basically nothing to assist in integration or testing of services, and adds more complexity than the “VM complexity layer” ever had.

I don't think so. In the average company running VMs themselves, the person managing the VM is a different person that runs stuff on it. Even in K8S is a different story, it can be managed by a devops team (or a really engaged dev ;)). VMs virtualize your network interface and can take care of some IP routing, K8S can route HTTP traffic and TLS-terminate it. It facilitates being aware of other services and multiple instances. Basically it's possible to get rid of nginx. And most importantly it runs the containerized applications basically on bare metal. Spinning up a test instance and destroying it 1 minute later is cheap, any dev can do it.

Re: Back to the '70s with Serverless

#310

Post by 59nadir » Tue, Dec 22, 2020, 12:14 PM UTC

tinco wrote: post #197

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…

Because all the shiny new things make promises. From larger talent pools in node.js, to cheaper scaling with kubernetes. They all talk to business leaders in terms they understand. Also, this is a fundamental property of innovation, innovation usually is made possible by the new and shiny things. I run the software side of a hardware startup, and I wouldn't have been able to run such a complex software system with su…

> Yes a lot of it is wobbly, but we're also comfortably a year ahead of the established players.

It's likely that you would be ahead of established players with old, not shiny technology as well. Established players have an inherently harder time progressing in most circumstances and an entirely different maintenance burden in pretty much every layer of their product. Shiny, new technology accounts for much less than people think it does.