DevOps is constantly ranked as one of the highest-paying professions, with a median salary of $100,000. Entry-level DevOps engineers can expect to earn anywhere from $75,000 up to $145,000. As you progress in your career, you can expect to earn more. Look at the following graph:

Figure 1.1 – DevOps salaries

Another reason you should consider a career in DevOps is you will never get bored as it is ever-evolving, which allows many opportunities to learn new skills.

Constant learning opportunities

Part of your job as a DevOps engineer is to stay up to date with the latest tools, technology, and trends that are occurring in the industry. DevOps engineers get paid to learn! It is one of my favorite things about my role as a DevOps engineer. As a DevOps engineer, you will ward off boredom while at the same time future-proofing your career.

Impact on the company

As a DevOps engineer, you will be delivering features used and felt by every part of the company. There is no other technical position where your efforts will have such a significant impact on the business.

Flexibility

As a DevOps engineer, you will have the flexibility to work where you want, when you want. Remote work has become increasingly accepted across the technology industry; DevOps teams were doing this before it was considered cool. Collaboration tools including Slack and Jira have made asynchronous work possible. What this means is you do not have to work the same hours as the rest of your team – at least not all the time.

So, Why Should You Pursue a Career in DevOps?

As a DevOps engineer, you will be highly compensated, constantly learn and apply cutting-edge technology to solve problems impacting the entire business, and have the flexibility to work where and when you want.

You are reading a book on DevOps, likely meaning you have a basic understanding of what DevOps is; if not, there's no need to worry – that will be covered as well. The history of DevOps is less known even within DevOps communities. First, we'll go back to understand key elements that came before DevOps that laid the groundwork and created the environment needed for DevOps to grow.

Lean manufacturing

Lean manufacturing is a production method aimed primarily at reducing cycle times within the production system as well as response times from suppliers and to customers.

The term Lean was coined in 1988 by John Krafcik and defined in 1996 by James Womack and Daniel Jones. Lean manufacturing is well-established as a set of best practices for manufacturing. Often branded as the Toyota Manufacturing Method, Lean manufacturing strives for process optimization across the manufacturing floor. Continuous improvement is the mantra for Lean manufacturing and practitioners continually evaluate ways to do the following:

• Keep inventory at a minimum.
• Minimize the queue of orders.
• Maximize efficiency in the manufacturing process.

Agile

In the early 2000s, traditional waterfall methods were evolving and being replaced by Agile, which required a large culture shift that focused on team empowerment. Agile is based around 4 core values and 12 principles. Some were adopted into DevOps as it evolved (https://kissflow.com/project/agile/values-and-principles-of-agile-manifesto/).

Extreme programming

XP aims to improve software quality and responsiveness to changing customer requirements. If you are thinking that sounds a lot like Agile, you wouldn't be wrong; it is a type of Agile software development. The biggest difference between XP and other Agile frameworks is the emphasis placed on the code and development (https://en.wikipedia.org/wiki/Extreme_programming).

The main contribution XP gave DevOps was Continuous Integration (CI). CI was a term introduced in 2001 by Grady Brooch and was published as the Brooch method soon after.

DevOps

The exact inception of DevOps will forever be debated; it is widely accepted that between 2007 and 2008 is when the movement started. It was a perfect storm of events that allowed and triggered the DevOps movement. The dysfunction in the software industry, namely between IT operations and software development communities, was the spark that ignited the movement, but it was the pioneers of Agile, Lean, and XP who were responsible for the initial fuel of the DevOps movement.

In a world absent of DevOps, developers and IT operations belonged to different corporate hierarchies and Key Performance Indicators (KPIs) for IT operations and development were asynchronous and detrimental to the other. These conditions created teams siloed from one another, causing a breakdown in communication, and ultimately leading to failed deployments, missed deadlines, and angry customers.

In 2008 Andrew Shafer, a software engineer, tried to put together a meetup session entitled Agile Infrastructure at an Agile conference in Canada. Patrick Debois, an Agile practitioner, was the only one there. The two had a long conversation, which today is known as the spark that ignited a fire that became a movement known as DevOps. Andrew and Patrick formed a discussion group for other people to post their ideas for how to solve this divide between development and operations later that year. In 2009, the first DevOpsDays was held, in Belgium, which turned DevOps into a buzzword forever cemented in history. The DevOps movement continued with local meetups around the globe. Around 2010, open source software focused on DevOps began growing in popularity; Jenkins CI server software and Chef infrastructure provisioning software were a couple of pioneers.

Pro Tip

Understanding the history behind the job title you are applying for will make you seem more serious about the role and conversation much more natural. Dig deeper and read some books such as The DevOps Handbook and The Phoenix Project. They will only increase your chances of success further.

The following diagram gives a timeline of key dates in the history of DevOps:

Figure 1.2 – History of DevOps timeline

Now that we have learned about the history of DevOps, let's look at DevOps culture in the next section.

DevOps is a set of practices that combines software development and IT operations. It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development; several DevOps aspects came from the Agile methodology (https://en.wikipedia.org/wiki/DevOps). Diving deeper into that definition, we learn DevOps is a multi-faceted practice. DevOps has seven guiding principles that combine to form DevOps culture. DevOps culture aims to decrease cycle time, apply incremental changes, and create a more streamlined development process.

The following diagram gives a graphical representation of the seven principles of DevOps:

Figure 1.3 – DevOps culture – principles

Now we will take a deeper dive into each of the seven principles of DevOps.

Customer-centric

Test often, get end user feedback frequently, and fail fast. The feedback loop between the customer and end users of products needs to be as short as possible. All actions taken by a team should be focused on the experience of the end user. This is also where the saying shift-left comes from, meaning the sooner a feature is tested for bugs, the quicker it will be resolved, and fewer downstream dependencies will be compromised.

A Tale of Two Start-Ups Bidding to Develop a Fitness Tracker for a Large Insurance Company

Need: A wearable device that will track users' fitness.

Acceptance Criteria: A wearable watch-like device that tracks various workouts.

Company X employs test-driven development and has weekly demos where they receive feedback. During a demo, they showcase a device and describe plans to track running and cycling. They learn that a big portion of their customers are swimmers. The team takes the feedback and shifts priority from running and cycling to swimming. The customer is impressed.

Company Y does not feel it is necessary to have demos as their past applications have done relatively well. The team focuses on the running and cycling workout tracking ability. During acceptance, they receive feedback that the watch must have the ability to track swimming. The development team is unable to meet the requirements in the given time frame. The customer is not impressed.

Outcome: Company X is awarded the contract and goes on to be a billion-dollar company. Company Y is not awarded the contract and receives poor press leading to another failed start-up.

Foster collaboration

The collaboration between the development team and IT operations teams is the most basic must for DevOps. Removal of silos ensures collaboration and alignment across entire organizations, ensuring a singular focus on the customer.

A collaborative culture is most effective when implemented using a top-down approach; executive sponsorship should be lined up ahead of any major culture shift. Another, much slower, approach is grassroots initiatives within an organization. A group of like-minded individuals with a platform to share on is all it takes to start a revolution. The trouble with the latter approach is overtime burnout can occur if you work tirelessly to make a change and see no results time and time again. Instead start with something you do have control over, such as your team.

Robert Weidner is a senior director at Optum and is one of only 26 Certified Enterprise Coaches in the world and is also my mentor and former manager. While working under Robert, our team was empowered to choose what micro team we worked in. We were also encouraged to hop over and help any other micro team who needed our support. When it came to stack ranking the team and fitting us to the bell curve for our bonus, we did our reviews of each team member during an offsite with the entire team present and in the hot seat while receiving feedback. It was frightening, but it worked because the team trusted each other.

End-to-end ownership

Feature teams ensure end-to-end responsibility by giving the team a vertical slice of a product, a feature. The feature, Feature 1: Button X, has two user stories: one for development and one for testing. The definition of done for the feature also requires the feature to be deployed successfully. This can be seen in Figure 1.4. The final piece to note is the ongoing support of Button X also remains with the team. Our company has started to call this You Build It, You Own It (YBYO). The rationale behind this concept is that the team who built something is going to have the most knowledge about it when there is a production issue.

Figure 1.4 – Feature-centered team (E2E ownership)

In traditional development methods such as waterfall, teams are broken down and created at the activity level, also known as a horizontal slice of work. Ownership of a feature is split among various teams. In the following example, three teams must interact with the feature before it makes it to the end user, and another team is responsible for ongoing support. This is problematic; the operational support team is oftentimes not aware of the most recent changes the development team made, leading to extended downtimes and outages:

Figure 1.5 – Waterfall teams

Now, we'll talk about continuous improvement.

Continuous improvement

Continuous improvement was inherited from Lean. The entire team should be encouraged and, more importantly, empowered to make changes without fear of failure. Teams instead use failure as opportunities to improve on flawed processes. This is also known as failing forward. Failing forward allows for better control over risks as well as continuing to push the team forward. For your entertainment, the following is a script (continous_improvement.sh) to ensure your team is empowered to make improvements, continuously:

Figure 1.6 – Continuous improvement shell script

The preceding script is a simple script that defines the flow of how the continuous improvement flow would operate if it were a shell script.

Automate everything

While doing research for this book, I noticed two common wordings: automate everything and automate (almost) everything. Further research revealed a common theme in types of processes that should not be automated, items with no payback, and items including a high degree of design or visual inspection, as seen in the following list (https://dzone.com/articles/what-to-automate-and-what-not-to-automate):

• Automation with no ROI
• Design
• Final QC of an application

Processes should have the least amount of manual intervention possible. The reason for this is simple: humans are error-prone while machines (computers) are excellent at executing high-volume repeatable tasks.

Next, we will cover continuous learning, a DevOps principle that is important for individuals looking to enter the field of DevOps, as well as those looking to stay relevant in the ever-changing field of technology.

Continuous learning

Technology is evolving at an astonishing rate; the most well-known example of this is Moore's law. Moore's law is the observation that the number of transistors in a dense Integrated Circuit (IC) doubles about every 2 years (https://en.wikipedia.org/wiki/Moore%27s_law). The number of transistors that fit into a microprocessor reached over 10 billion in 2017. It was under 10,000 in 1971( https://ourworldindata.org/technological-progress). Being a continuous learner is a personal attribute that will get you hired.

Pro Tip: You Must Be a Continuous Learner If You Wish to Succeed in DevOps

Creating a public project using a new technology is a great way to showcase this to potential hiring managers. Another way is to make sure to leave digital breadcrumbs of the most recent articles you have read, whether it be a post on LinkedIn or a tweet on Twitter.

An example that sticks out is an interview for a senior DevOps engineer role that was down to the final two candidates. Both candidates had tenure with the organization, exceeded the qualifications, interviewed well, and had advanced degrees. The candidate that received an offer displayed a hunger for knowledge throughout the interview process in subtle ways. The candidate chose to focus not on their degree but on a side project that had the purpose of teaching the candidate Golang. The theory of data science was being demonstrated with the application and it was cool. What stuck out, and continues to, was the candidate's desire to learn new things.

In summary, the combination of development and operation along with the seven DevOps principles, when applied together, form the DevOps culture. DevOps is a completely unique derivative of Lean, Agile, and XP aiming to shorten the feedback loop between development and the end user.

Take a look at the following visual depiction of DevOps culture broken down into the practices and principles:

Figure 1.7 – DevOps culture chart

In summary, DevOps culture contains seven guiding principles, as seen in Figure 1.7. In the next section, different career paths for a DevOps engineer will be discussed.

The field of DevOps is dense and is challenging to navigate, even for experienced practitioners. DevOps consists of eight core practices and follows seven basic principles. Unsurprisingly, there are numerous career paths in the field of DevOps. The generalist is the most common DevOps role.

A DevOps generalist is comparable to a Swiss Army knife, which is designed to handle as many tasks as possible. It can cut rope, open a can, cut wire, and if needed, the Swiss Army knife could fillet a fish. A DevOps generalist can create a deployment pipeline, write infrastructure as code scripts, and manage an Elastic Kubernetes Service (EKS) cluster in Amazon Web Services (AWS) if necessary.

A DevOps specialist is comparable to a fish fillet knife, which is singularly designed to fillet fish most effectively. The knife's profile, blade material, and ergonomics are finely tuned for a singular task, slicing fish. For example, a DevOps cloud specialist has spent their career focused on becoming an expert in cloud infrastructure, cloud architecture, and cloud security, and managing an EKS cluster in AWS is what they do in their sleep. It is likely that they would find a more cost-efficient way to do it than a non-cloud specialist.

A DevOps specializing generalist is comparable to an Everyday Carry (EDC) knife with a trailing point blade. This knife has ergonomics similar to a Swiss Army knife but a blade profile giving it the ability to fillet fish at a comparable level to a fillet knife. A DevOps specializing generalist who spent the past 10 years working in an AWS environment would be able to complete most DevOps tasks but would excel at those that involved AWS services.

Common skill profile shapes for a generalist, specialist, and specializing generalist can be seen in the following diagram:

Figure 1.8 – Skill profiles

The profile of your skill set can be very useful when determining how to classify yourself. Start with a comb. Each prong (skill) has a similar length (depth). The comb shape is typical of a generalist. The second common profile is the T shape. A T has a single line (skill) that has a full length (depth). The T shape is typical of a specialist. An E-shaped profile, sometimes referred to as an unequal comb, has prongs (skills) of differing lengths (depths). Oftentimes, one or several skills have a definitively greater depth than the rest. The E shape is common for a specialized generalist.

A mentor told me the unequal comb (E shape) skill profile is the only true measure of an individual's skills. The comb shape is flawed because it assumes all skills have an equal depth, which is impossible. The T shape has a lack of detail; it shows a singular skill the individual is highly adept at but does not account for the other skills possessed by the individual.

Pro Tip

For this chapter, do not focus on what is required for the example skills listed as they will be covered in the next chapter. Instead, focus on how the skill profiles relate to the different types of DevOps engineers' specific requirements.

Common skill profiles fitted to the E profile can be seen in the following diagram:

Figure 1.9 – Skill profiles (E profile fitted)

In the following sections, we will take a look at skill profiles for a DevOps generalist, specializing DevOps generalist, as well as several skill profiles for DevOps specialties. We will begin by looking at the skill profile for the DevOps generalist.

DevOps generalist

Google's Ben Fried stated, Generalists, not specialists, will scale the web (https://devops.com/specialists-vs-generalists-enterprise-devops/). This is a quote from back in 2011 but still holds true to an extent today. A generalist understands the entire Software Development Life Cycle (SDLC). The generalist has broad knowledge across domains and skill areas but lacks a deep understanding of any domain. This is common in small companies, start-ups, or vertically integrated companies having only a handful of products and tools to support. There needs to be almost no handoff of work, leading to fewer places to drop the ball or forget something.

The following is a sample skill profile for a DevOps generalist. Take note of the relatively flat shape:

Figure 1.10 – DevOps generalist skill profile

The DevOps generalist is one of the first to feel the pains of growing or introducing new software, especially in smaller companies or organizations with a small DevOps department. When a new tool is introduced, the DevOps engineer needs to understand the tool before it is implemented. Next, an environment must be provisioned for the new tool, oftentimes unlike the environment the existing tool uses, or at least with quirks and subtle differences. Finally, the tool is implemented. At this point, both the new and existing tool need to be supported by the DevOps engineer. The comb shape that was used graphically to describe the generalist has an inherent flaw: it assumes a generalist does not have a deep understanding of any domain.

DevOps specializing generalist

If you stay working in the same industry or with the same type of projects long enough, you will eventually become a specializing generalist. The specialized generalist is also referred to as a master general. In the preceding example, the DevOps engineer has all the required skills but has a much deeper understanding and knowledge in the domain of programming and developing code. This is typical for software engineers who transition into a DevOps role. This could also be a skill profile you evolve over time if you enjoy certain skills, or if you just happen to always be assigned to tasks that require those skills. Regardless of how your skill profile evolved, knowing you have a deeper understanding of certain areas can be beneficial both when looking for a job as well as when it comes time to ask for a promotion.

In the following figure is the skill profile of a DevOps engineer who has knowledge in many domains with a deeper understanding of the Build and Deploy domains:

Figure 1.11 – DevOps specializing generalist skill profile

Understanding your own skill profile can be very helpful both for a manager of a team when planning capacity, as well as an engineer when choosing which roles to apply for, which is likely what you are interested in. In the next chapter, we will take a deeper dive into how you can create your own skills profile.

A specialist has a very deep understanding of a singular domain. This does not mean they are not capable of doing other things; however, it is usually not efficient to have a specialist work across domains. Specialists are more common in large organizations that define specialists by the tools they support. If we apply this to our previous example, DevOps engineering team A would specialize in tool A. When a new tool is introduced into the company, a new team would be formed and talent would be hired with correct skills or existing employees would be up-skilled to join the team. Specialists who possess deep knowledge in one of the DevOps domains are the ones that will be focused on in this book going forward.

DevOps security specialist

A DevOps engineer specializing in security is known to be in the niche field of DevSecOps. DevOps security specialists have a deep understanding of areas such as penetration testing, cloud security, chaos engineering, and continuous verification as seen in the following example skill profile:

Figure 1.12 – DevOps security specialist skill profile

Now, we will talk about DevOps cloud specialists.

DevOps cloud specialists

One of the fastest-growing fields is cloud engineering and cloud engineers are some of the highest paid. What is the difference between a cloud specialist, a cloud engineer, and a DevOps cloud specialist? you might be asking, and the honest answer is nothing. Titles are meaningless and, oftentimes, they differ between companies and sometimes even between departments in larger organizations. A DevOps cloud specialist has traditional DevOps skills but has a very deep knowledge of the cloud tools, architectures, best practices, and management of entire cloud environments, sometimes multi-cloud environments.

The wide-scale adoption of the cloud has made a strong understanding of the cloud something even entry-level jobs oftentimes require.

Figure 1.13 – DevOps cloud engineer specialist skill profile

In this section, skill profiles for DevOps generalists and DevOps specialists were covered.

In this chapter, you gained insight into the history and goals of DevOps. DevOps was founded around 2008 when a developer and Agilist met at a conference and decided there needed to be a better way of developing software. The goal of DevOps is to remove silos between development and IT operation teams as well as shortening the feedback loop between developers and customers. DevOps is a mix of Lean, Agile, and XP methodologies.

You also learned about the numerous career paths to choose from in the field of DevOps. Career paths in DevOps are defined by the depth of knowledge required. Three skill profiles were discussed: DevOps generalist, DevOps specializing generalist, and DevOps specialist. A DevOps specialist has a much greater depth of knowledge than a generalist.

In the next chapter, we will cover specific skills required for a DevOps generalist.