DevOps took root amid a variety of IT headaches over the past few decades:
Unsatisfactory customer service
Trending business methodologies, such as Agile and Lean, brought DevOps into focus in 2008, and its popularity is increasing thanks to its focus on the day-to-day pain points touching all layers of IT.
At the Agile 2008 conference in Toronto, two software developers, Andrew Clay Shafer and Patrick Debois, discussed “Agile Infrastructure,” and the term “DevOps” soon after was popularized through a series of “DevOps Days,” starting in 2009 in Belgium.
Common DevOps Myths
The DevOps movement rapidly accelerated across IT organizations. However, much like other hot trends, DevOps also sowed confusion and disagreements among IT professionals:
Myth #1 - DevOps is a skill.
Myth #2 - Automation is DevOps.
Myth #3 - DevOps is a technology movement for modern systems.
Myth #4 - DevOps is just for development and operations.
Myth #5 - DevOps is cultural shift.
Myth #6 - DevOps is multiple daily deployments.
Myth #7 - Adopting tools makes you DevOps.
Myth #8 - DevOps is using “the cloud.”
While there appears to be a growing DevOps consensus, there is certainly a need to have a single view that combines all aspects. By taking a “360 Degree View,” we will attempt to bring all DevOps dimensions together in the drive to a Lean IT.
“360 Degree DevOps” focused on four major stakeholder groups, identifying their pain areas, needs for improvement and expectations while designing a robust solution.
Let’s look at every group separately to identify what today’s IT needs.
Dimension 1: Customer
First element in DevOps enablement is to understand the needs of customers and figuring out solution for them. Key take away here is to use customer feedback to drive your DevOps movement.
Dimension 2: Business
The very first question we should ask is, “does every business need to end-to-end automation?”
DevOps is a fuel to drive “Lean IT” which is constantly evolving.
Example: Imagine your organization as a vehicle—it can be a small or big car; the key to this vehicle is your organization’s culture and core values. The driver? Your development methodology.
Here, “DevOps Maturity” is a type of fuel for your vehicle that will be a factor in speed, efficiency and up-time.
Design right blend of DevOps strategy to achieve desired speed.
Selecting the appropriate DevOps “fuel” is critical to achieve top performance; not every fuel is right for every vehicle.
The level of automation with tooling is directly proportional to the needs of an organization. Don’t run behind the fancy tools and automation techniques just because other companies are doing so. Think wisely: is it going to add value for my organization?
Dimension 3: Development
With Development, your focus is not on changing the way developers work in their comfort zone. Developers already invest a lot of time in mastering their text editors, learning shortcuts and developing a flow that works for them.
However, your prime focus area is on automating tedious manual build and deployment activities in a principled way to make developers’ lives easier. Good practices and processes needs to be embedded with right set of tools.
In traditional development models, validation can take weeks or even months. By that time, the developer has already moved on to different tasks and may have forgotten the details of the changes. So, how to reduce this timeline to days, or even hours, instead?
Dimension 4: Operations
DevOps is popularized as a bridge to make developers and IT operations work closer together, ensuring that the wall of conflict between them is removed. DevOps culture means they both instantly evaluate the scope of the entire system and assess the impact of those changes.
As I mentioned earlier, there’s a growing DevOps consensus, but still a pressing need for a single view combining all aspects of DevOps.
Now, if we bring all above aspects together then we can have single dimension view of “DevOps House.”
Enabling DevOps is generating a lot of buzz in the market.
Unfortunately, there isn’t any benchmark or the same level of understanding, or even a common definition for DevOps. Based on my experience over recent years, key capabilities for DevOps Enablement are listed below.
Most of the time, you won’t find a single picture capturing basic aspects of every DevOps capability. The image below offers a good example of how to tie all these threads together.
It’s very common that teams get confused about how the new world is going to look. It is just one click, and most of things are done. But, what exactly is happening in the backend?
There are two typical cases of DevOps enablement:
Case 1: Fresh Start - Setting up DevOps strategy for fresh new organization/environment, starting from scratch to build up a new world that’s very straightforward.
Case 2: Common Scenario - Established Organization transitioning into new model, where you need to study existing processes and transform them into the new world.
By focusing on these four major stakeholder groups, you can get a “360 degree of DevOps” to further your journey toward Lean IT.