I think the biggest issue with devops is that it originally meant "socialising" your sysadmins, by getting them to sit with your devs, so that shit didn't get lost because nobody thought to talk to the right team.<p>But then it morphed into "oh lets innovate with infrastructure" but the innovation turned into "lol lets just restart from scratch and ignore history" Anybody who used early k8s can attest to how <i>un production ready</i> it was for the longest time. It _felt_ like progress because it required a lot of (to dev eyes) hidden magic to make it work.<p>Now, we are back with sysadmins, but they are called SREs. They provide a platform, which devs talk to to deploy stuff.<p>Basically we're back where we were in 2015, just with more yaml.<p>The good things that have come out of devops has been the dashboarding and metrics tools. Its just a shame that everything else touched by it appears to be an infinite source of busy work (looking at you kubernetes)<p>(before anyone asks, I'm an SRE at a FAANG.)
Yuck, Portainer... when I read that I get nightmares.<p>The problem is: when you give developers access to Kubernetes, to ECS, to Portainer, to <i>whatever</i> they. will. not. care. about literally anything. You'll find a hotpot of cobbled together Dockerfiles with zero provenance, with base images pinned to stuff years old, and completely inefficient layer ordering. Pipelines won't use caching or parallelism (okay, sometimes because they use Maven which is a clusterfuck on its own).<p>Software developers are <i>developers</i>, 90%+ will never have heard of how Linux works below the hood, how Docker actually works, they'll just copy and paste together stuff from Stackoverflow without even attempting to understand how it works.<p>And I don't even blame them. I can't, I don't want and I won't.<p>Companies, it's time to stop loading stuff onto your developers that they don't have to (have) any clue. JFC.
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.<p>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 time I've spent writing actual application code.
If the DevOps "culture shift" didn't solve problems for you, this will not either. You will still have similar problems, now abstracted away into a different team that operate at their own pace. They will also be overbooked, like before, with the difference that now they are serving multiple teams you didn't have to contend with before. They will not share your incentives or priorities for specific features. Their time will still not be taken into account during product planning.<p>Both the DevOps move, and its current issues, as well as platform engineering are organisational problems. Your organisation needs to be set up around this in order for it to succeed.<p>Notice that the article paints platform engineering with the same utopia like brush strokes that once painted "DevOps as a culture", only to be mangled in its handling and blamed for the problems that it brought about.
The creation of DevOps teams instead of SRE / Platform seems pretty common and I think originates from ignorant engineering leaders and poorly defined roles and responsibilities. You want to leverage the expertise of the folks who focus on cloud infrastructure, but you can't move the responsibility of operations away from the application teams without seriously compromising incentives that effect quality, throughput and reliability.
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 deployment friction and hardware costs, so we are back to DevOps being an almost completely separate field from software engineering, and the programmers still can't deploy software.
All this IT stuff fails, needs to be replaced, repaired, or adapted to a new situation.<p>The best solutions, whatever the methodology and avenue of implementation, are made better when the builders "live below the dam."<p>The incentive to build the best dam is when the party responsible must live below the dam.<p>The best metric is customer retention. Directors of customer support need to be on the phone with escalations, not just watching metrics. There's a leak? Take the complaints. Embrace the hate. Fix the damn dam.
Replacing "DevOps" with "Platform Engineering" is not waving a magic wand and removing problems. The original article's main point is: "use DevOps marketplaces", more or less, but that comes with its own set of headaches (mainly auditing and making sure you trust them, which might easily take more time than rolling your own stuff).<p>I fully stand behind the "just have programmers that write internal tooling" recommendation though. Over the course of my long career this is what has worked best almost every time, and these are the programmers who get the least amount of respect even though they have to dance and juggle on a burning rope more often than not.
2023 DevOps is awesome.<p>Today's "sysadmins" are kind-of, sort-of expected to know a programming language, at least superficially. This was definitely not the case in 2015.<p>The whole idea of Platform Engineering formally existing (I.e. platform is a product) is fantastic. There has always been lip service from IT about treating the rest of the business as customers, but the definition of "customer" was usually bastardized to fit whatever agenda IT execs wanted to push. Not the case (as much) anymore.<p>Also, the idea that today's "sysadmins" are part of application delivery into production was extremely nascent in 2015. Most sysadmin jobs didn't touch apps with a 10-ft pole back then. This, IMO, is the greatest benefit the movement brought to bear.<p>Shoot, even the fact that saying DevOps feels dated because it's obvious now demonstrates how far we've come.<p>Saved the best for last. Kubernetes is hella complicated compared to 2015 "DevOps" tech stack (which i miss because they are simple), but provides so so so SO many benefits for free, especially if you're not in public cloud.
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Simpler solutions, conveyed and implemented in human language, will be king in 2024.
DevOps is terrible because we want to have a team of fullstack expert engineers that have certs in every tech, but pay them for a single role.<p>First there are not enough ppl with that huge landscape of knowledge.<p>Second you would have to pay a salary of 5 ppl i.e. 500k/y to make ppl willing to spend that much time on work.
The original article is here, this guy just copied it, lol<p><a href="https://medium.com/@mbianchidev/2023-devops-is-terrible-ec88162c86d7" rel="nofollow noreferrer">https://medium.com/@mbianchidev/2023-devops-is-terrible-ec88...</a>
"DevOps" as in Developers being closer to Ops, or "DevOps" as in "I'm a shiny Golang outfit that is going to solve Real Problems TM with YAML and a bunch of templated-generated Golang?"<p>I realize this is a bit of an odd tangent, but I would love to hear cadey talk more about what "devops" means at a shop like Tailscale. Actually, as I type this, even more curious. I know some of those folks are cut-me-and-I-bleed-Go types, but I also know they're deep into NixOS for server management. It would be very interesting to hear more about how those intersect for their infra/server/dev culture.
In my opinion, more than half the problem is the tooling, as indicated by the cartoon in the linked article.<p>DevOps pipeline languages are generally either weakly typed or stringly-typed. They generally expect users to do the control character escaping, in several different obscure formats. Did I say escaping? I meant three layers of nested escaping!<p>Variable/macro substitution as a rule uses syntax that overlaps with either PowerShell, Bash, or both because otherwise it would be <i>too easy</i>.<p>Another basic thing is the absence of a debugger — I have to run a complete pipeline with a <i>change</i> to dump out environment variables!<p>Instructions contain the display names of paths, scripts use the variable names, but the output (and errors!) use the values with no clear mapping backwards. What the eff is C:\s\1\x? I dunno, but it caused an error!<p>The worst sin is not having a local development experience where the entire pipeline can be run without having to commit code and push stuff almost all the way to production. Even if the pipeline agent is made available, it’s useless without the underlying VM image which is huge and not easily obtained. Not to mention KMS/KeyVault and other similar services on which pipelines can depend.<p>Developers complain about having to do DevOps, but in my opinion the problem isn’t <i>who</i> is doing it, but <i>how</i>. The tooling is just so bad, so <i>very very bad</i>, that anyone would hate it if they were the ones forced to do it. I’m an ex-dev-now-SRE and I hate it.
What drives me nuts is the number of places that expect you to have deep experience with whatever CI/CD solution they're using before they'll even consider you for a position. How have we gotten to the point where deploying an application is so fucking arcane of a process that you need to have 5 years of experience with whatever acronym soup some CTO bodged together or you are considered worthless?
DevOps as a culture vs DevOps as the neo modern unix admin has no right answer. It's just like software development philosophy and organization.<p>It's a fine approach, if you have a well aligned group of people working with the same understanding. The same is true for places that prefer to draw boundaries of responsibility in other ways.
Looks like OP copied and pasted the entire article from somewhere else. <a href="https://medium.com/@mbianchidev/2023-devops-is-terrible-ec88162c86d7" rel="nofollow noreferrer">https://medium.com/@mbianchidev/2023-devops-is-terrible-ec88...</a>
This is the original author / article - <a href="https://medium.com/@mbianchidev/2023-devops-is-terrible-ec88162c86d7" rel="nofollow noreferrer">https://medium.com/@mbianchidev/2023-devops-is-terrible-ec88...</a>
Most commenters here seem to ignore the fact that saas deployments have become increasingly complex over last decade in part bc low hanging fruit has been picked. Also the massive scale of even relatively no-name companies out there.<p>I'd add that most of the 1-4 "problems" (boo-hoo, managing IAM is boring for devs) OP mentioned as well as advent of so called "platform engineering" stem from one thing only - poor engineering leadership.
Devops got stunted or intermingled with the great migration to the Cloud. It could be practiced on any level of infrastructure, but the discourse currents of the Cloud were too strong.
Sysadmin, devops, platform eng all suffer from made up problems.<p>What’s IAM?<p>Access control.<p>What’s a firewall?<p>Access control.<p>What’s a route table?<p>Access control.<p>What are resource limits and reservations?<p>Access control.<p>Yet years of legacy solutions has us discussing all these things as if they are fundamentally different. User management comes wrapped in vacuous jargon. Network addressing schemes are completely design by the pocket protector committee (fuck off they can be wrapped in abstraction that is less obtuse jargon and more memorable/mnemonic).<p>There are no users, groups, or network routes in the machine. Devops is obtuse access control because a lot of companies can make money from insuring its obtuse access control.
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?