The Rise of DevOps: What It Is & How It Helps Businesses [OverView]

Last updated on 03rd Jan 2022, Blog, General

(5.0) | 19148 Ratings 968

Share:

The DevOps movement started to coalesce some time between 2007 and 2008, when IT operations and software development communities raised concerns what they felt was a fatal level of dysfunction in the industry.

• Introduction to Rise of DevOps
• What problems does DevOps try and fix?
• Why has DevOps exploded onto the scene?
• Why is it so popular?
• Which problems is DevOps trying to solve?
• DevOps as self-service
• What are the defining tools?
• Your DevOps tool kit will most likely include
• DevOps everywhere?
• Conclusion

Introduction to Rise of DevOps:

• “Currently, DevOps is more like a philosophical movement, yet a precise collection of practises, not descriptive or prescriptive” What makes DevOps so appealing is that there is no absolute true definition of it. It has evolved from a set of concepts that are not new to the technological world. However, mostly, the phrase arose from the modern application of the agile and lean approach to how operations work. It is also an increasingly valuable return to collaboration between development teams and operations staff over the lifecycle of software, especially in this service-driven world.


• A good definition of DevOps is probably best summed up as “the practice of operations and development engineers participating together in the entire service lifecycle, from the design through the development process to production support”. This definition helps to highlight the importance that collaboration between teams of developers and operations teams play on the evolving landscape of IT development and by adopting similar best practises and uses, the product on which both teams work together. doing, it can be developed. more efficiently.


• As mentioned earlier, DevOps also originated from agile and lean methodology. However, with these approaches, the development and operations team are viewed separately, with the development team tackling the product prior to launch, then handing it over to the operations team after the product is released. The IT community realised that silencing the two teams and treating them as separate entities led to the development of DevOps and made it more collaborative. By collaborating closely with customers, developers and product managers, the aim is to create an overall better product.

What problems does DevOps try and fix?

• “Any role involved in a project that does not directly contribute to the goal of putting valuable software in the hands of users should be carefully considered as soon as possible.” — Stein Ing Morisbaki


• In the past, it was common knowledge in the IT industry that projects were likely to go ahead and that when they were eventually delivered, products often performed poorly. Until DevOps came out to offer a possible solution, many IT companies were hesitant to change for a variety of reasons, including the old mantra ‘if it works then don’t fix it’, as well as the silo issues mentioned above. are also included.


• In the past, one of the biggest reasons not to adopt a more collaborative process is because businesses that have invested large amounts of money in the process of developing products, software, and platforms don’t want to change anything on their concerns. . break things. With this there is often a lengthy process involved in changing anything at large companies. DevOps attempts to fix this by offering a collaborative approach throughout the process, from design to launch. This way, everyone is invested in the whole process, bureaucracy is removed or reduced, and a better product and service is released.


• Also, a common theme in the past for IT departments was the division of teams to work on different elements of the project. No teams were intertwined and no collaborations took place as we see them today. If problems do arise, and they always do to some degree, it used to be common practice to escalate the problem to different teams. This results in a lot of time and effort being developed without a permanent solution. DevOps again tries to solve this by promoting collaboration between teams and implementing standard practises.

Why has DevOps exploded onto the scene?

“Showing a strong success and visible benefit is the key to getting others to agree to try your way of doing things.” — Frederick Riven One of the main reasons why DevOps appeared was because people in the IT community realised that, while the ultimate goal was to create software that works and is ultimately profitable, all the teams involved in the process, from design to launch, are together. They are all trying to achieve the same goals, to produce a high quality product that delivers goods.




While the above may seem obvious to many of us now, a few years ago, it did not. With the introduction of DevOps, better communication has been achieved across businesses and this has been the driving force behind the DevOps explosion. The fact that it is now a common phrase used in the IT community, the fact that it brings together internal teams under a common goal and the fact that many major companies have embraced DevOps suggests That the trends around DevOps are here to stay. Next week in this series, we’ll cover what the future holds for DevOps, where the trends are headed, and what more innovations we can expect.

Why is it so popular?

• The problems DevOps tries to solve are in the name. It aims to bridge the institutional divide between the team writing the code (dev) and the team managing the infrastructure and tools used to run and manage the product (ops). As the software development life cycle becomes more complex, it has become harder and harder to track responsibilities for results and blame other departments for product quality constraints, delayed deadlines or shortcomings.


• Dev, QA, and often further fragmented ops groups may be unaware of each other’s constraints, have little insight into the business context, or even have opposing goals. The mistrust is hurting the organisation and making everyone involved in it sad. Tom Limoncelli, Site Reliability Engineering Manager at Stack Overflow, described the pain points as short and simple: “The software development life cycle is broken in most places. DevOps helps fix it.”


• The term DevOps offers a solution to one of the most pressing questions of our time: How can software teams best deliver business value? Answer? Developers and Operations Working Together (DevOps) Instead of Isolation. If DevOps delivers on its promise, benefits could include improved deployment frequency, faster time-to-market, fewer failures of new releases, and less time between fixes. With the benefits of greater predictability, efficiency, safety and maintenance along the full life-cycle. Or to put it simply, like Teresa Dietrich, Stack Overflow’s Chief Product Officer, “the right DevOps culture ultimately improves the product you deliver.”


• Many engineering teams around the world are trying to ease some of the pain of modern software development, with 44% of this year’s Stack Overflow Developer survey respondents working in organisations with at least one dedicated DevOps employee.

Which problems is DevOps trying to solve?

At a high level, there are three pillars of DevOps: Communication, Automation, and Measurement. The DevOps Status report found that companies that succeeded in DevOps shared these common threads. Let’s break it down a bit more and take a look at some of the DevOps practises together to see the problems they are trying to tackle.




From Silos to One-Team-Thinking:

• Devs work primarily with Devs, Operations Engineers primarily work with Operations Engineers, Infrastructure Engineers focus on their infrastructure problems. It’s easy to be isolated.


• Different departments and experts need to start thinking as a team towards a goal. Tools are needed to encourage a cultural shift and transparency for teams to work together without friction. The idea is described by the widely cited Jean Kim as a seamless transition between all SDLC steps, from identifying requirements, to actually building the application(s), then delegating the code to IT operations, and finally delivery to the customer.



Develop Your Skills with Advanced AWS Devops Certification Training
Weekday / Weekend BatchesSee Batch Details
• When silos prevail, most companies will feel more pain between dev and ops around application deployment. Limoncelli recalls from his time at other companies, when new releases meant days or weeks of manual deployment, working on weekends was not uncommon. There is a month’ in many places: a stressful time when everyone is rushing to finish the release and deploy it. In some companies this happens more than 12 times a year.” With good DevOps practises, those months’ disappear. Automation is a big part of eliminating months. It burns Prevents -out, reduces accidents, and makes businesses more sustainable.


• Similarly, the State of DevOps report highlights the need for delivery teams to standardise their patterns and components. The report’s authors acknowledge that the complexity of this task varies widely. “Some teams do this without much thought. Others, especially those who inherit code from across the organisation, will have to take a systematic approach toward eliminating variables and achieving standardisation.”


• Still, Limoncelli is convinced that change is happening. He is happy to see the change in culture. From a hiring perspective, they told me that the lack of months” used to be an “advantage” that only a few companies could offer. “Eventually”, he predicts, “companies that do not have good DevOps practises will be difficult to hire.”



Standardisation of tech stacks and lazy paths:

• There are many historical or sometimes political reasons for the unnecessary complexity and variation. So standardisation as part of the process makes automation easier. Andy Mann, chief technology advocate at Splunk, writes in the State of DevOps report that successful companies ‘show a concerted effort to normalise the stack and get rid of outliers or snowflakes that need to be maintained, tested, and managed as a one-time’. is required to do. The authors include creating a standard set of technology, keeping application configuration under version control, testing infrastructure changes before deployment, and making the source code available to other teams, which are essential steps for the early stages of DevOps.


• For a fresh perspective on how to make DevOps successful, Limoncelli suggests trying to ‘reference the following’. In contrast to one with high reference, a system of low reference requires very little elementary knowledge. The simple example that Limoncelli gave me goes like this: Airport signage is easy for everyone to understand – travellers around the world may need to know how to go to the bathroom (if you’re lucky). Whereas the customs of a family dinner, and the complex relationship between all present, has been learned unwritten for decades.


• Limoncelli believes that DevOps teams are more effective when they try to create a low-context work environment. For example, he advocates that the best way for people to adopt a recommended practice is to make it a ‘lazy path’. “If your defaults to basic tools like CI/CD and match your recommended practises, you’re doing the same right thing as doing the easy thing. You want people to fall into the trough of success.”

DevOps as self-service:

• Note that the state of DevOps report involves self-service in the fifth and final stage of the ideal stages of DevOps success. So you can consider it as reaching higher stages of DevOps.


• The implementation of the organisation philosophy here should allow everyone throughout the life-cycle to have access to internal services, including development, operations, security, ITSM, and other functional areas.


• Creating these self-services allows teams and individuals to work at their own pace, without having to wait for things like getting tickets approved, obtaining a licence key, setting up the necessary configuration, or having Sarah come back from vacation.


• According to the State of DevOps report, a key requirement for this is that Ops deliver systems and configurations used by QA and Dev that match the final production environment. Without it, software is often tested in an environment that is different from production. Self-service infrastructure helps to make the two environments as similar as possible.

What are the defining tools?

Tools don’t magically solve problems. However, better practises require the right tools. You were expecting to name a few? We have a dedicated Stack Exchange DevOps community on Stack Overflow’s sister network. Most DevOps engineers spend their time with us on this site as well as on Stackoverflow.com. These tags are a pretty good indication of what DevOps engineers are working with right now.

Your DevOps tool kit will most likely include:

Task Tracking: Asana, Monday, Jira,

Source Code Control: Github, GitLab, Bitbucket, TFS

CI/CD: Jenkins, Teamcity, Github Actions

Source Code Analysis: SonarQube

Artefact Management: Artifactory, Docker Container Register

Configuration Management: Terraform, Ansible, PowerShell/DSC, Puppet, (which are behind the state of the DevOps report) and Chef

Container Orchestration: Docker, Kubernetes

Monitor: Prometheus




To further enhance the automation tools, virtual infrastructure allows organisations to configure a server in an automated manner. Amazon Web Services and Microsoft Azure are examples of virtual infrastructure.

Note: Most of these DevOps tags have vast knowledge resources on Stackoverflow.com. Like DevOps, don’t think of it as a rigid technology stack. The reality will most likely be tools that are loosely coupled with those adjacent in the application life cycle.

DevOps everywhere?

• It’s come a long way since the day at Toronto’s Agile conference in 2008, when discussions on how ops and devs could improve collaboration attracted an audience of just one. In contrast, 80% of respondents to this year’s Stack Overflow developer survey believed that DevOps is at least somewhat important.


• In addition, 44% report working with at least one dedicated DevOps employee. We also see an increasing demand in the price tag on experts in the field. Specialisation is at the top of the pay scale for individual contributors.


• Not only that, if you account for experience, we see that DevOps get paid disproportionately higher than developers within the same level of experience in different roles.


• Even though about 12% of our developer survey participants this year identify themselves as DevOps experts, the process of adopting a DevOps mindset has never meant hiring one of those well-paid experts with DevOps in the job title. But keeping and working with it cannot be. DevOps engineers must build tools and train people on DevOps practises. The wrong way is to have a dedicated DevOps team that is expected to work for others, and thereby create a new silo. Exactly what DevOps is ready to end.


• Leadership in space comes from but isn’t limited to some of the usual suspects. How the DevOps mindset is interpreted on a team by team basis can vary. And how it will evolve to involve security teams in a holistic approach to software development as best practises is exciting to see.


• It is said that only a few unicorns (think. Netflix, Amazon, or Google) ever reach the continuous deployment ideal of “deploying all the way to production without any human intervention”.


• I was curious about where the Stack Overflow staff would put us on the spectrum. The people I spoke to (mostly SREs) all agree, we are somewhere in between. The introduction of DevOps is a huge organisational change. No doubt there are risks involved. So it required a certain curiosity and commitment. Spafford at Garner once called it “DevOps challenges traditional IT thinking, its continued evolution, and its need for acceptance and management of risk.”

Conclusion:

DevOps is not a goal, but a never-ending process of continuous improvement.”

A decade into the great DevOps experiment, the data is clear: DevOps is here to stay—and for some very good reasons. Many thought this was impossible, but DevOps has been successful in integrating business users, developers, test engineers, security engineers, and systems administrators into a single workflow focused on meeting customer needs.




Why would they do this voluntarily?

Because there is something in it for everyone. Developers and system administrators stop arguing and start supporting each other, thereby lowering the blood pressure all around. Business managers are happy because they get the software products they need to sell the products and services. Executives see their beloved dashboard metrics—revenue, customer satisfaction, system reliability—moving north. And everyone is able to provide the best results and overall experience to the customer.