Do not hire a DevOps Engineer
DevOps is not a person, not a job description, and not a role. I’d be willing to bet you already have the right people with at least some if not all of the right skills currently on staff. They know the environment, the code, networking infrastructure and all. Engineers working on DevOps come from all disciplines as outlined above and most if not all of them are already on your roster.
In a previous post we looked at the Three Musketeers of DevOps at a higher level. We looked at the term DevOps in general and what it means for companies brand new or more mature, small and large.
This post will look at each of the Musketeers in more detail and why it is important to consider them in the order presented. What’s the significance of People, Process, and Product for DevOps?
The People of DevOps
As with anything new, some people embrace it and see the opportunity, others are adverse to change and see it getting in the way of how things work. IT managers, introducing DevOps top-down, have the difficult task selecting the right team members.
Reading about DevOps on blogs and in the press you easily get the impression it is about developers taking over operations by coding a bunch of automation scripts and that’s it. No more operations required. Operations through code. With the cloud it has become even easier. No need to know how to setup a physical server anymore. Go to the cloud management portal, spin up a bunch of services and VMs and off you go or even better, use Visual Studio to do development, testing, and deploy.
While there are phases during the application lifecycle requiring exactly that power and flexibility of the tools, reducing DevOps to just that could not be farther away from it. DevOps means people of different disciplines, different teams, and different cost centers now working together.
Developers want (and need) freedom to change, to modify, to evolve code. Operations must “keep the lights on” at a reasonable cost. Stability, security, and availability are their mantra. But you cannot stop there. Any group involved in shipping a product (enterprise or not), must be involved at the right time, the right way to contribute its part to the success.
How to get started with a DevOps Team?
Especially enterprise Devs and Ops look at DevOps and most see the benefits – if only they could be like a startup. The various roles you need on your DevOps team vary by project. It should contain developers, sys admins, maybe a designer, you need security and networking folk close by and, ideally self-contained.
Starting with small team working on a narrowly scoped project is good. Take a look at your parameters and decide. Many companies find these DevOps team inside their large organization to be very un-enterprise. That is a good thing. Small and un-conventional is the way to go.
The most important thing is kept for last as it blends into the next topic. We saw teams failing in the beginning for the simple reason that team members did not feel empowered. Empowered to do what you may ask? Empowered to break the rules. While it highly impacts the people selection process, the team believing in their own empowerment defines your success from the get-go.
Your company will only be able to take advantage of the DevOps paradigm if your people buy into the idea of the Three “P”, the musketeers of DevOps. Let’s take a look at the processes next.
The Processes of DevOps
Your new/old team is pretty excited: “We should have done this a long time ago.” “I have always said we should do it this way, no one was listing.” “This was our idea all along.” DevOps is a journey more than anything else. Once you have figured out the people you want to take on your journey, time to look at the processes to get to DevOps land.
First thing the team has to do is selecting the right set of tools, right? Wrong.
Embarking on the journey requires you to understand or anticipate the roadblocks you may find along the way. You need to understand the scope of your project. Turning to automation or selection products only makes sense, once you fully understand the scope of the problem you want to solve.
Regardless whether you are working on a green-field project or on improving features of an existing LOB application, the team must identify the scope first. What are you going to focus on solving collectively in a different way?
Team must be allowed to break rules. IT, especially in larger companies, follows (many times very strict) rules how things are done. Processes that have been implemented over time are based on regulatory demands, best practices like ITIL and ITSM, infrastructure requirements, sometimes by people and skill availability. Following the rules is what keep them out of jail.
Your DevOps team must be allowed to break the rules. Rules to select the proper tools to get work done. But also refrain from certain established standards. Even access to restricted resources (difficult subject) might be necessary.
As for the overall processes of delivering results there a many lifecycle best practices to follow. Listen to your new DevOps team. Most members are with the company for some time. They have all the knowledge. They know the issues your current model has. Let them figure it out. Empower them.
Microsoft provides guidance and suggestions using our tools and services supporting your successes in DevOps. IT pro is playing a key role and should – more than anyone else – drive this motion. Eventually the future success of your company depends on your agility to respond to the demands defined by the business and imposed by new development processes.
Show me the Money
As a matter of fact your team has to get out of hiding and start tooting their horn. Your business “allowed” you to find out if and what DevOps can do for them. You better be prepared to show results. And I am not saying you wait until you’re done. On the contrary. It is essential that you demonstrate what you are doing and explaining why you are doing it as often as possible. You probably have a senior executive as sponsor. Make sure he knows what’s going on. He will be under close observation by his boss. She will want to see improved performance and results.
Doing demos to executive sponsors and to other teams will go a long way helping your company to transition to DevOps, and understanding the benefits, one project at a time. Communicating progress – good AND bad – will do a long way.
DevOps is not a development best practice, nor is it an operational model. It is not developers forcing a new model onto operations, nor is it operations defining new or restrictive processes. It is the right people, implementing the right processes for the challenge. The following selection takes a look at the third musketeer, Product.
The Products of DevOps
We’ve looked at forming an innovative team. The team is allowed to break some rules along their way to delivering results the DevOps way. They start implementing improved processes, enabling them to deliver results in the expected quality and within expected timeframes.
Now is the time to look at the infrastructure needs. Which tools support the selected processes? Do we have people with experience in certain products? What’s the role of the cloud? To what level should processes been automated? Git anyone? Depending on your resources and timelines, the team might decide to get developers and operations folks together and build the automation tools together.
A few questions your team will have to answer. Some answers they will have to figure out along the way. And team members will have to learn a few new tricks as well. How many of your Ops people have scripting skills? I mean, like, really? Ruby can be hard, PowerShell is great but can be daunting at first. Working on continuous delivery, developers will have to look at infrastructure stuff. Here’s a situation your team might have to deal with frustration. Which developer wants to deal with infrastructure? Why would an IT pro look at or even touch code? DevOps is about collaboration. Be prepared for anything to happen.
Mostly driven by demand from the developer community, the Open Source world has created a large number of tools supporting Agile development methodologies and continuous delivery movements required by Dev and Ops. More pointer in the section below.
The list of tools and products used by companies of all sizes is almost limitless. Especially after recent announcements at the //Build 2014 conference, Microsoft provides plenty support for more agile teams beyond development. Look for pointers in the resources section below. Since cloud and Microsoft Azure are key enabler for DevOps, I suggest you taking a look at a very comprehensive blog post of a co-worker of mine, Brian Keller. He just posted “Building your Dream DevOps Dashboard with the new Azure Preview Portal.” Well worth your time.
Our global team of IT Pro evangelists talk to customers of all sizes every day. In trainings, briefings, and meetings of all kinds we collect a tremendous amount of information about what works in operations, in DevOps, and more. Starting in May we will start sharing details about the use of Microsoft products and services and Open Source tools and services in DevOps scenarios. You will find pointer to the growing number of posts via their landing page here. And this blog will continue its DevOps journey too.
I want to close this post with a reminder about how we started:
“DevOps is a cultural and professional movement. Period. That’s it!”
The Three Musketeers of DevOps are People, Process, and Product. In that order.
Resources
As always, more resources for you to familiarize or dive deeper
Have fun.
Comments
- Anonymous
May 02, 2014
Hey IT operations professionals, what do you think? All Hype? What's your CIO thinking? Is she already - Anonymous
August 30, 2016
And I strongly believe you've just chosen a wrong career, some of the worst posts I've ever read.