Steve Brodie

What I want to talk about today in this session is the trends and predictions that we see for DevOps, particularly in the enterprise.

Some of the things I'm going to share with you are things that we've gleaned from our team members at Electric Cloud, from working with a number of prospects and customers on their DevOps implementations. Also, some data from some of the industry analysts that cover the DevOps space, and finally, from some of the industry thought leaders and authors that some of you guys may know.

Before I go into that, I want to provide just a brief introduction to Electric Cloud. Who's heard of Electric Cloud? A few of you. Okay.

Electric Cloud, as some of you may know, we're actually the co-founder of the DevOps Enterprise Summit. We partnered up with Gene Kim a couple of years ago, and we created the inaugural DevOps Enterprise Summit in San Francisco. We saw a gap out there for DevOps events that would target the enterprise.

Electric Cloud, we've been in business since 2002, and our mission is to help the world deliver better software faster. That's been our mission from the outset. So for 15 years, we've been working predominantly with large Global 2000 companies to help them deliver better software faster, accelerate their release cycle times as one of the primary benefits.

The positioning for our solution, we describe it as DevOps release automation. What we do is we automate and we accelerate the software delivery process from the time a developer checks in the code, through the build, through the test, deployment into all the environments along the path to production, all the way to production release. And we orchestrate all the tools in the toolchain along the way.

That's a little bit of the background of what we do. We work with a number of customers on this front, and that's some of the basis that we have for some of the predictions that we make.

Also, it's worth noting, I mentioned that some of the information we'll provide is from some of the industry thought leaders. We have as strategic advisors for our company Gene Kim, who I already mentioned. We've been working with Gene Kim as an advisor for several years. Again, we co-founded the DevOps Enterprise Summit.

Gary Gruver has been a longtime advisor to the company. He's written a couple of books on how do you do Agile and how do you do DevOps at scale. He's actually done this at HP. He's done it at Macy's, and he's consulted with a lot of companies.

And then yesterday, we announced two additions to our strategic advisory board, two folks that are here. Dr. Nicole Forsgren. Dr. Forsgren is a leading IT metrics and DevOps researcher. She is the primary researcher on the State of DevOps report that comes out annually. Electric Cloud sponsored it this year. So this year, it's sponsored by Electric Cloud and Puppet Labs. We're really excited to be working with Nicole, as metrics and measurements are such a key aspect of DevOps.

And then we also added John Willis. Some of you may have seen John Willis' talk yesterday. John is an evangelist at Docker. He's an expert in microservices and container systems. He's also one of the co-authors of The DevOps Handbook.

Okay, so to kick this off, one of the things I want to talk about is just the overarching trend that we see around DevOps adoption.

What started back in 2008 at Agile 2008 and DevOpsDays 2009 as a set of discussions around how do you break down the silos and the barriers between dev and ops has really evolved. Now you're seeing mainstream adoption of DevOps if we roll forward to 2017, and we roll forward eight years. We're seeing adoption not just amongst what used to be Netflix and Etsy and Amazon. It was these California companies that are out there. We're starting to see broad adoption in the mainstream.

I think if you just look at the number of attendees here, we talked about it before. If you looked at last year when we did DevOps UK, we had 300 people in the room, and now we have 600. So I think that's a testament to the adoption and the interest in DevOps in the enterprise.

So what are some of the reasons for this?

I think if you look at it, one of the key drivers for this is we live today in a world where there's a very dynamic, highly competitive marketplace. It's a world in which new companies can come in with new business models powered by technology, powered by software, and it has the ability to create or destroy billion-dollar businesses.

Just a few examples that you can see here. If you look at the retail sector, Amazon came in and radically transformed the retail sector with an e-commerce platform that was powered by technology, powered by a logistics platform, and has really impacted basically the entire retail sector and has forced a lot of brick-and-mortar retailers to respond there. And I think the evidence that Amazon is really a technology company under the covers is the emergence of AWS. They've exposed the platform under the covers. So that's really a technology-driven disruption.

If you look at Apple, obviously what they've done in the phone sector is impressive. If you look at the music sector as well, with the introduction of iTunes and the ability to buy songs for $0.99, it's changed the way that we buy music. You don't go to the record store, you don't go buy CDs anymore. Again, that's technology-powered disruption.

Uber, of course, some people love it, some people hate it. I know here it's been some issues recently with it. But if you look at the taxi industry, it really didn't change for a long time. With the advent of a handheld app where you could request a car, you could have seamless payment, and there's a back-end service to dispatch the drivers and to process the payments on the back end, it radically transformed this industry. It's not going to be the same ever again.

Those are what Gene would call unicorns. Unicorns are these technology companies, West Coast-based. They've architected things up, newer companies with a new way of doing things.

GE, longtime company, very, very large industrial conglomerate in the US, they see themselves as disrupting themselves. One of the reasons they've stayed around for so long is they're able to disrupt themselves. There was a quote from the CEO of GE, Jeffrey Immelt, in 2012, and he said, "You have to be paranoid of other software companies." They said, "We run the risk of getting disintermediated by a software company coming in and disrupting our business."

In response to that, GE decided to create a software center just outside of Silicon Valley. They invested a billion dollars and put in a software center in San Ramon to support software development across their entire organizations. That's how important GE saw software. And GE, you really think of as an industrial company: wind turbines, airplane engines, things like that. So it's pretty amazing that they see software disrupting their business.

Business disruption is rampant. If you look at this chart, this is from a survey report that was done back in 2012, and it looks at the tenure of companies that are on the S&P 500. If you go all the way to the beginning, the report started in 1958, the average tenure of a company on the S&P 500 was 61 years. If you roll forward to the 1980s, it was 25 years. If you roll to today, you look at 2017, it's just shy of 20. And by the end of 2030, it's estimated to be 10 years is going to be the average lifespan on the S&P 500.

So by 2030, 75% of the S&P 500 is probably going to be new companies. A lot of this change that's happening is really powered by technology. It's by new companies coming in and having new business models that were powered by technology, powered by software. This is why it's very important for existing companies to respond to what's going on here.

This spans all verticals. There's the quote by Marc Andreessen. Marc said that, "Software is eating the world." He was saying software is going to affect pretty much every industry out there.

This is from an article that was in the Harvard Business Review, and they surveyed 2,000 C-level executives. The percentages that are here is how many of you think that digital has the ability to massively or moderately impact your business? You can see here, with the laser pointer, 72% media, telecom 64%, consumer financial 61%. But even as you go down, you can look at all of these, and almost all of them are 40% and above. So this digital disruption is affecting everyone, and this is something that's on the radar screen of C-level executives, probably executives at your organizations as well.

As Charles Darwin wisely noted, it's not the strongest, it's not the most intelligent that survive. It's really those that are most adaptable to change. So for those of us in the business and the IT world, it's important to sense what's going on in the marketplace, what's happening in our environment, and be prepared to respond to that, thinking of new ways that we can become competitive and support the customers, and how you leverage technology to do that and be able to adapt quickly to support some of those new business models and where the business needs to go.

If you don't change, there's an immediate financial cost to not changing. These are some stats from an IDC report, and it was, what is the cost of failures?

On average, and this is for the Fortune 1000, so the top largest companies. For infrastructure failure, it's estimated the average cost is $100,000 per hour. Now, if you have a critical application that fails, it's even higher. It's a half a million to a million dollars per hour of cost on average. Looking across the entire Fortune 1000, it's estimated that the cost of downtime per year is $1.25 to $2.5 billion per year.

I think some folks here may have heard of the British Airways incident that happened recently. The costs there were probably pretty staggering. Probably a lot of people were impacted, customer satisfaction, reputation, a big impact. So beyond the financial, there's other impacts as well in terms of the direct financial costs.

Now, on the other hand, people that have employed DevOps, people that are high performers that embody the DevOps principles, that follow the DevOps approach, see significant benefits. I think Gene talked about some of these stats before. This is from Puppet. This is from the State of DevOps report that was published last year that Nicole Forsgren helped put together.

High performers have 200 times more deploys than average or low performers, 24 times faster mean time to recovery, 300% lower change failure rate, 2,555 times faster lead times to deliver changes. Obviously, in terms of responding to the business, satisfying the customer, that's very important.

What's really interesting is on that cost of downtime, there was another chart that's here. It's probably kind of hard to read here, but it looks at high performers, the cost of downtime, medium performers, and low. For a high performer, the cost of a downtime incident was on average $37,500 per incident. For medium performers, 4.6, and 2.8 for low performers. Kind of interesting here that the medium performers have a higher cost, but the driver for this is the ability to fix the change.

So if you have a deployment that fails, if you're doing DevOps and you have small batch sizes, it's much easier to fix it forward, and it's much easier to roll it back, so you can respond much more quickly with that mean time to recovery. DevOps not only helps you deploy innovation faster, but it helps you respond when you do have incidents, so you don't have a BA type of incident. You can respond quickly.

Okay. So I talked about the overarching goal around DevOps adoption, what some of the drivers are for it. Now I want to drill down and talk about some trends.

I want to talk about some predictions in three categories. I want to talk about the nature of DevOps adoption, how people are adopting DevOps. I want to talk a little bit about the trends that we see around tools and technology. And then finally, organization, culture, process. We'll drill into that area as well.

DevOps adoption. This dovetails with what we were talking about before, and this is another IDC report. It follows along to one of the other ones.

By the end of 2017, two-thirds of CEOs of Global 2000 companies will have digital transformation at the center of their corporate strategy. So we talked about C-level executives being aware of the risk of digital disruption. I think this is evidence of that. And if you look at this, this is not saying CIOs, this is saying CEOs have digital transformation at the center of their, not their IT strategy, but of their corporate strategy. So again, C-level executives are recognizing you have to do something here.

The Global 2000 adoption is picking up pace. To survive and to thrive in this digital transformation world, you have to adopt things like DevOps. It's no longer enough to just develop things faster in Agile, you have to deliver it to the customer faster. You have to break down some of those silos. It's not just for the unicorns.

Again, I talked about the evidence in this room of growing from 300 people to 600 people. We do the same event in San Francisco. We did the third annual San Francisco event in November of last year. We had 1,300 people in the room. We had 500 enterprises represented. We had 50 sponsors. So this is a huge movement. It's a huge movement that's being adopted by the enterprise.

So if your organization is not looking at DevOps, is not looking to adopt it, you can be pretty sure that some of the competition is out there looking at this and looking to adopt it.

Okay, so in terms of enterprise adoption, it's one thing for Google and Facebook to do this. It's a little bit different for a traditional enterprise to do DevOps. You've got some unique needs, you've got some unique requirements that are out there.

You've got legacy systems. You may have mainframe applications, you may have old monolithic applications. You may be leveraging microservices. Regulatory demands. If you're in the financial services sector, the healthcare, government sector, you've got compliance and regulations that you have to address. Hybrid architectures, growing security risks. Digital attacks, hackers trying to get into the system is increasingly an issue.

Shared services. In many large organizations, you don't want to develop it differently for each business unit. You may want to have a shared service that you propagate to be more efficient in how you do it.

Have to support this at massive scale. Myriad tools and integrations. I was working with a very large telecommunications company, and for one software delivery pipeline, they had 57 different tools in that pipeline to deliver that application. So how do you support all those tools and integrations?

What we're seeing is, in the early days of DevOps, companies like Facebook would build this on their own. They would go out and develop it. But enterprises, they're looking for enterprise-ready solutions. They want to look for solutions that have been proven out there that can address some of these needs that many organizations don't have.

The other trend that we're seeing is application release automation is becoming the hottest segment of DevOps.

There's a lot of buzz about DevOps as it emerged and, when you have these red-hot spaces, it's kind of like cloud 2007. Everyone jumps in, everyone has a DevOps solution. Everyone had a cloud solution. It makes it very confusing. Some vendors may give the impression that it's a silver bullet and they can solve all your problems for you. It becomes confusing in terms of what's there.

But as enterprises have started to do this, as companies have started to do it, the types of tools and technologies that you need to be successful, what's actually working out there, is becoming a little bit more evident from people that have begun to do this.

This is from Gartner. This was actually in 2015. They did a survey of 338 IT business leaders, and they said, "Which of the following technologies have been most important to your adoption of DevOps?" So effectively, what are the ones that are providing the most value?

It's interesting here because release automation was cited by 60% as the most important technology. Obviously automation is very important, so it's not surprising to see testing here, 51%. There's some other things, IT operations, APM is certainly important. Infrastructure as code, if you think of things like Puppet, Chef, and Ansible, that's key. That's a key enabler that you have to have to be able to configure your infrastructure. But pretty low here.

Where the value really comes in is being able to accelerate the release, improve the cycle times of your application delivery, and that's where you get the most bang for your buck here in terms of release automation. So it's no surprise that this is one of the fastest-growing segments.

Again, from Gartner report, they said of the Global 2000, they expect 50% of Global 2000 enterprises to adopt application release automation by the end of 2020. They estimated that in 2016, 10% of enterprises had adopted ARA in some portion of their business, some percentage of their applications. That means 40% of the Global 2000 is going to be adopting ARA over the next two and a half, three years. So that's pretty incredible.

All the major analysts have started covering this: Gartner, Forrester, Ovum, IDC. You name the analyst, they've started covering application release automation as a sub-segment of DevOps.

If you look, Gartner recently published, back in August of 2016, they published the inaugural Magic Quadrant for application release automation. Forrester has done a vendor rating out there. IDC has done a vendor rating. I'm going to do a little bit of bragging as the Electric Cloud CEO. I'll delve into that.

We're very honored to be the leader in the Magic Quadrant report with the highest score on both the vision and the execution axes for application release automation. So if this is something that you are looking at, I would definitely encourage you to look at Electric Cloud and perhaps visit us in the booth.

Okay, so we talked a little bit about the nature of DevOps adoption. It's about enterprise application release automation being one of the newest emergent sectors that's a pure-play DevOps segment.

I want to talk a little bit about tools and technologies at this point and what we're seeing on that front. I would say probably the biggest trend that we're seeing by far is the rise of microservices and containers. There's not a customer that we go in and work with that aren't starting to adopt microservices and containers, aren't embarking on trying to figure out the strategy around microservices and containers.

Microservices are very well suited for DevOps. If you look at microservice, they're smaller, well-contained services with well-defined interfaces. The idea here is that with the microservice, because it's isolated, well-defined interfaces, you can more rapidly deliver them. You can improve the cycle time without risking breaking the broader system.

If you look at containers, containers are the ideal deployment vehicle for microservices because they're designed to run one process and run it very well with minimal deployment and runtime overhead. So it's ideally suited.

Certainly you can do microservices without deploying on containers, and certainly you can employ containers without leveraging microservices, but they do go hand in hand. In the US, we call this the PB&J, the peanut butter and jelly of DevOps, but I think here it's maybe the bangers and mash, and I'm sure there's some other analogy we can use on the continent here.

If you look at what enterprises need for microservices and containers, there's a couple things that we see from talking to the customers and talking to the prospects that we work with.

The reality, I talked about big companies having a portfolio of applications, and so you may have some traditional applications that are components. Maybe there's some mainframe apps. You have to continue supporting those. You may be doing some new projects on microservices that are pure-play microservices, built from the ground up, brand-new application, entirely microservices and containers.

But the reality, what we see very often is people are refactoring their existing applications. You're taking an existing multi-tier application, you're identifying some things that you can carve out as microservices, and you end up having a hybrid architecture out there. So what you need to look for in a DevOps tool is solutions that support containers, that support microservices as a first-class citizen, along with supporting the traditional application models as well.

Now, when you go through this-- Oops. Jumped forward there a little bit. When you go through this, you still have a pipeline. So working with containers and microservices, it doesn't change the need for having a delivery pipeline, but it changes the nature of how it works.

Instead of redeploying all your components in every environment as you move along, you're basically moving that container, that microservice that's implemented in a container, through that pipeline. Again, you need to be able to move that thing through the pipeline. You need to be able to do all the automated testing on it. There's a different set of testing tools, different set of security validation tools. But fundamentally, the process is the same.

One other unique requirement that we see here is, just like DevOps is hot, the container market is red-hot as well. Again, it is a very dynamic, very fast-changing market out there. Certainly Docker has become the standard in terms of how you develop containers. But in terms of the runtime, the clustering, the orchestration environments, there's a lot of flux in that market.

You had Mesosphere, you got Kubernetes, you've got Google Container Engine, Microsoft's in the game, Amazon's in the game there as well. There's ability to deploy this in the cloud. A lot of people want to put this in the data center.

How do you make decisions here? Every one of these is actually unique. If you look at how you set up pods and replication and configure your clusters, it's all different. So how do you make a bet? Do you really want to invest on one of these with the risk of it changing downstream?

Ideally what you can get is a solution that's future-proofed, a solution that will allow you to easily switch from one platform to the other as one rises and falls. If a new runtime platform becomes the emergent leader, you want to be able to quickly switch to that.

Again, this is something that we've focused on pretty heavily based on what we're hearing from our customers. We've invested heavily in microservices and container support. We have it as first-class citizens, and we have this supported too.

So when you get ready to deploy and you want to deploy with Electric Cloud, you can just hit a dropdown and you can say, "I want to deploy this to Amazon Container Service." Now, maybe in the next environment in production, maybe it's going to go to Kubernetes on-premise. It's just a dropdown. You click it. You want to go to OpenShift, it's just a dropdown. You click it.

We handle all the mapping for you, so you don't have to understand all the nuances of what you have to do for each deployment platform. So if containers and microservices is something you're looking at, something you're embarking on, you're struggling to figure out how to address some of these needs, again, I would encourage you to take a look at the ElectricFlow product in the booth.

The other thing that we're seeing, and again, this is a trend that has started, and I think it's just going to continue to accelerate, is this notion of shift left. It's really shifting left things that were traditionally done in operations, post-production, and verifications that are done late in the lifecycle. The idea here is let's do some of these things earlier in the lifecycle so we can identify issues, we can identify problems before they hit production.

Certainly what we're seeing is more automated testing. You saw that in the chart. Automated testing is much more important, and you're seeing much more continuous testing. Again, every time I make a change, obviously I want to do the unit testing. I want to go through my battery of functional testing, even more performance testing that I want to do in a more continuous basis.

It's important to look for tools that are designed for this. Some of the traditional tools that you see out there were not necessarily designed for the era where it's not manual testing, it's predominantly automated testing with very, very fast cycle times. So looking for tools that are optimized for this is pretty important.

Monitoring. Monitoring has traditionally been done in production, or perhaps you might do some monitoring when you're doing performance testing just before you release. Now you're seeing performance monitoring being done earlier in the lifecycle so you can identify performance degradations early on when you make a change.

Then the rise of service virtualization. With service virtualization, if you look at your system, one of the impediments that's traditionally been there is if you've got a lot of external services, if you have very expensive services externally, maybe it's a mainframe system, it's an external system where you have to pay per transaction, how are you going to do that?

Every time you make a change, you want to go through and you want to do some testing and validation, you're going to incur quite a bit of expense. So with service virtualization, it allows you to emulate those services. You can emulate this external system, you can emulate this mainframe call that's out there. You can go through and test your application and get some sense that it's going to continue to work with the environments and the services that it's integrated with.

Another shift-left activity that we're seeing is security and compliance. When we did the first DevOps Enterprise Conference and we asked people, "What do you think is one of the biggest inhibitors that's out there?" one of the things we always heard was security, was compliance, was one of the biggest issues. And that's not true. Security and compliance is something that should be folded in as well.

Again, what you want to see is that security verification, security scans, are something that you're actually doing as part of the delivery pipeline. Again, it's one of those shift-left activities that you do along the way.

We've had at the DevOps Enterprise Summit in the US, we had an auditor who works with Google, who works with Facebook, who do some of these techniques. They do continuous delivery. The reality is, he goes, "The auditors love it. This is great." He goes, "Because automation is compliance."

If you've got application release automation, if you've got a DevOps orchestration tool that's orchestrating the entire pipeline and you have traceability of everything, you've got an end-to-end trace here. The auditor can come in and see exactly what changed.

So security and compliance is not an impediment. Again, compliance gets built in when you have end-to-end automation, and security is something that you can do throughout the lifecycle.

The other thing that we're seeing is that customers are demanding integrations with some of the best-of-breed tools. As I talked about before, as DevOps gets adopted, there are leading tools that are emerging out there. You're seeing leading tools by category that we most commonly see.

This is what I call my DevOps matrix. You've got Dev on the left, you've got Ops on the right. We put the infrastructure on the bottom, and tools that are more oriented to the application layer. Down here, you've got your cloud platforms, you've got your configuration management solutions that help configure the infrastructure, and then here are the tools for developing, delivering, monitoring, and servicing your applications after you deploy it.

These are some of the tools that we most commonly see out here. This is not an exhaustive list. There's others that are emerging. There's others that are in the hall there. But these are the ones that we most commonly get asked to integrate with.

Again, Electric Cloud orchestrates the whole delivery pipeline, the software delivery pipeline, and these are the tools that we see. So we're starting to do strategic alliances with the likes of Dynatrace, integrating with ServiceNow, working with Splunk, integrated with Chef. We're partnering up with Microsoft and Amazon to make sure that we have out-of-the-box integrations.

When you're doing this in the small, developing these integrations one-off is okay. But when you want to propagate this across the enterprise, you really want your vendors to work together to have first-class, out-of-the-box integrations. And so this is something we're seeing with the rise of enterprise DevOps, is the demand for out-of-the-box enterprise-grade integrations.

Okay. The next prediction that we have here is predictive analytics.

If you look at it, the focus for DevOps early on has been around automation, and rightly so. It's been the siloed automation around test automation, around configuration management, and so forth. And then you saw application release automation. You saw software delivery, continuous delivery pipeline orchestration, really automating the end-to-end pipeline. But it was really focused on that.

Once you start orchestrating the pipeline, when you start tying together all these tools, you're gathering all this data. You're gathering logs, and you're gathering metrics from all of these tools. You can start serving it up, and looking at these data sets, and they're very actionable. You can even apply machine learning to it to get some insights into what's the health of my pipelines. Is there risk of a certain pipeline failing?

You can even start setting up policies based on characteristics that you see and say, "Would I potentially stop a pipeline run that's at risk of failure and causing some downtime in production along the way?"

Here's just a couple examples. If you look at Electric Cloud's solution, this is just a release dashboard. This is pretty basic. How many deployments have I done? You can filter this by applications. How many were successful? What are the trends in terms of frequency of deployments? What's the average deployment duration? How many have failed? Are they failing by environment? That's really coming out of the release process that you see.

But because all the tools are tied in together with this, the other thing you can do is serve up much more of a business metrics command center. Pulling data out of your Agile planning tools, pulling data out of Jenkins, pulling data out of some of the other automation tools, the test automation tools, you can see the progress for a particular application release, and you can see it holistically.

Again, now if you're sitting on the ops side, if you think of the train station analogy, I don't get to see the train when it arrives. I start getting visibility up the tracks. I start getting a board up there that shows me where the train is coming and what the status is, and what is the cargo on the train that's coming down the path. This is information that you should be able to provide.

Then again, you can start providing some analysis and some metrics. So you see here the example of a health score. What's the health score of this release? Is it going up? Is it going down? Is this something I should hold on this particular release?

Okay, so we talked about the nature of DevOps adoption. We talked about some of the high-level trends in tools and technology. I want to talk a little bit about culture, org, and process. It's last on the list, but it may be the most important.

I think one of the things that we'll begin to see is that culture truly is recognized as the DevOps differentiator. I think if you've been at this conference, if you've been at this community, you hear it all the time that culture is one of the key ingredients. It's the prerequisite. You can go buy the automation, but if you don't address the organizational requirements, if you don't address some of the cultural issues, you're probably going to not have as good of an outcome as someone that does address some of these things.

So this is just a sampling: shared responsibility, empowered teams, cross-functional teams, blame-free culture. A lot of those items that we've been talking about, and you've been hearing on Main Stage over the past couple days.

I'll tell you, we work with a number of enterprises, and we can go into the same vertical. I can go into two financial services companies in the same business. They can buy the same automation tool from us and have totally different outcomes. The difference is fundamentally the ones that have embodied this culture, have instilled this, and have cultivated this DevOps culture.

So it's not just lip service. Some people say, "Oh, I got to do the culture." This is critically important. And if you look at some of the failures that are out there in terms of early DevOps initiatives, a lot of times it'll come back to this. It's usually not that there's not automation tools out there to address it. These are some of the key factors. So this is very, very important.

Process. I think Gene mentioned a tweet yesterday on the main stage where it was a German company that says, "This DevOps looks great, but we can't adopt it because we haven't finished our ITIL implementation." So pretty funny here.

I think on this front, ITIL is certainly important. I think there's a lot of great principles in there, and there's been definitely some talks on how ITIL can work in a DevOps world. But fundamentally, what we see is that ITIL has to be adapted for this new accelerated and this new automated world.

One of the things that we expect to see is that perhaps pre-approved changes. If you have a change and it passes through all the automation verification thresholds, then it's pre-approved for change into production.

When you had change control boards, change advisory boards, you could do that with humans sitting around when you had releases every quarter, releases every six months. That doesn't work in a continuous delivery environment where you're delivering every week, even every couple of weeks, and certainly not if you're doing continuous delivery. So it moves much more to more of an auditing function.

The other thing that you see is how do you keep your CMDB populated? How do you keep all that up to date when you're moving at such a rapid pace? One of the things I think you'll see is, of course, much more discovery of CIs. But also, as your software delivery pipeline is creating CI items, those can be automatically populated into your CMDB. So these are some things that we expect to see on this front.

The other thing I want to talk about here is, if you look at this movement, it started, like I said, back in 2008, 2009 at Agile, the Agile Conference. It was a discussion about how do we break down the silos between dev and ops. But the philosophy is really bigger than that.

DevOps, it talks about two branches, but really what it's about is breaking down the organizational silos. It's about fostering collaboration across all the groups that need to work together to deliver a business outcome.

When you looked at Agile, Agile initially focused a lot on the business and development. How do you work and how do you deliver functionality? But there was the bottleneck of how do you deliver it into production? Ops really wasn't part of that Agile equation, and DevOps breaks that down.

We talked about Sec being InfoSec. You had these groups of InfoSec professionals. They're on the side, not really part of the delivery process. That's not going to work in this world where you're delivering faster and you have all this threat of digital attackers.

Really, we see it as it's not just BizDevOps, it's not DevOps, it's not DevSecOps. All of these items have to work together. You really have to break down the barriers across all of these silos. Again, this can happen in a phased approach, but this is fundamentally where you want to get to, to achieve the best business outcome.

And someone's probably looking at this and going, there's something missing on here. There's another functional loop here. This could be like a flower with other petals that come in there, and there's probably other things that you could add into this based on your organization and what's important.

So just to wrap up here, just in terms of some key takeaways.

DevOps at this point is no longer a fringe movement. It's become an existential necessity in many cases for many Global 2000 companies. Application release automation is the highest-value technology that people that have started adopting DevOps have seen.

Containers and microservices, they're here, they're coming, they're very well suited for the DevOps approach. They've got to coexist with traditional architectures. You want to avoid vendor lock-in.

We're seeing more shift left to identify quality, performance, and security issues sooner. And when you look for technologies, when you look for tools for quality, performance testing, monitoring, you definitely want to look for solutions that are designed for rapid cycle times for the DevOps approach.

Then culture, organization, process, this is a critical prerequisite. You've got to address these things. They have to be optimized for speed. If you don't do this, the automation is not going to be successful. You're not going to see the business outcomes.

Then in closing, if you're interested in learning any more about ElectricFlow, we're in the booth downstairs in the expo hall if you want to learn more. For those of you who like to get hands-on, we've got a community edition. It's available as a Docker container. You can get it up and running in five minutes. It's available as an AMI on Amazon. It's available as an image on Microsoft. We've got it available as an appliance, so you can download and get started.

It's got tutorials to get you started so you can quickly get value. It's got a sample app, so within minutes you can figure out how to use the tool to deploy and see how it would work with what you have internally. So I encourage you to take a look at it.

That's it for today. I hope you've enjoyed it. If you have any questions, I'll be around for a little while after. I'd be happy to take any of those questions.