People put too much pressure on themselves to do DevOps the "right" way or that they're not doing it like they read about at Netflix or Amazon or any other examples. At small to medium sized companies introducing these new concepts, someone(s) need to own getting it started and to be the evangelists.
Yes, long-term having only a single team as your "DevOps" team is an anti-pattern, but you gotta start somewhere.
What follows is my response to post online about how someone was feeling like they're doing DevOps wrong at their company. And asking why is a DevOps team frowned upon.
I look at it like this as I currently have a DevOps title but didn’t really want one.
DevOps should be your entire company’s culture. Shift responsibility left. Let the devs run what they build.
But you have to start somewhere. You need people to be the catalyst. They need to learn Jenkins first to help others. Much like you describe. A central team is a DevOps anti-pattern long term but I feel like they’re necessary at first. To be the evangelists. To be the first to install the tooling, get it working in your SDLC, to create the pipelines and grease the cogs to get the culture moving.
They likely own the tooling too. Or a tooling team splits off at some point. Someone needs to manage the tooling and host it and upgrade it and juggle licensing.
But be open to others learning. Cross train devs and ops people. Make sure not to bottleneck people needing resources. Find ways they can fire up their own vms, containers, app services, storage accounts, etc. Eventually that is.
Gotta start somewhere. Not everyone is or can be a FAANG company. Not everyone needs every aspect of DevOps people try to shove your way. Not everyone needs to throw k8s at every problem. And so on.
Improve tooling.
Improve dev empowerment.
Improve SDLC.
Improve testing.
Improve blameless culture.
Improve observability.
Improve continuously.
Do those and your company/team will become DevOps too. Your team will evolve too. You’ll continue to expand what you offer and what you can institutionalize.
Or maybe they resist every damn change you propose and never want to improve. At that point you flip the proverbial table and find a place where you CAN do those things. :)
This article originally was published on thebouv.com
Top comments (2)
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!