I came across this HN post recently
https://news.ycombinator.com/item?id=20668168<p>> In practice, and talking from my experience, unless you're one of the lucky few this is what it really means to do DevOps in 2019:
- Forget what the books said, theory, semantics and idealism. You are a DevOps Engineer, working in a platform specific team.<p>- You deal with Jenkins or similar, and consult other teams or developers to write scripts for it, or worse, do the work for them since they're too busy doing actual programming.<p>- You are not allowed to come up with your own abstractions. Proposals to develop anything are automatically declined by your Product Owner, who simply points you to whatever tool with a fancy logo he could find listed in the Cloud Native Computing Foundation.<p>- You pride yourself for being an engineer, but decisions end up being only made in terms of getting free open source labor and ease up hiring, so you end up doing what everyone else is doing.<p>- Half of your team co-workers are perfectly fine dealing with churn, software updates and other sort of manual, classic sysadmin tasks.<p>- You are repeatedly being paged at night for problems that your fellow developers won't feel responsible for. You hear buzzwords and talks about this SRE thing or "you built it, you run it", but it never seems to materialise due to politics.<p>It used to be a lot of fun back in the day, and a great chance to get paid to solve interesting problems related to system and infrastructure engineering instead of the boring CRUD work that plagued the last decades, but seeing the "App Store" that this turned into, if you are a creative individual with a software engineering background and you're considering a career in DevOps, my advice is to run away while you can.<p>I wonder what developers are actually thinking about DevOps?
I agree, in general, it's a relatively thankless job, where you are constantly cleaning up after other people's messes. Many developers don't think how their decisions impact downstream processes, deployment, or operations. You get to fix build and deployment errors all the time, from either your own problems, hardware problems, upstream problems, or other developers on your team. Work is thrown over the fence all the time at you, with no warning.<p>I don't think there's much need to come up with your own abstractions, and those that do like to write a lot of devops code seem to dig themselves into a hole. Simplicity is key.<p>It's a lot like development, in all these ways. It's just even more annoying, since people call you when it stops working, rather than just waiting until tomorrow to barge into your office.<p>It's not just politics that keep people from being responsible for their own messes. It's honestly about ability. Those who can't solve hard problems that pop up randomly are the ones who get to write features, leaving head-scratching bugs to those who have the ability to fix them.<p>But then again, I might just be feeling jaded today. I'd consider myself both sides of Dev and Ops, and been called everything in between (usually when they try to convince me to take on something).
My approach to DevOps has always been to enable the developers and move ownership of remediating broken processes to their responsibilities.<p>One, it allows them to be more self reliant, have faster feedback on their work. Two, you create visibility into where bugs and issues come from so the responsibility to fix is made clearer. They get the calls late at night if you've done your job correctly. That being said, you may still get called in because you will likely have gained unparalleled insights into the complex interactions not grokked by the developers of one component More often than not, the interaction of services is where things break down.<p>The goal for DevOps has been to produce systems where developers are more successful and productive. If you start reading I to the cult messages too much, and prioritize process over outcomes, you've missed the point.