There are a lot of DevOps myths floating around the IT world. That’s not surprising, given how much hype the term — a combination of “development” and “operations” — has built up in the past few decades.
DevOps is more than worthy of the hype. When done properly, the DevOps approach can deliver massive positive impact for businesses. It can reduce costs, improve performance and break down silos between teams.
To understand the power of this approach, however, it’s important to know what DevOps is and what it is not. Let’s start by correcting six common DevOps myths.
It’s true that DevOps mostly started at companies that were born on the web. Maybe that’s why people get the idea that this methodology will only work at internet firms such as Netflix or Etsy. That idea turns out to be a myth.
Large enterprises have been successfully using DevOps principles to deliver software for decades.
The name DevOps clearly reveals the origin of the approach. DevOps started as a better way for operations and development teams to work together.
Today, the approach can empower the entire organization. Everyone involved in the delivery of software has a stake in this methodology.
Regulated industries have an overarching need for checks and balances, as well as approvals from stakeholders. This doesn’t mean DevOps is a problem, however.
Adopting DevOps actually improves compliance, if it’s done properly. Automating process flows and using tools that have built-in capability to capture audit trails can help.
Of course, organizations in regulated industries will always have manual checkpoints or gates, but these elements can be compatible with DevOps.
When many people think of DevOps they think of cloud. There is a good reason for this. Cloud technology provides the ability to dynamically provision infrastructure resources for developers and testers to rapidly obtain test environments without waiting for a manual request to be fulfilled.
That doesn’t mean cloud is necessary to adopt DevOps practices, though. As long as an organization has efficient processes for obtaining resources to deploy and test application changes, it can adopt a DevOps approach.
Virtualization itself is optional.
Operations teams have a long history of writing scripts to manage environments and repetitive tasks. With the evolution of infrastructure as code, operations teams saw a need to manage these large amounts of code with software engineering practices such as versioning code, check-in/check-out, branching and merging.
Today, operations teams can create a new version of an environment by creating a new version of the code that defines it. This doesn’t mean, however, that operations teams ,must learn how to code in Java or C#. Most infrastructure-as-code technologies use languages such as Ruby, which is relatively easy to pick up for people who have scripting experience.
This myth is totally off-base. The opposite is actually true: complex systems often require the discipline and collaboration that DevOps provides. Large systems typically have multiple software or hardware components, each of which has its own delivery cycles and timelines. DevOps facilitates better coordination of these delivery cycles and system-level release planning.
To understand the power of this approach, however, it’s important to know what DevOps is and what it is not. Let’s start by correcting six common DevOps myths.
1. DevOps is only for shops born on the web.
It’s true that DevOps mostly started at companies that were born on the web. Maybe that’s why people get the idea that this methodology will only work at internet firms such as Netflix or Etsy. That idea turns out to be a myth.
Large enterprises have been successfully using DevOps principles to deliver software for decades.
2. DevOps only matters to engineering and operations.
The name DevOps clearly reveals the origin of the approach. DevOps started as a better way for operations and development teams to work together.
Today, the approach can empower the entire organization. Everyone involved in the delivery of software has a stake in this methodology.
3. DevOps can’t work for regulated industries.
Regulated industries have an overarching need for checks and balances, as well as approvals from stakeholders. This doesn’t mean DevOps is a problem, however.
Adopting DevOps actually improves compliance, if it’s done properly. Automating process flows and using tools that have built-in capability to capture audit trails can help.
Of course, organizations in regulated industries will always have manual checkpoints or gates, but these elements can be compatible with DevOps.
4. You can’t have DevOps without cloud.
When many people think of DevOps they think of cloud. There is a good reason for this. Cloud technology provides the ability to dynamically provision infrastructure resources for developers and testers to rapidly obtain test environments without waiting for a manual request to be fulfilled.
That doesn’t mean cloud is necessary to adopt DevOps practices, though. As long as an organization has efficient processes for obtaining resources to deploy and test application changes, it can adopt a DevOps approach.
Virtualization itself is optional.
5. DevOps means operations learning to code.
Operations teams have a long history of writing scripts to manage environments and repetitive tasks. With the evolution of infrastructure as code, operations teams saw a need to manage these large amounts of code with software engineering practices such as versioning code, check-in/check-out, branching and merging.
Today, operations teams can create a new version of an environment by creating a new version of the code that defines it. This doesn’t mean, however, that operations teams ,must learn how to code in Java or C#. Most infrastructure-as-code technologies use languages such as Ruby, which is relatively easy to pick up for people who have scripting experience.
6. DevOps doesn’t work for large, complex systems.
This myth is totally off-base. The opposite is actually true: complex systems often require the discipline and collaboration that DevOps provides. Large systems typically have multiple software or hardware components, each of which has its own delivery cycles and timelines. DevOps facilitates better coordination of these delivery cycles and system-level release planning.
Posts
0 comments:
Post a Comment