DevOps: Introduction to DevOps and its impact on Business Ecosystem

Introduction to DevOps and its impact on Business Ecosystem

Stephen Fleming

• Publisher: Stephen Fleming
• ISBN:
  9781537827872
• Topic: Informatica
• Subtopic: Programmazione open source

"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change." - Charles Darwin

As the industry is moving towards maximum digitization there is a consensus that DevOps practices help you deliver software faster, more reliable, and with fewer errors.

DevOps is set of practices and cultural values that have been proven to help organizations of all sizes improve their software release cycles, software quality, security, and ability to get rapid feedback on product development.

This book is aimed at Consultant, Project Manager and people from techno-commercial profiles who would be explaining the benefits of DevOps to the client, internal leadership or project teams. As the crux of DevOps methodology lies in the cultural transformation of the organization, people who are stakeholders in shaping this change must understand the overall alignment of business goals with this methodology.

You would get to explore:

• What is DevOps
• Relationship between Agile, Scrum, Kanban and DevOps
• DevOps Adoption: Organizational cultural Change
• DevOps Ecosystem
• Emerging Trends
• DevOps success stories

In the Bonus Booklet you will find out:

• DevOps Job Market overview
• Insights into DevOps job application
• People to follow on twitter

"Grab your copy today along with Bonus DevOps Booklet"

What Is DevOps?

DevOps – or development and operations – is a term used in enterprise software development that refers to a kind of agile relationship between information technologies (IT) operations and development. The primary objective of DevOps is to optimize this relationship through fostering better collaboration and communication between development and IT operations. In particular, it seeks to integrate and activate important modifications into an enterprise’s production processes as well as to strictly monitor problems and issues as they occur so these can be addressed as soon as possible without having to disrupt other aspects of the enterprise’s operations. By doing so, DevOps can help enterprises register faster turnaround times, increase frequency of deployment of crucial new software or programs, achieve faster average recovery times, increase success rate for newly released programs, and minimize the lead time needed in between modifications or fixes to programs.

DevOps is crucial for the success of any enterprise because, by nature, enterprises need to segregate business units as individually operating entities for a more efficient system of operations. However, part of such segregation is the tendency to tightly control and guard access to information, processes and management. And this can be a challenge, particularly for the IT operations unit that needs access to key information from all business units in order to provide the best IT service possible for the whole enterprise. Simply put, part of the challenge in segregating business units into individually operating ones that are independent of each other is the relatively slow flow of information to and from such units because of bureaucracy.

Moving towards an organizational culture based on DevOps – one where the enterprise’s operations units and IT developers are considered as “partners” instead of unrelated units – is an effective way to break down the barriers between them. This is because an enterprise whose culture is based on DevOps is one that can help IT personnel provide organization with the best possible software with the least risk for glitches, hitches, or problems. Therefore, a DevOps-based organizational culture is one that can foster an environment where segregated business units can remain independent but, at the same time, work very well with others in order to optimize the organization’s efficiency and productivity.

––––––––

DevOps Venn diagram

––––––––

Key Principles

One characteristic of DevOps is that it isn’t grounded or dependent on stringent processes and methodologies. It’s based more on key principles that allow an enterprise’s key business units to efficiently work together and, in the process by breaking down any “walls” that may prevent optimal working relationships among such units. These key principles that guide an enterprise’s DevOps are culture, measurement, automation and sharing.

Challenges Solved By DevOps

Just before the development of DevOps, it took several teams to collate the necessary data and informational requirements as well as writing code. After that, another team – a QA team – performed tests on new codes in a separate software development environment once the necessary requirements were met. Eventually, it’s the same QA team that releases the new code for deployment by the enterprise’s operations group. After that, the deployment teams are divided further into groups referred to as “silos” which include database and networking. And if you consider all the teams involved with the development and deployment of just one code, you won’t be surprised why many enterprises suffer from project bottlenecks.

With such a set up, several undesirable things happen. One is that developers often become unaware of roadblocks for Operations and Quality Assurance that may keep the new programs from working as they were designed to work. Another thing that may happen is that as the QA and Operations teams work on so many features of the program, they may not have a true understanding of the purpose and value of the programs that are being developed/tested, which may keep such teams from effectively doing their work on such programs. Lastly, inefficiency and unnecessary backlogs are highly probable given each team or group has their own goals and objectives to achieve, which often times oppose those of the other groups, as well as the tendency to absolve themselves of responsibility for things that go wrong.

With DevOps, these potential problems can be addressed via creation of cross-functional teams that collaborate and share a common responsibility for maintaining the systems that are responsible for running software and other programs, as well as for prepping up the software so that they run on said systems with excellent feedback mechanisms for possible automation issues.

A Typical Scenario That Illustrates the Need for DevOps

Imagine that an enterprise’s development team (the Dev team) releases a new program “over the wall” to Quality Assurance – the QA team. At this point, the QA team assumes the responsibility of discovering as many errors as possible in the new program, if any. Without any good working relationship – or any relationship at all for that matter – chances are high that the Dev team will be very defensive about the errors found by the QA team on their newly developed program, especially if there are lots of them. At which point, it’s highly possible for the Dev team to even blame the QA team for such errors or bugs in the program. Of course, the QA team will deny that it’s them or their testing environment that’s to blame for the errors or bugs and that at the end of the day they’re just there to discover bugs that exist within the programs developers create. In other words, the QA team will just revert the blame for the errors back to the Dev team. It can become nasty.

Let’s say, after several attempts, the bugs and errors were fixed and the program has fully satisfied the QA team. They now release the program to the operations team concerned, a.k.a., the Ops team. But the Ops team refuses to fully implement the new program because they feel that too much change too soon will hamper their ability to do their jobs effectively. So they limit their system’s changes. As a result, their operating system crashes and blames the Dev team for it, notwithstanding the fact that their refusal to implement the system fully led to the crash.

Defending their honor and glory, the Dev team blames the Ops team for not using the program the way it is designed to be used. The blaming continues on for a while until finally, someone has the sense to intervene and eventually lead the teams to cooperate their way into fixing the program. But the delay and the losses were already incurred.

The Continuum

One very practical way to look at the various DevOps aspects is to use what’s called the DevOps continuum. The vertical axis represents the 3 delivery chain levels of DevOps, which are continuous integration (lowest level), continuous delivery, and continuous deployment (highest level). The bottom horizontal plane or axis represents people’s perceptions of what DevOps is focused on, where the left side represents an automation or tools perspective while the right side represents a culture perspective. Others feel strongly that DevOps must be focused more on culture than tools while for others, it’s the other way around.

––––––––

The ideal location is the upper right hand corner, i.e., continuous deployment under a cultural perspective. Organizations that are located at this part of the continuum are considered as endangered species or unicorns simply because they’re few and far in between. Very good examples of these “unicorns” include Etsy, Netflix, Flicker, Amazon, Google and Pinterest.

Bloggers, coaches and some thought leaders usually paint a DevOps picture that’s located on the upper right corner of the continuum. They may also have a strong bias towards either tools or culture. While it’s not necessarily bad to have robust debates or discussions as to which is more important (tools or culture), the fact remains that organizations need both in order to optimize their productivity. Culture won’t be productive without the necessary tools and tools won’t work properly without the support of a very good culture.

It’s important for organization to realize that moving up to the DevOps Nirvana spot in the continuum takes time. Many times, the first move is to combine tools, culture and continuous integration, which is at the lower wrung of the continuum. It shouldn’t be an issue because DevOps isn’t a very simple and easy activity and as such, it takes many baby steps and some time to maximize.

An optimal DevOps may be diffe...

Table of contents

• Title Page
• Also By Stephen Fleming
• DevOps: Introduction to DevOps and its impact on Business Ecosystem
• Introduction
• What Is DevOps?
• The DevOps Evolution
• The Agile System and DevOps/CD
• Scrum
• Kanban
• Kanban versus Scrum
• Organizational Culture Change for DevOps Success
• DevOps Ecosystem and emerging trends
• DevOps Success Stories
• Conclusion
• Sign up for Stephen Fleming's Mailing List
• Also By Stephen Fleming
• About the Author