— ROELBOB
— ROELBOB
So you’re considering a shift to DevOps, Forbes recently reported that highly skilled DevOps specialists with just a high school degree earn a median salary of $106,734. A recent study of IT salaries revealed that 46% of companies plan on hiring DevOps in the coming year.
The DevOps space is red hot but here’s the skills you need, and what you should expect to encounter, in a career in DevOps.
What is DevOps?
DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better-quality software more quickly with more reliability.
It is also an automation process that allows quick, safe and high quality software development and release while keeping all the stakeholders in the loop.
What DevOps is not
DevOps is not a person, a role, or a title. You are not a DevOps engineer, even though you may call yourself one. DevOps is not about using a specific set of tools and it most definitely is not about renaming your Ops team the DevOps team.
Understand continuous delivery
Continuous delivery is an automated process for building software that expedites its release. It allows you to deploy a feature or upgrade rapidly, and with minimum manual intervention. The goal is more frequent, and far less risky small changes, to get dramatically faster and more focused feedback.
The ability to communicate is a must
Sharing and empathy is central in DevOps as it is in life. Knowledge not shared with the team is useless and will just create a bottleneck. Empathy for everyone on the team and their tasks is also crucial. You must have empathy for the challenges that each role brings to create a harmonies workplace.
Bring a wide business understanding
A DevOps specialist must be able to see the big picture in terms of processes, needs, and constraints. You have to be very familiar with all sides; Development, Operations, Sales, Product, etc. and you must know how they all work together to achieve the organizations goals.
Be prepared for late nights
DevOps means becoming ever more agile and responding to a client’s needs in real time. Critical events often occur in large and complicated systems. Hence, don’t be shocked if you get a 2 am call in the case of a crises.
Questions you can expect to be asked in an interview
According to Mike Baukes, if the interviewer wants to make sure you understand the framework you’ll be working with, they may ask “how does HTTP work? How does a web page appear in a browser?” Baukes advises that you may get a question like “How would you prepare for a migration from one platform to another?”, “Tell me about the worst-run/best-run outage you’ve been a part of. What made it bad/well-run?” or “What is the purpose of a post-mortem meeting?” and “Do you know how to learn from mistakes?”
Programs you need to know
Learn tools like Jenkins, Ansible, Chef and Puppe. It is well worth doing it on your own time and with your own dime, hands-on experience with actual tools and projects and an understanding of best practices can be more valuable than a college degree.
What you need to know about operations
If you’re coming from the developer side, obsessively get involved in everything your team does involving operations — deployment, scale, etc. If your team doesn’t do any of that for any number of reason, go over to the operations team and sit in on a few deployments.
Understand the databases role
Your database holds your companies most valuable asset, you must understand how the database and DBAs fit into the DevOps process so that the database does not become the weak link holding back the entire application development.
Ultimately DevOps is knowledge, concepts and best practices. It gives an edge to every developer or operations who practices it over those who don’t. It might not be something to do as a full time job, but any developer with DevOps experience will find themselves at the focal point in any organization striving to improve its processes, and hence position themselves to climb the ladder quicker.
Yaniv Yehuda is the co-founder and CTO of DBmaestro, an enterprise software development company.
If you’ve scrolled through LinkedIn or companies’ career pages, you’ve probably seen the term “DevOps” used as a part of a job title. DevOps Engineers and DevOps architects are everywhere, and many people are surprised to find that those titles aren’t correct. It sounds innocuous: After all, isn’t DevOps something that you do? If you’re a marketer, hiring manager or non-engineer at your company, it might seem like it.
But nothing could be further from the truth. DevOps is actually a philosophy and a set of practices that guides how your engineering and IT teams work. And using the term improperly can cause problems, even if you’re speaking with somebody who has “DevOps Engineer” on their LinkedIn profile.
To clarify what DevOps is and what it means, it helps to know where the movement came from and why it matters.
Where Did DevOps Come From?
The rise of DevOps is rooted in the Agile Systems Admin and Enterprise Systems Management movements, as well as an effort by businesses to become more responsive to rapidly evolving markets and problems. Enterprise Systems Management attacked this problem by replacing large vendor solutions with faster, smaller and sometimes open-source tools, while at the same time, the Agile Systems Admin movement was gaining popularity in Europe as forward-thinking companies translated lean and agile manufacturing lessons to IT departments.
The combination of these agile movements, the rise of SaaS and 24/7 service delivery, and examples like Flickr of excellence in developer-operations collaboration all helped prime the technical community for a change. After a talk by Flickr at the O’Reilly Velocity conference in 2009, highlighting challenges the company faced in continuous deployment and how they solved those problems with focused collaboration across the development and operations silos, Patrick Debois started organizing the first Devopsdays conference, and the name stuck. DevOps has been growing ever since, with conferences around the world, and has become synonymous with collaborative, agile, teams that ship quickly while maintaining high quality. This a very simplified account, of course— I recommend Richard Rapaport’s “A Short History of DevOps”, or Damon Edward’s video on the topic for a detailed history.
And when you understand that history, it’s easier to understand why engineers bristle at the idea of DevOps as a job title or company role. By referring to and thinking about DevOps properly, you’ll not only make tech talent at your company happier, but will also help internalize DevOps principles within your organization.
So, What Is DevOps, Then?
Definitions vary according to who you ask, but The Agile Admin sums it up well:
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
Put another way by the site, it’s “agile systems administration.” That means DevOps is about software developers and ops engineers working together with shared values, principles, methods, practices and tools to build, maintain and improve systems. “Works on my box, ops’ problem now” has no place in this movement, and the entire technical organization takes responsibility — together — for delivering great quality and service to customers.
Engineering organizations often think about problem-solving in terms of technical constraints: do we have enough server capacity? Enough bandwidth? Enough test coverage? But DevOps is also about engaging with the human side of shipping: do responsible teams have the right communication processes? How do we minimize error, and how do we effectively learn from mistakes without compromising morale? Patrick Dubois characterizes effective DevOps champions as “ambassadors, peace makers, facilitators and communicators,” who build bridges across the organization and rally teams around a common cause.
Why Isn’t DevOps a Job Title?
For many organizations that are moving to a DevOps model, it represents a fundamental culture shift, and the messaging around it is important.
The definition above doesn’t fit on a business card. DevOps is not about software developers taking over the job of ops nor ops taking over the job of developers. And it’s not just about shared tools (though that is part of it). It’s about breaking down organizational silos, scaling and automating processes, and leveraging best practices from both the development and operations world to ship better stuff to customers.
Good DevOps work requires testing, iterating and, even, breaking things. That needs to happen quickly, without friction and, most importantly, without blame. Defining someone as a “DevOps manager”or creating a “DevOps team” could imply that only those individuals are responsible for DevOps, and, should it fail, those failures are due to that individual or team rather than systemic organizational problems.
As Chip Locke writes, software developers and operations engineers are often different types of people, and trying to combine them into a single role won’t always be effective. When devs and ops are forced into a contrived role instead of encouraged to collaborate across their individual teams, competing values and (sometimes) suboptimal results are the outcome. Additionally, implementing DevOps as a third team that sits between the development and operations teams is a recipe for disaster.
You’re not in Kansas anymore
As organizations have to ship faster, more complex software to an increasingly demanding and quickly changing market, the prevalence of devops will only grow— fluency in the movement will help you collaborate with, hire, and retain great engineers, while pigeonholing it can lose you credibility with your technical team that’s hard to get back.
As the outsider, the onus is on you to educate yourself. Watch the presentations that birthed the movement, read some history, talk with those in the movement. To start you off, here are some of my favorite resources.
10 Deploys Per Day: Dev and Ops Cooperation at Flickr
A recurring argument in the DevOps community is whether the word DevOps should exist within a job title. Most people close to DevOps think it’s a potentially harmful anti-pattern which indicates a misunderstanding of what DevOps is all about. A few years ago I agreed with this, but I’ve now changed my mind.
Yes, DevOps is a culture, a mindset and all of those good things. It is about how people work together much more than automation. I also appreciate the argument that labelling individuals and teams with DevOps potentially introduces a silo where we are trying to solve a problem of siloes.
With all of that recognised, I’m still more than happy to now call myself a DevOps Engineer.
There were lots of job titles that didn’t exist 10 years ago. Agile Coaches, Social Media Managers, Data Scientists and Mobile App Developers for instance. Those fields evolved and there are now recognised experts in those fields who know how to apply the tools and help organisations be successful with them.
DevOps is the same. It is maturing as a movement and there is now enough specialist knowledge in the niche that people can build significant niche expertise, work within it full time, and even build long term careers as DevOps Engineers.
Definition Of A DevOps Engineer
DevOps Engineers are the people who sit between or within Development and Operations and use automation across the SDLC to reduce the cycle time from development to production.
These Engineers will bring knowledge across Development, Testing and Operations and help with gluing those areas together to ease the transition of code across them.
They will have deep technical skills in tools such as Puppet, Chef, Ansible, Vagrant and Docker, and use these tools to help their organisations deliver better software, faster and more reliably. They will also likely understand cloud and how to use infrastructure automation to leverage this to best effect.
As important as the technical knowledge is what we call the ‘DevOps Mindset’ – a personality type and approach that can help the IT organisation move from traditional ways of working, break down siloes, and collaborate more effectively. Technical skills alone do not make an effective DevOps Engineer.
Why This Matters
To me, this all sounds meaty enough to be a full time role and a career path. Therefore, why shouldn’t it also have it’s own name to identify it by?
I’ve always been pragmatic about this, but my main interest in this is how accepting DevOps Engineers as a job title might help to overcome the DevOps skills crisis – the huge shortage of people in industry who have this skill set and the fact that as an industry, we have still have no sustainable path to creating these people.
By accepting DevOps Engineers as a job and a career path, I think the definition of one would become more concrete. There would be more of a shared understanding over what it means, rather than savvy build and release engineers or system administrators re-badging themselves.
More people could align themselves to DevOps Engineering and work towards obtaining this recognised skill set.
Visibility of DevOps activities within the business would grow, and budgets would be created to support DevOps rather than it being an under the radar activity happening under other functional siloes.
Training for DevOps Engineers might emerge, and one day, it might even end up as a University Level course.
All of these things would help DevOps expand as a movement and practice in industry, which is ultimately a good thing for the sponsoring organisations and anyone who works in IT. Here at Contino, the more we interact with customers around DevOps, the more I realize this is the path things should take.
Once, people used the word genius only when describing someone who really was a genius. Someone with extraordinary intellectual and perceptual capabilities. Today every parent uses this word to describe their, likely cognitively regular child – and this term has lost any good taste. I find the same trend holds true for DevOps. And yet, that doesn’t stop everyone from saying the word DevOps, a lot (and more often than not, in a completely wrong context).
Many recruiters are now looking for “DevOps Engineers”. The demand for “DevOps engineers” has grown exponentially over the course of the last few years by thousands of %, just a small trend graph from indeed.com, and snippet from Google.
We constantly hear about companies building, “DevOps Teams”, and developing “DevOps Tools”. Everyone wants “DevOps” but have no idea what it means.
The short definition of DevOps is the ultimate business-requirements to customer to business-requirements cycle (often referred to as the best “development to production cycle”). How this would look in code:
(Of course, this snippet presents the problem very broadly and doesn’t take serious bugs into consideration)
All of this, aside from the development process is expected to happen automatically, not affect users at all, and have monitoring that is so exceptionally smart that it always points to the exact problem. Hmmm. What’s described above, is of course…. utopia.
Reality Check. Most companies are more likely in the camp that:
DevOps aims to solve these problems.
It is a culture, in which people work together to improve the product delivery cycle.
At its base, it requires good collaboration/communication (with the other teams), familiarity (with the system), control (over features and failures), short dev-to-prod cycles (this isn’t mandatory, but can help to prevent major bugs), and quality testing (‘nuff said). This is practically a great analogy to a good relationship except that it also requires automation (to make all of the above possible), which is something you should probably refrain from in your relationship if you want your belongings to remain inside the house.
Let’s look at the following job descriptions.
See anything… strange about them? Yes, they want a God.
The Dream Errr…”DevOps Team” is basically a group of:
Bottom line, they are supposed to be a group of people who know everything, can do anything, yet do not develop the application (That’s the Devs Job), nor do they install servers manually (That’s the Ops job).
Don’t even get me started on “DevOps Tools” – Puppet, Chef, Ansible, Cloudify, Saltstack, OpsWorks, Jenkins.. these are all “DevOps Tools”, right? WRONG! They are automation tools! They don’t “DevOps”. They automate, i.e. enable “DevOps”. JIRA, HipChat, PagerDuty, CloudWatch, New Relic… these are communication, collaboration and monitoring tools. You get the idea.
There are no “DevOps Tools”. Developers have development tools because a developer is a profession. Just like a blacksmith has a mallet. Can you define a set of culture tools? Are the pen, the paintbrush, and the violin considered culture tools? No, they are instruments for the writer, painter, and musician to create works of cultural significance.
In the same way, there are automation, collaboration and communication tools that enable the DevOps culture to be implemented into the organizational DNA.
What we tend to mean when we say DevOps:
What we should mean when we say DevOps:
This is enabled by:
Culture is a very abstract and complicated concept. It isn’t as simple and obvious as a tool.
Along the way, we took the tools and skills that are required to implement DevOps and named them DevOps instead. We appended the skills necessary to deal with these tools to a list, created a job description, and from there… the rest is history.
What people refer to as “DevOps people” is usually (not always) a term that describes operations people who know how to code and who automate stuff – “InfraCoders”.
So pretty much, you can’t (well,you can – it just doesn’t make much sense) have a “DevOps Team” or a “DevOps Engineer” because “DevOps” is not a thing.
It is a how. It doesn’t respond to the question: ‘What’s your job?’ or ‘What does your team do?’ it responds to: ‘How does your company do it?’. And most importantly: DevOps, is “DevsWITHOps”, not “DevANDOp.”
Having said that, DevOps is not ONLY for Devs and Ops. It’s for everyone. It’s not about the titles or teams, it’s about the way a company handles the process of delivering a product to production in the best way possible.
The problem with the “everything is DevOps” attitude is that it renders definitions meaningless. If everything is DevOps, then it’s everything and nothing, and de facto has no meaning. DevOps is already a complex concept. Making it mean everything, will make it practically impossible to implement.
Ultimately, it really makes no difference whatsoever what you call your special forces team. You can call them “DevOps” or you can call them Bean Soup. Just be sure not to delude yourself that by constantly using the word DevOps in the wrong context, that your company is doing DevOps, while all you’re actually doing, is using Puppet.
About the Author
Nir Cohen – is an Ops Architect at GigaSpaces working on Cloudify and a co-organizer of DevOps Days Tel Aviv. He’s the brainchild behind the awesome open source tool Packman for package management. Nir loves system architecture, likes to think of himself as an innovative, think-tank type of guy who adores challenges and has an extremely strong affinity to automation and system architecture. He’s primarily driven by researching and deploying new systems and services. To Nir, the most important thing in life is ethics. Find Nir on GitHub or follow him on Twitter.