The word DevOps is a combination of the development and operations of the term, meant to represent a collaborative or shared approach to the tasks performed by a company’s application development and IT operations teams. In its broadest meaning, it is a philosophy that promotes better communication and collaboration between these teams — and others — in an organization. In its most narrow interpretation, DevOps describes the adoption of iterative software development, automation, and programmable infrastructure deployment and maintenance. The term also covers culture changes, such as building trust and cohesion between developers and systems administrators and aligning technological projects to business requirements. It can change the software delivery chain, services, job roles, IT tools, and best practices.
- Web Developer Roadmap in 2024
- Free USA Ethical Hacking Course for Beginner
- Facebook Ethical Hacking Complete Tutorials Free for Beginner: Learn Online Hacking Course 2022
- SSTI (Server Side Template Injection)|Detect|Idenfify|Exploit
- Explore Hackthebox Walkthrough
What is DevOps (AWS Azure)?
Contents
While DevOps is not a technology, DevOps environments generally have common methodologies. These include the following:
- continuous integration and continuous delivery or continuous deployment (CI/CD) tools, with an emphasis on task automation;
- products that support its adoption, including real-time monitoring and incident management systems, configuration management and collaboration platforms; and
- cloud computing, microservices and containers implemented concurrently with DevOps methodologies.
Where Did DevOps Come From?
The two primary antecedents of DevOps are:
- Enterprise systems management (ESM). Many of the people involved in the initial definition of DevOps were system administrators. These operations experts brought key ESM best practices to DevOps, including configuration management, system monitoring, automated provisioning, and the toolchain approach.
- Agile development. One observer notes, “DevOps can be interpreted as an outgrowth of Agile—agile software development prescribes close collaboration of customers, product management, developers, and (sometimes) QA to fill in the gaps and rapidly iterate towards a better product. [DevOps acknowledges that] service delivery and how the app and systems interact are a fundamental part of the value proposition to the client as well, and so the product team needs to include those concerns as a top-level item.
What Problems Led to its Creation?
Developers and system administrators don’t always see eye to eye on a lot of things. But they do agree that their customers on the business side of the house frequently pull them in different directions. On the one hand, business users demand change—new features, new services, new revenue streams—as fast as possible. At the same time, they also want a system that is stable and free from outages and interruptions. That creates a problem where companies feel like they have to choose between delivering changes quickly and dealing with an unstable production environment or maintaining a stable but stale environment.
Not surprisingly, neither choice is acceptable to enterprise executives. And, more important, neither allows a business to provide the best solutions it can to its customers.
DevOps was created to resolve this dilemma by integrating everyone associated with software development and deployment—business users, developers, test engineers, security engineers, system administrators, and sometimes others—into a single, highly automated workflow with a shared focus: rapid delivery of high-quality software that meets all user requirements while maintaining the integrity and stability of the entire system.
How do these disparate groups join forces? By subscribing to a common set of principles that transcends traditional discipline boundaries and roles, for example:
- Set expectations and priorities and the fundamental beliefs that guide them.
- Collaborate both within and between teams on problem solving.
- Automate common and repetitive processes to free up time for higher-level work.
- Integrate feedback into the work, measuring everything that is moved into production.
- Share the data with everyone involved to foster a more effective culture of working well together across different skills and specialized knowledge.
Working
DevOps is a methodology meant to improve work throughout the software development lifecycle. You can visualize a DevOps process as an infinite loop, comprising these steps: plan, code, build, test, release, deploy, operate, monitor, and — through feedback — plan, which resets the loop.
Ideally, DevOps means that an IT team writes software that perfectly meets user requirements, deploys without any wasted time, and runs optimally on the first try. Organizations use a combination of culture and technology to pursue this goal.
To align software to expectations, developers and stakeholders communicate about the project, and developers work on small updates that go live independently of each other.
To avoid wait times, IT teams use CI/CD pipelines and other automation to move code from one step of development and deployment to another. Teams review changes immediately and can enforce policies to ensure releases meet standards.
What problems does DevOps solve?
Each company faces its own challenges, but common problems include releases that take too long, software that doesn’t meet expectations, and IT that limits business growth.
Without wait times, manual processes, and lengthy reviews, its project moves from requirements to live software faster. Shorter cycle times can keep requirements from shifting so that the product delivers what customers want.
DevOps solves communication and priority problems between IT specializations. To build viable software, development teams must understand the production environment and test their code in realistic conditions. A traditional structure puts development and operations teams in silos. This means developers are satisfied when their code delivers functionality. And if the release breaks in production, it’s up to the operations team to make the fixes.
With a faster process from idea to live software, companies can capitalize on market opportunities. In this way, DevOps provides a competitive advantage for businesses.
Benefits and Challenges
DevOps benefits include the following:
- fewer silos and increased communications between IT groups;
- faster time to market for software;
- rapid improvement based on feedback;
- less downtime;
- improvement to the whole software delivery pipeline through builds, validations and deployment;
- less menial work, thanks to automation;
- streamlined development processes through increased responsibility and code ownership in development; and
- broader roles and skills.
However, its challenges are:
- organizational and IT departmental changes, including new skills and job roles;
- expensive tools and platforms, including training and support to use them effectively;
- development and IT tool proliferation;
- unnecessary, fragile or unsafe automation;
- scaling DevOps across multiple projects and teams;
- riskier deployment due to a fail-fast mentality and job generalization vs. specialization;
- regulatory compliance, especially when role separation is required; and
- new bottlenecks.
DevOps skills
DevOps is often said to be more of a philosophy or collaborative IT culture, rather than a strictly defined job description or skill set. Because the area is so broad, DevOps positions suit IT generalists better than specialists.
The role of a DevOps engineer does not fall along one career track. Professionals can enter into the position from a variety of backgrounds. For example, a software developer can gain skills in operations. Such as the configuration of the hosting infrastructure, to become a DevOps engineer. Similarly, a systems administrator with coding, scripting, and testing knowledge can become engineer.
Many job listings call for the container, cloud, and CI/CD knowledge, as well as soft skills. A DevOps engineer might also need to change processes and solve organizational problems to achieve business outcomes.
Other titles often found in DevOps organizations include the following:
- infrastructure developer;
- site reliability engineer;
- build and release engineer;
- full-stack developer;
- automation specialist; and
- CI/CD platform engineer.
How to Get Started
There’s not one path to DevOps – there’s just what works in your organization. Very successful DevOps initiatives have been originated from dev teams and from ops teams, top-down and bottom-up, from inside the company and from consultants, with widespread education and with skunkworks pilots. Therefore it’s hard to give a generic playbook for how you can get it implemented.
I think it’s safe to say that it starts with you yourself learning about the values, principles, methods, and practices of DevOps. And trying to spread it via whatever channel is most effective – telling fellow techies, getting management buy-in, just starting to implement things in a more DevOps way yourself and letting success speak for itself… People will try to tell you how things can rise to success in your org, but that advice is usually more policy and wishful thinking than reality. Observe how other popular things in your organization have arisen and gained currency and try those same channels. And keep learning.
LinkedIn Learning Courses
Because we were frustrated with the state of education, we’ve started to create some courses with lynda.com/LinkedIn Learning to help people get up on core DevOps concepts! Check them out:
- DevOps Foundations (James, Ernest) – a three hour set of videos designed to orient beginners into the whole scope of DevOps. Read more about it here!
- The DevOps Foundations: Infrastructure as Code (James, Ernest) – two hours of infrastructure automation concepts, with demos illustrating them in everything from Cloudformation to chef.
- DevOps Foundations: Continuous Integration/Continuous Delivery (James, Ernest) – what you need to know about continuous integration and delivery, with demos in jenkins, nexus, and more.
- The DevOps Foundations: Lean and Agile (Karthik, Ernest) – Lean and Agile inform DevOps at a fundamental level, and adopting their methods will contribute to your success.
- DevOps Foundations: Site Reliability Engineering (James, Ernest) – The “Third Leg” of DevOps along with IaC and CI/CD, this is the “ops” part of ops.
- The DevOps Foundations: Monitoring and Observability (Peco, Ernest) – Monitoring is such a huge topic we did it separately from the SRE course.
DevOps Reading List
DevOps is still new so an undefined batch of blogs that changes monthly and following people on Twitter is often the best source of up-to-date information. Yes, that’s annoying. However, there are several books and other reliable sources of good information you can use and then share with others.
- Top pick – The DevOps Handbook, by Gene Kim, Patrick Debois, John Willis, John Allspaw, and Jez Humble, came out in late 2016 and is finally a definitive source on DevOps. If you just get one book, get this one.
- The Phoenix Project, Gene Kim, George Spafford, Kevin Behr – In novel format inspired by the seminal Lean work The Goal, this is a narrative of a DevOps implementation in a troubled software company.
- Web Operations, various – An O’Reilly book collecting a series of essays on Web operations that are really thoughts from a lot of the key DevOps pioneers.
- Continuous Delivery, Jez Humble and David Farley – While CI/CD isn’t the sum total of DevOps like some people would have it, it’s certainly a major area of innovation and this is the definitive work on it.
- A Practical Approach to Large-Scale Agile Development, Gary Gruver – For those who think DevOps is just for startups or just for Web software, this is the tale of how the HP LaserJet firmware division transitioned to an agile/CI/DevOps structure.
- The Practice of Cloud System Administration, Tom Limoncelli, Strata Chalup, Christina Hogan – A textbook style guide from the operations side, with loads of great new-style systems guidance and a lot of explicit DevOps content.
- Release It!, Michael Nygard – There needs to be more books like this. It explains common systems failure patterns and success patterns. I think of it as the Gang of Four Design Patterns book for systems.
- Lean Software Development, Mary and Tom Poppendieck – Lean is being increasingly adopted within the DevOps community, but starting from Deming and TPS is somewhat intimidating. This book is the seminal work on Lean in software.
- And round it off with Gareth Rushgrove’s DevOps Weekly email newsletter.
