DevOps is really hot at the moment and most of my friends, colleagues, and senior developers I know are working hard to become a DevOps engineer and project themselves as DevOps champion in their organization.
While I truly acknowledge the benefits of DevOps, which is directly linked to improved software development and deployment, from my limited experience I can say that it’s not an easy job. It’s very difficult to choose the right path in the middle of so many tools and practices.
Being a Java blogger, many of my readers often ask me questions like how to become a DevOps engineer, which tools should I learn? which practices should I follow? does learning Maven and Jenkins must for a DevOps guy?
how about Docker and Kubernetes? Does the infrastructure automation part of DevOps? should I learn Chef, Puppet, or Ansible are just some of those questions which keep coming to me.
I have tried hard to answer those with my minimal experience but I couldn’t jot them down in a manner which is simply awesome and reusable, but, not to worry.
Today I am going to share with you an awesome resource which will help you to become the DevOps Engineer you always wanted to be, the 2018 DevOps RoadMap.
I was casually surfing through internet yesterday when I come across this excellent GitHub page by Kamranahmedse, which shows a couple of useful roadmaps to become a front-end developer, back-end developer, a full-stack web developer, and last but not the least, the DevOps Engineer.
This RoadMap is awesome in any sense as it does not only highlight what is the role of a DevOps engineer but also tells which tools and technologies you need to learn to cover that area.
On top of that, it’s visually appealing with nice colors(don’t you like yellow and cream with blue lines?), so you can just take a printout and stick in your desk for easier reference.
Though the Roadmap is good in the sense that it tells you what to learn but it doesn’t tell you how to learn and where to learn. In order to complete the Roadmap, I have shared some useful online courses, both free and paid, so that you can learn and improve the tools or area you want.
What Is DevOps?
DevOps is a term for a group of concepts that, while not all new, have catalyzed into a movement and are rapidly spreading throughout the technical community. Like any new and popular term, people may have confused and sometimes contradictory impressions of what it is. Here’s my take on how DevOps can be usefully defined; I propose this definition as a standard framework to more clearly discuss the various areas DevOps covers. Like “Quality” or “Agile,” DevOps is a large enough concept that it requires some nuance to fully understand.
Definition In Depth:
DevOps means a lot of different things to different people because the discussion around it covers a lot of ground. People talk about DevOps being “developer and operations collaboration,” or it’s “treating your code as infrastructure,” or it’s “using automation,” or “using kanban,” or “a toolchain approach,” or “culture,” or a variety of seemingly loosely related items. The best way to define it in depth is to use a parallel method to the definition of a similarly complex term, agile development.
- Agile Values – Top level philosophy, usually agreed to be embodied in the Agile Manifesto. These are the core values that inform agile.
- Agile Principles – Generally agreed upon strategic approaches that support these values. The Agile Manifesto cites a dozen of these of these more specific principles.You don’t have to buy into all of them to be Agile, but if you don’t subscribe to many of them, you’re probably doing something else.
- Agile Methods – More specific process implementations of the principles. XP, Scrum, your own homebrew process – this is where the philosophy gives way to operational playbooks of “how we intend to do this in real life.” None of them are mandatory, just possible implementations.
- Agile Practices – highly specific tactical techniques that tend to be used in conjunction with agile implementations. None are required to be agile but many agile implementations have seen value from adopting them. Standups, planning poker, backlogs, CI, all the specific artifacts a developer uses to perform their work.
- Agile Tools – Specific technical implementations of these practices used by teams to facilitate doing their work according to these methods. JIRA Agile (aka Greenhopper), planningpoker.com, et al.
Ideally the higher levels inform the lower levels – people or organizations that pick up specific tools and practices without understanding the fundamentals may or may not see benefits but this “cargo cult” approach is generally considered to have suboptimal results. I believe the different parts of DevOps that people are talking about map directly to these same levels.
- DevOps Values – I believe the fundamental DevOps values are effectively captured in the Agile Manifesto – with perhaps one slight emendation to focus on the overall service or software fully delivered to the customer instead of simply “working software.” Some previous definitions of DevOps, like Alex Honor’s “people over Process over Tools,” echo basic Agile Manifesto statements and urge dev+ops collaboration.
- DevOps Principles – There is not a single agreed upon list, but there are several widely accepted attempts –here’s john Willis coining “CAMS” and here’s James Turnbull giving his own definition at this level. “Infrastructure as code” is a commonly cited DevOps principle. I’ve made a cut at “Devops’ing” the existing Agile manifesto and principles here. I personally believe that DevOps at the conceptual level is mainly just the widening of Agile’s principles to include systems and operations instead of stopping its concerns at code checkin.
- DevOps Methods – Some of the methods here are the same; you can use Scrum with operations, Kanban with operations, etc. (although usually with more focus on integrating ops with dev, QA, and product in the product teams). There are some more distinct methods, like Visible Ops-style change control and using the Incident Command System for incident response . The set of these methodologies are growing; a more thoughtful approach to monitoring is an area where common methodologies haven’t been well defined, for example.
- DevOps Practices –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration management, metrics and monitoring schemes, a toolchain approach to tooling… Even using virtualization and cloud computing is a common practice used to accelerate change in the modern infrastructure world.
- DevOps Tools – Tools you’d use in the commission of these principles. In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.
In the end, DevOps is a little tricky to define, just like its older brother Agile. But it’s worth doing. When left at the pure philosophy level, both can seem like empty mom-and-apple-pie statements, subject to the criticism “You’re just telling me ‘do my job better,’ duh…” But conversely, just the practices without the higher level guidance turn into a cargo cult. “I do what this Scrum book says so I’m doing Agile” is as erroneous as “I’m using Chef so I’m DevOps right?” To be a successful Agile or DevOps practitioner is to understand all the layers that go into it, and what a given DevOps implementation might contain or not contain. In the end, what DevOps hopes to bring to Agile is the understanding and practice that software isn’t done until it’s successfully delivered to a user and meets their expectations around availability, performance, and pace of change.
Specifically, I’ve come to believe there are three primary practice areas that are usually discussed in context of DevOps.
- Infrastructure Automation – create your systems, OS configs, and app deployments as code.
- Continuous Delivery – build, test, deploy your apps in a fast and automated manner.
- Site Reliability Engineering – operate your systems; monitoring and orchestration, sure, but also designing for operability in the first place.