A great example of “doing” devops. But I continue to see this ideal that we “do” devops in companies like we “do” agile. And places are continuing to miss the core cultural changes that these systems are designed to bring. You end up with companies that are “using pipelines” to deploy code but they are about as devopsy as a battle ship is nimble.
Are we ever going to realize that devops like lean is more of a culture shift then a job position and actually use it, or is it destined to ride of into the sunset of derision that agile seems to be riding off into?
I hope I didn’t actually talk about “doing” devops. I agree that it’s a culture, not a job title, but that wasn’t my experience in the environment where I came up with this presentation/blog post.
Remove silos. At my current company, the Dev team has to ask the devops team for a pipeline, then they have to ask the infrastructure team for the cloud resources they need to be provisioned. When they should be able to do all of that internally to the team.
Hire generalist developers. Generalists can get you 80% of the way there, and then in most cases a team of generalists can get you the next 20% that need if you even need that full 20% to be successful. And if you tackle every 20% problem with a team the whole team gets better.
Remove the idea of non working managers. I’m currently working to instill this idea of working managers that are active in pulling tasks of the queue because then if they know the pain that comes directly to them from decisions then they will make better decisions and push back on upper management and the business to make smarter decisions.
Actually do agile/lean and when a problem arises the whole team owns it and fixes it. That way everybody gets better at the problems and they become less of a problem because developers know to look out for them in the future.
I’m actively working at a mid sized corporation to work to do these things and honestly we are having to look at pulling a team completely out of the existing IT monolith to be under the CTO directly because the powers are so entrenched they will
Never be able to make these changes in the existing monolith. So I’ve proposed tackling it like you would micro services. Small teams that are pulled out and rolled into this new more startup like structure. We shall see if my experiment is successful or if they fire me.
I found the nix explanations in the article really interesting - seeing an example that goes all the way from writing an application to having it deployed and running on a server is really useful. I didn’t know about nixops before and it seems to fill in the gap between packaging and deployment I’ve seen when looking at other nix articles.
The correct solution would be to talk to the developers and have them implement support, but in the meantime, how should we proceed?
This line (and a few others) really stood out to me though - I think the author has followed the common misunderstanding that “DevOps” is a type of technology, rather than the culture of operations and development engineers participating together. The process the author hints at looks exactly like a classic engineering team where development writes an application and it gets passed over a wall to the operations team who deploy it.
That particular section was inspired by an experience I had where there was exactly this kind of split. In my case the development team never got around to prioritising the fix we needed, so we worked around it.
I completely agree that DevOps is a culture, not a job title, but that unfortunately wasn’t the case where I used to work.
A great example of “doing” devops. But I continue to see this ideal that we “do” devops in companies like we “do” agile. And places are continuing to miss the core cultural changes that these systems are designed to bring. You end up with companies that are “using pipelines” to deploy code but they are about as devopsy as a battle ship is nimble. Are we ever going to realize that devops like lean is more of a culture shift then a job position and actually use it, or is it destined to ride of into the sunset of derision that agile seems to be riding off into?
I hope I didn’t actually talk about “doing” devops. I agree that it’s a culture, not a job title, but that wasn’t my experience in the environment where I came up with this presentation/blog post.
What would you say are the core culture changes that a company switching to DevOps should look into, or should pay special attention to?
You have to make several changes.
Remove silos. At my current company, the Dev team has to ask the devops team for a pipeline, then they have to ask the infrastructure team for the cloud resources they need to be provisioned. When they should be able to do all of that internally to the team.
Hire generalist developers. Generalists can get you 80% of the way there, and then in most cases a team of generalists can get you the next 20% that need if you even need that full 20% to be successful. And if you tackle every 20% problem with a team the whole team gets better.
Remove the idea of non working managers. I’m currently working to instill this idea of working managers that are active in pulling tasks of the queue because then if they know the pain that comes directly to them from decisions then they will make better decisions and push back on upper management and the business to make smarter decisions.
Actually do agile/lean and when a problem arises the whole team owns it and fixes it. That way everybody gets better at the problems and they become less of a problem because developers know to look out for them in the future.
I’m actively working at a mid sized corporation to work to do these things and honestly we are having to look at pulling a team completely out of the existing IT monolith to be under the CTO directly because the powers are so entrenched they will Never be able to make these changes in the existing monolith. So I’ve proposed tackling it like you would micro services. Small teams that are pulled out and rolled into this new more startup like structure. We shall see if my experiment is successful or if they fire me.
I found the nix explanations in the article really interesting - seeing an example that goes all the way from writing an application to having it deployed and running on a server is really useful. I didn’t know about
nixopsbefore and it seems to fill in the gap between packaging and deployment I’ve seen when looking at other nix articles.This line (and a few others) really stood out to me though - I think the author has followed the common misunderstanding that “DevOps” is a type of technology, rather than the culture of operations and development engineers participating together. The process the author hints at looks exactly like a classic engineering team where development writes an application and it gets passed over a wall to the operations team who deploy it.
That particular section was inspired by an experience I had where there was exactly this kind of split. In my case the development team never got around to prioritising the fix we needed, so we worked around it.
I completely agree that DevOps is a culture, not a job title, but that unfortunately wasn’t the case where I used to work.