Live data from Hacker News

2023 DevOps Is Terrible

abidmoon.hashnode.dev

41–50 of 126 posts

Re: 2023 DevOps Is Terrible

#41
post #2

The fact that we have a “devops team” at work infuriates me. It’s enough to distract me me from how “Scrum” has destroyed Agile.

The only thing I like about the return of sysadmins and the end of the "you build, you run it" culture of Devops it is that I'm 100% off the hook if something dies in the middle of the night.

The so-called DevOps guys are stressed out of their marbles, but when the CTO calls me 4 AM I can't say anything but "Sorry dude, I'm not a clairvoyant. I have no permission to do shit in prod, call Ops or give me AWS access now". He stopped calling.

The fun part is Ops wants us engineers to help more, but they don't even trust (and some don't know how to run) my Terraform or CloudFormation scripts (I let them choose which), so they just read the tf/yaml and click AWS buttons manually. Often making lots of mistakes.

Re: 2023 DevOps Is Terrible

#42
post #3

Earlier quoted context omitted.

What is so horrible about it? Our devs are happy they can focus on fixing unit tests in pycharm, while others care about where the code is going.

Because it's just a hip way of saying you have a sysadmin team. How can something or someone be "devops" if all the developers are in one team doing dev tasks, and the ops in a separate team doing ops stuff?

A devops team is in practice typically very different than a sysadmin team. Good sysadmins automate the hell out of everything, but it’s usually not something other people can use. Devops teams automate all of that stuff but then they also let teams build new infrastructure when they do deploys and automate that whole process, but it’s client facing. It’s development and operations, it’s a pretty good name, though I think platform or production engineering is typically a better name.

Re: 2023 DevOps Is Terrible

#43

DevOps just makes the problem worse which it is intended to solve. DevOps started from "deploying is too hard, and the developers don't know how to run complicated shell scripts to deploy our software to release, anyone should be able to deploy it and have it scale!". However, most companies started to cargo-cult Google and just built everything in the "most scalable" way, incurring tons of overhead, both in deployme…

We use simple github workflows to release microservice based services and frontends on a daily basis. They're pushed through a series of dev environments for testing before being "released" into production by managers. It's not hard for devs at all.

Re: 2023 DevOps Is Terrible

#44
post #6

Yep, bang on. As for the PE being the “solution” it is incredibly important and sorely needed but it won’t solve your enterprise culture.

Regarding enterprise culture I’m curious who will be in this “platform engineering” team and what expertise they’ll have. In (enterprise) reality it will more than likely be a bunch of sysadmins and former “network/storage guys” who saw which way the wind was blowing and got a cloud cert. They really have no business forcing a particular infra pattern on application teams because they have no application level expert…

I think that once a company is big enough you can have a few options to get code to prod and make sure it stays running as expected. You could have an option where a team is focused on building most of the platform up to an agreed point (e.g. everything under an application’s container image) and provide some common ways of setting up application monitoring / logging etc…. Making sure that while there is a core internal platform as a product team that you’re focused on being a capability rather than a business unit - by that I mean you should have some if not most folks embedded (or rotating through) dev teams. You can also have an option that lets teams self organise how they get their code running - with some light touch guard rails and potentially caveats for applications with PII etc…

Re: 2023 DevOps Is Terrible

#45

DevOps just makes the problem worse which it is intended to solve. DevOps started from "deploying is too hard, and the developers don't know how to run complicated shell scripts to deploy our software to release, anyone should be able to deploy it and have it scale!". However, most companies started to cargo-cult Google and just built everything in the "most scalable" way, incurring tons of overhead, both in deployme…

Devops absolutely fixed a lot of issues. Going from manually merged SVN branches on a quarterly release monolith to a "click and release application" is a huge saver in developer time and pain.

that's great for you. at my company devops are still doing monthly releases and unable to deploy single microservices because all the services are too interconnected.

Re: 2023 DevOps Is Terrible

#46
post #13

Whats your SRE / DevOps ratio? In my experience, in the 10 teams I had or oversaw, I had about 1 FTE in DevOps for 15 SRE. Of course it depends, but what’s your personal experience?

DevOps isn’t a role, it’s values and ways of working.

Yes, unfortunately, the misconception that DevOps is a role or person, rather than a culture, is the root of most problems with DevOps, DevSecOps, and DevSecMlTriceratops.

Re: 2023 DevOps Is Terrible

#47
post #41
post #2

The fact that we have a “devops team” at work infuriates me. It’s enough to distract me me from how “Scrum” has destroyed Agile.

The only thing I like about the return of sysadmins and the end of the "you build, you run it" culture of Devops it is that I'm 100% off the hook if something dies in the middle of the night. The so-called DevOps guys are stressed out of their marbles, but when the CTO calls me 4 AM I can't say anything but "Sorry dude, I'm not a clairvoyant. I have no permission to do shit in prod, call Ops or give me AWS access now…

I always do a better job of writing logic when I sympathize with the victims. Some of those late night calls are devs setting ops up for failure. It was meant to close an open loop.

Re: 2023 DevOps Is Terrible

#48
Since the in house server days, technology solutions have only become more and more time consuming to implement, ID & PII obsessed, and bulky (data footprint-wise). I am thankful I remember much more simple times, when apps were tiny, run on regular computers in my office, and you could symply restore from a local backup to bring a service back online.

Now we have companies paying thousands of dollars a month to host a simple site or web app, because now it's all in the cloud, no matter the apps function, while hosting customers assume about 80-90 percent of responsibility for securing and maintaining their app anyway. Containerization is leveraged to add a "backdoor" for individual admins, but that only serves to protect infrastructure, it actually makes a customer's individual app open to vulnerability that same as running your own instance if you miss vital updates or if there is a breakdown in the supply chain. We need to stop listening to the companies that market tools and be honest with ourselves... Security needs a better model than just adding new tools and entry points to the app chain.

There's gotta be a point where you evaluate things and tell yourself that there has to be a better and more affordable way than tunneling through 5 VPNs just to push updates for 8 disparate JS and PHP libraries and 5 containers. App and library updates are also far too frequent in 2023 as well... Frameworks need to ship instances with less features, and modules should be reduced to only those used and deemed most essential, reducing footprint is a key aspect lost on technological advancement, it is also a firm indicator of increased efficiency for app and library devs if you ask me.

Now with zero trust, devs literally spend a lot of their daily workload logging back in and re-establishing VPN connections due to timeouts. There's got to be a point where we develop a far more simple IT solution to all of this mess. Security is still getting compromised regularly no matter what is done. The solution also won't likely involve Ai at this point in my opinion, as security and complexity are assuredly not resolved by leveraging current-state Ai tools.

It's also important to note this is why PHP is still going strong, it doesn't require compilation, and is relatively easier than most other langs on learning curve to implement.

I literally built my IT career on making things simpler, and in explaining complex IT issues in human language to non-technical people. There is a lot of room in my field for growth due to the rest of the industry's constant focus on jargon and over-complexity.

Simpler solutions, conveyed and implemented in human language, will be king in 2024.

Re: 2023 DevOps Is Terrible

#49

Earlier quoted context omitted.

Because it's just a hip way of saying you have a sysadmin team. How can something or someone be "devops" if all the developers are in one team doing dev tasks, and the ops in a separate team doing ops stuff?

A devops team is in practice typically very different than a sysadmin team. Good sysadmins automate the hell out of everything, but it’s usually not something other people can use. Devops teams automate all of that stuff but then they also let teams build new infrastructure when they do deploys and automate that whole process, but it’s client facing. It’s development and operations, it’s a pretty good name, though I…

The quality of devops scripts, from the perspective of a person who likes to write code that has to work right the first time, is about two standard deviations better than sysadmin scripts. But still of a par that would keep someone from getting promoted past a Senior Dev title.

What’s worse is they can be condescending while shoveling out absolute garbage. If I’m honest that’s the part that bugs me the most.

Re: 2023 DevOps Is Terrible

#50
post #38

To me, DevOps culture just feels like a way for businesses to save money by not staffing a dedicated infrastructure team and pushing all those responsibilities onto application developers. The amount of time I've spent fiddling with Terraform, Ansible, Kubernetes manifests, Helm charts, Jenkins configuration, GitHub Actions configuration, AWS IAM, and so on over the past few years is absurd, probably more than the ti…

What now? If you’re spending that much time on devops I feel like you’re doing it wrong. I do eng (team of 7) and devops (only me) and I feel like I spend about 5% of my time on devops.

These tools have made deploying production quality infrastructure take a fraction of the time. These environments are basically already preaudited and verified. They’re also just much higher quality in general. It’s quite typical for different projects to share infrastructure in traditionally deployed systems but with devops we can have much better isolation with less deployment time.

Post reply on HN