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

51–60 of 80 posts

Re: System Initiative: Second Wave DevOps

#51

Post by solatic »

The tools aren't the problem, leadership and culture is. Tools can't fix problems with leadership and culture. "Executive buy-in" is conspicuously missing from the post. When companies are "doing DevOps" by wiring up manual deploys and manual approvals in GitHub Actions, it's not the tool that's at fault. When developers are applauded for deploying once a month, it's not the fault of the YAML engineers who were hired to build the pipeline that's used once per month, it's the fault of the executives putting their hands together and clapping.

No tool in the world is going to convince an executive to trust their people, to take risks with uptime and stability, and to break production as a necessary part of organizational learning. No, that requires executives to feel supported by other executives. Tools do not create collaboration and trust; people do.

Re: System Initiative: Second Wave DevOps

#53

Post by mailund »

esafak wrote: post #37
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…

It's mainstream in Silicon Valley.

Interesting! I'm not in SV, but consulting in a European city that portraits itself as having a fairly advanced tech community. I've yet to encounter anyone on a team I've been on that is familiar with it

Didn't know the differences could be that huge.

Re: System Initiative: Second Wave DevOps

#54

Post by oofnik »

I'm happy to see someone really trying to color outside the lines with deployment tooling. I think we've fallen into a number of paradigms for system operations that we know are kind of bad, but we tell ourselves about how much more awful it used to be to numb the pain. That sort of attitude is the real killer of innovation.

I say bring it on; more variance and more disruption in this space as people try new approaches might be what we need to get us out of the rut we've been stuck in for too long. No idea if it will work, but good luck to Adam and his team.

https://youtube.com/watch?v=5lPa2U239C4

Re: System Initiative: Second Wave DevOps

#55

Post by esafak »

anotherhue wrote: post #40
esafak wrote: post #36

Earlier quoted context omitted.

Why? Keep build artifacts and deploy any build you like. Do you have a state or dependency problem?

Same reason clocks shouldn't jump backwards, it breaks so many assumptions you end up with insanity. Do a revert commit so it's the old code in new clothing.

Sure, my bad. I was thinking of the case when the build fails in deployment, not after it is fully deployed. In that case, it should be okay to revert to the last successful build.

Re: System Initiative: Second Wave DevOps

#56

Post by trabant00 »

Another attempt by Dev to make Ops a commodity? I was there when Microsoft announced ~20 years ago they're doing away with sysadmins with a GUI. Then Suse tried as well if I remember correctly. The conferences erupted with anger and booing, I was shaking my head and laughing.

Then came the great YAML plague and we had to give up our title and general purpose languages in favor of silly names, templates and DSLs. But you still have to understand the OS, the hardware, and have real world experience with availability, redundancy, etc. So the new generation of "DevOps" who was raised directly on terraform and k8s failed miserably in achieving any results.

Anybody saw any junior Ops (DevOps, SRE, GitOps, wtfeverops) job openings in the last few years? No? I wonder why. The tools are better, no? It should be easier than ever to deploy. We have all this micro-service orchestration and all those beautiful public clouds. All the conferences and the marketing are saying it's a breeze. You don't have to worry about ha, replication, iops and so on, we'll put that on your bill thank you very much.

So here comes Dev again with a solution: click-click-drag Ops. Surely this will fix things, surely you can now hire right from the street and train to deploy. Or will my old admin ass get even pricier as the demand ever rises and the supply is dwindling? Stay tuned to find out.

Re: System Initiative: Second Wave DevOps

#57

Post by rossmohax »

I like the appeal of model being bidirectional. Also modelling sequence of actions is really not solved problem in Terraform & Pulumi: canary change, check metrics, rollout to the rest of the region, check metrics, then all regions, if they solved it all while being "declarative" and high level it can be the next tool of choice for me.

I am not worried about UI representation of the model like many comments, it is not the main point of this project as I understand. UI just that - a representation, same relationships might as well be coded in HCL or the like of it.

Re: System Initiative: Second Wave DevOps

#59

Post by rossmohax »

oofnik wrote: post #54

I'm happy to see someone really trying to color outside the lines with deployment tooling. I think we've fallen into a number of paradigms for system operations that we know are kind of bad, but we tell ourselves about how much more awful it used to be to numb the pain. That sort of attitude is the real killer of innovation. I say bring it on; more variance and more disruption in this space as people try new approach…

This talk is must see to understand what SI tries to achieve.

Re: System Initiative: Second Wave DevOps

#60

Post by azanar »

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 designed, developed, and tested against a set of supported configurations. At that point, the system might only run under one configuration at a time, but can be trusted from a requirements perspective to operate under other configurations without needing to go through the whole software development lifecycle again.

Why not just store this in user data, then? Different requirements. Three off the top of my head: configuration data wants much better change management than most user data does. That management wants to be exportable and importable. It wants different access controls.

Historically, configuration data change management has been done in SCM, such as git. The reason why git isn't a big deal in development is because it is not a point of particularly high friction relative to the other parts of the software development lifecycle. It is a _much_ bigger point of friction in configuration changes.

Hence, three models.

We can argue about whether or not configuration changes _ought_ to go through the full cycle, because I am wrong to trust _any_ change to a system with anything less. My practical experience suggests that most of the time, the damage done is less than the cost of enforcing a strict lifecycle on everything.

Post reply on HN