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

System Initiative: Second Wave DevOps

systeminit.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: System Initiative: Second Wave DevOps

#71

Post by firesteelrain »

dipperdootydoo wrote: post #66
chologrande wrote: post #64

Earlier quoted context omitted.

You're assuming you know the use case. We do more than serve LAMP stack. It takes more than a few playstations I can assure you.

No, I don’t need to know the use case. There are a vanishingly small number of use cases that cannot be performed 25,000 times per second on hardware from 25 years ago. If you indeed work on one of those few cases, you wouldn’t simultaneously call Terraform and public utility cloud simple architecture for any use case relevant to Hacker News discussion; that’s just plainly false beyond a certain level of computing de…

I really don’t understand your argument.

Re: System Initiative: Second Wave DevOps

#72

Post by firesteelrain »

azanar wrote: post #60
chologrande wrote: post #7

After reading this post, I've browsed the site. I'm not sure how this is anything but significantly worse than the current model? I've been around long enough to know that any "no code" style interface or GUI are typically the _problem_ not the solution. Regardless of the code they export, you end up with fat fingers, misclicks, forgotten UI paths to follow... Taking a software eng approach to shipping infra is a sta…

I don't see the current model as a single model, but as several models interrelating. In software, there are at least three models I can think of immediately: code, configuration and user data. Why do I separate configuration? Isn't configuration just code or data? I don't think it is. It is data _about_ a particular system, as opposed to a particular user. Why the distinction here? The code of a system can be design…

You obviously have never worked in Aerospace or Safety critical systems

Re: System Initiative: Second Wave DevOps

#74

Post by peteridah »

mailund wrote: post #24

> Things like using source control, shared observability, feature flags, dark launching, continuous integration, and continuous delivery are widely considered best practices. I seriously want to know which places this is! I've been at 5 different companies, and I've never been a place where people don't look at me like I'm speaking French when I suggest dark launching a feature or introducing feature toggles. I've ye…

I feel you – I had heard a _lot_ about dark launching and never actually worked at a company that actually did it until I worked at Hashicorp. Now in my mind it seems mainstream. I truly am in a bubble.

Re: System Initiative: Second Wave DevOps

#75

Post by silok »

I think it looks pretty promising, as long as the deployment setup is not only configurable via the UI, but also can be specified decoratively with code and hierarchical data (eg json).

IaC is a really powerful concept, and system initiative does not need to be in conflict with that paradigm, just another layer of abstraction that still allows IaC.

The main issue is how to combining UI state + and manual state.

The worst thing you can do imo, is to use a common representation, eg the UI would try and edit your manually written declarations. That is just a recipe for disaster.

The answer to this type of mixed editing is a layer approach, eg what is being done in the USD format (https://openusd.org/release/index.html)

Each authoring "instance" has full control of its layer, and composition semantics define how the layers compose to the final declarative structure.

Re: System Initiative: Second Wave DevOps

#76

Post by emptysongglass »

JohnMakin wrote: post #61
jedberg wrote: post #42

Earlier quoted context omitted.

Click ops is great for most shops, as long as it has advanced configs available and you have at least one expert on staff for when those configs are needed. At Netflix our goal was always to build tools where the majority of devs just check into source control and click a few buttons, but could go as far as configuring kernel tunables if necessary (but also making that as unnecessary as possible).

But the infrastructure underneath the stuff the devs use was almost certainly not click ops’d. I’m fine clicking a deployment into prod, I am not fine making advanced cloud or build configurations via a UI

Precisely. Even very small companies, should they grow (and we hope they will) should not be doing ClickOps architecture. They will pay for it later when their team is larger and trying to sort head from tail.

Re: System Initiative: Second Wave DevOps

#77

Post by holoway »

skywhopper wrote: post #67
holoway wrote: post #5

Hi! Adam Jacob here. Happy to answer questions!

What does the performance curve look like with larger numbers of resources? ie, How soon does it get bogged down? 1,000 resources? 10,000? 1,000,000?

It’s too early to know with real data. Architecturally, it should scale - but you know it’s going to need optimization when we start getting into high numbers.

Re: System Initiative: Second Wave DevOps

#78

Post by xylophile »

dipperdootydoo wrote: post #66
chologrande wrote: post #64

Earlier quoted context omitted.

You're assuming you know the use case. We do more than serve LAMP stack. It takes more than a few playstations I can assure you.

No, I don’t need to know the use case. There are a vanishingly small number of use cases that cannot be performed 25,000 times per second on hardware from 25 years ago. If you indeed work on one of those few cases, you wouldn’t simultaneously call Terraform and public utility cloud simple architecture for any use case relevant to Hacker News discussion; that’s just plainly false beyond a certain level of computing de…

"I don't need to know anything about the problems you've solved in order to determine that you've solved them incorrectly, and that I'm smarter than everyone, and I'm going to be rich."

Let us know how that works out for you.

Re: System Initiative: Second Wave DevOps

#79

Post by cmrdporcupine »

convolvatron wrote: post #39
hinkley wrote: post #27

Earlier quoted context omitted.

That’s definitely part of the dynamic. My biggest regret with automated testing is that software used to be a triumvirate of Quality, Dev, and Management, and when dev was fucking around they had two teams hitting them, and when Management was out of control, they had everyone mad at them. Get rid of QA and it’s Us vs Them and that worked briefly at the dawn of Agile but they got wise. OP’s should replace QA at that…

I agree. but having a QA group was hardly a magic bullet. most of the really talented contributors eschewed QA - even if they enjoyed it - because it meant being identified as a QA person for the rest of their career. even if you could staff a competent group, they are often left with nothing to do while the devs 'work their magic'. and suddenly its 3 months past the original 'functionally complete' deadline, and QA…

The most productive QA/dev team experience I had back in the day was in a shop that was playing with eXtreme Programming and we did little 2-3 person strike mission per-issue groups with 2 to 3 devs and 1 QA person. Work on strictly defined small feature and continuously QA through the process, and then iteration end the QA person worked more intensely. The point being that the QA staff was treated like another development engineer even if they weren't writing code, so no "toss this over the fence to QA" and "oh god this is horrible, the devs are shit" mentality. Outcome of the feature was not just completed code, but (hopefully) test plans and sign-off from QA.

The QA people hated it though.

Re: System Initiative: Second Wave DevOps

#80

Post by Coryodaniel »

anotherhue wrote: post #44

We could begin by accepting that operations work often deals with far more complex problems than feature work. Yes, the tooling is bad, all tooling is bad, but hearing the same old 'Infrastructure should "just work"' trope is getting old. Such developers should stop grandstanding and roll up their sleeves. Learning about TCP isn't beneath you.

> Learning about TCP isn't beneath you.

Its literally beneath you as an application developer in the TCP/IP stack :budumptss:

Post reply on HN