Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Back to the '70s with Serverless

evrl.com

Post reply on HN
Print view View original

121–130 of 310 posts

Re: Back to the '70s with Serverless

#121

Post by kortilla »

ab8 wrote: post #73
muglug wrote: post #45

Earlier quoted context omitted.

Thanks for putting this into words. People want a reason to log on, a reason to show up to work. I wrote a blog post on Monday about a relatively old and not-hot language. The post nevertheless trended on Medium and received 50k views. A lot of the feedback was from people who were just happy to see someone senior say something positive about the not-hot language. Anyway, working with The New Hotness also gives peopl…

Is being paid hundreds of thousands of dollars plus stocks and bonuses not enough of a reason to show up at work?

Well the funny thing is that once you crack FAANG interviews you can usually get offers from multiple of them and then money no longer becomes the decision factor. The choice becomes, “work on X and make $400k or work on Y and make $400k”. You bet the tie breaker often ends up being the prospects for working on cool shit.

Re: Back to the '70s with Serverless

#122

Post by sveme »

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…

Does anyone know of a resource showing me some parameters for estimating how far different managed servers reach? How many concurrent users, bandwidth, etc.? Have a hard time getting a mapping for expected concurrent users -> hardware requirements. How quickly can you adjust the HW resources in a non-cloud setup if your startup product is more successful than expected?

Re: Back to the '70s with Serverless

#123

Post by thethethethe »

manigandham wrote: post #118
thethethethe wrote: post #41

Earlier quoted context omitted.

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

All you needed was PaaS, which has existed for a long time. Or the even older name: managed services, offered by pretty much any decent hosting provider for decades. I remember using companies like MediaTemplate and FullControl 10 years ago for clients and not having to worry about OS updates.

Serverless is a PaaS. And yeah, those services could work too. Serverless isn’t the only solution that works.

Re: Back to the '70s with Serverless

#124

Post by flarg »

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…

The cloud makes money for people so it's important. Would you rather that money went to shareholders or to wage earners?

Re: Back to the '70s with Serverless

#125

Post by kortilla »

still_grokking wrote: post #82
travbrack wrote: post #66

Earlier quoted context omitted.

The business case is that you won't be able to retain good engineers if you refuse to rewrite your AS400 COBOL app.

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 thing, change light bulbs, etc and stay fulfilled. A person who is an expert at making new things won’t like being in maintenance. It’s that simple.

Re: Back to the '70s with Serverless

#126

Post by nocman »

TheColorYellow wrote: post #106
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…

This is the type of cultural accuracy I've been looking for. Are all the commenters in this thread just cynical engineers who really can't see past their own narrow world view? I get snake oil is snake oil, but there is such a strong brand of "anything new must be snake oil" that runs through the HN community it boggles my mind. The world is actually full of complex systems. And only once these systems are in place d…

> there is such a strong brand of "anything new must be snake oil" that runs through the HN community.

I would say there's at least as strong a "brand" of "if it is a new way it is probably a better way" on HN as well.

I think making blanket assumptions in either direction is a terrible idea. Best to be aware of your own biases, and try to be as objective as you can in your decisions.

Experience matters, and there are new solutions that are inferior to older ones in many cases (yes, there is plenty of "snake oil" for sale). However, sometimes new people look at an old problem with fresh eyes and come up with better ideas on how to solve it.

This really isn't anything new. When I was fresh out of college I remember older programmers talking about "such-and-such" is just the old way of doing it repackaged. There is lots of oscillation in the computer industry.

Re: Back to the '70s with Serverless

#127

Post by tannhaeuser »

chubot wrote: post #51
l0b0 wrote: post #18

> XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster. There are a few fundamental differences between these languages, but it's just plain wrong to say that any of them are not "structured." Did OP mean…

I'd say that JSON is "structured", and probably HCL as far as I know, but the others have problems. I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ... I just translated my .travis.yml to JSON, and I learned that deploy: on: branch: master gets t…

> I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ...

Is as easy as declaring
vs
with DTDs.

Re: Back to the '70s with Serverless

#128

Post by rangoon626 »

FpUser wrote: post #43
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…

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

Re: Back to the '70s with Serverless

#129

Post by 3pt14159 »

otabdeveloper4 wrote: post #94
mattmanser wrote: post #8

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…

Yes, "the cloud" is bunk from any technical point of view. It exists to shift CapEx to OpEx for accounting. Any technical considerations are a distant third place on the list.

Well, if you mean CapEx because one needs fewer programmers and a higher AWS bill, then yes I agree with you. But if you mean CapEx because one needs fewer physical computers that they own and a higher AWS bill for computers that they rent, then no I do not agree with you.

First, the markup in just sheer ops terms is enormous. Minimum 4x, and in some cases 20x. Sure, you get a couple more nines of reliability, but 99% of startups don't need that much reliability.

Second, in countries like Canada where capital expenditure on computer systems can be heavily marked down[0] people still use AWS and DigitalOcean by default.

The main reason people don't do colocating is that it is a waste of time better spent. DigitalOcean is cheap enough. AWS is cheap enough and if the team doesn't have experience running Postgres, fine, they use RDS. Sometimes it's just sheer laziness at first that later blossomed into "holy shit, we're growing too fast to even think about migrating off of these giant AWS bills" which was essentially Dropbox's story if I recall correctly.

[0] 55% per year, and in practice they allow full expensing in the first year for petty amounts of outlay. For example, if your business is a data centre, sure it's 55% per year, but if you run a flower farm and fully expense a new laptop for sales the CRA is generally fine with it.

Re: Back to the '70s with Serverless

#130

Post by kumarvvr »

zelly wrote: post #93
kumarvvr wrote: post #57

For all its flaws in design or philosophy, cloud computing has a sweet spot. As an indie, lone dev, I can run my site, email and a basic web app for about 10 USD a month and, if my app kicks off, I can scale it to a million users without breaking a sweat. To me, that is the true power of the modern cloud computing paradigm. An influx of great apps and services enabled by cheap scalable and sweet competitive cloud ser…

Wait until you see the "data transfer" costs for what is basically or literally free from the bare metal/colo hosts. $10 is too much for what you're describing. You could be paying $0-$3. Most users of the top public clouds are paying 2-10x more than they should just because using the public cloud "is what you do".

For running a static site on Amazon, for low traffic requirements, it indeed costs about 3 to 4 USD per month.

Also, which bare metal server providers would you recommend?

Post reply on HN