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

Choose Boring Technology (2018)

boringtechnology.club

Post reply on HN
Print view View original

131–137 of 137 posts

Re: Choose Boring Technology (2018)

#131

Post by dang »

hnreport wrote: post #120
nailer wrote: post #97

Earlier quoted context omitted.

> I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI. Spending a few hundred K on Unnecessary Kubernetes (and the surprises that result) is definitely still a popular thing amongst junior/mid devops people.

Gotta let the kids pop their cherry on something .

Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

Re: Choose Boring Technology (2018)

#132

Post by lmm »

simonw wrote: post #118
threeseed wrote: post #53

Earlier quoted context omitted.

> but there are thousands of production PostgreSQL instances out there have solved them Great. Can you provide the details on exactly how they did that. Ensuring of course that it doesn't rely on anything proprietary e.g. Citus. Because with every other database I can just go to the officially supported and maintained documentation.

OK, you've attracted my interest. What are some examples of official database documentation pages that do a great job of covering these advanced deployment topics? It's important to note that "boring technology" doesn't mean the official documentation will answer all of your questions: it means that there is enough experience out there in the user community that you can find the information if you go looking for it.

How is it an "advanced" topic? Having multiple instances so that you don't have a SPOF is table stakes for any service you care about, and something any half-serious datastore like Cassandra, Kafka or even MongoDB (for all of which "clustering, replication and high availability" are boring things that you would naturally set up without making a fuss about it) will do out of the box. I'm constantly baffled that when it comes to RDBMSes people suddenly decide that single points of failure are fine now actually.

Re: Choose Boring Technology (2018)

#133

Post by jpgvm »

crabbone wrote: post #103
jpgvm wrote: post #48

Earlier quoted context omitted.

Biggest time wasters and innovation token consumers IMO is third-party vendors, especially shiny startups/products. Don't waste your time, money and energy being someone else's guinea pig, you need to be focused on your business problems. Bigger companies that have engineers and resources to waste can try these out for you and eventually that startup you knew a few years ago will either be successful and ready for yo…

Well, here's a problem with your approach. Say you are a startup in storage niche. Well, big companies aren't going to try using you because you need to have like 10+ years of proven work record before they even consider trying. So, you find yourself in a catch 22 situation. What you can do is find another startup who'd agree to use your product. Maybe fore cheap. Maybe for sharing some resources with them, like mark…

Storage (and other kinds of infra startups) all face these problems. They are solved via a number of factors:

1. Huge amounts of upfront VC investment to allow time to actually build out an enterprise ready product.

2. Leadership heavyweights with experience in the industry, both on the business relationship side and equally importantly on the technical side.

These two factors allow people like Andy Bechtolsheim and John Colgrove to build these sorts of companies and sell directly into enterprise from the get go.

This makes sense because startups have no money to spend on these things anyway, enterprises are used to accepting some free/cheap hardware to "test things out". In fact when I used to run an IaaS company we would frequently get a free box or two when AMD or Intel launched a new CPU architecture, they would push marketing spend through Dell or HP to allow us to have one to play with.

These aren't the companies I was talking about though. I was talking about chasing shiny things that are half-baked. You can't sell a half-baked storage product to anyone so it's not really a concern.

Re: Choose Boring Technology (2018)

#134

Post by paulryanrogers »

appplication wrote: post #116
eddmakesio wrote: post #104

Earlier quoted context omitted.

> todays tech landscape is far less edgy Writing an app in a microservice architecture with services in Rust, Go, and Nim. Database is a serverless DB like Planetscale. Front end in HTMX. Etc… I think any tech your team is not already familiar with, and isn’t the standard pick, is an innovation token.

So I agree 100% with this, but postgres is so easy and scales infinitely (for the meaning of infinite in 99% of business use cases), I suppose I don’t understand why I would choose MySQL. Do folks just use it as a user cache? Most systems I’ve designed of worked on have required a central database so MySQL never seemed the right fit.

MySQL has better compression and IME can scale further thanks to redo log and alternative engines. Still love Postgres's rich feature set for smaller DBs.

Re: Choose Boring Technology (2018)

#135

Post by MichaelMoser123 »

em-bee wrote: post #124
MichaelMoser123 wrote: post #123

Earlier quoted context omitted.

Already know? I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. Look at 'boring' php, facebook was using this language at scale, so they had to develop a just in time compiler for the whole thing. Python didn't have that problem, so it still doesn't have a just in time compiler (for the default interpreter) Also look…

I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. yes, that is true but i think that supports the point: use boring tech to solve interesting problems.

i think it that the definition of 'proven' technology smells of silos: if you come from the Java world, then everything else is not relevant, same for php/python, same for the nodejs world.

Re: Choose Boring Technology (2018)

#136

Post by bongobingo1 »

dgb23 wrote: post #74
jpgvm wrote: post #48

Earlier quoted context omitted.

Biggest time wasters and innovation token consumers IMO is third-party vendors, especially shiny startups/products. Don't waste your time, money and energy being someone else's guinea pig, you need to be focused on your business problems. Bigger companies that have engineers and resources to waste can try these out for you and eventually that startup you knew a few years ago will either be successful and ready for yo…

It’s interesting that the wisdoms of “buy, don’t build” and “NiH” etc. seem to be shifting in general. I think a lot of people have been realizing through the pain of maintenance that dependencies are liabilities and that general, open source solutions with a bit of plumbing are often the lesser evil in that regard. Given my anecdotal experience it seems to be true in the small, and I can imagine how this problem is…

Don't clone, contribute!

Re: Choose Boring Technology (2018)

#137

Post by em-bee »

MichaelMoser123 wrote: post #135
em-bee wrote: post #124

Earlier quoted context omitted.

I think that any technologies can pose a non boring challenges. These tend to happen when a technology is used at scale, or with an unusual use cases. yes, that is true but i think that supports the point: use boring tech to solve interesting problems.

i think it that the definition of 'proven' technology smells of silos: if you come from the Java world, then everything else is not relevant, same for php/python, same for the nodejs world.

true, it's a matter of judgement. i don't think that chosen software has to be proven in general, but if i chose it i want to be sure that i can trust it myself. everyone is free to make up their own criteria what that means for them. it's a risk assessment.
Post reply on HN