Wen Gu - The Last Mile with DevOps

Andre Pino: You're listening to DevOps Radio, a podcast series that dives into what it takes to successfully develop, deliver and deploy software in today's ever-changing business environment.

Sacha Labourey: This is DevOps Radio. Sacha Labourey here at CloudBees and Wen Gu –

Wen Gu: Yes.

Sacha: Welcome, Wen. I think that the first thing we need to do is we share something, which is probably everybody say our names wrong.

Wen: Yes, always.

Sacha: So, I probably just screwed up right now, so how do we say your name?

Wen: Wen –

Sacha: Wen.

Wen: And the last name Gu, G-U.

Sacha: Gu?

Wen: Wen Gu.

Sacha: Wen Gu, so more like a K than a G for me.

Wen: Yeah, yeah.

Sacha: Right? Okay. So, that's done. Okay, that's great. So Wen, we're here to talk about DevOps, obviously, and what I found interesting is that today, you work at Twitter.

Wen: Yes.

Sacha: And tell me the name of your team. I found extremely interesting.

Wen: Okay. So at Twitter, previously before I joined, it was the DevOps engineering team, or dev tools team. It's not the – the original name is called dev tools. And then, they found out our value for the customers are really making engineering more effective or more productive, and that's why we changed the name, changed the organization name, to the engineering effectiveness.

Sacha: Engineering effectiveness –

Wen: Yeah.

Sacha: I love that.

Wen: Yeah.

Sacha: Yeah, that's great. So, before you tell us what brought you to Twitter, I'd love to hear the story of the company you worked at before, which was Intuit.

Wen: Intuit, yes.

Sacha: Because I think it's a great proxy of what we see in many organizations today, which is the adoption of DevOps at scale, and then thinking about what does it mean, how can we centralize and so on. So anyway –

Wen: Correct.

Sacha: -- tell us the story. I think it's pretty interesting.

Wen: Sure, I can talk a little bit about it. At Intuit, I joined Intuit about two-and-a-half years ago. At that time, Intuit was kind of a collection of different brands, different products. We have TurboTax, we have QuickBooks online, we have Quicken, those products coming from acquisition. So, the engineering practice, and in the tooling, is managed and maintained within each product line. At Intuit, they tried to create an end-to-end seamless custom experience integrating all these different tools together, so people using TurboTax can also use QuickBooks or use Quicken, so that when they file tax, they don't need to reenter their financial information or those things again when they already typed them into Quicken or something else.

Sacha: Right.

Wen: So, we want to improve the customer experience by offering the suite of products that Intuit provides. In order to achieve that goal, the CEO of the company fired out – we think about how to get there. The first thing they think about is how we unify the tooling and the practices. That's the foundation to get the products integrated with each other.

Sacha: Right.

Wen: So they started this initiative forming a CTO dev tools team, and I feel privileged that they asked me to lead that team. We look at all the different tools that are used by the developer, from source code control all the way to how we deploy to production systems. Jenkins is part of that, and we're also using CloudBees Enterprise Jenkins.

Sacha: Right. And so, most of the discovery, right, you had that first phase where you had to talk to all of the teams –

Wen: Yes.

Sacha: -- to see what they were using.

Wen: Yes.

Sacha: First, did you see a lot of overlap amongst the tools they were using, or everybody was using different tools?

Wen: For Jenkins, for the execution platform, Jenkins was pretty dominant among all the different BUs, different teams, and there was some exception, some people using some other tool.

Sacha: Right.

Wen: The majority is using Jenkins, but they are using open source Jenkins.

Sacha: Right.

Wen: Part of the reason we, at central office, is want to providing a value to the customers, to the BUs. We want to rely on a company like CloudBees to give us the enterprise support and have the quality level that we can rely on, because when you deliver this kind of service at a central level, it's kind of – we have an SLA between central office and the BUs.

Sacha: Right.

Wen: It's different from managing within the BU themselves. Within the BUs, they probably can work with the BUs so it's –

Sacha: More flexible.

Wen: Yeah, more flexible, but at the central office, because we're serving 4,000 engineers across the company, there's no allowance in the downtime and those kinds of things. So, one of the first things that we did is actually reach out to CloudBees to get enterprise agreement or something like that.

Sacha: Did you see also other tools that were very frequent that a lot of teams were using beyond Jenkins?

Wen: Good question. Yes, we do, I mean especially when – at Intuit, one tool used pretty widely is Perforce as the SCM, although it's kind of – when we looked, I mean there were people using Perforce that's using Git. We tried to select an SCM tool to unify that experience as well. We ended up selecting Git as the minority of the people using them. And for people transitioning from Perforce to Git, it's actually pretty natural. For the people using Git, we were trying to convince them to go back to Perforce, that's kind of hard.

Sacha: Right.

Wen: That's part of the reason we – we picked a – I think the point is that we not only – we not just picked the majority, but we picked the right tool for the job, and that is the – I think the key to getting people to consolidate.

Sacha: Right. When I see typical effort to centralize as a CI/CD infrastructure, what I see a lot is that obviously, as you do it, you want to do it at scale, meaning you don't want to deal with too many exceptions, right? You want to streamline things.

Wen: Correct.

Sacha: But teams might have specific requests.

Wen: Yes.

Sacha: So how did you deal with that? Was there tensions with those teams? How did you resolve those?

Wen: Yes, there's a tension, I mean, from different perspective. First, when we – in the early days of our team, the tension was not really in the technical. It's really on the – even the business value. Why would we even do this at the CTO level?

Sacha: Right, yeah.

Wen: And executive layer, the VP and above, they all understand why we do this. But at the engineer level, why?

Sacha: Loss of power, right?

Wen: Yeah.

Sacha: We do it ourselves. It works fine.

Wen: It works fine, and it actually works better than me on a uniform CTO. How do you know what I need?

Sacha: Yes, yeah.

Wen: Those kind of conversations, especially in the first couple months, come out a lot. At that time, we were asking them about technical challenges. They don't even want to tell us about it because they say, "Everything I have is perfect and we don't need you."

Sacha: Yup.

Wen: But we – to overcome that, we want to demonstrate our industry leadership. We want to do – pick not only the popular ones or whatever it is. We really tried to understand what kind of problem we are trying to solve, and pick the best in the industry that applied to the company, and it showed them our technical leadership in selecting which tool to use, in Jenkins or in Git or in Nexus or all those kinds of things. After they've seen us going through this due diligence of selecting tools, they started buying our vision to have a centralized tool. And then, it came down to technical discrepancies, those kinds of things.

Sacha: Yes.

Wen: Of course, there's no perfect tool out there. Even if we select the best tool in the industry or in the market, it does not mean it's a perfect tool to solve all the use cases.

Sacha: Yeah.

Wen: In that case, we understand those specific use cases that works well for the existing tool chain, and how we at least mimic or to be equal par to that level. And even if we cannot do that, be very transparent and honest about, "Hey, this is something we cannot match up, but on the other hand, look at all the other benefits having a centralized team provides you with maintenance cost, or makes that easy," so a kind of trade-off. We're not trying to force anything. We tried to give them – we do recognize the technical challenges and be very open.

Sacha: How long ago has the transition took place?

Wen: The first phase take about three, four months.

Sacha: Right.

Wen: The second phase, the really onboarding and those things, take us about – I mean we started onboarding the first customer after 12 months, a year. It really depends. I mean for the Git, probably it's easy. For people using Git, it's easy. For Jenkins, we have to create something, and we have to address lots of security issues because when they do it at the BU level, they don't worry so much about security and the HADR, those kind of reliability issues. Essentially, we spend our engineering time to make that sort of the same way. We have pilot customers, so our pilot customers start with 9 to 12 months, our first pilot customer. After about 16 to 18 months, a year-and-a-half, then we start loading – well, first, we did the soft launch, and so, we onboarded about 20 customers, 20 different teams, large size, small size, C++, Java, different flavors.

Sacha: Right.

Wen: And then, having them try it out for three months, or three to six months, then we decided to roll out to the rest of the company.

Sacha: How many teams did that cover?

Wen: Our goal is to cover about 350 teams –

Sacha: Wow, that's a lot.

Wen: -- around 4,000 engineers.

Sacha: Amazing, yeah. And so, you get first distributed infrastructure. Then, you get some kind of official, the CTO, to assemble all of that and centralize thing, people get pissed, you overcome this, you set up a shared infrastructure for hundreds of teams.

Wen: Yeah.

Sacha: The question I have is really, what happens after? Meaning, did people come and say, "Well actually, that was the right thing to do. It's much better"? Did you get positive reaction, because sometimes, people get emotional and pissed about things because they lost something they think works. But when they get something else, they realize that wow, it's much better. Did you get that kind of feedback?

Wen: Yes, I do. I mean the funny thing is, in our business, we don't get lots of positive feedbacks.

Sacha: Right.

Wen: And in this case, one of the things I heard a lot is it's like in a negative way. "Why did it take you so long?"

Sacha: Right.

Wen: And well, we did it as fast as we can, but it still took a long time to get things right because even at Intuit, they tried this multiple times in the past, and it was not very successful. But so far, what we did is – they want to use it, and they really enjoy the benefit. The thing they see is, from the BU side, they feel managing, maintaining Jenkins is not their expertise.

Sacha: Right.

Wen: They're main value-add for the business is writing the QuickBooks or writing the TurboTax great. That's serving for the Intuit customer, and then maintaining Jenkins, upgrade Jenkins, or replacing hardware is not their job. Having somebody from the central office to take care of that for them, they're really happy about it.

Sacha: Yeah, obviously, yeah.

Wen: Of course, at first, they kind of not used to it. I want to install a plug-in, or something like that, cannot get it instantly, but they do understand this kind of tradeoff. From the business point of view, they can see we got buy-in from the engineers. The engineers are not going to push that back that much with that.

Sacha: I think you just sent a big message of hope to lots of people who are fighting to centralize their CI/CD, yeah.

Wen: Yeah, it's hard.

Sacha: Yeah.

Wen: The thing is, if you have too much flexibility with the BU, you're adding overhead to your maintenance. But if it's too much standardization, you're restricting their use cases. And for the customer, you try to find the right balance between the two, and the right balance is different from every business, different from every company.

Sacha: Right.

Wen: You really need to understand the culture of the company, the technology, the other things. In the meantime, our industry is not standing still. The industry also keeps changing things. You want to leverage the industry advancement as well, but on the other hand, even in the industry – I'm trying to say that even on the industry side, there's lots of new things coming up. As somebody at the central office managing this infrastructure, you need to pick and choose which one applies to your company. Not everything is all about good _____, and then may or may not work for the company I'm working. There's lots of moving parts. To get all these moving parts right, it's kind of a little bit tricky.

Sacha: Yeah, yeah, I bet. I bet. And so, Intuit is interesting because it obviously has lots of software, but it also has an increasing online presence –

Wen: Yes, exactly.

Sacha: -- you have lots of multi-class assets.

Wen: Yes, yes. Actually, nowadays, I don't believe – I cannot believe until I heard a stat is that 90-percent of people who file tax is using TurboTax online.

Sacha: Wow.

Wen: Only ten-percent is using the desktop version.

Sacha: All right. Yeah, yeah, well CloudBees, as a customer of QuickBooks, used to be using the offline version when we started the company, and now, we're using the online version of QuickBooks.

Wen: Yeah.

Sacha: That leads me to more of the continuous delivery process side of things because one of the huge benefits when you do SaaS, is that your deployment cycle can be much more flexible than if you have to ship software to customers.

Wen: Yes.

Sacha: So, did you see that transition happen? What can you say about the – because a company that has true root in software, when suddenly, they have this SAS model that opens up, that's a change of DNA, right?

Wen: Exactly.

Sacha: How did you see that?

Wen: Yes, that's a huge transformation across Intuit. Intuit is a great company going through these kinds of changes many times. Intuit has a history of 30 years. It started with the DOS program if you remember. I don't remember that, but Quicken used to be DOS program.

Sacha: Oh, wow.

Wen: The CEO of Intuit talked about the era of changing from a DOS command line thing to a graphic user interface. That's a mindset change as well.

Sacha: Right.

Wen: At that time, Intuit was competing against Microsoft.

Sacha: Yes.

Wen: Imagine a company like Intuit competing with Microsoft and not only once, but twice. Microsoft tried to create some Windows-based accounting software as well.

Sacha: Money, right, it was called, Microsoft Money?

Wen: It was Money. There was also another called Tax Save or something.

Sacha: Oh, right.

Wen: It was shut down even before the tax season is over. That how bad it is. We tried to learn from that experience, how we transition from a DOS to a Windows. Now, we're transitioning from a boxed software to a SaaS software. The practice will change, the tooling is changing, and the CI/CD is playing a – I mean in the SaaS model, CI/CD is playing an important role because you won't get your – because with today's technology, it's so easy to – I mean it's so fast to get your bits to the customer because it's a online version. So, at Intuit, the business made the decision that we offer both desktop version and online version at the same time. That's what the customer wants. The majority of the new customers, they have no hesitation and jump on the online version immediately, bypassing the desktop, but some desktop, they hesitate to do some – there's the security concern, privacy concern. They don't feel comfortable with _____. Actually, I think the point is that not just myself, for the engineers themselves, but also for the customer as well, how we make this transition.

Sacha: As part of the SaaS and continuous delivery process, what were some of the metrics that were important to you? Do you know – what matters the most to you?

Wen: Yes. So, for us, the top – there's lots of metrics we're talking about.

Sacha: Right.

Wen: And the top line metric is – one is the latency, meaning how long does it take from having the idea, to checking the code, to production, how much time it takes to have that completion. It used to be a month.

Sacha: Right.

Wen: And now, we've kind of cut down to weeks.

Sacha: Wow.

Wen: Yeah. That's one line. The other one is the just how frequent we release code. Just because we have the speed, it does not mean we want to release that often because –

Sacha: Correct, yeah.

Wen: -- those kinds of things, but that's another key metric we're tracking from the business point of view. And then from an internal CI/CD preference point of view, we are really tracking all the – especially during the onboarding – is how many customer is using the CI/CD platform.

Sacha: I see.

Wen: How many jobs? How many executions that they run?

Sacha: Were you offering some shared numbers to the different business units as to how they compare, or create some kind of formulation among teams, or that was not really taking place?

Wen: We don't compare team to team.

Sacha: No? Okay.

Wen: Because we're understanding different software, different application. They have their own cadence.

Sacha: That makes sense, yeah.

Wen: And the frontend usually releases more frequent than the backend components. But we do track the progress within the application itself.

Sacha: Oh, right.

Wen: For example, the frontend application, they used to release every three days. Now, they release three times a day and those kinds of things. We do track that as a progress. But we do not compare a frontend application to a backend.

Sacha: Right.

Wen: We know that's not a fair comparison.

Sacha: Okay, okay. Then, you moved to Twitter.

Wen: Yes.

Sacha: Right?

Wen: Yes.

Sacha: Different culture? Different company?

Wen: Definitely, yes.

Sacha: Talk about the culture for a bit maybe, and how this is impacting your job. It's helping? Explain a bit about that.

Wen: Yes. If you think, Intuit is a 30-year – they're a very mature software company. Twitter has only existed for like ten years, and it's very young, energetic startup.

Sacha: Right.

Wen: There's lots of startup atmosphere. They really want to push the new technology envelope, and try to empower people to communicate and share ideas. The idea behind Twitter is very powerful in the way we communicate with each other. If you see from global events, local events, you can see how much influence, how much power that Twitter enables us, the average people like us. We can have a broadcast channel for ourselves. We can say something. Like they say in Jenkins, [inaudible]. People here will tweet and there's a million people and now, a million people can see this.

Sacha: Right.

Wen: It's a power to the people.

Sacha: Right.

Wen: That's something I – I heard about Twitter a lot in the past, but when they called me and asked me, "Hey, there's an opportunity here. Do you want the job," yeah, I would like to become part of that team.

Sacha: Right.

Wen: Because it's a young company, on the other side, it's just lots of innovations, lots of those things going on. Exciting and sometimes challenging as well. People are doing things organically and by themselves, and sometimes, there's overlapping of effort on those things. I mean that's something I feel I can help to – based on what I've learned in the past, not every new thing is actually turns out good.

Sacha: Yeah, yeah. So your mission when you joined Twitter was really to – well, not when you joined, but as you joined this office of the CTO, it was really to consolidate CI/CD. What was your mission when you joined Twitter? Was it also to try to give some kind of common ground for CI/CD?

Wen: Actually, not exactly.

Sacha: All right.

Wen: Because the good thing is that Twitter, they're already consolidated, so the consolidation is completed.

Sacha: All right.

Wen: So my team is actually running a CI platform. We have not done CD yet, but the CI platform the entire company. So all the builds running on the CI platform, my team maintains and the engineering tools. What they're looking for is more reliability, more security, more performance and find out the gaps we have, and how we elevate the CI practice at Twitter to the next level. That's my mission at Twitter. It's how to advance them to the next level.

Sacha: To the next level. So you make an interesting comment. You say you do CI but not CD when you would expect Twitter to be doing a lot of CD, so does it mean it's done within the teams, or why is it split between CI and CD?

Wen: I think within Twitter, we're clear what CI means.

Sacha: Right.

Wen: We are still debating around what CD means.

Sacha: Okay.

Wen: What I noticed today is they're still a few – they're looking at – a CD, if you talk to different people, it means kind of two different things. One is the deployment, how to move bits from the depository to the endpoint, not deployment itself.

Sacha: That's when it comes to deployments, right?

Wen: Just the –

Sacha: Just the deployment, the last mile.

Wen: -- just the last mile.

Sacha: Right.

Wen: Some people thinking that is CD.

Sacha: I see.

Wen: The way I see it is the entire release process, which is starting from commit all the way to that CD. So, if we define this as CD, CI, of course, is a portion of this.

Sacha: Correct.

Wen: You cannot do this CD without CI.

Sacha: Correct.

Wen: If you do just last mile deploy to production, yes, it's just a follow-up step after CI.

Sacha: Right.

Wen: Actually, this is not just happening at Twitter. It's also happening at Intuit and other companies as well. People are confused about what exactly CD means.

Sacha: Right.

Wen: By the way, the DevOps is also that kind of word too.

Sacha: True, true. Yeah, yeah, that's true.

Wen: People have all different things.

Sacha: Definitions, yeah.

Wen: That's why here today, we have now – I should just mention it's not a CI/CD team yet, but it's evolving. This needs some – we still need to build some consensus to fire out what exactly CD is and how we achieve that.

Sacha: What I read from what you say is that the CI part is done, the last mile is automated, but there is not necessarily a bridge yet between the automated lifecycle, as a continuous aspect of things, and the last mile. There is a gap in between.

Wen: It is actually happening continuously today.

Sacha: All right.

Wen: Just manually happening.

Sacha: Oh, the last mile?

Wen: Yeah.

Sacha: Oh, right.

Wen: It's just people running – and because it's manually happening, it's different from team to team, different from application to application, and we need to find out what's the best way to standardize how we're managing that quality control, or security control, compliance, those kinds of things. When we deal with production, that's the – it's not necessarily a technical challenge, and we know how to automatically deploy.

Sacha: Right.

Wen: It's more about compliance and security control and those things and those checkpoints.

Sacha: This is going to be one of your challenge and objective to overcome and try to –

Wen: Yeah.

Sacha: -- to get meter by meter to the last goal.

Wen: Yes.

Sacha: Feet by feet to the last mile, yeah?

Wen: That's right. That's right.

Sacha: All right. Okay. You know that's very interesting because perceptions sometimes are hard because I would've ess you would've told me that at Intuit, they would not do the full CD thing, but Twitter would do it, but you realized that actually, a very mature company like Intuit has actually some teams that are pretty mature in how they achieved continuous delivery, while Twitter, even so it's a "young" company purely born online, born in the cloud, still has some work to do to get there. Right?

Wen: Yes. Well, for Twitter, I'll say they're – I mean for Intuit, let's back to Intuit. Yes, there's some application, there's some teams at Intuit that achieve CI/CD with this kind of – with a plan. But those flagship products, the products that have legacy, still have lots of work to do to get to CI/CD.

Sacha: Right.

Wen: But as a CTO team, we facilitated and enabled the technology, enabled them, but there's lots of tech debt on the application itself that needs to be reflected to achieve that.

Sacha: It takes time, huh?

Wen: Yeah, it takes time, definitely.

Sacha: Yeah, I see it's probably work.

Wen: Some applications, some like customer care or those kinds of things, were able to achieve CI/CD. To go back to Twitter, they are doing CI/CD like ad hoc. So from the results point of view, perspective, they are actually doing CI/CD just using manual process. I mean they – some teams, they do deploy to production every day. From a CI/CD metrics point of view, that's pretty good, although, they don't do it automatically.

Sacha: Right.

Wen: But they do deploy to production every day, or sometimes, more than once a day.

Sacha: Right. And so, to step back a bit, you actually worked with some pretty impressive names. We know of Intuit and Twitter, but you also worked for HP and Yahoo.

Wen: And PayPal.

Sacha: And PayPal, oh, yes. And so, you've been doing DevOps in lots of pretty fancy companies for a long time. You actually used Jenkins before it was called the previous name, Hudson, right?

Wen: Yeah, yes.

Sacha: What do you see as being – so every company has its own challenges, own issues, own advantages, and so on.

Wen: Yes.

Sacha: What do you see as the same things that keep happening? What are the patterns that you see that exist anywhere you go? It can be resistance to change. It can be adoption of CI, consolidation, I don't know, but is there anything you observe that tends to happen anywhere you went?

Wen: A common pattern is that CI/CD, you have two groups of people that have different motivations to push for CI/CD. One is the grassroots engineers. They want to do CI/CD as a way to make their job easy.

Sacha: Right, a better way to do it.

Wen: A better way to do it. "I hate to click that button every day," those kinds of things, "I want to automate those things." Then, you see a different motivation from executives for why we want to do CI/CD. For them, it's more about how we have a consistency and reproducing our process so we know better how we predict the future.

Sacha: Right.

Wen: Those two, although the end results are the same, they come from different needs. As someone in the SaaS, to drive the CI/CD effort, to make this happen, they have this idea to do this. And it's how we address those both needs, so they don't get confused about the message. I think one of the challenges that we're facing is CI/CD is such a large scope from developer all the way to operations. You touch almost every aspect of the development activity. People have different expectations or different requirements, different things. Sometimes, they even conflict with each other. There's lots of friction, which is good friction. I'm not trying to say friction where there's different functional or people from different backgrounds.

Sacha: Right.

Wen: And in CI/CD, it's how do we live with this kind of different opinions, different perspectives, and how we address this. One of the key things we want to – I emphasize a lot is the collaboration. How do we define a common goal? How do we do these things aligned with all these different people from different organizations, and get them aligned for the effort of CI/CD.

Sacha: Yeah. It's funny what you say because we talk a lot about CI/CD in terms of the business, and I'm probably the worst offender because that's always the angle I'm taking, which is to explain why it makes business sense. But you're right. There is an amazing match, for once, with the field where it makes people's life much better. Right?

Wen: Yeah.

Sacha: Nobody wants to be code monkey and click on things, right?

Wen: Yeah.

Sacha: Repetitive tasks, manual tasks, that's boring, and especially, if you think about the Bay Area, but I know it's the same everywhere, where it's hard to find qualified resources. If you can find a job anywhere, why would you pick a job where you need to click on things and do manual tasks, right?

Wen: Well, yeah.

Sacha: Yeah, yeah. So, you're not – well, please don't say the name of the company, but what was the hardest challenge you had to overcome, or maybe you could not overcome because there was too much resistance?

Wen: I think get people's mindset change is – the culture change – I mean at first, the people – I mean it depends on where – I think that the mindset change is the most challenging part of it.

Sacha: So people.

Wen: People, but the people culture – I mean the mindset of the people.

Sacha: Right, rewire their brain to do something different, right?

Wen: Yeah. There's different examples. One is the developer. They want to have a flexibility. They want to have innovation done. CI/CD is kind of restricting what they can do. I tried to convince them no, that CI/CD is actually enabling you, empowering you. The restriction is for the production side, not to restrict engineering innovations – I mean innovations. But to the production people, they see when we enable the developer to do the innovation, they got scared because hey, I'm running production, how can you allow these kinds of changes to my production without – I have to change their mindset. So that's good for you because we have consistency, and it's the process that guarantees the quality, not the human being doing quality. Just try to understand different people, where they're coming from, and explain to them the benefit in their language. Because we cover so many things, people – if the production people hear what I say to the developers, they kind of get scared because they don't hear it in the context of it, but that does not mean I'm trying to lie or anything. It's the same thing. It's just like if you said –

Sacha: It's a different narrative.

Wen: And also, you should mention that from the business side and the engineering side, also they have different – engineers make my life easy. Business side makes things faster.

Sacha: Right.

Wen: If you tell engineers – if the CEO tells you we need to make it faster, that does not resonate with the engineer as much because hey, you know, what will you do for me?

Sacha: Right, exactly.

Wen: These kinds of challenges, to me, communication to me – it sounds to me – communication is very hard because we have one story, but so many different angles to look at it. As a team caught in the center of driving this, we have one single story, but from the audience point of view, they hear different versions of the story, and sometimes, they get confused because why are saying one thing to me and another thing to other people, and those kinds of things. I think we – that's why I'm telling you one of the challenges we have is making sure our story is consistent even if we say different things to different people, that does now mean we have a different story.

Sacha: Right.

Wen: We have the same story from day one to day whatever.

Sacha: Right.

Wen: Yeah, and people always hesitate or suspect what's going on, especially something like CI/CD. They've never done this before.

Sacha: Right, right.

Wen: Another thing about CI/CD is that because there's so many moving parts, if you miss a knob somewhere, just the whole thing does not work.

Sacha: Right.

Wen: Well, it requires the entire channel of activities to be all perfectly working, and there's so many failures, or so many underachievement. We have a very lofty goal, and we end up coming short of that goal. There's so many of those kinds of things happening in the past, people are kind of scared even trying to do this because hey, we tried this before, not once but three times or five times, whatever it is, and why try again? The last thing is, the reason we try again probably is because it's a good idea.

Sacha: Yeah. We did it wrong, but it's not a bad idea.

Wen: It's not a bad idea.

Sacha: Yeah, yeah.

Wen: But if you think of it from that point, there's times where you have some idea you've tried three times wrong, and probably it's not a good idea. Right?

Sacha: Yeah.

Wen: But in CI/CD, I've been in this world more than ten years. I know this is a good idea.

Sacha:Yes, yes, yes. Let's talk about the technical aspect as well. How do you think containers are impacting CI and CD?

Wen: I think containers, a powerful container is you can move the container from one state to another state –

Sacha: Right.

Wen: -- very cheaply, very easily. That would definitely improve the speed and velocity of how we deliver code because essentially, what that means is we actually – we don't need to deploy multiple times. We can just move this container from one state to another state.

Sacha: It's the same container, right, simulator?

Wen: It's the same container, yeah. As long as we can – managing the – whether it's the customer data or testing data, those kinds of thing, if we can do a better job, how to make that container portable.

Sacha: Right.

Wen: And if we can solve that problem, essentially, we can take away deployment time in our pipeline execution. Today, it depends on how many stages you have, you have to deploy N-times. Thinking every deploy takes ten minutes, and that's really fast, but that's N times ten minutes. If you can take that out, you essentially reduce the –

Sacha: The lengths, yeah.

Wen: -- the lengths, and that's one thing. The other thing is, just for CI/CD itself, how are we leveraging our containers for the security, for the reliability, and those kinds of things. I think we're still learning – trying to fire out how we best leverage that technology to our advantage to move CI/CD.

Sacha: You know it's going to bring advantages, but you're not sure yet what's the right way to use it.

Wen: Yes. Well –

Sacha: In a secure fashion.

Wen: We're experimenting. The thing is, this is also – the container is also moving very fast.

Sacha: It's very young, right?

Wen: Very young.

Sacha: A few years ago, it didn't exist, yeah.

Wen: Yeah, it's something we are keeping a close eye on it, and have our hands on it, and because it's not stabilized enough, but we don't want to use something, put it in production, and then three months later, this whole thing does not support it anymore.

Sacha: Right.

Wen: You know?

Sacha: Yeah.

Wen: That's something we don't want – we want to avoid.

Sacha: All right. So Wen, is there anything you'd like to share with us, something I did not ask, a message you want to share with the public about DevOps?

Wen: I think I'll kind of echo your keynote speech. This era is a software era, and with software, we can do good things to the community through the business. We, as software professionals, we need to make sure we do the right thing. The public gives us the trust, and we want to – there's lots of hacking. Software is powerful and also, there's a way of the public, there's people a little bit hesitant about technology, and we want to make sure, as a technical professional, we want to make sure we do the right thing for the public.

Sacha: So developers are the new kings, and with power comes responsibility?

Wen: Exactly. That's something I want to – as a community, we want to drive. And also, for CI/CD specifically, because CI/CD is so powerful, there's some companies that – as CI/CD, we touch every node. We access all the soft skills. It's so powerful, we come with the responsibility, how we do the right thing, and security, and those things, we want to pay attention to those things. I think today, I feel privileged people trust us to take care of this. We don't want to abuse it.

Sacha: Thanks a lot for those very wise words, Wen.

Wen: Yeah.

Sacha: I appreciate it.

Wen: Thank you.

Sacha: Thanks.

Wen: Okay, good.

Andre Pino: Like what you've heard today? Don't miss out on our next episode. Subscribe to DevOps Radio on iTunes, or visit our website at cloudbees.com. For more updates on DevOps Radio and industry buzz, follow CloudBees on Twitter, Facebook, and LinkedIn.