Ten years ago, IT organizations could choose from a plethora of tools that would monitor the runtime environment, alert ops teams, and tell you just about anything. But there was little available if you wanted to remediate those problems in an automated way. Recently, this has begun to change dramatically.
One reason why enterprise automation has taken such a front-and-center position is that the complexity of enterprise environments has grown exponentially. You have an untold amount of data you didn't have to deal with 10 years ago, with data coming in from on-premises resources, public cloud, private cloud, hybrid cloud, and more. If IT organizations don't start to automate some of the tasks associated with these environments, they will be overwhelmed with errors and face relentless pressure from the business. You need to focus precious human resources on creative problem-solving and automate everything you can within the software development, deployment, and feedback cycle.
Gartner has a helpful way of explaining the change, in terms of what it calls Mode 1 and Mode 2 organizations. Mode 1 emphasizes stability, while Mode 2 is more exploratory, emphasizing agility and speed. If you want to remain competitive, Mode 2 is where you need to be; it's where your IT teams have the bandwidth to explore and exploit new opportunities for the business. And this is also why Mode 2 is an "automate or die" scenario. Where formerly automation was considered by many organizations as optional, today automation is a must-have.
Beyond kicking the DevOps tires
Ideally, DevOps helps you deliver software according to the agile requirements of the business itself, as with the ITIL, IT service-management movement from 15 years ago. The experts said people needed a different framework, a different way to solve these problems because ad hoc methods were not producing the right outcome.
Over the past two to three years, there's been a tremendous rise in the acceptance of DevOps practices and the understanding of their value. Organizations are generally past the stage where they're trying to get their heads around requirements for agility. Now I hear more organizations asking questions that are further along the adoption curve: "We need help in executing. What are the best new practices around DevOps?"
This was the big difference I saw at the DevOps Enterprise Summit (DOES) in October, where over 1,200 people were no longer just kicking the DevOps tires, but fully on board and adopting the principles of agile delivery. They were deep into execution. This is where automation vendors come in, whether you're working on an open source project or with a commercial enterprise software vendor. Neither is likely to be the "evangelists" around DevOps and its benefits. You either have to be there and ready for that, or consultants can help you as you get further into your DevOps organizational transformation.
Why the heavier interest from the dev side?
The benefit of DevOps comes from the top of an organization, but the DevOps movement itself seems to be grass roots—and from the dev orgs more than the ops side of the equation. At the DOES conference, I estimate that 70 to 80 percent of the participants in the conversations and presentations I attended represented dev. But this will soon shift to about a 50-50 split between dev and ops. After all, ops teams are the control mechanism, and they can't let the dev teams define most of the practices around the DevOps movement!
All kidding aside, there's a practical reason for this heavier interest in DevOps among developers. It reflects the current pressure on dev teams to attain an unprecedented pace. That pressure leads to a big worry: Release a software bug into the world, and it can cost you exponentially more money than catching it during the development cycles.
Just in the past year, systems at The Wall Street Journal, United Airlines, Starbucks, and other major corporations have gone down. In Starbucks' case, it rolled out updates to its point-of-sale terminals that took down its ability to process transactions; it ended up giving away free coffee for a day. If you're on a development team that just rolled out those kinds of problems, you're living your worst nightmare.
Yes, there's a shared responsibility here, but the onus is on the development team to not let bugs roll out. Automation helps you create a framework, beyond the mechanics, for implementing the changes that development and operations must go through via a tool set. You decide what you want to do organizationally, but then enterprise automation lets you see how the software in development moves through the tool chain and the pipeline. That's where the rubber meets the road.
Open source and DevOps
There are many open source tools out there, many of which developers have become quite comfortable with. As an enterprise software vendor, our objective is to embrace and extend those capabilities. No one who's truly promoting DevOps is likely to take a "my way or the highway" approach. So we integrate with Puppet, Jenkins, Chef, and other tools.
There's a clear place and a role for those tools. Devs like to program, and they love the ability to see the source code for the tools they use and contribute back to the community. That's healthy. But when you're rolling out highly visible, production-ready, customer-facing software to an enterprise, there's a point where you want to do something that can truly scale. People are not choosing open source tools for that.
When you're pushing out code to thousands, maybe hundreds of thousands, of users, you want hardened, reliable software. I realize this sounds self-serving, but if it weren't the case, we wouldn't be in business. We just surveyed 200 customers and asked specific questions, such as "Would you consider using open source tools for your production environment?" Only a single-digit percentage said yes. Ops teams tend to avoid using open source in production environments.
But I want to be clear. The open source movement is vital to the overall growth of DevOps. And as vendors on the packaged application side, we need to integrate with the tooling environments our clients present us, to integrate and extend them as our clients' needs and capabilities grow.
Different use cases, different cultures
We tend to think that cloud isn't appropriate for certain use cases or customers, like banks or investment houses. But take a look at Amazon, Google, Microsoft, VMWare. These businesses are making enormous investments in the cloud space while working to make the cloud, both public and private, part of a full, enterprise-hardened infrastructure. They need that infrastructure to be acceptable for the majority of their customers very soon.
I do see different rates of adoption in cloud computing and DevOps between the US and Europe. The US has led on this, which may not be so surprising. Europe, in general, is just a little more risk-averse. Europeans require more rigors around reliability and quality, and insisting on caution as a primary concern works against the whole notion of agility.
But over the past six months we've seen our own European customers moving toward the "time to execute" mode with some of the same eagerness I found at the DOES conference. I think it's because they are accepting what they're hearing out of the US, and what I believe we'll see is a structured, managed rollout of DevOps that will be right for that market.
A natural extension of agile
DevOps is a natural extension of the agile movement—except much more of the business is pushing you along, and customers are providing feedback much more rapidly than with the agile practices of 10 years ago.
Gone are the days when you simply rolled out apps with thousands of lines of new code, then began your next six-month or annual release cycle. Now, unless you're linking the apps back up to the business service you're trying to deliver and the data pool around that service, you're missing the boat. The most successful businesses are delivering smaller apps more frequently, paying close attention to the data that results from those deployments. And they are finding that automating as many parts of this cycle as possible can help.
DevOps is the essential reason behind the broad enterprise automation story we see evolving. The use of automation is going to grow over the next five years, especially as DevOps practices proliferate, and cloud adoption continues to accelerate.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
