You have probably started to hear all the noise about DevOps. Most likely you fall into one of the following categories:
- I have no idea what DevOps is.
- Sounds promising. Where can I buy it?
- We realize that it’s a journey and we have already started it.
- Our team is way ahead in that journey and we are looking at ways produce even more value.
Regardless of which phase of that journey you’re actually in, there are few pillars that your organization has to go through.
Understand that this is an organization wide effort
If you walk into a room of 5 people and ask the question: What is DevOps? You will get 10 answers. Hence, it’s really important that your team, and more important your organization, has the same common understanding of what DevOps is. So what is it?
- Development and Operation collaboration: form a team of highly motivated individuals and include all the required specialties to design/build/test/run/monitor your application.
- Continuous delivery of value: Get your customers into the habit of continuously receiving new value from you at a regular cadence. Prioritize/balance customer input/feedback/market influence in selecting what comes next.
- Automation and innovation at every phase of the lifecycle: Someone once told me a joke that goes: “If you don’t automate, machines get together at night and make fun of you”! . It’s a joke. But automation is about giving yourself enough time to work on what’s important. That is business value. Hence focus on automating anything that can be automated. Documentation, Testing, Deployment, Telemetry, Feedback are some of the areas where the industry has matured, you really don’t have to reinvent the wheel, unless that’s your business.
- Small (miniscule) deployments: 5 lines of code are easier to deploy and fix in case of a problem than 5000 lines of code. Setting a similar target will drive your whole lifecycle to focus on small needs and small problems and split big goals and into small pieces.
- Treating your infrastructure as code: This is another area where operations can help developers, but the overall team should focus on being able to reproduce or create environments from code. What you deploy should be idempotent, giving you one less variable to plan for.
- Feature switches: Deploying a feature to production doesn’t mean it’s already live. You should have the ability to control when it can be seen, who can see it, what’s the percentage of my overall audience that I want to enable it for, and how do I learn from it.
- (possibly) Kanban for Operations: Get your operation team to adopt the same visual application lifecycle tracking techniques that the planning team uses. Kanban offers a great way to do that.
Be willing to experiment
Understanding that DevOps is a journey and that each case will have its own context, constraints and complexities is crucial to your success. Often times I get asked “How does Microsoft do it”, I am glad to share, but that doesn’t mean that’s exactly how you should do it. You may be facing a case that is unique to your business or your industry. That means you should get inspired from others have done, but anchor it to your situation. Try new things, learn from their success and failure and adapt fast.
Challenge the status quo
“That’s not how we do it at….”, have you heard this before? Well you can’t expect to keep doing what you have done for 20 years and for some reason get different results. Entering such a journey, should not be simply because you heard it on the news, but because of a clear business need (Competition/Making the market/ or innovation). Therefore, new situations may require new solutions. And new needs should drive change. No one person should own the decision, but the group should drive towards what’s best for them.
It’s not about any one tool
While DevOps is not a tool you install or a product you buy. Tools and products will be a major part of it. Each of you will have a tool of preference, just like we all drive different cars. (I still believe my car is the best). But the most important part is the flow of data, and traceability from one phase of the cycle to the other. Why?
- Smartly repeat yourself: If a new business need is similar to something you’ve done in the past. You should be able to easily trace it to the code you wrote, the test you automated, the (positive or negative) impact it had on your product and your customers.
- Fix it fast: If you deploy this great new feature and it shuts down your system, then you should be able to easily point out Who/What/Where to get it fixed. DevOps practitioners call that MTTD (Median Time to Detect) & MTTR (Median Time to Resolution).
- How fast can we get something out to the market: Can we trace the real effort it took us to get something out? (don’t think about it from a traditional project management perspective) but rather here is what we will have to do to deliver something.
- Use what you have first, until it doesn’t meet your needs: Can the tool we have already do 80% of what we want?
Learn how to be data driven
Data insight can be a great way to make conversations objective. Are you measuring the right things? How do you measure Customer Satisfaction? How do you measure your ability to deliver fast? How do you measure your reaction to problems? How do you measure the productivity of your team? Set up the right KPIs, and stop using them when they stop driving change.
Don’t be scared of the word Cloud
Cloud can be a great enabler of many of the challenges you will face during your DevOps journey. Don’t be scared of it. Try to even go after it. Cloud is not about one specific public cloud provider. It could be an internal cloud. But distinguish between cloud and virtualization. If your team has to send an email or a fax or call an 800 number to get a VM, then you don’t have a cloud. It should be self-service, and should support automation.
“This all sounds too cool, let me go hire a consulting firm to help me get started.” There is nothing wrong with that, but you should be as involved as they are if not more. They should have lived this in the past, so that they are able to share real field experience.