I’ve long held this opinion but I consistently get drowned out.
DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways.
All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be.
There is also a lot of rewriting of history that gets thrown in, similar to how when people talk about cloud then the only alternative is to start making CPUs by hand and begin building your own nuclear reactors. It’s the idea of what came before, not the reality, that people seem to be defensive of.
It’s honestly exhausting to discuss.
So instead I became CTO so I can solve this mess properly, I don’t hire devops, I hire infra engineers, build engineers, release engineers and: backend engineers.
Roles so simple that you already have a clue what they do, which is sort of the point of job titles.
I have bewilderingly tried to discern why software development continues to grow more and more complex.
It wasn’t always like this. There was a time when we talked about languages and OSes and libraries as if they made a difference on how much you could get done with as little people and cognitive load as possible (the claims were very much overrated, but the point was we acted like it mattered).
And then it started ballooning. It seems to me that much of that coincides with a lot of new money being dumped into the economy, and software moving past the necessary-evil-so-how-do-I-drive-down-my-costs and on to the gold rush of you must have a web app for your service that rivals a video game in complexity and visual finesse. It seems to me that as long as their is so much free money sloshing around venture capital funding, that it was inevitable that the process of making software would complexify to soak up the extra cash. After all, you can only add so many levels and varieties of managers to add value. After that comes the variegation in roles of software development.
I like the Uncle Bob explanation: the number of developers has a doubling rate of ~5 years due to the constant entry of new developers [1]. Over time, the number of inexperienced developers far outweighs the experienced ones. Inexperienced developers naturally gravitate toward complexity because they don't know any better.
Couple that with a social drift toward hyper-specialization. That sort of hierarchy naturally creates minds that don't think at the systems level. This is the general theme of Buckminster Fuller's Operating Manual For Spaceship Earth: the shift toward hyper-specialization (or narrow focus) has long-term disastrous consequences.
When you couple inexperience with narrow focus, you get messes.
Part of this is to blame on the industry-standard thinking that because someone works for Company X, they're a competent, logical engineer (and should be granted authority/responsibility over essential products/projects). This is the downfall of "code tests" and "whiteboard coding." They don't evaluate for systems level thinking and so a developer with poor creativity and logic skills slips through the cracks because they're great at eeking performance out of a function which impresses the lollipop guild.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.[2][3]
— Melvin E. Conway
The problem isn't necessarily software itself, but how we organize people (more than 2 or 3), how we communicate, how we mirror operations, expectations, etc. in software.
Scaling sustainable software feels like an "unsolved" Problem, because the society hasn't figured out how to organize better.
> I have bewilderingly tried to discern why software development continues to grow more and more complex.
It's because of growth, software development today is both simpler and way more complex than before and that's entirely due to growth in the sector. In many ways it's simpler than it ever was, I'm writing an API using Lambda/API Gateway in AWS and it blows me away how quickly I am able to get services stood up and configure my API. But in another way it's so much more complicated, for this same API I spent 2-3 weeks experimenting and researching IAM roles and how all my AWS resources would interact with one another.
I would say the floor of software development has become way simpler, deploying a site to Netlify is way easier than dealing with webservers of the past. But while the floor is lower than ever before, the ceiling is in the stratosphere, with extremely complex systems that you can string together in the "Public Cloud".
My theory is we need to add "software history" to computer science education programs. How many developers whose careers began after 2000 have ever hand written or know the power of a Makefile? I've worked at research labs and major animation studios that back in the 90's the entire infrastructure was fully automated thru Makefiles, and it purred like a well fed cat. There are hundreds of thousands of forgotten perfectly fine software tools, ignored simply because our industry has absolutely no respect for it's own history or lessons painfully learned beyond pulling up disparaging stories for new marketing angles.
It has blown me away too. There was a time where it seemed like the default "devops" strategy for startups was to use Heroku. Developers could spend all their time working on code. Worked at a startup a few years ago. We had 2 devs, and one devops guy building out Kubernetes, Docker, running on Aws. Had to constantly spend me time with him troubleshooting why this or that thing wasn't working rather than writing application code. We had like a 100 concurrent users.
Now I am working at a large org for an internal application. There is an ops team I push code to github and Jenkins runs the CI and deploys it to a dev environment. I push a button in Jenkins to deploy to production. In two years there has been one ops related issue where I had to bump up the memory limit from 2GB to 4GB. There is a single server and a database. Setup works fine for a few thousand concurrent users. My skills are in development and understanding business reqs, not mucking about in config files. There are people that are good at that and enjoy doing that, let them handle it.
Because you have, in 90 (99?) percent of instances a smart person (probably IQ 120+) doing a stupid menial job that requires a level of competence that only someone smart can provide.
So to prevent themselves from ending it all, they invent things to do to keep themselves sane while they churn out CRUD apps all day long for decades. Sometimes you get truly amazing software, but most of the times it's just reinventing the wheel, but worse.
Even worse, some of them become infatuated with doing things "Like Google," and errant CTOs enable them, leading to a 6 person team supporting a piece of software that could be replaced with WordPress, to the betterment of the primary stakeholder.
I've been consulting for over a decade now. The number of times a potential client has told me they've spent into the six figures (or eight) for something that free software does out of the box but better is depressing. The worst part? I usually can't convince that person they've been absolutely swindled, and so I have to let them keep on their merry way.
I semi-agree but my take is that money can buy you people, it can buy you lines of code, more moving parts, more stuff. But it can’t buy elegance, efficiency and good design - those have to be nurtured. Most engineers nowadays haven’t ever seen a codebase that isn’t a hot mess (no offence folks). The demand for talented and experienced engineers eclipses the available supply. The industry is growing too fast for that. The engineers that really are good are needed in leadership, or become founders.
Your guess is as good as anyones at this point. There’s just many over corrections that resemble strong levels of grandstanding. React is complex? Okay, let’s ditch JavaScript and just do basic server rendered pages.
It’s a laughable over reaction (pun unavoidable).
These are manic states the dev community enters, and all pragmatism is lost in our discourse on the solution.
Cooler heads are not prevailing. There is certainly a solution in the middle.
Devops is bullshit is also an over correction. It’s worth saying that making infra more accessible is a democratization of that entire sub-field. How do we preserve the good part of that?
I completely agree that 20+ years of cheap money have absolutely caused much of the complexity we see today. That's because people aren't working on problems that matter; instead, they're just trying to make VCs rich--effectively passing the buck on to the greater fool. I think this era is coming to an end, and we should see a drastic reduction in software development costs with the end of cheap debt.
The complexity of what we are building keeps expanding. Theres no large conspiracy. We have a lot of tooling to build things that were near impossible to build in the past.
SaaS model requires software to be always online (strict sla) and you need to be able to update it without downtime or very little downtime. That’s the reason. For example, telecom software that always had these requirements was always complex
My theory is a variation on that, which is that the money has placed so many more people in the space you inevitably end up with more people working in different directions, the JS ecosystem especially comes to mind here.
There is this moronic obsession with "scaling" in this industry, and it just blows my mind. You can have a wildly successful and profitable company while serving just a few hundred customers that requires nothing more than a basic LAMP stack.
Meanwhile people are now spending millions of dollars and years of person-hours building MVPs in the cloud that won't ever go anywhere because the business model sucks.
Focus on delivering value to your customer first. How you get there is quite literally irrelevant to your customer.
I sometimes marvel at how few people worked on various pieces of commercial software in the 90s. You'd have 4x the headcount and still take twice as long, today. And it'd probably be webshit instead of native because "productivity matters more than performance".
This is my theory too, and as someone learning to program (hopefully as a career), I'm very worried what a new paradigm of tightening will do to the field. I feel like LOTS of people who think their stack is secure are going to get dropped because at the end of the day, lots of the B2B SaaS doesn't actually deliver anything to the world of material needs.
I tried out cloudflare for the first time yesterday using a personal website. Previously I was just using a domain registrar and setting DNS to digital ocean. cloudflare is a very different/complex beast, but I can imagine that the pretty interface alone brings in customers.
I don't like this hyper-expansion either, but when you have an army of monkeys on typewriters, well, a lot gets "produced".
This just reads like a "Damn kids, get off my lawn!" type comment to my admittedly young mind. Same with a lot of similar comments I see floating around HN, especially ones that have anything to do with web development.
This echoes the philosophy of Google Site Reliability Engineering, which (this is key) is an engineering discipline.
The job of DevOps is not to close tickets. That'd be like driving a car by shouting directions at someone lying on the floorboards holding a wrench to the steering pinion.
The job of DevOps is to build a steering wheel (and ideally, teach SWEs how to drive... at least enough that they understand what a "road" is and why it's a pleasant experience for everyone if you stay on it. If the road doesn't go where they need to be, then it's time to file a ticket, but that ticket had better be "Build a new road," not "Offroad this one car to the cabin in the woods and call it a job well done").
The raw hardware of an enterprise deployment is so flexible it solves nobody's problem. DevOps is in the business of writing the operating system for a mega-computer physically represented by hundreds to possibly millions of heterogeneous computers. It's a process of continuous growth to make that work.
> If the “DevOps” team ships a Postgres RDS instance it will run fine forever, that is until an application starts using it. All of a sudden a cascade of N+1s hit, the CPU spikes, and queries grind to a halt. Who is woken up? And why does this always happen at 2 AM? In this scenario, there is nothing for operations personnel to do, yet here they are.
This is definitely a symptom of a broken model and not what I would call devops. IMO the most important tenant of devops is "if you build it, you run it," meaning the appdev team that decided to use Postgres RDS is the one getting woken up at 2am.
It's also, in my experience, one of the best ways to reduce masturbatory engineering decisions and get people to focus on picking boring technology that works. Coding up a serverless application in Rust that's using a CockroachDB backend at a Python/MySQL shop would get a lot of engineers excited, but those people would be less excited knowing they're going to be the ones paged at 2am when this new and exciting architecture falls over in an unfamiliar way (as opposed to Python/MySQL, where a wealth of operational knowledge at the org has already been built up).
Similarly, it naturally reduces architecturally complexity. Younger senior engineers love drawing boxes of queues, multiple microservices, event buses, etc to show off their skill in creating the ultimate engineering fantasy, but once you throw enough late night operational incidents at a senior engineer, suddenly the preferred architecture becomes "an executable running on a box that I can SSH into when things go wrong."
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code.
There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and a single point which all work flows through. Then you don't wander onto a new project only to realize they use $BESPOKE_DEPLOYMENT_METHOD because "it's what we used 6 months ago". Or worse, you don't have a developer playing with a massive, nuclear powered, foot gun like Terraform and accidentally destroying infrastructure.
Making DevOps/DevSecOps/$BUZZWORD the responsibility of developers is a cost-cutting measure not a responsibility measure.
It is more nuanced. I care, but my skillset demands I spend more time on the Development side, so Operations must take the backseat in my mind because of this incentive structure. Asking one person to do two (actually three) job functions is a scam.
Most developers have to do Frontend, Backend, and Ops. These have wildly different mindsets and feedback loops and not enough time exists. Don't hate the player, hate the game. The orgs are fucked, not the workers.
Sometimes the engineers _do_ care about the deployment and operations of their apps and management doesn't let them administer them in production under the guise of "separation of responsibilities" or "regulatory compliance". It makes the ops team unhappy that they're on the hook for stuff they didn't build and the dev team unhappy because they're steering their metaphorical ship by proxy.
I'm not sure why this happens but it does and I don't like it (as somebody who's very M-shaped).
I absolutely care where and how my code runs. And yet I don't give a damn about writing terraform, managing IAM, VPCs, keeping up with backups, upgrades, etc. I want specialists who know what they're doing to deal with that stuff.
I'm also not convinced that the average junior or mid level application dev needs to know where or how their stuff beyond some high level concepts (i.e. our app uses auto scaling).
I've done some, and it feels like reading an arcane text in another language. I've seen the thing I want before, so I know there exists a magical YAML incantation that brings it about but I have no idea how to even start looking for it. It devolves to an extremely slow feedback loop of "did that work? No."
I've never found anything that explained how I'm supposed to create a systematic approach to creating anything I need.
> You have people who build stuff without caring where and how it runs.
In the old days, developers would also configure the design of the system it ran on.
"Alright, we're going to use some fast CPU front end nodes with smaller, faster disks, and then have a load balancer, our database server is going to have the most RAM, now let's set these resources up on a CDN to serve faster, this memacache server is really going to lighten the load..."
I think the idea was to use tools that automatically did all this work for you, but it just ended up creating another tier of people that configure this side of it.
Yup. I basically came here to quote the same line answering with "And I don't want to work with them."
Though mind you, the article touches - but doesn't go into - the real reason things go shit. It's not ops, it's not devops, because your knowledge silo can too, and in my experience (that's longer than the writers, lol) _will be_ pressured.
If the estimates are consistently too low (because honest ones would render many - maybe most - projects non-viable), the requirements are often bullshit (because otherwise the lies in the estimate would be too obvious, and everyone needs to agree on the lie) and and rewards are not the ones the jobs claims to be (in every workplace, your job is to improve your resume. That's all. That's the only thing that, materially, matters for your career. I can care about software I write, but if anything I end up punished for it) - then no amount of renaming things and shifting org charts around or motivational reading for managers is going to fix that. Nor will a Cloud or latest orchestration software.
That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022.
Counter points as to why DevOps is not BS:
Today there's just an acceptance that you version your code in VCS, it wasn't always that way. "Hey, this doesn't look right, i know you said you based your change on gui-app.latest-final2.zip but was that Steve or Laura's version of latest-final2?". If you didn't work through this period you'll struggle to believe how common it was for shipping products not to be fully up to date in VCS or not to have VCS at all. DevOps changed this.
Continuous integration? No there were people hired as "merge masters" or "build managers", i promise i am not making this up. DevOps changed this, the idea that you wouldn't do at least CI or perhaps CD is unexpected today.
Deployment automation? Sure, you email it to the ops team, send a few more emails with attachments late on Friday with ammendments and hope that they deploy the right one. Automated deployment as far as the developer was concerned. The ops person on the other end? Sure they had a batman's belt full of hand crafted tools and scripts but it was definitely pets not the cattle DevOps has made us strive for.
Testing automation? The testers sit on level 3 not next to dev on level 4, there's about 4 banks of desks over by the cupboards, that's all the testers. They have lotus notes databases with checkboxes to confirm when they test something. If they find an issue a regression report will arrive with the dev team in under a week.
I could go on an on. Platform teams are great when used correctly. You can say something similar about DevOps.
At uni back in ~2000 was the first time I ever heard of version control. It was a bit of a curiosity, nobody seemed to be using it.
In 2004, engineering at the place I worked (you've heard of it) were developing PL/SQL in production with no VCS.
In 2007, I worked in IT at the same place. They were developing in SharePoint without VCS. When I asked if I could use VCS, I was told to use a 1996 or so Visual SourceSafe which was more temperamental than Subversion.
The first place I worked that used VCS was in 2008, and only because the devs had started using it against the wishes of the principal developer.
> That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022.
Serious question, as I think this has been part of my thought process in the challenges of platform engineering: what does it mean to automatically provision a database?
I can think of lots of different examples that are insufficient in one way or another (I think I'm mostly talking UX here, and how many questions the user has to answer in one way or another / infrastructure as code, not should the user have to apt-get install postgres, which should I think rather obviously be automated.) But if infrastructure as code is defined as automation, this can conflict with the developers who don't want to learn terraform and thus still leads to "file a ticket with devops"
Over the last ten years, the market has tried to kill off the hardware, systems, network and security people, and mostly succeeded.
As a result, it's relatively easy to find someone who advertises as "full stack devops" who has never actually operated any infrastructure more complex than a LAMP webserver cluster. And it's hard to find a senior sysadmin who has enough years of experience to understand and troubleshoot all of your infrastructure from layer 0 up. People with that experience have moved into management or consulting or retirement, and there are no jobs for new folks.
I had a very weird sensation while reading this where I was shaking my head disapprovingly at this article. Specifically when they were talking about the commoditization of DevOps.
Speaking personally, I used to work on a Platform Engineering team for a major multinational that rhymes with ay-do-bay. And their requirements for the workloads that we needed to be built and hosted where very unique because you have teams running completely different languages and toolchains, esp. from acquisitions. I can argue there that the template K8s setups wouldn't work.
In the author's case, the only reason why they feel the way they do is because we finally have some sense of standardization on what Infra looks like for most companies. It's no longer a question for most folks if they should adopt Docker, we have accepted images into our lives. Same for K8s (after a certain point of scale). So uh... yea. Catchy blog title to sell some thin layer on top of K8s in which it doesn't solve the root issue that they are talking about.
I'm not sure if having two teams is always going to be better than having one DevOps team, but my experience in having two teams is that it's rare to have the incentives aligned. The author of the post pointed out that dev teams will cut corners and throw broken applications over the wall to ops to deal with.
When ops gets woken up at 2am because someone in dev cut corners, what happens? Does dev feel the pain? Almost never.
The same thing happens when outside contractors develop code. They often provide a buggy and undocumented mess, and then no longer work on the project. They never feel the pain, so they're not incentivized to provide good code.
Until we find ways to align incentives, we're going to keep getting crap whenever more than one team is involved.
Reminds me of that time when my team was called into a meeting where the CTO "advised" us that "code does not have to be perfect", when all we wanted to do was review the code for a PoC that we were ordered to "own" and deploy to production (even the creator said he cannot guarantee the code he copied from Stack Overflow for the PoC is production-ready).
In the same meeting, the CTO was ranting about the instability of a service (which was also a PoC that was pushed to production before we were _also_ made to "own" it, yet never given the budget to even get acquainted to the codebase), claiming the reason for that because we devs are lazy and unprofessional.
I highly doubt making people who _responds_ to the incentives to "feel the pain" will fix much. I suspect things are more likely to get fixed if the people who _creates_ the incentives are the one "feeling the pain".
As they say in Hunger Games, "remember who the real enemy is".
On the other side, the ops team sets up a system of slow and complicated deployments, but they don’t have to deliver features with it, they don’t feel the pain of working with it as much as the feature devs.
I disagree. DevOps was intended to break the organizational mindset of having this group of people here doing this set of activities and this other group of people over there doing that set of activities when in reality both groups of people are needed to work together and deploy software. It was about breaking down those organizational silos. Anybody creating a dedicated "DevOps" team was way off the mark, unless that team was a coaching team whose job it was to help other teams become self-sufficient. Unfortunately the fact that an engineering team had responsibility for their software from implementation, to deployment, to operations was a news flash to large organizations having traditional IT staff. The DevOps mindset has led to much better operational excellence.
The DevOps mindset has also led to the Internal Developer Platform this article discusses. Honestly, I don't see how traditional IT organizations are going to easily arrive at such a platform without having adopted the DevOps mindset first.
So DevOps isn't bullshit, but it's not the end goal either. It's a necessary step needed on your journey for getting somewhere better.
When I ran a fairly small team of engineers, I created what I called an "Infrastructure Engineer." I staffed it with a fairly junior, but still brilliant, engineer.
He rapidly became the most popular member of my team.
His job was to commoditize configuration management, and strip away as much of the overhead from the coders, as possible. He didn't do release management, and we didn't really work automatic testing into our release workflow. This was because Japan did not trust auto-testing, so each engineer did their own unit and harness testing. Japan also wanted each engineer to make their own "official" release, as opposed to having a CD system spit it out.
There were reasons. I didn't necessarily find them that compelling, but they were the boss, so I gave them what they wanted.
Japan liked him, as it gave them one single person to talk to, and he also helped them to streamline their own infrastructure. In fact, he is the only employee that I ever had (including myself), that traveled to Japan before being there a year.
For myself, I find using things like Fastlane, JIRA, and Jenkins, aren't actually helpful, for a one-man shop. I tend to do a lot of stuff by hand.
Most developers have no fucking clue how Linux, networking, storage or whatever works under the hood. They know how to develop whatever stack you're at, but stuff like latency, packet loss, redundancy factors, backup policies, monitoring or other classic ops topics are completely beyond the comprehension of 99% of developers.
"DevOps" usually means some C-level execs say "fire the expensive neckbeards that have the time to properly understand a system" followed by them saying one of
- "oh fuck, someone managed to compromise a service and because no one knows what the fuck firewalls are / Kubernetes doesn't come with ones OOTB the hacker got complete control of everything"
- "oh fuck, production is down because someone fat-fingered in Elastic Beanstalk which recreated the environment, dropped the RDS database and there were no backups" (I've been personally bitten in the arse by their definition of "recreate" - all I wanted it to do was to replace the damn EC2 instance)
- "oh fuck, we're seeing insane AWS bills because someone DDoS'd us and no one created a cost limit or a sensible limit for autoscale or a simple dumb monitor that alerts someone"
- "oh fuck, we're seeing an insane AWS bill because someone got his AWS access credentials stolen and some shithead spun up a ton of g3.xlarge instances to mine shitcoins"
Other C-level execs see constant issues between "ops and dev teams" because their team leads are friends of the silo model and decide that instead of getting rid of the dumbass managers they're getting rid of the ops team because "cloud", with the exact same result.
I'm not sure I agree with author. Sounds like they have worked at shitty places that are using the word "DevOps" but really they are doing things the old way.
My company practices "DevOps" and it feels great:
- Infra team build self-service tools (build, deploy, scale, observe)
- Infra team write good documentation for these tools
- Dev use tools to build, deploy, and monitor their apps
- Dev not use use words like: AWS, k8, Envoy. These are abstracted by tools.
- if problem with app (very common) Dev fix it using the tools
- if problem with tool (very rare) Infra fix it
We have no build engineers, release engineers, etc. However we do have a rotation (similar to on-call) whereby Dev is responsible for releasing code that week.
Sure there are sometimes problems, frustrations, etc. No system is perfect. But you are getting paid lots of $$$ so shush with your whining & instead help improve the system.
DevOps has suffered the same fate as Agile. In particular there is one thing that both had in common that got lost somewhere in most implementations: cross-functional teams [0].
Agile teams were supposed to be composed of not just devs doing everything (quickly, because agile is about raw speed, right?) but people competent in the various aspects of the system development, potentially deployment, customer needs, etc. working together as multidisciplinary teams to meet a particular objective. The purpose of this was to break the silo that is common because it feels natural to many managers (the same sort, I presume, who don't like when their mashed potatoes touch their fried chicken on the plate).
Silos impede communication and promote the "throw it over the wall" approach to product/system development. A system engineer (or team of) made the design after sales (and possibly only sales) talked to the users. Throw that design over the wall and let the devs build it. Devs throw it over the wall to test, maybe there's a volley. Eventually it's tossed to ops. A goat is sacrificed and maybe it works.
Multidisciplinary teams are able to communicate across those boundaries because instead of the role-silo the roles are all in the same team, working (more clearly) towards one common objective. But then businesses managed to fuck it up. They got rid of test, devs do all testing now. Devs do all the database logic. There are no UI/UX experts anymore, it's all full-stack, and on and on.
DevOps was supposed to be the same. It was supposed to take that Agile cross-functional team and add in the sysadmin/operators (among other things). The critical problem being solved was the two (really more, but at the limit) silos of dev and ops failing to communicate. A Friday release with Ops spending the weekend rolling things back because Dev wasn't there and didn't even know the system wouldn't work as intended. Maybe their test environment was too different from the operational environment, the reasons matter a bit but there are too many to enumerate.
Instead, businesses did what they do best, they fucked it up. Again. They said, "Take the sysadmins and teach them to code. If they can't, dump them in the woods. The devs will takeover the world." Then they started making "devops" job listings and full-stack grew to encompass a new set of skills.
Funny, I thought DevOps was introduced as a way of having the specialists be part of the same team, so that the dev side would keep ops in mind and the ops side would be getting dev help in automating. Creating a separate DevOps team seems like a manager reading an article and implementing without understanding.
The problem in a lot of orgs is having various priesthoods that have their own goals that aren't aligned with other teams/the business. For example:
- hardware purchase
- software purchase
- DBA
- ops/infra
- networking (firewalls esp)
- security
- HR/recruiting
- business analysis
- front end/design/ux/dev
- back end dev
- technical documentation
All of these are roles and they can have specialists, but you probably want them aligned and rewarded for keeping the business running, not serving specific measurement goals like uptime, to the detriment of selling product. These priesthoods often have their own religious virtues that they espouse, like 3rd normal form or low TCO, that they pursue in absence of directions and understanding of their role in the business.
It's easy to see the problem but wicked hard to prevent it or fix it. I have a small organization and it's difficult to get people really on board with a vision.
I was semi salty reading this....but they are spot on in a lot of ways. There are times where my code looks like a bad 4 year old wrote it, but 10 minutes later I'm in a conversation where I have to explain basic security concepts, like not leaving everything wide open to the internet, to some random Sr Software Dev.
For every operations person without software development skills, there are FORTY engineers without cloud operations skills. If you are going to build an internal platform, you’ll need experts with overlapping experience in both fields working together.
I guess I just need to find a role with more inter-team collaboration; Being able to mostly self teach is great, until you have no one to learn from anymore.
The problem is that devs simply can't accept that ops exist.
We spoiled devs way too much.
Software are still being thrown over the wall and ops takes all the blame.
The problem is that many devs can get away with spawning servers and doing the easy parts of ops, when it requires rules and discipline, then we all know what happens, over engineering and security holes.
See the index on the left. Do you need to know everything about all of these things for every single project? No. But as you grow into a senior, you'll be touching almost everything in that list.
It's an absolute explosion in complexity. Web development once was barely considered engineering, now it's one of the most complicated roles in the industry. Consider also that almost everything on that list is constantly evolving, this list being 4 years old.
Has all this added cognitive load and complexity resulted in massive productivity wins and dramatically better outcomes (UX, quality)? I'd say no, or at least it's questionable.
My point being is that this is already too much. I work in teams with a distribution like this: senior (20%), medior (50%), junior (30%). So the vast majority of them are median. And the median programmer is severely lacking against our ever growing demands. It's crude, but the typical programmer really sucks at programming.
So if next you're going to add even more to this pile with all sorts of devops and funky cloud tooling, the issue becomes clear: we're over-asking.
We over-value flexibility and scaling but ignore its dramatic costs.
I hate devops. We used to have a dedicated systems team. Now programmers are expected to both write code and manage their own cloud infrastructure. These are two entirely different skill sets.
> The problem is most engineers don’t want to do operations work.
Nah, the problem is that most (software) engineers don't have the skills to do operations work.
Let's not fool ourselves: software development is 95% development (writing code/docs/test etc) and 5% system administration (getting your local mysql or whatever up and running etc) whereas operations is usually 95% screaming at the machines (various linux tasks, writing glue scripts, infrastructure, networking etc) and 5% development (the aforementioned glue scripts, writing internal docs).
The fields do overlap, but very little.
They require two different skill sets.
They require two different mindsets, too: a software engineer is usually optimistic (works on my machine, will work in prod too) whereas a sysadmin/operations person is usually pessimistic (what's our disaster recovery strategy?).
i wouldn't say the operations view is pessimistic perse.
Its a different frame of mind, mainly because its the place where the rubber meets the road so to speak. Once things are production, you cannot revoke or redesign your product/system because people are directly reliant on it.
[+] [-] dijit|3 years ago|reply
DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways.
All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be.
There is also a lot of rewriting of history that gets thrown in, similar to how when people talk about cloud then the only alternative is to start making CPUs by hand and begin building your own nuclear reactors. It’s the idea of what came before, not the reality, that people seem to be defensive of.
It’s honestly exhausting to discuss.
So instead I became CTO so I can solve this mess properly, I don’t hire devops, I hire infra engineers, build engineers, release engineers and: backend engineers.
Roles so simple that you already have a clue what they do, which is sort of the point of job titles.
[+] [-] travisgriggs|3 years ago|reply
It wasn’t always like this. There was a time when we talked about languages and OSes and libraries as if they made a difference on how much you could get done with as little people and cognitive load as possible (the claims were very much overrated, but the point was we acted like it mattered).
And then it started ballooning. It seems to me that much of that coincides with a lot of new money being dumped into the economy, and software moving past the necessary-evil-so-how-do-I-drive-down-my-costs and on to the gold rush of you must have a web app for your service that rivals a video game in complexity and visual finesse. It seems to me that as long as their is so much free money sloshing around venture capital funding, that it was inevitable that the process of making software would complexify to soak up the extra cash. After all, you can only add so many levels and varieties of managers to add value. After that comes the variegation in roles of software development.
That’s my working theory anyway.
[+] [-] rglover|3 years ago|reply
Couple that with a social drift toward hyper-specialization. That sort of hierarchy naturally creates minds that don't think at the systems level. This is the general theme of Buckminster Fuller's Operating Manual For Spaceship Earth: the shift toward hyper-specialization (or narrow focus) has long-term disastrous consequences.
When you couple inexperience with narrow focus, you get messes.
Part of this is to blame on the industry-standard thinking that because someone works for Company X, they're a competent, logical engineer (and should be granted authority/responsibility over essential products/projects). This is the downfall of "code tests" and "whiteboard coding." They don't evaluate for systems level thinking and so a developer with poor creativity and logic skills slips through the cracks because they're great at eeking performance out of a function which impresses the lollipop guild.
[1] https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
[+] [-] Jorchime|3 years ago|reply
Scaling sustainable software feels like an "unsolved" Problem, because the society hasn't figured out how to organize better.
[+] [-] _fat_santa|3 years ago|reply
It's because of growth, software development today is both simpler and way more complex than before and that's entirely due to growth in the sector. In many ways it's simpler than it ever was, I'm writing an API using Lambda/API Gateway in AWS and it blows me away how quickly I am able to get services stood up and configure my API. But in another way it's so much more complicated, for this same API I spent 2-3 weeks experimenting and researching IAM roles and how all my AWS resources would interact with one another.
I would say the floor of software development has become way simpler, deploying a site to Netlify is way easier than dealing with webservers of the past. But while the floor is lower than ever before, the ceiling is in the stratosphere, with extremely complex systems that you can string together in the "Public Cloud".
[+] [-] bsenftner|3 years ago|reply
[+] [-] confidantlake|3 years ago|reply
Now I am working at a large org for an internal application. There is an ops team I push code to github and Jenkins runs the CI and deploys it to a dev environment. I push a button in Jenkins to deploy to production. In two years there has been one ops related issue where I had to bump up the memory limit from 2GB to 4GB. There is a single server and a database. Setup works fine for a few thousand concurrent users. My skills are in development and understanding business reqs, not mucking about in config files. There are people that are good at that and enjoy doing that, let them handle it.
[+] [-] debacle|3 years ago|reply
So to prevent themselves from ending it all, they invent things to do to keep themselves sane while they churn out CRUD apps all day long for decades. Sometimes you get truly amazing software, but most of the times it's just reinventing the wheel, but worse.
Even worse, some of them become infatuated with doing things "Like Google," and errant CTOs enable them, leading to a 6 person team supporting a piece of software that could be replaced with WordPress, to the betterment of the primary stakeholder.
I've been consulting for over a decade now. The number of times a potential client has told me they've spent into the six figures (or eight) for something that free software does out of the box but better is depressing. The worst part? I usually can't convince that person they've been absolutely swindled, and so I have to let them keep on their merry way.
[+] [-] jahewson|3 years ago|reply
[+] [-] jesuscript|3 years ago|reply
It’s a laughable over reaction (pun unavoidable).
These are manic states the dev community enters, and all pragmatism is lost in our discourse on the solution.
Cooler heads are not prevailing. There is certainly a solution in the middle.
Devops is bullshit is also an over correction. It’s worth saying that making infra more accessible is a democratization of that entire sub-field. How do we preserve the good part of that?
[+] [-] nathanaldensr|3 years ago|reply
[+] [-] ldjkfkdsjnv|3 years ago|reply
[+] [-] dilyevsky|3 years ago|reply
[+] [-] user3939382|3 years ago|reply
[+] [-] woeirua|3 years ago|reply
Meanwhile people are now spending millions of dollars and years of person-hours building MVPs in the cloud that won't ever go anywhere because the business model sucks.
Focus on delivering value to your customer first. How you get there is quite literally irrelevant to your customer.
[+] [-] yamtaddle|3 years ago|reply
[+] [-] boppo1|3 years ago|reply
This is my theory too, and as someone learning to program (hopefully as a career), I'm very worried what a new paradigm of tightening will do to the field. I feel like LOTS of people who think their stack is secure are going to get dropped because at the end of the day, lots of the B2B SaaS doesn't actually deliver anything to the world of material needs.
[+] [-] imetatroll|3 years ago|reply
I don't like this hyper-expansion either, but when you have an army of monkeys on typewriters, well, a lot gets "produced".
[+] [-] sensanaty|3 years ago|reply
[+] [-] shadowgovt|3 years ago|reply
The job of DevOps is not to close tickets. That'd be like driving a car by shouting directions at someone lying on the floorboards holding a wrench to the steering pinion.
The job of DevOps is to build a steering wheel (and ideally, teach SWEs how to drive... at least enough that they understand what a "road" is and why it's a pleasant experience for everyone if you stay on it. If the road doesn't go where they need to be, then it's time to file a ticket, but that ticket had better be "Build a new road," not "Offroad this one car to the cabin in the woods and call it a job well done").
The raw hardware of an enterprise deployment is so flexible it solves nobody's problem. DevOps is in the business of writing the operating system for a mega-computer physically represented by hundreds to possibly millions of heterogeneous computers. It's a process of continuous growth to make that work.
[+] [-] mjr00|3 years ago|reply
This is definitely a symptom of a broken model and not what I would call devops. IMO the most important tenant of devops is "if you build it, you run it," meaning the appdev team that decided to use Postgres RDS is the one getting woken up at 2am.
It's also, in my experience, one of the best ways to reduce masturbatory engineering decisions and get people to focus on picking boring technology that works. Coding up a serverless application in Rust that's using a CockroachDB backend at a Python/MySQL shop would get a lot of engineers excited, but those people would be less excited knowing they're going to be the ones paged at 2am when this new and exciting architecture falls over in an unfamiliar way (as opposed to Python/MySQL, where a wealth of operational knowledge at the org has already been built up).
Similarly, it naturally reduces architecturally complexity. Younger senior engineers love drawing boxes of queues, multiple microservices, event buses, etc to show off their skill in creating the ultimate engineering fantasy, but once you throw enough late night operational incidents at a senior engineer, suddenly the preferred architecture becomes "an executable running on a box that I can SSH into when things go wrong."
[+] [-] counttheforks|3 years ago|reply
There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.
[+] [-] Test0129|3 years ago|reply
There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and a single point which all work flows through. Then you don't wander onto a new project only to realize they use $BESPOKE_DEPLOYMENT_METHOD because "it's what we used 6 months ago". Or worse, you don't have a developer playing with a massive, nuclear powered, foot gun like Terraform and accidentally destroying infrastructure.
Making DevOps/DevSecOps/$BUZZWORD the responsibility of developers is a cost-cutting measure not a responsibility measure.
[+] [-] lucasyvas|3 years ago|reply
Most developers have to do Frontend, Backend, and Ops. These have wildly different mindsets and feedback loops and not enough time exists. Don't hate the player, hate the game. The orgs are fucked, not the workers.
[+] [-] alexjplant|3 years ago|reply
I'm not sure why this happens but it does and I don't like it (as somebody who's very M-shaped).
[+] [-] Merad|3 years ago|reply
I'm also not convinced that the average junior or mid level application dev needs to know where or how their stuff beyond some high level concepts (i.e. our app uses auto scaling).
[+] [-] wry_discontent|3 years ago|reply
I've done some, and it feels like reading an arcane text in another language. I've seen the thing I want before, so I know there exists a magical YAML incantation that brings it about but I have no idea how to even start looking for it. It devolves to an extremely slow feedback loop of "did that work? No."
I've never found anything that explained how I'm supposed to create a systematic approach to creating anything I need.
[+] [-] bluedino|3 years ago|reply
In the old days, developers would also configure the design of the system it ran on.
"Alright, we're going to use some fast CPU front end nodes with smaller, faster disks, and then have a load balancer, our database server is going to have the most RAM, now let's set these resources up on a CDN to serve faster, this memacache server is really going to lighten the load..."
I think the idea was to use tools that automatically did all this work for you, but it just ended up creating another tier of people that configure this side of it.
[+] [-] BiteCode_dev|3 years ago|reply
[+] [-] LaGrange|3 years ago|reply
Though mind you, the article touches - but doesn't go into - the real reason things go shit. It's not ops, it's not devops, because your knowledge silo can too, and in my experience (that's longer than the writers, lol) _will be_ pressured.
If the estimates are consistently too low (because honest ones would render many - maybe most - projects non-viable), the requirements are often bullshit (because otherwise the lies in the estimate would be too obvious, and everyone needs to agree on the lie) and and rewards are not the ones the jobs claims to be (in every workplace, your job is to improve your resume. That's all. That's the only thing that, materially, matters for your career. I can care about software I write, but if anything I end up punished for it) - then no amount of renaming things and shifting org charts around or motivational reading for managers is going to fix that. Nor will a Cloud or latest orchestration software.
[+] [-] CraigJPerry|3 years ago|reply
Some interpretation of DevOps may be BS, e.g.
>> Need a database? File a ticket with DevOps.
That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022.
Counter points as to why DevOps is not BS:
Today there's just an acceptance that you version your code in VCS, it wasn't always that way. "Hey, this doesn't look right, i know you said you based your change on gui-app.latest-final2.zip but was that Steve or Laura's version of latest-final2?". If you didn't work through this period you'll struggle to believe how common it was for shipping products not to be fully up to date in VCS or not to have VCS at all. DevOps changed this.
Continuous integration? No there were people hired as "merge masters" or "build managers", i promise i am not making this up. DevOps changed this, the idea that you wouldn't do at least CI or perhaps CD is unexpected today.
Deployment automation? Sure, you email it to the ops team, send a few more emails with attachments late on Friday with ammendments and hope that they deploy the right one. Automated deployment as far as the developer was concerned. The ops person on the other end? Sure they had a batman's belt full of hand crafted tools and scripts but it was definitely pets not the cattle DevOps has made us strive for.
Testing automation? The testers sit on level 3 not next to dev on level 4, there's about 4 banks of desks over by the cupboards, that's all the testers. They have lotus notes databases with checkboxes to confirm when they test something. If they find an issue a regression report will arrive with the dev team in under a week.
I could go on an on. Platform teams are great when used correctly. You can say something similar about DevOps.
[+] [-] l0b0|3 years ago|reply
At uni back in ~2000 was the first time I ever heard of version control. It was a bit of a curiosity, nobody seemed to be using it.
In 2004, engineering at the place I worked (you've heard of it) were developing PL/SQL in production with no VCS.
In 2007, I worked in IT at the same place. They were developing in SharePoint without VCS. When I asked if I could use VCS, I was told to use a 1996 or so Visual SourceSafe which was more temperamental than Subversion.
The first place I worked that used VCS was in 2008, and only because the devs had started using it against the wishes of the principal developer.
The world moves fast and slow at the same time.
[+] [-] mikkergp|3 years ago|reply
> That does seem like a bit short of the mark. E.g. that should be automated provisioning in 2018, never mind in 2022.
Serious question, as I think this has been part of my thought process in the challenges of platform engineering: what does it mean to automatically provision a database?
I can think of lots of different examples that are insufficient in one way or another (I think I'm mostly talking UX here, and how many questions the user has to answer in one way or another / infrastructure as code, not should the user have to apt-get install postgres, which should I think rather obviously be automated.) But if infrastructure as code is defined as automation, this can conflict with the developers who don't want to learn terraform and thus still leads to "file a ticket with devops"
[+] [-] dsr_|3 years ago|reply
As a result, it's relatively easy to find someone who advertises as "full stack devops" who has never actually operated any infrastructure more complex than a LAMP webserver cluster. And it's hard to find a senior sysadmin who has enough years of experience to understand and troubleshoot all of your infrastructure from layer 0 up. People with that experience have moved into management or consulting or retirement, and there are no jobs for new folks.
[+] [-] ndneighbor|3 years ago|reply
Speaking personally, I used to work on a Platform Engineering team for a major multinational that rhymes with ay-do-bay. And their requirements for the workloads that we needed to be built and hosted where very unique because you have teams running completely different languages and toolchains, esp. from acquisitions. I can argue there that the template K8s setups wouldn't work.
In the author's case, the only reason why they feel the way they do is because we finally have some sense of standardization on what Infra looks like for most companies. It's no longer a question for most folks if they should adopt Docker, we have accepted images into our lives. Same for K8s (after a certain point of scale). So uh... yea. Catchy blog title to sell some thin layer on top of K8s in which it doesn't solve the root issue that they are talking about.
[+] [-] justin_oaks|3 years ago|reply
When ops gets woken up at 2am because someone in dev cut corners, what happens? Does dev feel the pain? Almost never.
The same thing happens when outside contractors develop code. They often provide a buggy and undocumented mess, and then no longer work on the project. They never feel the pain, so they're not incentivized to provide good code.
Until we find ways to align incentives, we're going to keep getting crap whenever more than one team is involved.
[+] [-] yihtserns|3 years ago|reply
In the same meeting, the CTO was ranting about the instability of a service (which was also a PoC that was pushed to production before we were _also_ made to "own" it, yet never given the budget to even get acquainted to the codebase), claiming the reason for that because we devs are lazy and unprofessional.
I highly doubt making people who _responds_ to the incentives to "feel the pain" will fix much. I suspect things are more likely to get fixed if the people who _creates_ the incentives are the one "feeling the pain".
As they say in Hunger Games, "remember who the real enemy is".
[+] [-] atom_arranger|3 years ago|reply
[+] [-] taylodl|3 years ago|reply
The DevOps mindset has also led to the Internal Developer Platform this article discusses. Honestly, I don't see how traditional IT organizations are going to easily arrive at such a platform without having adopted the DevOps mindset first.
So DevOps isn't bullshit, but it's not the end goal either. It's a necessary step needed on your journey for getting somewhere better.
[+] [-] ChrisMarshallNY|3 years ago|reply
He rapidly became the most popular member of my team.
His job was to commoditize configuration management, and strip away as much of the overhead from the coders, as possible. He didn't do release management, and we didn't really work automatic testing into our release workflow. This was because Japan did not trust auto-testing, so each engineer did their own unit and harness testing. Japan also wanted each engineer to make their own "official" release, as opposed to having a CD system spit it out.
There were reasons. I didn't necessarily find them that compelling, but they were the boss, so I gave them what they wanted.
Japan liked him, as it gave them one single person to talk to, and he also helped them to streamline their own infrastructure. In fact, he is the only employee that I ever had (including myself), that traveled to Japan before being there a year.
For myself, I find using things like Fastlane, JIRA, and Jenkins, aren't actually helpful, for a one-man shop. I tend to do a lot of stuff by hand.
[+] [-] mschuster91|3 years ago|reply
Most developers have no fucking clue how Linux, networking, storage or whatever works under the hood. They know how to develop whatever stack you're at, but stuff like latency, packet loss, redundancy factors, backup policies, monitoring or other classic ops topics are completely beyond the comprehension of 99% of developers.
"DevOps" usually means some C-level execs say "fire the expensive neckbeards that have the time to properly understand a system" followed by them saying one of
- "oh fuck, someone managed to compromise a service and because no one knows what the fuck firewalls are / Kubernetes doesn't come with ones OOTB the hacker got complete control of everything"
- "oh fuck, production is down because someone fat-fingered in Elastic Beanstalk which recreated the environment, dropped the RDS database and there were no backups" (I've been personally bitten in the arse by their definition of "recreate" - all I wanted it to do was to replace the damn EC2 instance)
- "oh fuck, we're seeing insane AWS bills because someone DDoS'd us and no one created a cost limit or a sensible limit for autoscale or a simple dumb monitor that alerts someone"
- "oh fuck, we're seeing an insane AWS bill because someone got his AWS access credentials stolen and some shithead spun up a ton of g3.xlarge instances to mine shitcoins"
Other C-level execs see constant issues between "ops and dev teams" because their team leads are friends of the silo model and decide that instead of getting rid of the dumbass managers they're getting rid of the ops team because "cloud", with the exact same result.
[+] [-] gitpusher|3 years ago|reply
My company practices "DevOps" and it feels great:
We have no build engineers, release engineers, etc. However we do have a rotation (similar to on-call) whereby Dev is responsible for releasing code that week.Sure there are sometimes problems, frustrations, etc. No system is perfect. But you are getting paid lots of $$$ so shush with your whining & instead help improve the system.
For context my company is mid-size ~150 engineers
[+] [-] Jtsummers|3 years ago|reply
Agile teams were supposed to be composed of not just devs doing everything (quickly, because agile is about raw speed, right?) but people competent in the various aspects of the system development, potentially deployment, customer needs, etc. working together as multidisciplinary teams to meet a particular objective. The purpose of this was to break the silo that is common because it feels natural to many managers (the same sort, I presume, who don't like when their mashed potatoes touch their fried chicken on the plate).
Silos impede communication and promote the "throw it over the wall" approach to product/system development. A system engineer (or team of) made the design after sales (and possibly only sales) talked to the users. Throw that design over the wall and let the devs build it. Devs throw it over the wall to test, maybe there's a volley. Eventually it's tossed to ops. A goat is sacrificed and maybe it works.
Multidisciplinary teams are able to communicate across those boundaries because instead of the role-silo the roles are all in the same team, working (more clearly) towards one common objective. But then businesses managed to fuck it up. They got rid of test, devs do all testing now. Devs do all the database logic. There are no UI/UX experts anymore, it's all full-stack, and on and on.
DevOps was supposed to be the same. It was supposed to take that Agile cross-functional team and add in the sysadmin/operators (among other things). The critical problem being solved was the two (really more, but at the limit) silos of dev and ops failing to communicate. A Friday release with Ops spending the weekend rolling things back because Dev wasn't there and didn't even know the system wouldn't work as intended. Maybe their test environment was too different from the operational environment, the reasons matter a bit but there are too many to enumerate.
Instead, businesses did what they do best, they fucked it up. Again. They said, "Take the sysadmins and teach them to code. If they can't, dump them in the woods. The devs will takeover the world." Then they started making "devops" job listings and full-stack grew to encompass a new set of skills.
[0] https://en.wikipedia.org/wiki/Cross-functional_team
[+] [-] projektfu|3 years ago|reply
The problem in a lot of orgs is having various priesthoods that have their own goals that aren't aligned with other teams/the business. For example:
- hardware purchase
- software purchase
- DBA
- ops/infra
- networking (firewalls esp)
- security
- HR/recruiting
- business analysis
- front end/design/ux/dev
- back end dev
- technical documentation
All of these are roles and they can have specialists, but you probably want them aligned and rewarded for keeping the business running, not serving specific measurement goals like uptime, to the detriment of selling product. These priesthoods often have their own religious virtues that they espouse, like 3rd normal form or low TCO, that they pursue in absence of directions and understanding of their role in the business.
It's easy to see the problem but wicked hard to prevent it or fix it. I have a small organization and it's difficult to get people really on board with a vision.
[+] [-] AcerbicZero|3 years ago|reply
[+] [-] breakalot|3 years ago|reply
We spoiled devs way too much.
Software are still being thrown over the wall and ops takes all the blame.
The problem is that many devs can get away with spawning servers and doing the easy parts of ops, when it requires rules and discipline, then we all know what happens, over engineering and security holes.
[+] [-] fleddr|3 years ago|reply
To me, this gets to the heart of the matter. As example, I present the required skillset for a front-end engineer:
https://frontendmasters.com/guides/front-end-handbook/2018/
See the index on the left. Do you need to know everything about all of these things for every single project? No. But as you grow into a senior, you'll be touching almost everything in that list.
It's an absolute explosion in complexity. Web development once was barely considered engineering, now it's one of the most complicated roles in the industry. Consider also that almost everything on that list is constantly evolving, this list being 4 years old.
Has all this added cognitive load and complexity resulted in massive productivity wins and dramatically better outcomes (UX, quality)? I'd say no, or at least it's questionable.
My point being is that this is already too much. I work in teams with a distribution like this: senior (20%), medior (50%), junior (30%). So the vast majority of them are median. And the median programmer is severely lacking against our ever growing demands. It's crude, but the typical programmer really sucks at programming.
So if next you're going to add even more to this pile with all sorts of devops and funky cloud tooling, the issue becomes clear: we're over-asking.
We over-value flexibility and scaling but ignore its dramatic costs.
"Devops" is just a made up word.
[+] [-] irrational|3 years ago|reply
[+] [-] znpy|3 years ago|reply
Nah, the problem is that most (software) engineers don't have the skills to do operations work.
Let's not fool ourselves: software development is 95% development (writing code/docs/test etc) and 5% system administration (getting your local mysql or whatever up and running etc) whereas operations is usually 95% screaming at the machines (various linux tasks, writing glue scripts, infrastructure, networking etc) and 5% development (the aforementioned glue scripts, writing internal docs).
The fields do overlap, but very little.
They require two different skill sets.
They require two different mindsets, too: a software engineer is usually optimistic (works on my machine, will work in prod too) whereas a sysadmin/operations person is usually pessimistic (what's our disaster recovery strategy?).
[+] [-] kazen44|3 years ago|reply
Its a different frame of mind, mainly because its the place where the rubber meets the road so to speak. Once things are production, you cannot revoke or redesign your product/system because people are directly reliant on it.