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

Re: Back to the '70s with Serverless

#191

Post by bob1029 » Sun, Dec 20, 2020, 12:07 PM UTC

cs702 wrote: 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 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 possible. Going inwards and reducing your latency per transaction is the best option for complex, synchronous problem domains. Going outwards is only going to speed up if you can truly decouple everything in the time domain.

Re: Back to the '70s with Serverless

#192

Post by ric2b » Sun, Dec 20, 2020, 12:11 PM UTC

dehrmann wrote: post #54

daxfohl wrote: post #17

My company is migrating a huge monolith to microservices. One of the proposed benefits is that it makes end to end testing easier because each service only interacts with a couple other services, so each service will be easier to write integration tests for. But in the monolith, those services communicate over interfaces, and are currently tested as unit tests! So we're replacing unit tests with integration tests and…

> So we're replacing unit tests with integration tests Nit: those were always integration tests.

But now they get to use docker and some homegrown scripts in their tests, instead of a testing framework!

Re: Back to the '70s with Serverless

#193

Post by BaronSamedi » Sun, Dec 20, 2020, 12:15 PM UTC

mattmanser wrote: post #8

cs702 wrote: 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…

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…

Scalability is just one reason for using serverless. There are many others. Most of which have to do with being able to focus on the part of your code that actually does something instead of on infrastructure and integration. For example, not having to configure and maintain VMs, containers, or Kubernetes, off-loading a part of security onto the cloud provider, and built-in integration with supporting services like logging and metrics.

Serverless, like every design decision, comes with its own set of trade-offs. Whether those trade-offs make sense for your environment is something you have to determine. At my company we have seen a productivity increase and shorter development times using serverless. Of course, that was after the learning curve which is certainly not trivial.

Re: Back to the '70s with Serverless

#194

Post by qz2 » Sun, Dec 20, 2020, 12:17 PM UTC

1337shadow wrote: post #167

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…

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!

There are a lot of religious followers of the one true AWS way of thinking. I dared bitch too loudly about SES delivery policy once and said to look elsewhere and earned the ire of the architectural elite.

This is insane because I'm certified too but a non believer, a concept which does not compute for a lot of people.

Re: Back to the '70s with Serverless

#195

Post by afarrell » Sun, Dec 20, 2020, 12:19 PM UTC

hyperman1 wrote: post #189

mjw1007 wrote: post #184

Earlier quoted context omitted.

As far as technology goes, I think what we describe as "fashion" is often mostly caused by a desire for safety in numbers, and to a large extent that's rational. If I pick the same language or framework or whatever as everyone else, there's a better chance it won't be abandoned, and when I want to integrate with some other project, someone else will already have done a great deal of the work.

Too true. On my job we have frameworks from the Architects, and stuff that drips in from outside. The Architects typically buy some Framework from a Trustworthy Enterprise, as approved by the Gods of Gartner. Quality varies wildly, but if you move half a mm from the beaten path you're on your own. I gain a thumbleweed badge on stackoverflow every time I deal with their stuff. Compare it to outside world stuff. Qualit…

If you found yourself using a boring, proven, working technology ...how vividly would you remember that experience?

Re: Back to the '70s with Serverless

#196

Post by heipei » Sun, Dec 20, 2020, 12:23 PM UTC

bob1029 wrote: post #191

cs702 wrote: 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 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 five nodes in our k8s cluster".

I really don't know why that is, my guess would be that few people have really built something beginning to end with the most boring tech possible (start out with PHP+MySQL like everyone did 15 years ago). Or they always operate at levels of abstraction where everything is slow, so they have simply gotten used to it, like their text-editor not running smooth unless it's on an i9, because the text-editor now is a pile of abstractions running on top of Electron when vim was able to run smooth decades ago. It's sad and both an opportunity at the same time, because you can be the one with the correct gut feeling of "This should really be doable with a single machine, if not we're doing something fundamentally wrong".

Re: Back to the '70s with Serverless

#197

Post by tinco » Sun, Dec 20, 2020, 12:25 PM UTC

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…

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 such a small team if it wasn't for all the shiny stuff. Yes a lot of it is wobbly, but we're also comfortably a year ahead of the established players.

Re: Back to the '70s with Serverless

#198

Post by empthought » Sun, Dec 20, 2020, 12:26 PM UTC

kortilla wrote: post #120

empthought wrote: post #39

Earlier quoted context omitted.

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.

Architecting a system properly is one of the key functions of devops. You don’t get it by investing a few minutes per month, whether public cloud or bare metal.

Re: Back to the '70s with Serverless

#199

Post by blablabla123 » Sun, Dec 20, 2020, 12:29 PM UTC

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 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 breeze. On the other hand there are fancy frameworks that don't solve such problems or the understanding is not good enough (yet) to solve them reliably. IMHO a lot of web frameworks that promised in the past to remove the boundary of frontend and backend suffered from that. Also the early NodeJS ecosystem to some degree.

It's fun to use a framework, get to it's boundary preventing you from getting things done and then discover a framework that actually crosses that boundary. Speaking of server-less, I never came into the situation where it would have made things easier for me so I never used it but YMMV...

Re: Back to the '70s with Serverless

#200

Post by diveanon » Sun, Dec 20, 2020, 12:32 PM UTC

echelon wrote: post #168

diveanon wrote: post #149

Earlier quoted context omitted.

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: eventu…

Great response.

I'm going to focus on one part of it for now.

"I'd argue your software stack fundamentally relies on the environment it lives within and that ceding control poses a non-zero risk"

This is factually correct, but more nuanced than "just build it in house". Many large orgs externalise this risk by relying on AWS / Azure / Google. Nobody ever got fired for picking IBM is more relevant now than ever, and it is because the largest companjes on the planet have invested huge amounts of time and money solving these problems.

I think you misunderstood me at some point, because nowhere did I advocate that everything should be a lambda. Or that everything should be in the cloud.

The point I am making is that a lot of people I speak to are afraid of complexity and lock in, when they should be afraid of never being able to grow past what they are comfortable with.

To your point about this becoming a trade... Brace yourself, I would wager most development positions will be obsolete in 10-20 years as AI assisted infrastructure and development hits full stride. Especially dev ops and front end.