Nmedia - Fotolia
IT organizations adopt DevOps to bring applications and software updates online more quickly. When it's implemented properly, DevOps helps a business gain market share and realize revenue sooner via better software. But DevOps involves increased communication between developers, quality assurance and IT infrastructure teams with automation at each step.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Many problems arise when DevOps is not implemented correctly, because of disagreements or lack of common tools. In order to tackle these DevOps problems, SearchDataCenter invited two experts to discuss the root of DevOps failures. Stephen Hendrick, principal analyst of application development and deployment research at Enterprise Strategy Group, brings a history in application development research and consulting work for Fortune 100 companies and leading software vendors. Chris Riley, a DevOps analyst at Fixate IO and author on DevOps topics, has worked with companies such as CloudShare, Pingar, LivingAnalytics and Artsyl Technologies.
To understand the origins of common DevOps problems that IT organizations face, these experts break down certain DevOps myths.
Myth 1: DevOps is just for big companies
While many IT pros and CIOs think DevOps is just for large software companies, this is not necessarily the case. DevOps works best for apps with long lifespans with growth or change potential.
"Small boutiques all the way up to the largest enterprise" need to consider DevOps, Hendrick says, because "more and more, technology is going to be driving their value proposition in the business world."
Riley adds that while organizations don't ever have to use the word DevOps, everyone must focus on modernizing their delivery of IT services. "Learning a whole bunch of new toolsets ... could be frightening," he says, and modernizing IT opportunistically rather than throwing everything out works for established enterprises and smaller businesses.
Myth 2: DevOps is an all-or-nothing culture change from the top down
Implementing DevOps from the top down may seem like a good idea. In reality, members of the development and operations teams probably use a wide variety of programs, and a top-down approach can wreak havoc on established workflows.
Bottom-up, middle-up and top-down all lead to DevOps success or failure based on buy-in and support throughout the transition. Many times, a smaller team will adopt DevOps for a certain project to see if it works for their company.
"Collaboration is undoubtedly one of the most important issues to get right and, of course, that's one of the reasons why the DevOps space has been so topical for the last decade," Hendrick says. This includes a bottom-up initiative undertaken by a developer, a top-down push from the C-suite, or somewhere in between.
Myth 3: DevOps breaks down silos and fixes the blame game
DevOps requires developers and the operations team to work together throughout the lifecycle of an application. However, blame can still be easily passed around, causing new silos to arise.
As Riley points out, developers can grab the latest greatest tool "without vetting it, without even knowing if the license policy fits the license policy of the organization because these are all things that they don't think about." They may not even try to connect their software with IT and production. The flipside is that sometimes the IT ops team doesn't make the APM (application performance management) tools available to developers or "give developers access to log analysis platforms," Riley elaborates. Without visibility, innovation is stifled by a lack of communication and collaboration between developers and ops, and thus they fall into old habits.
Hendrick points to deployment as the key to getting ops and developers on the same page. "What you really need to do is you have to have both of them vested in whatever the model is for how the application that's going to get deployed," he said. "That's going to go a long way toward forcing resolution around collaboration."
Myth 4: DevOps is too risky for production in enterprise
DevOps is not inherently dangerous to the production server setup. With properly trained IT professionals and the right controls in place, DevOps continues to work well during production.
Real-time predictive analytics is a game changer for IT ops teams, Hendrick says. "Once we have an application running in production, we need to be very sensitive to matching workload with capacity," he says. "As a consequence, being able to spot issues in that mismatch between workload and capacity [is] very, very key."
Myth 5: We're doing the best DevOps today, no need to improve
Any company that doesn't try to constantly improve how it operates is bound to become stagnant. A company's DevOps methodology in practice is far from perfect and the teams must always adjust to each project.
"[Application design] is something you do before you even start coding," Hendrick explains. "I think many organizations probably grossly underestimate the importance of good application design."
Riley sees DevOps problems arising at the end of the delivery chain, in testing and quality assurance. "Even though quality is a key tenet of DevOps, it is a severely neglected category," he says.
Allen: Welcome, and thanks for listening to SearchDataCenter's podcast on DevOps Failure. I'm Austin Allen, Assistant Site Editor of SearchDataCenter here at TechTarget. Joining us are two DevOps experts. In studio we have Steve Hendrick, who is the Principal Analyst of Application Development and Deployment Research at Enterprise Strategy Group. Is that right?
Hendrick: That's correct, yes.
Allen: And over the phone we have DevOps Analyst Chris Riley.
Allen: Hey, Chris. So today we're going to talk about the problems with DevOps, how DevOps can fail and how to avoid that failure.
Before we get into that, though, I'd like to set the stage, if you will. IT organizations are adopting DevOps to bring applications and software updates online more quickly. When it's used properly, DevOps can help a software business gain market share and realize revenue sooner. But it involves increased communication between developers, quality assurance, and IT infrastructure teams with automation at each step.
So these are for either of you. Feel free to jump in. So many see DevOps as something for bigger businesses since it involves in-house development rather than off the shelf apps, as well as investment in tools and training. What problems might businesses face when implementing DevOps?
Hendrick: Well, first of all, let me say I don't think DevOps is just for large organizations. When it comes right down to it, in the whole application development and deployment space, we're seeing lots of new technologies come into the picture. And as a consequence, those new technologies, many of them are appealing to the citizen developer. And so the reality is, is that organizations of all size now based on the technology that's available from small boutiques all the way up to the largest enterprise really needs to think about DevOps as a consequence of the fact that more and more technology is going to be driving their value proposition in the business world. So, Chris, you agree with that?
Riley: Yeah, mostly, mostly. I think that my point of view in the last two years has changed fairly significantly where I had majority of a top-down perspective leaning towards the enterprise, the bigger business. How it switched is that I think in reality you don't even need to say the word DevOps. I think that there is this aspect of having the goal in mind and realizing that as you modernize your delivery chain, it's a practice, it's a journey. It's not just one technology or just one process. However, I do see a lot of organizations getting stuck there and overthinking it.
For the startups or the smaller organizations, I do agree that DevOps is for them because I know that trying to do this retroactively is a very painful thing. So if nothing else, if the clear value isn't delivered to them day one, in the future by not doing it, it could cause issues. But there is value, and it's getting them to understand that the effort cost is well worth it.
I should say that I think of DevOps as two different things. I think there's DevOps the practice, which is definitely more focused on automation and infrastructure. And then there's the DevOps the methodology and the driving force. And sometimes when you talk about DevOps, a lot of times you're thinking only of the practice, but DevOps is much more than that.
Allen: Steve, I know you said that you don't think DevOps is just for bigger businesses. It's not, but how then does DevOps differ for smaller businesses? Is there a different way to approach it?
Hendrick: Well, I think that the scale and the complexity certainly is going to change based on organization size. And for smaller organizations, they may not do well with their own development. They may outsource some of it. Although from a standpoint of, as I mentioned earlier, with some of the more interesting tools coming forward for the citizen developer, I think really every organization has to think about what is their IT portfolio, what does it need to look like? And how, for instance, are they going to ensure that as they take this journey down the IT path, how are they going to be able to do that most effectively?
So for small organizations when it comes to DevOps, the scale obviously is going to be very different. It's going to be much smaller. There's a lot more packaged applications. A lot more of it's outsourced as well. But the reality is, is that they still will have a need to build applications and they'll going to need to put those applications into production. And so I agree with Chris from a methodology standpoint. There's a lot that small organizations need to appreciate and they need to learn from the standpoint of how to think about in an application that they need conceptually from its beginning all the way through to being in production. And so from a methodology standpoint, there's lots that needs to go on in the DevOps chain that will look a lot like bigger organizations as well. As I said, the scale and the complexity of the applications will be very different.
But the reality is, is that from a standpoint of how they need to think about design, what activities and alternatives they pursue for development, testing and deployment. Those are key stepping stones that remain the same regardless of whether you're a small organization or a large organization. And of course, the more mission-critical the application is, the more you have to invest in each one of those activities.
But the reality is, is that, as I said, small organizations need to actually, need to think all the way through what needs to happen from a standpoint of how they need to get from the inception of an application all the way through to its deployment. And the reality is, is that so they need to think seriously about what DevOps can mean to them.
Allen: Chris, have any additions to that?
Riley: Yeah, yeah, and so I do have a little bit of, I guess, an anchoring effect here because I am in the Valley and I'm exposed to a lot of the startup organizations who actually are thinking DevOps from day one, but they're not thinking about DevOps in the enterprise way. They're thinking of actually what they would call NoOps. I'd make the argument that that doesn't exist, but from their perspective how can developers handle everything to production and be accountable for that.
So there is the community of very small organizations who are actually building their delivery tank based on DevOps. I think what we're talking about here is more the SMB type organization who may or may not already be Agile, and staring at a big overhead required, which could be a resource overhead up or down, could be learning a whole bunch of new toolsets, and that could be frightening.
And a big part of this is how opportunistic are they, how forward thinking are they. Because for anybody who's approaching, we'll say continuous integration, which is probably the safest place to start, it's scary for everybody in some respects because you're changing what you're doing, so you have to test your tolerance for that. And there's a lot of ways to bring these processes and technologies on board without having a big impact. But maybe for the SMB, that impact is a little bit more threatening than with the large resources that a larger enterprise would have.
Allen: Chris, I heard you mention that some people in the Valley are referring to something called NoOps. But DevOps isn't an all or nothing deal. Right? Can DevOps coexist with traditional software development paradigms?
Riley: Yeah, absolutely. When I say that my big charter is to bring DevOps to real business, it really stems from that fact that I've dealt with a lot of startups in the Valley I'll say 200 employees or less who really were built bottom up DevOps, continuous delivery. All the fancy stuff that we talk about, it's a journey.
So when I divide DevOps into two categories, the methodology and the practice versus the implementation, there is the DevOps function, which is a person who focuses on mostly infrastructure automation, maintaining the scripts, probably managing the incident management system, making sure they know who's on call, who's not on call, and predominantly with the focus of fraud. But there is also just the idea of we need to release more faster and at a higher quality, which touches everybody.
And sometimes DevOps is actually started, in that respect, is started by the developer and it's never ending. I don't believe that you can say, "We are a DevOps shop." I don't think that that really can happen. I think you can say, "We have a DevOps function," but I think at the end of the day these tools are always going to be evolving. It's a moving target.
And so the idea is that if you're truly embracing DevOps if the new, better Docker arrives, you can take that tool in just as if you did early on with all the new tools. Because if it isn't that way, then we're just back in another world of waterfall adoption and we're back in a world where the tool dictates how you do what you do and you're locked in, and that's totally against the DevOps ideal.
Hendrick: Yeah, and we jumped right into this whole subject of DevOps. And one of the things that I think that's really key to get out on the table before we go into the minutiae of the DevOps space is to really talk about what does it take to be successful at doing DevOps. And so when I have looked at this and talked to a lot of enterprises about it, what really clearly comes through is that before you even begin to embrace the technology stack around DevOps, there's a whole issue of culture and application design that you've got to get right before you can really even begin this DevOps journey.
And I think culture is one of the biggest issues that organizations are going to have, especially if they have some traditional footprint in IT and they've had one for a while, because they probably come up through the waterfall methodology and maybe they're starting to embrace Agile and they're finding a lot of issues from a standpoint of being able to make that successful. But the reality is, is that in order to be successful in going down this DevOps path, there really has to be a cultural commitment to be able to make this all work, and that starts at the C-level. And they've got to have stakeholders up there that are willing to back this. And realistically there may be a lot of changes from the standpoint of how you think about development that has to be done.
One of the big vendors I do a lot of work with talks about two pizza teams and the idea of every application development activity is broken into small teams of people, typically four to eight. And the idea of a two pizza team is that the team can be no bigger than what it takes to be fed for a meal by two pizzas.
So the reality here is, is that from a cultural standpoint there can be some significant differences from the standpoint of actually making DevOps work, and therefore, I wouldn't underestimate the significance of coming to terms with the cultural side of all of this. So maybe we should start there before I dive into design because design is the next hurdle that you have to get over before you can really start thinking about DevOps seriously.
Riley: Yeah, I actually was hoping or trying to avoid saying the culture word at all, but it's just one less evil than the word DevOps, I guess. I've seen it happen in several ways. One of the big banks out there, what they did that I really liked was understanding that they had traditional data centers, mainframes, NOCs, all of this type of IT assets.
And then on the other end of the spectrum, they have mobile applications, tremendous customer demand, and the stuff that really screams for Agile. What they did was build the concept of shared services. It's not called DevOps, but it essentially was DevOps. But what shared services was, was this layer of both a library of technology and stewardship.
And so they somewhat addressed culture, but the segregations of duty still existed. It's just they were facilitators, and I saw that work very well. And that's a middle up and down type approach. I believe in the top-down, but I haven't actually witnessed this being successful myself only because I think the top very often doesn't understand. And actually, where I've seen the top-down tried, I've seen it backfire in a huge way.
And I'm going to call out one particular part of the delivery chain, which is QA. QA very often tends to get the short end of the stick because they're seen as the thing you do at the end, the insurance policy. And a lot of times the top has been educated that, oh the 'automagical' tools that you implement and it does it for you, so let's reduce the size of the team and go and get the tool. But that's not the reality because there has to be a strategy around how this automation works. And there's definitely opportunities to streamline your operation, but it just doesn't work that way.
But at the same time, I've also seen the developers make a huge cultural shift. There's one company in particular where, and granted, granted, this developer had the autonomy to do this, which is already something that had to be in place. But they went ahead and took the initiative to build a CI environment, and how they got people on board was they started delivering wins. And the easy way to do that with upper management is building dashboards and giving data and the analytics and showing up and to the right type things. And that started to drive the executive awareness on what was possible. So they delivered quick wins and grew from there, and that's a very heads down, in the weeds type of approach.
So I don't know if it's all or one. I've seen all work. But the top-down, even though I want to believe that that works, I've yet to see it happen.
Hendrick: Listen, what I mean by C-level support is the fact that the executives need to be behind what it takes to be able to embrace the whole concept of DevOps. There has to be a willingness to experiment. There has to be a tolerance for failure. There has to be a very strong message around collaboration and a real desire for innovation.
So when you really think about what it takes from a cultural standpoint, I guess I would say almost that collaboration is undoubtedly one of the most important issues to get right, and of course, that's one of the reasons why the DevOps space has been so topical for the last decade, which is that we've had this notion of developers throwing the stuff over the fence to the guys in IT operations, and that's just downright crazy.
The reality is, is that if we really want to do this right, we have to think about ways of surrounding the activity focused on deployment to actually get it right. And I think the way we do that is we have to be much more sophisticated in our thinking and the tools that we employ to be able to get both developers and the IT operations guys on the same page before we actually do any real deployment.
Riley: You're absolutely right. I think that when I hear the word culture, what I hear is being deliberate. And so from top-down being deliberate that communication is important. Versus culture's going to create itself whether your culture is Mountain Dew and ponytails or whatever. Suit and tie, that is a culture. But being deliberate is a top-down thing and you have to facilitate that.
Allen: Well Steve, I heard you mention that executives really need to be fully on board with this idea for it to work. Generally, executives have to be open and willing to do this. But going down a peg a little level, what are some of the problems with DevOps on the development side that you've seen, either of you?
Riley: It's still this bifurcation of who owns what, who does what. And IT can't blame developers, and developers really can't blame IT. They're all guilty of this. Developers today can go and grab the latest, greatest tool and start using it, and especially if it's an open source component, without vetting it, without even knowing if the license policy fits the license policy of the organization because these are all things that they don't think about. So they just say, "It's so easy for me to get a new SQL database and start using it" or "It's so easy for me to get Docker and do on my local dev environment, have containers and have the world open up for me in my development cycle." But how do I connect that with IT and production? And maybe I don't even try because it's just benefitting me.
But also, visibility because of this bifurcation has been very low. It's myopic for each team. Very often IT does not give developers access to log analysis platforms. At the same time, developers do not give IT ops access to the APM platform. Or it could be the other way around because sometimes IT ops owns the API platform and it doesn't go the other way. And that lack of visibility, which is the collaboration and the communication, does not allow for innovation because you're not talking about the same thing. You're not connecting the dots. And it's not a delivery chain. It's chunks, which is falling back on old, bad habits.
Hendrick: Well I think the solution to all of this is really, as I said earlier, focusing around deployment, because the reality is, is that in order to get the IT ops guys and the developers on the same page, what you really need to do is you have to have both of them vested in whatever the model is for how the application that's going to get deployed. So that's going to go a long way toward forcing resolution around collaboration, because if you have a workflow that suggests that there's no way that...And I don't care how automated it is. And I'm assuming it's going to be highly automated. But in order to be able, you have to have the agreement between ops and developers from the standpoint of what the policies are for moving the application into production.
Allen: So you're saying that there's more problems with DevOps on the operations side then if it's abundant?
Hendrick: So, absolutely not. No. I'm just saying that the collaboration and the communication, you have to make that happen between the developers and the IT operations guys. And in order to be able to accomplish that, there has to be a place for them to come around the policy that gets defined for the application so that as it moves from development into production okay, everybody is in agreement on what the policy is for the application.
Chris earlier when he had mentioned open source, I'm assuming that in the testing process you can deal with open source governance type issues. There's lots of tools out there that allow you, of course, to be able to deal with that. That's just under dimensionality of testing, in my book. But I really think that the solution to this really hinges on that shared responsibility that comes and focuses around application deployment, the actual act of moving something out of the test environment and into production. That's where the rubber is going to meet the road in the whole DevOps space, and that's I think where the energy has to be invested to really be able to make this work well.
Allen: Chris, do you have any follow up on the operations side more than the deployment?
Riley: No, I agree. To the point, there's a travel agency that had successfully allowed the developers to own the entire deployment process, which you could say they are DevOps. But still, the office team is 100% production. And so they've maintained the divide, but because they've taken over the ownership of deployment, it's very interesting that they can get it into production. And they have created more accountability for the developers. I think more and more developers are responsible for bad code. And the more tools that are used, the more transparency there is on code and code quality.
So I absolutely agree that communication is a key aspect to this. And if you look at Docker adoption today, container adoption today, it becomes very interesting because you can make the argument that it's not mature enough for production. But really it is, and there are scenarios where it's being used. But the reason Docker really has not made it in production has been isolated to DevTests is exactly what we just said here, the developers grabbed the tool, started using it, worked great for them, are controlling their releases to CI environments, working fantastic. Just looks like the best tool. But then when it comes to prod, it has to then wedge into what already exists, and they're not going to touch that process, and I think a lot of times developers don't want to. So that's part of the issue as well. But yeah, I think we've beat it to death that communication is key.
Allen: Are there any other problems you see on the operations side with maybe some risks with software releases, logistics of capacity planning? What are some other big problems with DevOps on this operations side?
Hendrick: I've given a fair amount of thought to this. And once you have applications in production, there is a whole host of manageability issues that come to the surface that are very important to address. And I think if you want a roadmap for how to deal with all of this, it seems to me that the first thing you have to do is you have to do some very comprehensive real-time continuous data collection. That means going to the logs. That probably means looking at packets to get a sense of not only what the important events that are going on inside of the environment, but also what's the flow of information that's going on as well. And you stitch all of that together and that becomes very meaningful from the standpoint of being able to support analysis. So that's your starting point.
From there, then there are multiple steps that you have to think about taking. And this is where it gets a little squirrely because we don't necessarily have all of the right tools and technologies yet to go down this path. But predictive analytics is very key from a standpoint of taking a look at okay, once we have an application running in production, we need to be very sensitive to matching workload with capacity. And as a consequence, being able to spot issues in that mismatch between workload and capacity are very, very key. And predictive analytics gives us a tool to be able to do that better than we have historically, go well beyond just what we can do with threshold analysis. So that's one dimension.
Another dimension is optimization, which is really thinking a little bit more about what is the objective for the performance envelope for the application that is running in production. And once again, through the monitoring of what's happening in real time for the application and then comparing that against the target for it, we can make decisions about okay, how should we change resourcing so we can optimize the behavior of the application.
I'll stop there because I think if you go beyond that, then it gets really crazy from the standpoint of very sophisticated analytics to be able to drive all that. But those are still both, I think, well within the grasp of most big organizations today from the standpoint of being able to deliver on.
Riley: Yeah, so if I were to throw some examples out there. The first thing that I noticed, because I'm a big fan of doing case studies these days, is that everybody I talk to has excelled in one area or another, but seldomly excelled in the entire delivery chain. So they're really good at QA or they're really good at responding to issues or incident management. Or they're really good at the releases. They're doing a whole bunch of releases every day, but their ability to respond is not very good. Or they have amazing functional test coverage, but they're not releasing very well.
So I think that that's interesting and I think it stems from the problem of there isn't very often a holistic point of view where they treat the pipeline as its own thing, as its own entity. At the end of the year, can you tell me, can you score your ability to deliver code. No matter what the code is, can you score your ability to deliver code over some period of time and see it go up? So that's more of the broad sense of the delivery chain.
But then I also think that the market is one of the big challenges with DevOps today because I think that there's so much flying at IT managers and there's so many considerations. We haven't talked about architecture, but the whole microservices movement implies so many things about application architecture, and delivery chains, and everything that it's really easy to get lost. And it's also really easy to think that the tool is going to solve the problem for you. So if I want to do microservices, is Kubernetes going to be the answer? Probably not.
And so the other thing when you talk about predictive analytics, the term machine learning has been beat across the head of these IT managers without them thinking about how they're actually going to use these insights. And so I actually think that that's a really big problem, which forces people into a silo and doesn't allow them to innovate.
Hendrick: Yeah, I agree with you, Chris. I do think, however, when it comes to the whole predictive analytic space. I think there are important activities there. We need to be able to predict workloads. We need to be able to predict when a server is going to go down. And the good news is that if we're real students of this real-time data collection, there's lots that we can do and lots that we will learn and patterns of behavior that we'll be able to see as a consequence that will help us do this prediction in terms of being able to better meet SLAs or better understand how we should manage resources in general.
Allen: Final question for us. We've talked a little bit about problems, some issues that we've had, some problems of marketive culture. This is a simplified question because it has the word simple in it, but what are some simple preventative measures organizations can take to avoid some common DevOps problems?
Hendrick: Yeah, let me start at the top here, because one of the things I haven't mentioned yet really is this whole issue of application design. So we talked about culture earlier. But in the application design space, this is an absolutely critical activity, and it fact, this is something you do before you even start coding. And I think many organizations probably grossly underestimate the importance of good application design.
And I think nowadays with where we are with containerization of microservices, the whole notion of really good design is actually even more important that it has been in the past. In working with consultants that are deeply involved in helping support application development at a big industry, what I have heard is that up to 50% of a project's time for successful projects should be spent in design, which is huge. In the reality it's huge, right? Everybody wants to jump into code because they're thinking, "Okay, we can get work done. It's a good thing, right?" They're very anxious to get going.
But the reality is, is that if you have good design in this day and age, first of all, that good design is going to surface through prototyping and through reviews on the UI and UX type issues. It's going to surface where you have problems. And you're going to get those problems resolved way at the front end of the whole software development life cycle, and not at the back end where it's going to cost you a fortune in both time and money. So that's why good design is so important.
The other thing that you get from it, especially given in the microservices environment that we live in today, is that if you have good small components that you have built or designed for your application, as comprised of lots of small components, that you have the ability during the coding phase to be able to run in parallel, build all these components in parallel because you already know how they're going to interface with one another, so that's not the issue. The issue is simply okay, so now that we've designed the application, how do we get it built quickly?
And as I said, with lots of components, not only are these components small so they're easy to build fast but at the same time, you can build them in parallel. And once the application gets deployed, you can maintain it much easier because the components are less ... there's less that can happen and go wrong with the component. So I think that, to me, is one of the most important issue to remember when it comes to really smart DevOps application development.
Riley: Yeah, it's really interesting the application architecture point of view. More than once I've been asked is microservices DevOps, and I think that speaks to the market education out there. Because microservices, it really has less to do with releases and getting code out faster than it has to do with architecting your application to be many small, autonomous units. So I think there's a lot of misunderstanding of the implications on architecture.
Just for fun, I'm going to go on the complete other end of the spectrum of one of the things that I think a lot of people probably wouldn't say to you in person that they're doing, but the reality has been different. And they actually relate to each other because a good architecture relates to quality. But I'm going to talk at the very end of the delivery chain, or if you're a firm believer in how iterations work, there is no end. But most people treat the end of the delivery chain as the point when you do testing and quality assurance. And even though quality is a key tenet of DevOps, it is a severely neglected category.
And from what I've seen is that people are more accepting of technical debt than they are of spending the effort and the energy in doing proper test automation, making sure that their co-coverage is not just complete but it's effective. Because it's very easy to write tests that have 100% co-coverage, you just follow a system, but is it actually benefiting the organization? Because where I see DevOps falling apart is when people only think about DevOps is the big green go button.
So if you think about you go and buy a Ferrari. The reason you buy a Ferrari is because it's really fast. But what happens when that speed makes you spin out and run into a tree? And that's where eventually if organizations don't prepare for better quality, for better test automation, if they're doing canary releases, the ability to roll back very quickly to a previous version and address the issues, then it's not going to sustain. I don't care how amazing your delivery chain is, it's not going to last. And eventually you're just going to go back into the shadows and say either DevOps did not work for us, or we're going to just go back to this "Agile," which is most often really fast waterfall. So I think I'm going to go on that spectrum. I think that's one of the biggest issues.
Hendrick: Yeah, let me just pile on here for a second on the whole issue of test. I totally agree with you, Chris. I think testing is a very important activity in the chain, and it typically doesn't get the attention that it deserves. What's really fascinating though is that when you think about approaches to testing these days, especially load testing for instance, load testing is essentially the poster child for cloud-based infrastructure because you can spin up what you need, you can do the tests, and you can then knock it all down. And if you're doing this in a public cloud service provider, you don't have to own anything. You're just going to use it for however long you need it. So it feels to me like there are good answers to how to deal with testing. It's just a question of I don't think there's the appreciation out there yet for the thoroughness of the testing and completeness of the testing that needs to get done.
Riley: Yeah, and actually on the functional testing side, so in the same vein, a little bit different because this one, functional testing has a much bigger resource implication. And most organizations still rely on manual testing. But the power of selenium and the scripting tools out there to execute in the cloud services, to execute on functional testing, is just remarkable. But a lot of organizations don't give that department due credit and don't bring on technical people. The testing team tends to be non-technical. And so they're not able to embrace these technologies.
Allen: Steve, Chris, thank you guys for being here. I guess Steve, thank you for being here. Chris, thank you for calling in. To learn more about DevOps, IT compliance, governance strategies, emerging IT workloads and types, and more, you can follow us on Twitter at @datacentertt, or you can go to www.searchdatacenter.techtarget.com. Where can people find you guys?
Hendrick: So you can find me, I'm Steve Hendrick, Enterprise Strategy Group. Just go out to esg-global.com. That's where I live.
Riley: I'd say the best place to find me is probably on LinkedIn and search for Chris Riley, analyst. But my website is Fixate.io. Also it's a good place to find my information.
Allen: All right. Again, thank you guys for joining the conversation today, and yeah.
Hendrick: Great. Thanks, Austin.
Allen: Thank you, guys.
Riley: Yeah, thank you. That was fun.
Allen: And Chris, thanks for calling in. I'm glad this worked out.