Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Jennifer Davis

Author
+ Follow
since Jul 12, 2016
Jennifer is the co-author of Effective DevOps. She is a co-organizer of devopsdays Silicon Valley, and the founder of Coffeeops. She supports a number of community meetups in the San Francisco area. In her role at Chef, Jennifer develops Chef cookbooks to simplify building and managing infrastructure. She has spoken at a number of industry conferences about devops, tech culture, monitoring, and automation. When she’s not working, she enjoys hiking Bay Area trails, learning to make things and quality time with her dog, George.
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
5
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jennifer Davis

Thanks for pointing out the policy here. So far I have been really impressed with the quality of community response here at the JavaRanch. This goes to the positive culture here with explicit values and norms that we talk about in Effective DevOps.
Jeanne,

Thank you so much for this valuable feedback! Really appreciate your thoroughness. We got some feedback that we had _too many_ stories at one point. So glad to get this feedback as it's something we fought hard to include as many as we did! I look forward to incorporating this feedback in Edition 2 (in which we hope to get more international stories included).

Junilu, thanks so much for the great answers!

Angus, in what way do you want to understand DevOps? Are you looking to learn how it can improve your current environment? Are you looking to level up your skills? The very first paragraph of Chapter 1 "The Big Picture" in Effective DevOps has this definition for you:

Devops is a way of thinking and a way of working. It is a framework for sharing stories and developing empathy, enabling people and teams to practice their crafts in effective and lasting ways. It is part of the cultural weave that shapes how we work and why. Many people think about devops as specific tools like Chef or Docker, but tools alone are not devops. What makes tools “devops” is the manner of their use, not fundamental characteristics of the tools themselves.



Based on your answers to the previous questions, I can point you in the direction of how to gain insight. As Junilu mentions, the answer is highly subjective based on your current environment, and your current needs.
Barclay,

We have a few pages on this very topic in our book in the misconceptions section of devops! Devops is orthogonal to roles as it's about the collaboration and cooperation between teams and across organizations. Assigning this to a specific team can be less than ideal as it puts the responsibility for collaboration and cooperation on that specific team. Some organizations are trying to use devops as a job title with the idea that a devops engineer can do twice the amount of work than someone else. This can lead to burnout and isolation for the individuals who are tasked with this challenge if that's the underlying reason for the role title. Some organizations understand that the value in devops _is_ the collaboration and rightfully recognize that collaboration isn't a 'free skill', meaning that it costs time and energy to do the relationship work associated with working with other people in your team and across other teams.

So is devops part of a full-stack developer role? Not really. Is it better as a role unto itself? Not really that either, although in some cases it's helpful to have a disrupting greenfield team that shows the way of how to devops before being incorporated back into the larger organizations current structures. Rob Cummings is one individual who has given some great talks on this subject around successful separate devops teams http://www.slideshare.net/robc77/nordstrom-devops-rollercoaster-gartner-datacenter-conf for example.
Holly,

Thanks for sharing a bit about your environment.

I think this is one of my favorite questions yet due to the participation of other folks in the thread! Love to see this kind of interaction.

So, Holly, what you've described sets off a few alarms around cultural challenges in the environment as Junilu rightly pointed out. It is completely ok to have an environment that due to compliance issues doesn't allow individuals to commit change to the live systems. Ideally this is true for the system administrators as well from a manual change stand point. All changes should be in code where there is transparency of folks to be able to see the changes and replicate them, and then automatically deployed to the live systems.

What you are describing sounds a little different from that, in that all change must be okayed by system operations team prior to the change happening. This sounds like a bit of fear driven deployment where the fear of change is associated with a large amount of risk which impedes everyone from doing their job.

Our book does indeed cover this topic throughout the book, as it's part of the whole larger than technical challenges scope that many organizations face. Specific technology will arrise and be better for specific conditions in an environment. Many folks focus on the outcomes that other organizations experience with specific technology. Some organizations look at the changes happening and ascribe the value of change "only being possible in those kinds of environments because in our environment we have these tools and technology that we must use". This is a big misconception that is leading to a lot of disruption in different areas as newer companies are able to displace larger companies due to their ability to rapidly change.

So some first steps in your organization to look at:

1) Do your development and test environments look like production so that when you hand off change to the system operation team they can feel confident enough in the risk of said changes?
2) Is there open communication between teams or does it get filtered through specific individuals with a lot of processes?
3) Is the reasons for why change is done the way that it is understood? If not, is it possible to have open discussions with people about it? (This is a sign of a problem in the environment if folks just respond 'because that's the way that it's always been done' or 'because it's the best practice')

I look forward to more threads like this one where folks chime in with their experiences as well! Thank you Junilu and Tim for your contributions!
Luis,

Thanks for the question. Effective DevOps does hope to help leadership change their mindsets on how to achieve rapid results with quality. Often Katherine and I have seen top down driven change dictated from management not understanding the values and understanding in their individual contributors who have the front row seats to incoming challenges that impede progress. Some of the most harm can come out of management seeing the outcomes of DevOps "faster deliveries, faster recovery from failures when they do happen, and less failures resulting even when more deliveries" and wanting those outcomes without doing the due diligence of what is required. Essentially when from the top down management says "Hey deploy devops so we can be like these other companies". When this happens, they can often see failure in their valuable employees because they can't understand why the strategy isn't working, and assume that it's just not possible or that their employees are not good enough.

So what is your place within your organization? Are you an individual contributor? A leader that inspires other individual contributors in your organization (not a manager, but someone who shows the way)? A manager that reports to other managers and has responsibilities to individual contributors to help provide them direction? Each of the different possibilities can have slightly different processes to follow to implement a successful strategy.

Often the first step is to define a specific, measurable, actionable, realistic, time bound goal (the often used SMART acronym) that shows the value of devops. When you have folks working together and seeing the value of buy-in in small projects the positive direction can evoke a desire to be part of the success as well. Let success do the bulk of the work of convincing as then you aren't the only one convincing more people that it's possible.
Tim,

It'd be great to hear more about what your company thinks the "devops way" is.

If we look back in history, the first software engineers actually were operators as well (the women who programmed the ENIAC without any kind of manuals because hardware engineers were basically 'We built it, you figure it out'). Over time as computers became ubiquitous and affordable to everyone, software engineering broke out into specializations like system administration, system operators, and developers. Where once the hardware engineers were pushing the responsibilities on to software engineers, now the developers were doing the same to the other specializations. This led to some increased silos due to organizational structures and the ever increasing battles for budgets. System administration specialized into network, operating systems, security, and database administration. Development has specialized into hardware, front end, back end, quality assurance development just to name a few! As we see the specialization because each of the components become more complex we see more siloization.

So what does DevOps have to do for any of these groups? Bringing us back together to find the common grounds and the differences in our specializations that help us inform how we do our jobs for the better of the organization. We can see how some of the benefits of coding has been shared with operations folks in advancements such as infrastructure as code. With development, qa, and operations folks working together we can see continuous integration, continuous delivery, and continuous deployment become possible.

What does DevOps specifically have to do with front-end development? From what I've seen, to some degree the siloization is still happening and many front-end developers don't think they are part of devops even though devops with front-end AND back-end development at Flickr with operations was the key point that started the drive for cooperation and collaboration between groups because the magical outcome of 10 deploys was possible when these parties were on the same page! Key elements like defining your sandbox environment with abstractions that are provided with test kitchen, vagrant or cloud provisioning, and chef for example will allow a front-end developer to write deployments that can easily be deployed to  OS platforms of ubuntu OR centos locally or into systems hosted in AWS or Digital Ocean without changing the code.

The impact means faster delivery of code into environments where customers can see the benefits and changes more quickly. Often this leads to a change from trying to get the code out to be seen, and more about the ability to choose when those changes get deployed because it's possible to do the deployments so quickly.
Lanny,

Thanks for the question. One of the challenges that arrises from our industry is the use of terms to have many meanings. In our book Effective DevOps we define devops as

Devops is a cultural movement that changes how individuals think about their work, values the diversity of work done, supports intentional processes that accelerate the rate by which businesses realize value, and measures the effect of social and technical change. It is a way of thinking and a way of working that enables individuals and organizations to develop and maintain sustainable work practices. It is a cultural framework for sharing stories and developing empathy, enabling people and teams to practice their crafts in effective and lasting ways.



What it sounds like you are describing are some of the outcomes of successful devops in some organizations that lead to automation, continuous integration, and continuous deployment. Getting to a specific outcome is possible, but the cost to do so may be high with the current processes, practices, and tools in use within the organization.

For example, are you using infrastructure as code to automate deployment of services like Oracle DB? (Oracle software can be challenging to install due to their licensing process).

In general, showing the value of successful implementations of desirable outcomes can encourage further progress on some of the older systems. It's critical that all folks have buy-in, and that will take time. If you have dependencies on vendors, that can be more challenging as if they aren't on board with automation that can be very difficult. I've seen situations where the vendor is not providing software that allows for easy automation due to antiquated packaging. If you can apply the appropriate pressure with the vendor to get that resolved that can be helpful.

Great question! We started out with 5 chapters. As we wrote, we realized we needed to break it up into even more chapters to make it more manageable. Over the year and a half of writing, we wrote over 600 pages, and cut over 300 pages of content.

We wanted to start out with explaining what DevOps is. Many folks have many definitions that end up detracting from creating a common dialogue. Each of the next 4 chapters are the pillars of devops, the essential foundations that make a difference in outcomes: Collaboration, Affinity, Tools, and Scaling. A lot of folks focus on the outcomes that arise from devops like continuous integration and continuous delivery.

The final part is the glue in how to connect the different aspects across different organizations in practice.

The structure evolved as we wrote it and it made sense at the time. It'd be great to get more feedback about the flow issues that you mention.
Hi folks,

Looking forward to hearing about your thoughts, questions, and feedback!

Thanks,

Jennifer