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
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: