Jonathan Vanian: Let's talk about what a failure looks like when an organization tries to implement DevOps.
Mike Baukes: I've been part of a couple of failures in the past, so I'm pretty well versed now in things that we did wrong a couple of times now. I've also been part of a really good success story, which is a really good thing too. I've seen both sides, not only as a consultant, as an employee, and now as a vendor too, which is great. I think too many companies they hear DevOps and they jump to automation and then jump to tooling. I think there's a lot of people out there talking about the effect of culture and the need to prepare a culture in order to be able to facilitate faster learning.
I think too often people are just naturally hearing about DevOps and they're like I'll just look at the call list and see what's available, and then there's a myriad of options there. I think the number one thing that people have to realize is that there's got to be a cultural ambition to actually work together and deliver fast. What I've seen in the past and jumped to conclusions about in the past, and instituted to some degree, is the need to automate as fast as possible. For us, whilst it met the needs of the project at the time, we didn't achieve any of the organizational roles or cultural goals and as a result the technology got left by the wayside.
This is a common thing that happens. You hear about it all the time. Particularly, when you talk about DevOps a lot of people talk about there's pockets of automation here, there's pockets of automation there, we've got a bash group and part of that is built on Jenkins. The unfortunate thing is that people quite often, particularly when you're in a large-scale enterprise with legacy systems and legacy apps, the need to automation feels like the right move, but quite often it can actually really, really hamper your efforts to introduce a DevOps style culture to your organization.
Jonathan Vanian: You've got to really set up the automation right before you flip the switch.
Mike Baukes: I think you've actually got to know what you've got. More often than not, you'll find most people don't know how to get something to production. They've never really spoken to the ops guys. They don't know why the security guys are there, trying to ask them well why are these files open, have you broken this out into a 3-tier structure, how does the data regress, all these questions. It's just how much does an individual know throughout their chain. More often than not, particularly from an engineering perspective, the natural inclination is to close in, just focus on 'I'll just keep on building' versus actually getting out there and talking to people. I think often that's the first inclination is that we can control is using code instead and then that leads to the automation problem, and then unfortunately they lose sight of what the business actually does.
Jonathan Vanian: All right. That's a good example of failure. What does a success look like?
Mike Baukes: I can say this is for us what we saw as success and that was an organization right about 2010 there was the best program happening within this large bank, right?
Jonathan Vanian: Correct.
Mike Baukes: It wasn't DevOps at the time, but there was an application-centric group , there was a whole need to remove assets from this bank, create new assets, and then at the same time bring together a brand new team. As a result of that, there was multiple entities that had to get mashed together so there was great application guys, there was great infrastructure guys, and what happened as a result of that is that there was enough people to not only deliver a great repeatable solution, but at the same time everyone was focused on actually delivering this project and delivering the solution from the CEO all the way down to the ... everyone was aware how this was operating.
For us, the philosophy of DevOps is we've got this outrageous project deadline that we've got to meet, we've got to create all these new capabilities for a business, we've got these existing capabilities, let's understand those first, let's map out our to-be state, and then let's execute iteratively on that using agile to some degree and a lot of the operational infrastructure test-driven development processes.
For us, we got that up and running. Collectively, when you looked across the organization everyone was really aware and everyone was really open and sharing those lanes we had regular continuous improvement sessions, there were scrums, you could learn a lot. There was visibility across the organization and what state we were at. Anyone could ask a question at any time and query any decision that had been made.
Jonathan Vanian: Management was totally okay with that?
Mike Baukes: Totally open, really irregular, particularly for a banking organization. This was a big project. The great thing was is that what was a two-year deadline was delivered in 18 months, I think.
Jonathan Vanian: Wow, that's pretty amazing.
Mike Baukes: This was a significant project budget too.
Jonathan Vanian: Was this a big bank?
Mike Baukes: I can't actually say. It's like the number one or number two bank in the UK, and a couple of international divisions were involved in this. It was huge.
Jonathan Vanian: This was not just a small organization, small shop.
Mike Baukes: Yeah, I think it affected directly about 1500 people in IT was a massive push to get this thing done. That was a small project team to some degree.
Jonathan Vanian: All right, let's talk a little bit about tools. Readers love talking about tools. What are some good tools out there people should be aware of?
Mike Baukes: Definitely on the open-source side, Puppet, Ansible. Ansible is getting increased traction. I think Puppet is a mainstay on the infrastructure side. Ansible is becoming more and more available too. Our product, GuardRail, of course, which is awesome.
Jonathan Vanian: Get your pitch out now.
Mike Baukes: Yeah, I won't do that to everyone. There's a whole hub. There's so many great platforms now for collaboration, a lot of the Atlassian tools, like Jira and Confluence, they're really helpful. One that I really, really like these days is a product called Slack. It's like a chat room for ...
Jonathan Vanian: ... How do you spell that? Was it Slack?
Mike Baukes: S-L-A-C-K. It's kind of like a ChatOps product, if you've heard of it. Basically, you get all of your events injected into this long stream that you can basically go through, you can add Twitter feeds, you can add Help Scout, you can add continuous integration tools. All of this stuff becomes this just moving canvas of the business at any point in time, which is really great.
Jonathan Vanian: That's really cool.
Mike Baukes: There's so much stuff. We're focused on a lot of things. There are some great products out there. If you get a chance to ever look at a monitoring tool called Geckoboard or Graphdat too, also really great tools these days that are being made that are SaaS subscription models that are fantastic.
Jonathan Vanian: Yeah, amazing time for the tools.
Mike Baukes: I blurted them all out to everyone here.