The DevOps Manifesto

What you’ll learn

The idea behind DevOps is picking up steam every day. We used to call it “cross-functional” in traditional enterprise roles. But, why not espouse the benefits of people that can contribute to more than one team in a more meaningful way? This paper talks about the emerging roles within modern IT organizations, and the benefits of encouraging the individuals in those roles to follow their passions and leverage their talents.

Not only do we talk about the roles and ideas in general, but we’ve profiled some of Opsview’s own DevOps staff to give you an idea of how this is working in the real world. Perhaps the ideas or individuals highlighted within this paper resonate with you or someone in your current organization. Maybe they don’t, but you’d like them to. You should gain enough insight and understanding from this paper to launch or further the emergence of DevOps culture within your organization, regardless of size. 

Blurring the lines

The idea of DevOps (and individuals that associate with it) should be revered with excitement and passion. It is a nod toward the future of computing systems and technology roles.

There are approximately 3 personas in the world of DevOps. I say “approximately” because the entire concept of DevOps, or Development or Operations, is to blur the lines between roles. It is to break down walls and decrease barriers to adoption. Not just adoption of new technology, but new ideas, and new approaches to implementation and ongoing development and integration. So, to explicitly state that there are 3 roles, or 2, or 5, would be inaccurate.

The two most commonly recognized roles in DevOps are the developers, who are becoming more operationally-focused, and the operators and administrators, who are increasingly becoming proficient in scripting and development. We will discuss both of these personas, individually, later in this manifesto. The third persona, though, is perhaps the most important of all - the DevOps Manager.

Developers

If your role has traditionally been defined as developer, do you desire to be more than just the person implementing other people’s ideas? Do you manage more than just your source code? Have you implemented systems or processes that decrease time to deployment, or increase uptime through monitoring and visualization?

Just a developer?

Some developers are really happy being just that, a developer. And that’s okay. Not every developer should be forced into a DevOps team. Just “because it’s DevOps” isn’t a good reason for all developers to dive into something with which they may not be comfortable. Fortunately, DevOps doesn’t obsolete traditional developers. It doesn’t make them less valuable. It just gives more options if or when those developers desire additional scope, or opportunity, from their positions.

The value of creativity

Developers, by their nature, are creative - they’re creatively writing in a foreign language to coax computers into creating something from nothing. That’s an impressive creative streak! Many of them have a lot of ideas beyond just translating ideas into computer languages. They see opportunities to innovate within the development, deployment, and operational ecosystems. They desire to automate the business and reduce human error. They see a bigger picture than just the piece of a program they’ve been asked to develop.

More than just code

As a developer, if you see more than just code, DevOps environments and culture may be your ticket to creative freedom. Don’t be afraid to approach your manager with new ideas outside of just functions and runtimes. Don’t be afraid to develop proof of concept (POC) code.

Embrace DevOps

IT modernization practically mandates that organizations start embracing DevOps cultures or get left behind the increasingly rapidly-paced competition. As a developer, Remember that not all ideas are great ones. Be ready to accept constructive criticism, and that, sometimes, it’s not going to happen. At the same time, be ready to defend your idea, and have supporting data, references and reasoned rebuttals to objections. “Because it’s really cool” is not a valid supporting argument. It’s the job of your manager to determine the relative value of your ideas within the objectives of the business. Don’t begrudge them their position, as much as you don’t want them to begrudge you for yours.

Josh, DevOps Engineer

Josh has experienced rapid career progression. He began with an apprenticeship working with Windows technologies, but quickly moved past it to a role on a NOC (Network Operations Center) team. He worked in the NOC for just under a year, but the hours were sporadic with a lot of night shifts, 90 hour and 7 day weeks. The job had all the issues that platforms like Opsview help companies prevent.

After interviewing to be a consultant at Opsview, Josh got a job doing support, which he handled with aplomb for about 6 months. He transitioned into a business systems role in which he started working closely with engineering. It became clear that Josh is a talented engineer and programmer. He has since transitioned into a full-time DevOps role in engineering, where he maintains a complete OpenStack environment on his own. He also works on various programming tasks, from the core product, to automation, to plugin programming.

Since starting at Opsview, Josh has learned Ansible and Puppet. He “eats, sleeps and dreams YAML” (his own words). He really enjoys working on lots of different new things, particularly exploring technology unknowns. He thrives in an environment where he’s always learning and doing something different. He’s found that his days are “not really enjoyable if he’s not learning new things.” He really likes solving larger and larger problems, going into something huge he’s never seen before and fixing and/or improving it.

IT Administrators & Operators

Real value

The public value/view of the role of operations seems to have diminished with the advent of virtualization, cloud, and modern IT. The actual value, though, of administration and operations, has never been higher. While it’s exciting to think that containers mean we can ignore operational best practices, or that hardware and infrastructure should be software-defined and self-managed, that’s simply not the case.

The rise of the cloud

As cloud computing, and all the derivations of it, continue to explode in popularity this only serves to dramatically increase the need for competent operators and IT administrators to design, implement, manage, and monitor it all. Developers wouldn’t have IaaS and PaaS cloud technologies without you.

The need for operations

Modern, massively scalable technologies don’t deploy, manage, and monitor themselves automatically, though. They require operations. They require management teams that understand the modern computing landscape.

Increasing skills

As an IT administrator or operator, you are almost assuredly editing and writing deployment scripts, manifestos and cookbooks. Scalable systems don’t exist in a vacuum. Your programming skills are increasing and leveraged every day. You are just as vital to the DevOps culture as the managers that support it and the developers writing custom applications.

Modern development

In a way, every unique deployment you support is another custom application. With microservices, that could number in the thousands. You may already be crossing into the territory of enterprise and modern IT development.

The DevOps Manager

The manager of a DevOps team might not even be one yet. Any person managing a modern, operational or development environment either is, or is likely to become, a DevOps manager. In some traditional enterprises, this person may not even know it. Whether you’re aware of your position as a DevOps manager, the most important thing to do is embrace it, don’t contradict it; let the indiscriminate aspect of DevOps success happen. Encourage it.

Be less prescriptive

It is commonplace for managers to desire to be in a prescriptive role. They are, after all, the manager. But, when it comes to DevOps, being overly prescriptive generally only leads to boundaries that limit creativity and innovation. If a developer can decrease deployment time by implementing automated regression testing within the operational environment, why would you stop them? If an IT administrator can significantly increase the uptime of systems by automating the deployment of system monitoring on all systems, why fight it?

Acknowledge strengths

While it may be human nature, as a manager, to want to manage, sometimes the best form of management is to advise, mentor, and lead by acknowledgment. By acknowledging the strengths and capabilities of the developers and administrators within your organization, you, as a manager, elevate yourself as a leader. This doesn’t mean you don’t provide guidance. It doesn’t mean there aren’t clearly defined business objectives. It just means that the method of arriving at those solutions does not always have to be entirely prescriptive from a management perspective.

Time management

A good DevOps Manager can reduce their daily workload of oversight while increasing business added value. They can spend more time nurturing and less time directing. A good DevOps Manager knows when it’s time to step in if a project isn’t progressing as planned. They also know when it’s time to let the talent that works for them shine, like when a project is feature-full or ahead of schedule.

DevOps culture

DevOps cultures are prone to naturally increase productivity. The developers and the administrators are passionately involved in their work. There becomes an almost tangible excitement over the infinite possible outcomes of the blurred job descriptions in a DevOps culture.

Innovation

So, as a manager of developers, as a manager of IT administrators or operators, it’s the perfect time to start encouraging and fostering an environment of DevOps innovation. Never before has technology been so enabled such that a developer can deploy an entire system, an entire stack. Never before has an administrator been so enabled to script or program their entire environment. Modern IT, cloud, agile, and more - everything has come together to create a nearly ideal environment for fostering creativity and innovation; for garnering the benefits of the creative ideas from nearly everyone in your IT organization.

Encourage risk taking

As a DevOps Manager, or an aspiring DevOps Manager, start encouraging your people to take some risks, to share their thoughts, to go the extra step. In return for the risks you might be taking, you can start taking some credit and avoiding some blame, when the creativity and the innovation of your team pays off.

Conclusion

DevOps isn’t new, it’s really just getting started...

The blurring of the lines between development, operations, IT administration, management, and monitoring is just beginning. Everyone involved should consider a broader view of their role. Everyone should come to the table with ideas and passion.

The success, the objectives, the conclusion of a project generally don’t change because of a DevOps culture. The benefits, though, are realized in the approach, the excitement, and the reduced resources required to achieve similar or superior outcomes. That’s what DevOps is all about, and that’s what organizations should generally be striving to achieve in everything they do.

Here at Opsview, we've been encouraging our people to blur the lines and expand their roles for some time now. It has been working. The people, the process, they all contribute to a monitoring platform that is increasingly DevOps focused. If you don't have your systems and applications monitored, or don't have them monitored the way your developers and systems administrators would like them to be - in an automated, thoughtful fashion - contact us today to learn more about Opsview for your emerging DevOps and modern IT environment.