Isn't This Just Good Development Practices?
Definitely, the most common question about DevOps is, "How is it any different than the good development practices in existence?" Several developers commented that communicating with the operations staff was already part of their everyday operations, and viewed DevOps as just a re-branding of an old concept. I do agree that, like a lot of concepts in IT, DevOps recycles many ideas from the past. Without good development practices as part of your process, a DevOps initiative will end up in the trash very quickly. But DevOps is more than just good development practices. When most organizations talk about implementing DevOps in their organization they are usually talking about applying those good development practices in new ways. Examples involve automating server maintenance where there previously was no development work, or creating custom applications to interface with your SDN control plane to add functionality that wasn't previously there. For a lot of organizations, DevOps simply applies good development practices to the parts of your business that previously had no development at all.The Operator Coder
My Now We do DevOps. Do I Need to Learn Coding? post prompted people on the operations side to share various opinions about picking up development skills as an operator. They pointed out a couple of things that I feel were either missed or not thoroughly covered.But I Don't Want to Code!
If you've already picked up development skills and enjoyed the process, it may be difficult to realize that there are some people who just don't enjoy crunching away on code. Admittedly, when writing that post, I may have glossed over the fact that if you are considering whether or not to learn to code you should first think about whether you want to do it and if it is enjoyable. Learning a new skill can be difficult, but learning a new skill you really don't care about is even more challenging.
Many Hats
When you work in a smaller organization, you likely are responsible for performing a variety of jobs each day. When management decides that they want to do DevOps in a small organization, it may fall on you to pick up development skills, simply because there are no developers on staff. In this case, it's not really a matter of whether or not you want to learn development skills. Like many other things that land on your plate, you learn whatever is required to get the job done.
Yes, you could argue that because there isn't a separate development staff, this isn't technically DevOps. However, every organization determines their own definition of DevOps--usually management personnel--regardless of whether that's right or wrong. Sometimes you just have to roll with it.
Developers and Operators are Never Going to Communicate
I found the stark differences among comments to be really fascinating. Several developers commented that communicating with operators was good development practice and that every developer worth his or her salt should be doing this already. Others commented that this just wasn't possible. Why? Because, based on experience, their developers and operations teams would never reach the point where they could effectively communicate with each other. Since we already talked about the first bit at this at the top of the post, let’s address the comment that developers and operations would never have enough communications to implement DevOps. If you've got a group of developers or operators who just aren't willing to communicate, what do you do? The easy answer would be to just say, "You all suck," and let everyone go and start from scratch. But if your organization isn't quite ready to initiate a scorched-earth policy, read on. While it's definitely possible, the lack of communication may not be rooted directly in your individual contributors. As discussed in DevOps Pitfalls, culture gets defined by behavior, which in turn gets defined by process. Does your organization have issues that make communicating between teams particularly difficult? Maybe you have a deeply rooted culture that supports a rivalry between operations and developers. Maybe operations and development have always treated each other with disdain, unfortunately. I'm sure you've seen organizations where the developers think the users are idiots that don't know what they want. This organizational attitude could be at the core of why you don't have communications between teams. It's important to look at both individual contributors and management. Are they helping to shape unhelpful team attitudes? Maybe this is why the teams can't seem to communicate effectively.I'm Going Somewhere Else
Now that you've read through this blog series, you may be wondering where else to look for information to help move your DevOps initiatives forward. I asked people to share some of their recommendations for implementing DevOps in their organizations and received several suggestions. Some focused specifically on DevOps, while others looked at management practices. I'll list several of them below.The Phoenix Project
When you write a novel that attempts to educate readers about a certain thing, there is the potential for that novel to be pretty hokey. When someone recommended The Phoenix Project, that person assured me that this was not the case. With a four-and-a-half star rating on Amazon from nearly 2,000 reviews, this is one that I'm going to have to check out myself.
Time Management for System Administrators
On the topic of making your DevOps work a little faster, sometimes you need to better manage your time. This book may be able to help you get there.
Here, you'll find lots of articles have been written about DevOps and how it is implemented in different organizations. I found the site to be very helpful when I was writing several of the posts for this series.
Another site that has a fair amount of DevOps content, including, "How to Get Started in DevOps" and "DevOps Culture." This might be a good place to pick up more information.
The Toyota Way
Another book focused on the management side of things, including processes that Toyota used to improve communication in their factories.
Team Geek: A Software Developer's Guide to Working Well with Others
Since this series has been focused on the importance of communications in your DevOps efforts, we'll round out this list with a book about working with other people, teams, and users when developing software.
