I've been also wondering lately how to get the entire team more on DevOps board. Unfortunately handling server setup, deploy and configuration seems to be some kind of scary "I don't want to touch this" taboo for a lot of developers.
But it would actually sharpen their understanding of the real production environment where their code is running, and make them probably rethink certain ways of implementing features. I've seen frontend and backend code that seems to be treating the server environment as an infinite resource that can be bombarded with countless requests and heavy workloads.
Being aware of the limitations and configuration of servers and services makes you also aware that these are finite, constrained resources and you need to be mindful about the way how something is implemented. "It works on my local" doesn't necessarily mean it works in production when hundreds or thousands of concurrent requests are processed.
So how to get there?
What I find promising and interesting is "configuration & infrastructure as code" (CAC, IAC). Tools like Terraform and Ansible allow us to formalize and declare server / service / cloud environments and their configuration as source code that can be stored in version control.
With CAC / IAC it's possible to go through the same processes you would go through for regular software development:
code review
automatic unit and integration testing
automatic build & deploy
Those checks and procedures should give the most skeptical manager types some assurance that DevOps for all is actually "a good thing™".
Combined with version control history it's also easier to understand why a configuration setting has changed. There would be a comment. A link to a corresponding ticket. Some context and explanation.
I believe having the configuration openly available as code, it might also help the dev team with evaluating certain software implementation decisions, such as: are there any concurrent request limits I need to take into consideration? Is there a timeout setting I need to be aware of for long-running operations? Is there a memory limit that could make the app crash?
Those things could be looked up in the CAC / IAC repo to get a better idea of what's currently going on.
At the moment I'm dealing with a bunch of hand configured servers that have hand-picked configuration settings that aren't documented anywhere. It's a mess. And it's hard to adjust and track what's going on there.
I think DevOps for the whole team is a matter of accountability. But it's shared accountability and additional transparency for the entire team.
Software development does not end when a PR is approved and merged into the mainline dev branch. It goes over build and deploy and beyond.
Book Recommendations
I started reading the following books about the topic, that also seem to be useful as material for convincing team and management to adopt those tools and practices:
Amazing response and I love the CAC/IAC angle. The great thing about that is it allows for that merging of Ops and Dev teams. Devs can see the config/infra as code and treat it as such. Ops can have repeatable builds and finally grok the benefits of version control and pipelines for more than "just code".
Another important win from this like you pointed out is devs seeing more about the skeleton underneath the muscle and skin they've been adding to the body so to speak. I'm surprised again and again at how many devs I talk to when I'm mentoring or even when I'm talking to senior level devs. They've always focused so much on the code, they really know very little about servers, how DNS works, hell even how the Internet works. With CAC/IAC as you say they can see, learn, ask questions and grow.
The DevOps Handbook is great! I love the mini-whitepaper style when companies growth through the DevOps journey is discussed. I just wish there were more examples of small to medium sized companies currently doing digital transformations into DevOps shops. I wish more articles were out there about that. Too much focus is given to how "the big boys" are doing it and 99% of devs will never work at places like that.
And of course I always recommend The Phoenix Project. I've read it once and listened to the audiobook twice. I need to pick up The Unicorn Project sometime too or finish listening to it.
Again, thanks for the comment!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've been also wondering lately how to get the entire team more on DevOps board. Unfortunately handling server setup, deploy and configuration seems to be some kind of scary "I don't want to touch this" taboo for a lot of developers.
But it would actually sharpen their understanding of the real production environment where their code is running, and make them probably rethink certain ways of implementing features. I've seen frontend and backend code that seems to be treating the server environment as an infinite resource that can be bombarded with countless requests and heavy workloads.
Being aware of the limitations and configuration of servers and services makes you also aware that these are finite, constrained resources and you need to be mindful about the way how something is implemented. "It works on my local" doesn't necessarily mean it works in production when hundreds or thousands of concurrent requests are processed.
So how to get there?
What I find promising and interesting is "configuration & infrastructure as code" (CAC, IAC). Tools like Terraform and Ansible allow us to formalize and declare server / service / cloud environments and their configuration as source code that can be stored in version control.
With CAC / IAC it's possible to go through the same processes you would go through for regular software development:
Those checks and procedures should give the most skeptical manager types some assurance that DevOps for all is actually "a good thing™".
Combined with version control history it's also easier to understand why a configuration setting has changed. There would be a comment. A link to a corresponding ticket. Some context and explanation.
I believe having the configuration openly available as code, it might also help the dev team with evaluating certain software implementation decisions, such as: are there any concurrent request limits I need to take into consideration? Is there a timeout setting I need to be aware of for long-running operations? Is there a memory limit that could make the app crash?
Those things could be looked up in the CAC / IAC repo to get a better idea of what's currently going on.
At the moment I'm dealing with a bunch of hand configured servers that have hand-picked configuration settings that aren't documented anywhere. It's a mess. And it's hard to adjust and track what's going on there.
I think DevOps for the whole team is a matter of accountability. But it's shared accountability and additional transparency for the entire team.
Software development does not end when a PR is approved and merged into the mainline dev branch. It goes over build and deploy and beyond.
Book Recommendations
I started reading the following books about the topic, that also seem to be useful as material for convincing team and management to adopt those tools and practices:
Amazing response and I love the CAC/IAC angle. The great thing about that is it allows for that merging of Ops and Dev teams. Devs can see the config/infra as code and treat it as such. Ops can have repeatable builds and finally grok the benefits of version control and pipelines for more than "just code".
Another important win from this like you pointed out is devs seeing more about the skeleton underneath the muscle and skin they've been adding to the body so to speak. I'm surprised again and again at how many devs I talk to when I'm mentoring or even when I'm talking to senior level devs. They've always focused so much on the code, they really know very little about servers, how DNS works, hell even how the Internet works. With CAC/IAC as you say they can see, learn, ask questions and grow.
The DevOps Handbook is great! I love the mini-whitepaper style when companies growth through the DevOps journey is discussed. I just wish there were more examples of small to medium sized companies currently doing digital transformations into DevOps shops. I wish more articles were out there about that. Too much focus is given to how "the big boys" are doing it and 99% of devs will never work at places like that.
And of course I always recommend The Phoenix Project. I've read it once and listened to the audiobook twice. I need to pick up The Unicorn Project sometime too or finish listening to it.
Again, thanks for the comment!