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

Re: Back to the '70s with Serverless

#251

Post by WJW » Sun, Dec 20, 2020, 5:19 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…

> Everyone's chasing "scalable", mostly for no reason at all.

No technical reason, maybe. There is a social reason though: if you point out that there is no need to build scale (yet), you are pointing out that the business will not achieve overnight success. Even if it's true, it kills excitement and is therefore not something that people want to hear. Who wants to realize that what they're spending large amounts of time on (and possibly even neglecting other things like health, sleep and social contacts) will not even make all their financial dreams come true? Much easier to not think too hard about it and keep on doing what everyone is doing.

So, building out scalable infra is signaling that you too believe in the company and are preparing for the moment (any time now!) that "webscale" is needed. It's showing that you are part of the team.

Re: Back to the '70s with Serverless

#252

Post by daxfohl » Sun, Dec 20, 2020, 5:19 PM UTC

aflag wrote: post #249

reader_1000 wrote: post #224

Earlier quoted context omitted.

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

If networking is not a problem, why not deploy it already decompressed? I'm assuming the 5 minutes time included decompressing it? It seems a bit weird to take so much time to allocate some objects in memory and possibly establish a few connections. Anyway, can you share which kind of environment even a 5 minute deployment would be a problem? Most places I worked at it took a lot more than 5 minutes to actually imple…

OP here. The move is definitely needed in our case as it's to the point where IntelliJ won't even load anymore. But I had to laugh when improved testability was brought up as one of the benefits.

Re: Back to the '70s with Serverless

#253

Post by still_grokking » Sun, Dec 20, 2020, 5:37 PM UTC

kortilla wrote: post #125

still_grokking wrote: post #82

Earlier quoted context omitted.

I'm not sure I would call people that would rewrite something just because it gets boring otherwise as "engineers". I think the proper term would be "children".

Yet the best engineers in the field aren’t working on legacy banking apps. The problem is that once a product is put into production and the hard problems are solved, the engineering becomes significantly less challenging (unless you’re in an ultra rare scenario of exponential growth). The problem we have in software is that we have engineers build bridges and then somehow expect them to stay around to paint the thin…

Sure, that's absolutely true. But it doesn't mean that you need to rebuild already working stuff over and over.

It's much more fun to improve the status quo by inventing something nice as to repeat the work of the past generation (only painting things in a different color).

Re: Back to the '70s with Serverless

#254

Post by jacquesm » Sun, Dec 20, 2020, 5:43 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 not the cost of failure that is so low, it is the cost of hanging on but not ever taking off that is so high.

Re: Back to the '70s with Serverless

#255

Post by jacquesm » Sun, Dec 20, 2020, 5:44 PM UTC

qz2 wrote: post #190

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…

Problem with investors is that they pay third parties to do audits and third parties are filled with box tickers who ask a load of questions. You can strategically answer any question. So the game becomes how to answer the audit questions effectively rather than an honest appraisal of the situation. Also it's not really fun. It's a frustration ridden shit show. You spend all day solving complex problems instead of bu…

> You can strategically answer any question.

Good luck with that.

We do exactly that for a living here, we're essentially 5 people who are all CTO grade and have run our own companies. If you can fool us for a whole day you've deserved your investment, but I highly doubt anybody ever got away with that.

Re: Back to the '70s with Serverless

#256

Post by still_grokking » Sun, Dec 20, 2020, 5:45 PM UTC

eightysixfour wrote: post #234

still_grokking wrote: post #85

Earlier quoted context omitted.

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.

So airlines were one of the first cloud users because they couldn't scale otherwise?

And they're doing "serverless" these days as their IT operations are a good fit for this paradigm?

Or could it be that they're small enough to get things managed with off the shelf software and/or something built and run in-house?

Re: Back to the '70s with Serverless

#257

Post by jacquesm » Sun, Dec 20, 2020, 5:48 PM UTC

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.

This is absolutely true. But shitty technology tends to have hard upper limits to scalability and shitty security tends to put hard upper limits on the company life span. It's interesting how established companies can have one security issue after another but the customers are so locked in they can't leave and so those companies are not nearly as affected as they should be (Equifax anybody?). But your run-of-the-mill start-up would be mortally wounded by such an affair because they still need to sign the bulk of their customers.

Of course it doesn't always play out like that (to every rule there are plenty of exceptions), but investors don't like to be associated with companies that fail or that blow up their reputations either because it makes their exit that much harder or even impossible.

I've seen investors that took the responsible route and made fixing major security issues or other undesirable elements of the target companies a condition to investment and typically these investments succeed in the longer term, not in the least because they cleaned up their act and could then turn that into a USP relative to the rest of the field.

Even so: better invest in a company with a mediocre product and a stellar sales team than to invest in a company with a fantastic product and a mediocre sales team. The first one will get you a better ROI, and tech can be fixed post deal.

Re: Back to the '70s with Serverless

#258

Post by mlthoughts2018 » Sun, Dec 20, 2020, 5:53 PM UTC

kortilla wrote: post #134

mlthoughts2018 wrote: post #49

Earlier quoted context omitted.

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…

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 and political in-fighting over who owns what and who gets to define how abstract vs purpose-specific the tooling will be.

You toss out “build a good CI/CD pipeline” like that’s just some localized, solvable problem, and it’s exactly that lack of imagination and lack of understanding about the true multitude of use cases that causes this problem in the first place.

I agree “serverless” isn’t a panopoly solution to everything, but externalizing and democratizing all infra tools to cloud vendors is a major transformative solution that is worth a lot of money and solves a lot of problems.

For example, if someone like you had any leadership influence in my company’s infra org, I’d be trying to spend money on cloud tools just to get away from your authority as fast as I could, and I would be 1000% correct to feel that way and would end up with much healthier tool solutions and less blockages on use-case-specific delivery requirements by doing a giant spin move around your myopic perspective.

Re: Back to the '70s with Serverless

#259

Post by AlexandrB » Sun, Dec 20, 2020, 5:57 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…

And just like fashion, what's "in" is driven by marketing.

Re: Back to the '70s with Serverless

#260

Post by [deleted] » Sun, Dec 20, 2020, 5:59 PM UTC

gabordemooij wrote: post #156

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…

This. Devs nowadays seem to be just NPCs, they jump on every bandwagon, it's very depressing. But this is the same with rest of society, groupthink is becoming a real problem. Unwanted opinions, thoughts are scrubbed everywhere.

[deleted]