Live data from Hacker News

Back to the '70s with Serverless

evrl.com

161–170 of 310 posts

Re: Back to the '70s with Serverless

#161

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…

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 throwing any old hacked up shit and containers from random joes in a limping kubernetes cluster that no one really understand and calling it a success.

That’s reality in 2020 unfortunately. I don’t sleep very well these days.

Re: Back to the '70s with Serverless

#162
post #140
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.

Plenty of scientific computing applications fall over on the "cloud", too.

The LHC produces somewhere between 20-30 petabytes/year[0][1] (at a rate of about 200 Megabyte/second[2] after ignoring many "uninteresting" events)

The LHC is a big name, but there are many other applications in disciplines like physics, genomics, meteorology etc for whom "just use the cloud" is a terrible suggestion.

[0] https://www.popularmechanics.com/science/a16716/lhc-data-vis...

[1] https://home.cern/resources/faqs/facts-and-figures-about-lhc

[2] https://www.lhc-closer.es/taking_a_closer_look_at_lhc/0.lhc_...

Re: Back to the '70s with Serverless

#163

Earlier quoted context omitted.

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

Serverless comes with its own problems though - a less seamless dev experience and cold starts plus you have to host your data on their choice of data store etc.

Re: Back to the '70s with Serverless

#164
post #5

> So what have we now? A “mono repo” codebase, because clearly a Git repository per function in your system would be too much, a large deployment descriptor per fine-grained component, which Spring maybe called “Controller” but is now called “Function”, and instead of combining them all on your desktop, you send them off to someone else’s mega-mainframe [AKA "the cloud"]. You deploy, get an error message, and login t…

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…

I'm sure you will be able to setup proper pipelines on new projects within a 24h time frame and be brilliant at finding root causes by reading the stack trace and associated sources in the blink of an eye when you will be a senior hacker, I'm not worried about that!

Anyway, I think your comment proves that once we decide to invest in something, our brain does everything it can to justify that choice, Human nature really :)

Re: Back to the '70s with Serverless

#165
post #16

This is stupid. If you don’t recognize the benefits of serverless of the capabilities of this you shouldn’t be writing about it. Go back to retirement if you remember the 70s. Maybe you would have laughed people out the door in 2000 but that doesn’t mean you by any means are right. Serverless doesn’t add complexity but provides a service that manages everything for you without having to manage scaling manually. This…

There might be a useful rebuttal buried in your reply, but it's going to be killed by downvotes because you obscured it with ageism and arrogant dismissal.

I’ll admit I was three sheets to the wind when I originally commented on this. Definitely could have left the ignorant low blows out.

That being said, I think what gets me most about this is it seems to overlook the fact that serverless exists to remove the effort and time and cost spent on maintaining servers and aims to allow developers to focus purely on providing value. There’s no doubt you pay more to have it managed by someone else, but at the same time costs are optimized as best as possible by only charging on a per use basis rather than having servers running all or most of the time to host services.

Massive monoliths are very difficult to maintain and often lack resiliency based on the often coupled nature of them. Microservices aim to solve this and also provide more ownership for teams. They also allow for flexibility in hosting as well.

Re: Back to the '70s with Serverless

#166
post #141

Earlier quoted context omitted.

Congratulations, from now on you are on call 24/7 in case anything happens to that machine. It is now your own pet. When RAM fails in unpredictable random ways, you'll spend hours reading the syslogs. When your SSDs fail, you'll spend hours ordering new ones, setting raid up and migrating the backups you've had to provision, automate, supervise and secure yourself. When the server gets even remotely suspected of havi…

You talk like using a physical server somehow prevents building a highly available system or from using automation. Why would the hardware be any more of a pet than any random VM in the cloud? You could also just run a hypervisor on the host and get the benefits of virtualization along with full control of hardware. Sure, if a drive breaks you'd probably want to replace it instead of just replacing the entire machine…

>"You talk like using a physical server somehow prevents building a highly available system or from using automation. Why would the hardware be any more of a pet than any random VM in the cloud?"

It is pure scaremongering and making not very nice assumptions about people's abilities without any real substance. If this is the idea of attracting customers or advocating the approach it seems like a very poor job.

Re: Back to the '70s with Serverless

#167

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…

True story: last "AWS Solutions Architect" I met told me "AWS is a sect and I am part of it", I'm still not convinced it was meant as a joke!

Re: Back to the '70s with Serverless

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

If it is overly complicated for you don't use it. However discounting it altogether because you don't need or understand why that complexity exists is naive. I hear this a lot in interviews and it's a clear signal that you haven't worked on anything big enough yet.

> I hear this a lot in interviews and it's a clear signal that you haven't worked on anything big enough yet.

Quite a bold wager, and totally incorrect. I hope you're not presumptive and rude to all of your candidates.

FWIW, I'm a senior engineer at a large tech company where I started pre-IPO and have had pretty great career growth. I've been on a variety of teams dealing with most of the levels of our stack: eventually consistent data models that are active-active, k8s, frontend, tearing down monoliths, etc.

I'm fine with microservices for medium to large orgs, and I love Kubernetes.

Lambdas and cloud are expensive lock-in, and holding this view doesn't mean you hate distributed systems or complexity. You can staff your own platform teams and manage your own capabilities. Imaging machines, upgrading, failing over - it's all automatable.

The excuse I hear is that companies don't want to build things that aren't related to their core competency. But I'd argue your software stack fundamentally relies on the environment it lives within and that ceding control poses a non-zero risk.

I'm incredibly fearful of the future where all software runs within AWS or Azure. We'll all be paying taxes to these companies and we won't be able to run or replicate similar environments on our own. It'll be difficult for new engineers to learn as our field will effectively become a "trade".

Can you imagine the world where it's expected that everything is composed of SQS and Lambda and other bullshit?

Re: Back to the '70s with Serverless

#169
post #43

Earlier quoted context omitted.

>"Invariably, their response has been to tell me that I just don't get it" I cured this one when my native server running on not so expensive multicore CPU with enough RAM left their cloudy setup in a dust performing more than a 100 times faster and still having huge potential reserve in vertical scalability. They were just astonished at what a single piece of modern hardware in combination with the native code could…

We need to meme c++ back into popularity

I do not think there is any real need. To me it is doing just fine. It does not have to beat every other language into submission.

Re: Back to the '70s with Serverless

#170

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…

When your infra is in AWS, you need an "AWS Certified DevOps"[0] instead of a "typical DevOps", I mean, the typical OSS hacker - which is kind of sad really, and makes me wonder: is this how we're going to build an Idiocracy[1] ? Anyway, things like backups, monitoring, alerting, debugging, is going to be a requirement anyway, and for me it's harder when locked in proprietary stuff such as AWS, I'd rather have OSS I have freedom to hack ;)

[0] https://aws.amazon.com/certification/certified-devops-engine... [1] https://en.wikipedia.org/wiki/Idiocracy#Plot

Post reply on HN