I haven't chosen a software niché to focus into and am curious about Development Operations -- anybody know any internet web-sites that have ,,Leetcode''-like exercises/education? Or even books and technologies I should study would be helpful, but obviously, content recommendations which are more structured would be more useful.
The Big DevOps Misunderstanding
251–260 of 321 posts
Re: The Big DevOps Misunderstanding
#252I haven't chosen a software niché to focus into and am curious about Development Operations -- anybody know any internet web-sites that have ,,Leetcode''-like exercises/education? Or even books and technologies I should study would be helpful, but obviously, content recommendations which are more structured would be more useful.
niché?
Re: The Big DevOps Misunderstanding
#253Earlier quoted context omitted.
In my experience, its because the tools that are given to the dev team are opaque, poorly documented, made for a general case that rarely is sufficient, and usually locked down with some role based access control to the point where, even if I can figure out whats wrong with some pipeline, I rarely have the access to change something. I have an AWS Codepipeline that I can see running, but the logs from each step are s…
Yeah that's also part of our job, to expose the right info to developers so they don't have full access to everything but can still do their job. In my case that involves shipping logs to Grafana so they can view them there. In AWS it wouldn't be hard to create a policy for IAM users so the devs can view logs in the AWS console.
You're right, it would not be hard. But I don't have the keys to do that. I would have to talk to someone on the devops team and I would hope they wouldn't write me off as some dumb developer who only knows how to code, whatever that means.
Re: The Big DevOps Misunderstanding
#254DevOps was always about de-siloing. In that, it is a culture but you need people to "be the change" and that's how I've played a DevOps Engineer for the last five years (well now SRE) and how I believe DevOps Engineers (and SREs by extension) ought to be playing their role today. Corporate management is always surprised when my first move is to go sit with the developers and ask how I can unblock their workflow, redu…
"be the change" I think nails the difficulty of devops and why we end up with the non Devops that we call Devops.
Most of us are not Fang companies and don't have the pick of the best engineers in the world (or the region). We cannot trust some of our devs to deploy directly to production because quite simply, some do not understand that responsibility and cannot rise to it. We still need our CTO to check any big changes because things are missed and this just reinforces the idea that you don't have to nail it, the CTO will probably find any problems.
We are also in Europe where you can't just fire people if they e.g. deploy 3 bugs to production. So what do you do? Like most companies, you try and introduce a good level of automated testing, some testers to write smoke tests etc. and we don't just deploy whenever like some companies do.
Then we are just back where we started with a bit more overhead and still not deploying more quickly to production.
Re: The Big DevOps Misunderstanding
#255I haven't chosen a software niché to focus into and am curious about Development Operations -- anybody know any internet web-sites that have ,,Leetcode''-like exercises/education? Or even books and technologies I should study would be helpful, but obviously, content recommendations which are more structured would be more useful.
nich é ?
Yeah, you are right pxeger1 1: niche (/NEESH/) doesn't have accent mark. (In French, the e without an accent mark is silent. According to some person on Quora . . . )
Re: The Big DevOps Misunderstanding
#256Earlier quoted context omitted.
In my experience, its because the tools that are given to the dev team are opaque, poorly documented, made for a general case that rarely is sufficient, and usually locked down with some role based access control to the point where, even if I can figure out whats wrong with some pipeline, I rarely have the access to change something. I have an AWS Codepipeline that I can see running, but the logs from each step are s…
Sending logs to a dedicated AWS account is usually done for compliance. That account will have rules set via AWS Organization policies that limit IAM user rights and protect S3 buckets from being tampered with. I don't see why it should be necessary to ban read-only access to these logs for troubleshooting. Anyone here know a good legal, compliance or best practice reason for blocking all access, or did the infra/sec…
Yea I completely understand the complexities that emerge when you're doing this stuff for a ~1500 person organization. And I know that overwhelmingly the people building these systems are talented and competent and have a stake in things and take pride in what they're doing. My comment was really more in response to the tone of the parent comment which insinuates that these helpless devs just can't figure out what the fuck is going on.
Coming from a team that builds and supports an end user suite of applications. I'm not asking you to bend over backwards like I would have to do for a client. But at least don't enter in to conversations with that attitude. You are in a service organization. You deliver value insofar as you can help the next link in the chain.
Re: The Big DevOps Misunderstanding
#257Lots of comments seem to get something confused. Devops doesn't mean you won't have specialist ops teams, but it also doesn't mean that every deployment has to go via the ops team.
Devops is:
Moving value quickly from left to right
Getting feedback quickly
Dynamically changing your process to avoid past problems in the future
The key point is that to achieve this to any degree, the developers must be empowered to get their code into production quickly, without needing anyone else to create a gate.
You might well need some specialists to setup and maintain e.g. kubernetes, VMs whatever but the end-game is that what is left is automated and repeatable deployments that mean devs get stuff deployed. It also means that a lot more of this can (and should) be maintained by developers. A developer should be able to modify a Jenkins pipeline as much as/more easily/reliably than an ops person so they should be. Why? Get stuff quickly from left to right and don't wait for others to do it.
Re: The Big DevOps Misunderstanding
#258Earlier quoted context omitted.
exactly right. the rug was pull out from underneath us and replaced with technology lacking parity. devops was able to convince the industry that "software engineers own their own infra" is a viable thing to do so they could do engineering work, expect, they're out of their element. That's not their job. devops should be pulling in open-source technology that's developed by real engineers and write tiny packets of gl…
So much to unpack here. Let's start with: > devops was able to convince the industry that "software engineers own their own infra" is a viable thing to do so they could do engineering work, expect, they're out of their element. Devops wasn't about getting ops people to start doing development. It was about getting developers to be start doing ops because infrastructure definition became a tye of coding. What's incred…
Devops wasn't about getting ops people to start doing development. It was about getting developers to be start doing ops because infrastructure definition became a tye of coding.
Reminds me of an idea that any user may expand a system by making plugins/changes, if you provide them a sufficiently humane programming language. Then they still can’t, and a completely new developers category is born.
Seems like another one here, cause it always turns backwards like that.
Re: The Big DevOps Misunderstanding
#259As someone who has lead a devops team, and still has a devops team reporting to me, I have also struggled with the idea of having a team called devops, since it does go against the devops philosophy of devs owning their software in production. However, in our case (and probably many others), our devops team is responsible for creating and maintaining the tools and processes that allow the dev teams to manage their sy…
Me too, I worked on Customers with "DevOps" teams responsible for creating and maintaining the tools and processes, creating a sort of polarization between two gropus: devs and "devops (sysadmin)" team.
Some Developers tend to stick with the Dev parts, ignore the Docker/helm configs so, yeah there is some trouble with a true "DevOps" project.
And Google is re-introducing a "K8s stability role", which is a Sys(Dev)Ops role, pushing on that direction (for valid reason).
A true shift so it is difficult, but DevOps time-to-market deploy speed is so high I will no look back :)
Re: The Big DevOps Misunderstanding
#260I had to basically give up my full time role as a Data Engineer who is supposed to solve "big data" problems (Storage, Streaming, Machine Learning pipelines) etc, and had to solely focus on DevOps because there was no other expert in the team. We (a colleague and I) basically learned Terraform, then Kubernetes, and then Helm in an extremely stressful environment. I wouldn't recommend that to most people. (Also, I can…
any suggestions on learning materials?
You'll find plethora of learning documentation, but by far, the one talk/presentation that made it click for me was this one: https://kube-decon.carson-anderson.com/