DevOps Tools Are Not Magic Bullets!
DevOps Tools Are Not Magic Bullets!
DevOps takes more than just tools. Learn how to reach real DevOps maturity with changes to people, processes, and automation.
Join the DZone community and get the full member experience.Join For Free
They're shiny. They're new. And they're what DevOps is all about! The cool toolsets that enable such amazing IT performance call out to us, "Download me! Install me! I'll make your IT life great!"
Don't fall for their siren song!
DevOps maturity does require a good toolset, but DevOps is much, much more than just implementing tools. DevOps is about people, and it is about the processes we use. DevOps often requires us to rethink the architecture of our systems and services, even how our organization is structured. And DevOps will inevitably raise cultural challenges that no tools can address.
So while we "automate everything we can," we must take care about how all of these shiny new tools will work with the realities of the people, processes, architectures, organization, and culture of our IT shop.
Let's look at some examples.
Infrastructure Configuration Tools
What can be more obvious than using Puppet or Chef to automate the configuration of our servers?
But who will use these tools, and what will they use them to configure? The server team? The network group? Back-end support? Desktop team? How about Database Administration? Or our Application teams? Maybe all of the above? If so, who's responsible for what? And (especially where there are overlaps, e.g. our Storage Area Network or application servers) how will all of these teams cooperate and collaborate? How will those configurations be defined and standardized? Who is allowed to do what, and when?
Organizational silos complicate these sorts of implementations, so if your shop is organized that way (and most are), then before any tool decisions are made you'll need to reach across silo boundaries, initiate collaboration, and work together to figure out how to get started and how to continue that collaboration over the long haul.
What? You don't get along with some of those folks? Then there's even more organizational mending that you need to address before you can get started.
Jenkins is one of the coolest tools! And we all want a screamin' fast deployment pipeline.
But who deploys stuff today? The answer likely depends on what stuff you're thinking of. Applications? Server configurations? OS Patches? Mobile apps? Firewall changes? And regardless of what you want to deploy, "who" is likely to be a variety of people from different specialty groups. And don't forget the Change Control Board (CCB)! Nothing goes out without the Change Manager's OK.
Your current deployment process probably involves analysis, approvals, signoffs, and then activity by lots of different people. Any automation we put into place will affect every one of those players and how they interact. Every change we make will require negotiations among all of these players to ensure that all of the risks are sufficiently addressed and the flow through the deployment process is indeed optimized.
This will result in significant changes to people's activities and responsibilities. Those with more power are likely to resist relinquishing control, and those with serious concerns are likely to be quite conservative in what they will agree to.
While automated testing tools are not new, their use will expand as you embrace DevOps. Indeed your deployment pipeline cannot be optimized without significant automated testing.
Who is responsible for test automation in your shop today? The test team? A sub-group of your test team? Or maybe no one, because all testing is manual?
If your shop has never used test automation, a complete change in thinking must start at the top. The holders of the purse strings must understand both the value and the necessity of investing in the tools (and the training people will need in order to use them). They must also embrace the idea that nothing is completely built until we have also built the automated tests that are needed to verify it.
Beyond that, adding test automation to the mix means adding to our technical contributors' responsibilities. This affects their job descriptions (which impact the performance appraisal process), as well as their self-perception, and quite essentially, means they must alter their work habits.
If you already have test automation professionals, you will find that they will need to share responsibility for writing automated tests with others. This will mean significant changes to their job responsibilities, expectations, and work patterns as well. Test automation will become a collaborative activity that they share with the other technical professionals in IT.
Regardless of what DevOps tools and practices you implement, you are likely to find that you need to address these additional issues.
Security must be a prime consideration in everything we implement. On the one hand, automating our deployment pipeline will yield little value if we have to stop at the Security Gate at the end of the process, where our work is routinely kicked back for rework. So we will need to collaborate with our security team to weave security checks in throughout the deployment pipeline.
With the limited number of security professionals, most IT shops have, finding the time for this collaboration can be a challenge. But the bigger impact, as some of the items discussed above, is how it will change people's jobs (by making security part of everyone's job) and change the ways in which the security team interacts with everyone else.
The other big impact is securing all of the automation we put into place. When specialists did things by hand, security wasn't a big issue — as long as we trusted those specialists. But when anyone can push a button or check in a configuration file, and when all of our system credentials have to be made available to our tools, securing these things becomes crucial.
Consider the exposure if a hacker broke into our operation and gained control over our deployment pipeline, or opened doors by changing the configuration of our firewall or servers, or harvested root passwords from our repository. YIKES! This is another place where collaborating with our security professionals is critical, so we can ensure we are not vulnerable to attack.
Small batch size becomes a focus when you are implementing any of these tools. Doing work in large batches taxes the automation, making it much less efficient and impeding the flow of our work. The Agile methods have already taught us about this. We break project requirements down into a large number of very small deliverables (Stories), and then build them in small batches (a few Stories in each short Sprint).
The most efficient and effective way to use any of our DevOps tools and practices is to apply this concept not just to developing software, but to everything we do.
- Application Architecture: Moving from large monolithic applications to Service Oriented Architecture (SOA) or microservices means that we are working with many small parts, which makes our deployment pipeline more efficient and simplifies automated testing.
- Projects: Shifting from large projects to a series of smaller updates simplifies the flow and the testing even more. Some IT shops are moving away from a project orientation altogether, focusing instead on making incremental changes to services or applications (a product orientation). Either way, it is a complete reform of the organization's approach to change that reaches all the way up to senior management where projects are approved and funding is allocated.
- Organization structure: Most DevOps organizations move to a cross-functional team structure (using Agile self-organization team principles) which means that specialists are no longer segregated along specialty lines, but are instead working shoulder-to-shoulder with others of different specialties. And some are abandoning functional teams altogether and reorganization around products instead. Either way, the "Who is responsible for what" questions that we raised earlier become moot points because the various specialties collaborate on a single team.
Yes, DevOps is about the tools, but it is about much more than just the tools. There are many other things we have to pay attention to as we choose our tools and figure out how to use them. There is no substitute for getting started...with some good guidance.
After you've wrapped your mind around the big picture and have a plan for moving forward with the tools and the other elements, then you will want to come back for our tool training (e.g. Puppet, Chef, Jenkins, Docker, Git) and our technical practices training (e.g. CI/CD Workshop, Test Automation, Test-Driven Development).
That will give you a good start on your DevOps Journey.
Alan S Koch will present a webinar entitled "DevOps Tools Are Not Magic Bullets!" in August 2018. You can sign up for the webinar here. If the webinar has already happened, you can see the recording here.
Published at DZone with permission of Alan Koch , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.