1 The DevOps ingredients
This chapter covers
- Defining DevOps
- Introducing the CAMS model
Itâs 11:30 p.m. on a Friday, when John, the IT operations manager, hears his phone ring. The ringtone is distinct, one that John has programmed so that he can instantly recognize a call from the office. He answers the phone, and on the other end is Valentina, one of the senior software developers at Johnâs office. Thereâs a problem in the production environment.
The last software release included additional functionality that changed how the application interacted with the database. But because of a lack of adequate hardware in the testing environments, the entire application couldnât be tested prior to release. Around 10:30 this evening, a scheduled task that runs only quarterly began executing. The job was missed during the testing phase, and even if it wasnât, there isnât enough data in the test environment to create an accurate test. Valentina needs to stop the process, but she doesnât have access to the production servers. Sheâs spent the last 45 minutes searching through the company intranet site to find Johnâs contact information. John is the only person Valentina knows who has the production access she needs.
Killing the scheduled task isnât straightforward. The task usually runs overnight and wasnât designed to be stopped midway through processing. Because Valentina doesnât have production access, her only alternative is to dictate a series of cryptic commands to John over the phone. After a few missteps, John and Valentina finally manage to stop the task. The two plan to regroup on Monday to figure out what went wrong and how to fix it for the next quarter. Now both John and Valentina must stay on guard over the weekend in case the behavior repeats itself with another job.
Chances are this story feels familiar to you. Having production code that hasnât been properly tested feels like a scenario that could have been avoided, especially when it interrupts a team member on their off-time. Why is the testing environment insufficient for the needs of the development group? Why wasnât the scheduled task written in such a way to make stopping and restarting it straightforward? Whatâs the value of the interaction between John and Valentina if John is just going to blindly type what Valentina dictates? Not to mention the two probably skipped the organizationâs change approval process. Nothing raises the safety of a change like five people approving something they donât understand!
The questions raised here have become so commonplace that many organizations donât even think to examine them in detail. The dysfunction detailed is often accepted as inescapable, due to the difference in roles between development and IT operations teams. Instead of addressing the core issues, organizations continue to heap more approvals, more processes, and tighter restrictions onto the problem. Leadership thinks that theyâre trading agility for safety, but in reality, theyâre getting neither. (When was the last time you said, âThank goodness for change controlâ?) These negative and sometimes wasteful interactions between teams and processes is exactly what DevOps is attempting to solve.
1.1 What is DevOps?
These days, âWhat is DevOps?â feels like a question you should ask a philosopher more than an engineer. Iâll give you the story and the history of DevOps before presenting my definition. If you ever want to start a fight at a conference, though, you can ask the âWhat is DevOps?â question to a group of five people, and then walk away and watch the carnage. Luckily, youâre reading this and not talking to me in the hallway, so I donât mind putting my definition out there and seeing what happens. But first, the story.
1.1.1 A little DevOps history
In 2007, a systems administrator by the name of Patrick Debois was consulting on a large data center migration project for the Belgium government. He was in charge of the testing for this migration, so he spent a fair amount of time working and coordinating with both the development and operations teams. Seeing the stark contrast between how development and operations teams functioned, Debois got frustrated and started thinking of solutions to this problem.
Fast-forward to 2008. Developer Andrew Clay Shafer, attending the Agile Conference in Toronto, proposes an ad hoc discussion session called âAgile Infrastructure.â He received such poor feedback on his proposal that he didnât even attend the session himself. In fact, only a single attendee joined the session, Patrick Debois. But because Debois was so passionate about discussing this topic, he tracked Shafer down in the hallway, where they had an extensive discussion about their ideas and goals. Directly out of those conversations, they formed the Agile Systems Administrator Group.
In June 2009, Debois was back in Belgium, watching a live stream of the OâReilly Velocity 09 conference. At this conference, two employees from Flickr, John Allspaw and Paul Hammond, gave a talk titled â10 Deploys per Day: Dev & Ops Cooperation at Flickr.â Debois, moved by the talk, was inspired to start his own conference in Ghent, Belgium. He invited developers and operations professionals to discuss various approaches to working together, managing infrastructure, and rethinking the way the teams worked together. Debois called this two-day conference DevOps Days. A lot of the conversations about the conference were happening on Twitter, which then limited the number of characters per message to 140. To save as many precious characters as possible, Debois shortened the conferenceâs Twitter hashtag from #devopsdays to just plain #devops, and with that, DevOps was born.
Definition DevOps is a set of software-development practices that combines a software development mentality with other functions in the organization. DevOps puts a heavy emphasis on shared responsibilities across all teams throughout the software development life cycle. The edges of job functions soften, as operations team members take on tasks that were traditionally more developer-focused, and development team members do the same. The term DevOps is most commonly associated with development (Dev) and IT operations (Ops), but the approach can be extended to other groups as well, including but not limited to security (DevSecOps), QA, database operations, and networking.
Itâs been more than 10 years since that fateful meeting. Since then, DevOps has moved beyond small web startups and has begun to penetrate larger enterprises. The success of DevOps, however, has brought the most cantankerous enemy of any movement: market forces.
According to LinkedIn Talent Solutions, in 2018 the most recruited job overall, not just in tech, was DevOps engineer. Considering weâve defined DevOps as a set of practices, itâs strange how a style of work quickly became a job title. Youâve never heard of an Agile engineer, because it just sounds silly. As transformational as DevOps is, it couldnât escape market forces. With that much demand, the job title of DevOps has led to scores of candidates rebranding themselves as DevOps engineers.
Product marketers are looking to cash in on the DevOps craze. Simple products like metrics and monitoring get rebranded into âDevOps dashboards,â further diluting the meaning of the word. With the market pulling the term âDevOpsâ in different directions, it has splintered into different meanings for different people. I could spend an entire chapter arguing about what DevOps should and shouldnât mean; instead, Iâll use the definition that I proposed previously. But if you ever see me at a conference and want to see me go on a tirade, ask me what itâs like being a âDevOps manager.â
1.1.2 What DevOps is not
Ironically it might be easier to define what DevOps is not rather than what it is. Thanks to market forces, these details will probably fall on deaf ears, but since this is my book, I figure I might as well go for it! For starters, itâs not about tools. If you purchased this book hoping to learn about Jenkins or Docker or Kubernetes or AWS, youâre going to be sorely disappointed. I donât do refunds, but you can feel free to scream into the ether with your disdain.
DevOps isnât about tools, but about how teams work together. Technology is definitely involved, but, honestly, the tools are less important than the people. You can install the latest version of Jenkins or sign up for CircleCI, but if you donât have a solid test suite, itâs useless. If you donât have a culture that considers automated testing valuable, the tool doesnât provide value. DevOps is about people first, then process, then tools.
You need the people on-board and ready for change. Once the people are on-board, they need to be involved and engaged with creating the process. Once a process is created, you now have the necessary input to pick the right tool!
So many people focus on the tool first and try to work backward from there. This is probably one of the top DevOps follies. You canât choose a tool and then tell the people that they have to change all their processes. Our brains are wired to immediately be hostile to that type of approach. When tools are launched like that, the tool feels like itâs happening to them, not through them. That approach differs significantly from the way people accept new ideas. You have to have buy-in.
In addition, when you get excited about a new tool, you begin applying it to problems you never had. When you buy a new table saw, suddenly everything in your home becomes a construction project. Itâs the same thing with software tools.
All this is to say that the major focus of this book and DevOps is about people and their interactions. While I may reference specific tools here and there, the book avoids giving specific examples based on architecture. Instead, the examples focus on capabilities, regardless of which tool provides that capability. To highlight this approach, the DevOps philosophy is structured on top of the CAMS model, which aims to place people first when addressing problems.