In this episode I chat with Donovan Brown, Principal Cloud Advocate Manager at Microsoft, about continuous delivery, the importance of adopting DevOps practices, and the continuous delivery of value to end-users.
Meet The Man in the Black Shirt. Donovan Brown is a Principal DevOps Manager on Microsoft's Cloud Developer Advocacy team. Why is DevOps one of the hottest topics? Because it hurts the most. Luckily, Donovan's unofficial tag line is #RubDevOpsOnIt and he's here to make it all better.
Before joining Microsoft, Donovan spent seven years as a Process Consultant and a Certified Scrum Master.
Developer Tools are his thing. Donovan has travelled the globe helping companies in the U.S., Canada, India, Germany, and the UK develop solutions using agile practices, Visual Studio, and Team Foundation Server in industries as broad as Communications, Health Care, Energy, and Financial Services. What else keeps the wheels spinning on The Man in The Black Shirt? Donovan's also an avid programmer, often finding ways to integrate software into his other hobbies and activities, one of which is Professional Air Hockey where he has ranked as high as 11 in the world.
Resources from this episode:
- Donovan’s Blog
- Donovan on Twitter
- Donovan on Channel 9
- DevOps Resource Center
- Azure DevOps Services
- ARM Template Reference Guide
Want audio only? Listen to this episode here:
https://cloudskills.fm/025
Full Transcript:
Mike Pfeiffer:
Hey, what’s up everybody? It’s Mike Pfeiffer and you’re listening to the CloudSkills.fm podcast. All right everybody, welcome back to another episode of CloudSkills.fm, I’m excited to have you here. We actually got a really great episode coming up here. I think you guys are really going to enjoy this. We’ve got the man in the black shirt from Microsoft that’s Donovan Brown, principal DevOps manager. Donovan, welcome to the show.
Donovan Brown:
Thank you so much for having me.
Mike Pfeiffer:
Yeah, I appreciate you being here because I know that you’re traveling all over the place. You’re super busy and so I really just appreciate it because I know that you’re probably challenged for time.
Donovan Brown:
I know, I appreciate you reaching out in such far advance so that we could actually find a moment where I’m on the ground. Because as you said, it’s rare nowadays that I’m on the ground. And expressing not only on the ground but on the ground at home, which is even rare.
Mike Pfeiffer:
Yeah, it’s hard man traveling like that. But it’s a dirty job someone has got to do it.
Donovan Brown:
It’s funny because everyone that knows what I do or ask what I do, and they’re like, “Man, that job sounds amazing. You’re so lucky.” I’m like, “It’s far more glamorous on Twitter than it really is in real life.” Don’t get me wrong, I’m not complaining, I do adore and love my job, but don’t think for one second it’s easy to be in a different time zone every day, it’s a taxing job.
Mike Pfeiffer:
Yeah. I just was on the road, I live in Phoenix and I was in San Diego and I was like, oh man, the travel and everything it’s so bad. I don’t know I’m like talking to you and I’m like, okay, I need to check that.
Donovan Brown:
Yeah. I just got back from Switzerland yesterday, and I’m going to freaking Norway in about a week. So yeah, I’m not feeling bad for you at all.
Mike Pfeiffer:
Yeah. That’s a perspective, right?
Donovan Brown:
Exactly.
Mike Pfeiffer:
Well, man, you’re really out there a lot too. I see tons of stuff that you’re putting out. Lots of interviews on channel nine, tons of different podcasts and other things I’ve seen you on lately and just a lot of content on your blog. But you’re doing a pretty ambitious job at Microsoft, and I think a lot of the people listening are going to be really interested because there’s a lot of people trying to get their arms around Azure DevOps services and Azure in general. And maybe you could share your background, how you got to where you’re at now and then we can get into what you’re working on these days in Microsoft.
Donovan Brown:
Sure. The beginning I started off as a developer. I was literally, I think the first time I ever wrote anything was in the seventh or eighth grade QBasic, and I didn’t do anything else with it till about the 10th grade. Again, QBasic couldn’t afford a computer back then because I’m much older than I look, so computers weren’t something you just had at your house all the time. And then eventually got into college, had a computer, wanting to play a game that I saw in a store and started writing the game in QBasic and just could not stop. I was just having so much freaking fun trying to figure out how I was going to turn this board game into a computer game.
Donovan Brown:
And at that time I was doing research at a Methodist hospital to become a cardiac surgeon. And I realized I was having far more fun with the computers than I was with medicine and I switched. I switched from biology to computer science. I went and got a job at Compaq computers as a technical writer because I had no degree, no experience. They weren’t going to let me in as a software engineer, self-taught.
Donovan Brown:
I got in as a technical writer and I nagged my boss for six months until she let me write code, so I can prove that I can actually write code. And then I wrote code for the rest of my time at Compaq before leaving. Rode the bubble like everybody and just bounced around from company to company, which is actually a really good experience because not only were you … I mean let’s be very honest, you were chasing the money, but you were getting a lot of cool experiences too because the money would take you to different industries, different languages, different platforms, different methodologies, different everything.
Donovan Brown:
I got are really nice sampling of all the different ways to write software well and poorly, different languages, different pros and cons. And then one day I got this cold call, it was funny, Chris [inaudible 00:03:41], he called me and said, “Hey Donovan, I got your resume from Microsoft and I’d love to offer you a job at Notion Solutions.” Like first of all, I think you have the wrong Donovan Brown because I’ve never submitted my resume to Microsoft. He was like, “No, a guy from Microsoft gave it to me. I called the number, I’m talking to you now, you’re the same guy.” So it’s like, I have no idea how you’re getting my resume from Microsoft, I’ve never submitted there.
Donovan Brown:
But nevertheless took the job and what that job did was it made me a process consultant. I flew around the world installing and implementing what was then called Team Foundation Server, which we all now know as Azure DevOps server and Azure DevOps services. I did that, everyone on the team got certified as scrum masters because not only would we install the software for the company, many of them were waterfall trying to transition into agile, and we would stay on staff as scrum coaches and help those teams come from the waterfall world into the agile world and I adored that job.
Donovan Brown:
I really, really enjoyed being able to take a company no matter what industry they’re in and have them struggling and then leave there and they’re just firing on all cylinders, they are delivering code. To be a part of a transformation like that is probably the part of my job I miss the most. Because as you pointed out when we first started, I fly all over the world and it’s crazy because I’m only in some of these places for an hour. To get on stage, do a presentation, get everyone excited about DevOps and you can see the glimmer in their eyes, you can see what they want and then I have to leave and it hurts sometimes. If I could stay with you, just the stuff we could do would just be amazing.
Donovan Brown:
So that’s the chart of my team though, is to go off and get people excited about the transformation and the way that DevOps can literally be that strategic advantage that you need in your industry, no matter what your industry is. If you can now innovate your competition by delivering value continuously and your competitors aren’t, you’re going to win that. And a lot of people are realizing that right now and they are … I hit DevOps at the right time. It’s probably one of the most popular topics out there. I’m asked to speak all over the world on it.
Donovan Brown:
And you name a company, chances are I’ve gone and spoken to that exact company and talk to them about how you need to start using DevOps and thinking differently because if you don’t, you’re going to be the one we used to talk about, not the one we’re talking about. So that gives you … that’s from the beginning to the end, from seventh grade to where I am now at Microsoft.
Mike Pfeiffer:
Yeah, that’s an awesome story and there’s a lot there. I think I really have to echo what you just said. I’ve been noticing it as well with customers over the last year, a couple of years, my own career as well, getting into DevOps and automation and actually innovation to move businesses forward, not just for the sake of doing cool stuff, but actually competing in the marketplace. Like you said, you can’t really keep up with people that are changing the world from a business standpoint if you’re not automating stuff.
Donovan Brown:
It’s amazing, I think we’ve become a generation of consumers that expect change. We expect every time we grab our phone to have an update on the latest app. We expect to have to download the latest update. We expect you to constantly be innovating. We do the same thing when we go to look at a package on GitHub. If it hasn’t been updated in a couple of months, we think that one has been abandoned and we’re going to go find another one that’s been updated within the last month or the last week. Okay, that one’s still has activity on it, that’s what I expected. It’s weird how we actually value activity. We value just changing your software, babysitting it lets us know that you’re still investing in that.
Donovan Brown:
And then what’s funny is just because it’s only been updated in the last month doesn’t mean they’re not innovating, they just haven’t deployed it. Why? Because probably it’s manual, it’s painful. But if deploying code is just a push of a button, then I’m going to do that all the time and my project’s going to look more active than yours and right or wrong, people are going to start to gravitate towards where they’re starting to see that change. So continuously delivering value has to be something that’s an afterthought. It’s something that you don’t waste time thinking about and right now if you’re doing it manually, it’s probably something that you love doing at all. So you don’t do it very often, which gives us the wrong impression of your company.
Mike Pfeiffer:
That’s a really good point. Especially now when businesses are moving to a subscriber model for everything they’re selling and the people are expecting updates constantly, and if you’re not doing it, you’re losing, right?
Donovan Brown:
Why did I subscribe to something that I only get once a year? I would’ve just preferred to pay you the licensing fee like I used to, and I’ll run the same software for four years until it doesn’t work, do what I need it to do anymore. But like you said, that subscription model is almost forced us into this behavior of, well, if I’m subscribing, I expect there to be like a subscription to a magazine, every month I better be getting something out of this, not just once and then I’m still paying you monthly for it.
Donovan Brown:
I don’t want to rate your software. I’m paying for that innovation and I’m paying for that change. And DevOps is what enables that for so many people. It’s automating those tasks that are just so mundane, painful, or even risky to do manually that you want to get that out of your way. And I want to be very clear, I used the term automation, but I don’t want anyone to hear me thinking that DevOps equals automation, it does not. But automation is a huge enabler and an incredibly critical portion of your DevOps transformation. You still got to monitor ones running in production. You still got to get that data back into your backlog to make sure that you’re working on what’s most important. So it’s a cycle that goes on forever. But most of us, let’s just be honest, focus on the automation. That’s where we’re always are focused for right or for wrong, but I want to be very clear that we don’t hang up this call and people think I think automation equals DevOps.
Mike Pfeiffer:
Yeah. It’s something that I have to keep bringing up as well when I’m talking to people because there is that thought that, oh, I wrote a script and we’re doing DevOps and that’s not the case. You’re actually famous for defining DevOps from Microsoft. I’ve seen so many articles and different things where, different Microsoft sites saying, what is DevOps? And then you’re the guy who is quoted by defining it. Maybe you could share the definition with us so we know what it is just beyond automation.
Donovan Brown:
Sure. So it was funny story. I remember when I got asked that, it took me 30 days to write the sentence that you’re now seeing all over the place. I reflected over my own career at Compaq computers, I reflected … There’s another blog post that proceeds the definition, which I think is also pretty interesting. Where before I attempted to define it, I asked myself, why are we even using this term? Why is it even a word? Let alone why, let’s not worry about what it is. Why is it a word? Because 20 years ago when I was writing software at Compaq computers, we were using this word. Why is this word important right now?
Donovan Brown:
And then that blog post kind of focuses on the fact that I think it’s because that’s what hurts the most right now. And what I meant by that is we’re all on this agile transformation. Everyone I think has finally agreed that agile is not a trend, it’s the best way to write software using scrum or agile or some flavor of Kanban. We’ve gotten really good at producing an increment of Shippable software, and that’s all that agile requires.
Donovan Brown:
If you look at the manifesto, the end statements said eight potentially shippable piece of code. They don’t give you any help or guidance whatsoever on how to ship it. They just say it better be potentially shippable. And then you’re like, great, we’re doing agile, but how do we now get it into the servers? Oh well, all of a sudden we need automation and we need infrastructure’s code and we need continuous integration, all these things that we are now grouping in as DevOps, to be able to take that increment of shippable software and actually ship it.
Donovan Brown:
And that’s when it kind of dawned on me like, well, the reason that we’re talking about this now is because it’s what hurts most right now. Producing the increments of code are now easy, but deploying them are still painfully bad. And that’s why I think we’re using this term called DevOps. So what is it? And at Microsoft we define it as the union of people, process and products to enable continuous delivery of value to our end users.
Donovan Brown:
And I wrote a medium blog post not too long ago called dissecting the definition. Because I get asked all the time, well Donovan, why did you use the word people and not culture? It’s all about culture. And then I have to argue, well, there is no culture without your people. Your people are what breathe and live and manifest your culture. And not to mention people are the biggest deterrent to adopting DevOps. It’s not your culture. It’s the people who refuse to believe, who don’t think it’s important, who’ve been doing it the same way for 30 years and have no intentions of changing tomorrow what they’ve been doing. So it’s the people that I thought were so important.
Donovan Brown:
And then I also use the word products versus tools. And generally the industry is using the word tools instead of products. And like why did you choose that? And I’ll see some people misquote me and still replace it with tools. I’m like, “Well, the reason why it was for me that tools alone aren’t enough.” And let me be very specific, I use an analogy like say for example, I were to say a hammer and a saw. No one will argue, those are definitely tools, a hammer and a saw. But if I were to ask you get a hammer and a saw, build your house, the answer is no.
Donovan Brown:
The hammer and saw did not build your house. A subcontractor, a carpenter, that’s who built your house and what they did is they wielded the hammer and the saw. Now I would think of things like PowerShell, fantastic tool, Bash, fantastic tool. Can I build an entire DevOps pipeline with just Bash or just PowerShell? Even if you could, I would recommend that you don’t, that’s not what you want. What you want is a product like Azure DevOps or even just the release management feature of that to wield these tools for you to build that pipeline. It’s the products that you want, not the individual tools and then that’s why I don’t use the word tools in the definition that we have at Microsoft.
Donovan Brown:
And then process is universally accepted. People say culture process tools or people process tools or people, but I was like, “No, it’s people, process and products coming together.” And then what I also focused on was this is not about changing software. The original definition when I wrote it and I probably had three or four renditions of the sentence that had been modified before I ever went public with it. And again it took about 30 days for me from the first writing to the last writing, and I did have the word software in there for a while. I did have the word tools in there for a while, but I actually talked myself out of it just like I’m discussing it with you and realized that that’s not what we need to be focusing on.
Donovan Brown:
But one of the words that was most important to me was getting rid of the word software and replacing it with the word value. Value is the goal, not software. We are not trying to worry about how many lines of code we changed or how many features we shift. What we’re trying to do is deliver a value to our end users. And when you focus on value, it really broadens your view. Because if you’re only worried about software, you’re interested about, okay, what functions do I use? What unit test do I write? What branching strategy do I use that software? That’s software, that’s what we’re focused on. Like, no, open up man, think about the value you’re supposed to be delivering. That involves your quality team. That involves your infrastructure team. That involves your developers. That involves project manager.
Donovan Brown:
This is not a developer thing. It’s called DevOps because you’re trying to combine the efforts of everybody involved from Dev to Ops, not just Dev and Ops, but everyone in between, which I think a lot of people miss as well. And I want to focus on value because I always use Black Friday and Cyber Monday as examples. When those days are coming, do I have to change a single line of my software to deliver value? I’d argue you don’t, all you need to do is scale up or scale out your infrastructure, your app already works.
Donovan Brown:
You just need it to work a lot. You need it to work for tens of thousands of people that are going to come over the course of the next weekend that weren’t there yesterday and won’t be there by Tuesday. And all you have to do is skill up your infrastructure and now all of a sudden you’ve delivered value and that should be the focus, not delivering software and not just delivering features. And another reason I love using the word value versus software is that it doesn’t alienate anyone in the conversation. When I say software, all the ops just turn off, like he’s not talking to me.
Donovan Brown:
And what’s funny is that I have some operations people that report to me who would say every operations person is a developer, even if they don’t want to admit it. Those ARM temperature writing, those PowerShell scripts that you’re creating, those infrastructures code files, that’s code. You’re a developer right now, but we won’t get into that. That’s for another show. But the thing is I don’t want to alienate anyone, so I don’t want to say words like software. I want to say words like value that we can all agree upon. And I think that brings everyone into the conversation.
Donovan Brown:
And I’ve also found that the word value is really helpful, when I go to companies and they say, Donovan, our Dev teams and our operations teams, it’s almost like they don’t like each other. They don’t speak to each other, they’re always pointing fingers at each other. They have a very adversarial relationship. And I asked him, so talk to me a little bit more about your organization. How do you incentivize your operations team? And they say, well, it’s all about uptime, keeping the lights on, keeping it safe, and keeping it healthy. It gets interesting. How do you incentivize your developers? It’s all about adding features and innovating.
Donovan Brown:
I’m like, great. So the easiest way to keep a server healthy, don’t change it. If the server is healthy, leave it alone, it’ll stay healthy. But you just told your developers to attack the servers and change them as much as they possibly can so that they get the big bonus. So what does any operations person going to do? They’re going to defend the servers from every change they possibly can. They keep the uptime high so that they get the big bonus. You’ve incentivize these two teams to work against each other. I would be shocked if they didn’t work against each other given the way that you’re incentivizing them.
Donovan Brown:
And it’s funny because no matter what level of the organization I’m talking to when I say that you see them like this epiphany, like, oh my God, how did we not realize this already? Again, it takes someone from the outside to say the obvious. It’s freaking obvious. But if you had those two teams focused on delivering value and you reframe the conversation to say the only way that either of you get rewarded, the only way that either of you get acknowledgement and recognition for doing a good job is if we can measure the value that you as a team delivered to our end users. Holy mackerel. Everything changes. Teams now start to work together and then value drives the fact that we have to measure what we’re doing in production.
Donovan Brown:
So that one sentence, and I remember I got a lot of challenges about, Donovan, you can’t define DevOps in one sentence. I was like, that sentence is a springboard for a much larger conversation that we’re going to have. I’m not going to sit here and try to beat you to death with paragraphs of culture and people and process, I’ve seen some really ridiculously long definitions. Like, no, the definition is to spark a conversation and they get people thinking about how they can change their organizations to continuously deliver. So that’s a long winded way of explaining to you how that definition came to be.
Mike Pfeiffer:
That’s super important man, because I think that a lot of people just gloss over it and not put the level of thought that you just shared with us. That’s important. And I’ve noticed a lot of the same things that you said and I love that you focused on delivering value versus … A lot of people are focused in on the low level details, especially the people in the trenches. And so they lose the bigger picture view of what you just said. And I think that people listening to this, it’s going to be a light bulb moment for a lot of people because I’ve gotten into a lot of places as well to try to implement some of these more progressive patterns and practices.
Mike Pfeiffer:
And in the early days I was like, “Oh, this is going to be easy because I’ve got the technology figured out.” And I’ve shared this on this show many times. I was always surprised in the early days that I realized it was more of a culture thing or more of a mindset or human elements of people working together or a lack thereof, that was the hardest parts of doing this type of stuff.
Donovan Brown:
Yeah, the people problems are the worst problems. And I say that, I usually show the definition on stage during my talks and I put my laser pointer and I just roll it back and forth under the word people, that’s your biggest problem. The rest of the stuff we have figured out already, and I’m not telling you anything that you don’t already know. So the problem is, is that your peers should be sitting next to you and they’re not. They’re at work right now, mad that you’re not even here and they’re going to put a kibosh on anything that you bring back here saying, get back to work, we really needed you here yesterday and you weren’t here. We don’t have time to do continuous integration. Just get back to work. I’m like, “Oh my gosh, you’re completely missing it.”
Donovan Brown:
The people just don’t get it. They need to understand that this is not a nice to have, this is not optional. You either implement DevOps or you lose. It’s that easy. And we have so many examples of where Netflix completely disrupts Blockbuster. Uber just comes in and changes transportation. Why? Because they thought differently. And some of these people don’t even know how to have the fight. They don’t even understand the fight that they’re in against these new companies just springing up out of nowhere, completely thinking differently, born in the cloud and rubbing DevOps on everything and making it better.
Donovan Brown:
And people are like, what is happening? Why isn’t waterfall working anymore? Waterfall actually never worked really well for you. You just didn’t notice because everyone was doing it. So we were all running slow, but now all of a sudden I guess I’d either implement it or you lose, the choice is yours.
Mike Pfeiffer:
I really agree with that. It’s been an interesting journey for us at my company in some of these things. But what you’re saying is really hitting a lot of stuff that we’ve seen and stuff that I’d been through. I’m excited for the people to hear this episode because I think the message is really important. One of the things I wanted to back up though and talk about, you mentioned earlier when you’re talking about your backstory and starting out. I started out working at AOL, that was my entry into tech industry. And then I worked for a big computer manufacturer kind of like you, but I never went to college for computer science and I never finished. And I kind of had to elbow my way in at those places, kind of like you and then prove that I could do it before I actually got put in the game so to speak.
Mike Pfeiffer:
And I realize now you are managing a big team of people and I think your team just doubled in size. And I’m wondering, currently now that things are completely different in the industry, there’s a big opportunity for people to come in when maybe they didn’t go to college for technology, but now they can get into doing things like DevOps and some of these things we were discussing. So I’m kind of curious, is that something, the people that work for you or that you see in the industry where there’s huge opportunity for people to come in where they might have think that they can’t do it?
Donovan Brown:
That’s interesting because I have a degree in computer science, I actually did finish my degree. Don’t think that it helped me much, I’ll be perfectly honest. I always give my parents a hard time it’s like, “If you’d let me drop down, I’d be rich like Zuckerberg.” All the billionaires I know, all dropped out of school, you didn’t let me drop out. So I didn’t think I had anything to prove. I just went through the motions with everyone. But I value experience over paper every day, all day. Matter of fact, I have a collection of people underneath me now, some have degrees, some don’t, couldn’t care less.
Donovan Brown:
And we only find out through a weird conversation or it might come up, but none of us are asking like, where’d you go to school? What was your GPA? What did you study? No one cares. Do you know what you’re talking about or do you not know what you’re talking about? And now what we see on social media, what we see in blog posts, what we see on videos will still outweigh anything that you say. I look at your transcript from your college. I’m not asking to look for that. But when I Google Donovan and all I see are DevOps talks and videos and blog posts and pictures, I’m like, “Holy crap, this guy probably knows what he’s saying.”
Donovan Brown:
I didn’t go to school for DevOps. There was no DevOps course back at university of Houston when I went there. So another thing that I learned in the industry in which I work came from my education. I think you just need to find something that you’re passionate about, that is the most important thing. Find something that you would happily do for free. Well, I’m not talking to you and as soon as we hang up, I’m going to go start building a pipeline for ACR because I want to go figure out how I can make that better for our customers, because I just get off on that kind of stuff.
Donovan Brown:
And I’m not going to learn that by going back to university. I’m going to learn that because it’s something that I’m passionate about. It’s something that I would spend my off time doing. It’s just what gets me going. And that passion is what drives me. And I think that’s what has allowed me to get to the point in my career where I am. Because when you meet me, you can feel it, you can see it. And what’s interesting is that when I’m face to face with you, what I’m being told is even more intense because people have seen me on videos and then they’ll come and see me speak live and do the exact same talk and they’re like, “Holy crap, it’s completely different because it’s almost like you can feel the passion coming off of you on the stage because you’re leaning in on us.” I’m like, “Dude, this stuff is awesome. It can change the way you live your life.”
Donovan Brown:
Honestly, I feel that way because if you implement DevOps correctly, you get your nights and your weekends back. That’s time with your friends, time with your family. That’s time for you to just decompress. You’re not fighting fires this entire time, and I know this personally because I am a developer, who’s been exactly where you are and I can see it can be better than this. So that passion comes off the stage. No one asks me about my degree. Very few people know where I went to school. So don’t let the fact that you don’t have a degree in any way deter you from going after what you believe that you’re passionate about, because that passion is intoxicating, people want to be near that.
Donovan Brown:
People want to lean in and learn more about what you’re passionate about when it’s genuine and it’s true. I would not recommend someone come into this industry for the money, because it’s almost like we can tell. I don’t want to work with a 9:00 to 5:00 programmer. When I used to interview technical people for programming jobs, the first thing I would ask them was, what was the last thing you wrote for fun? What was the last thing that you wrote that no one’s ever going to see that you just giggled about the entire time you’re writing it? What was that? And if I get the answer, oh man, I don’t touch a computer when I get home. I’m so tired of that thing, I just turn it off and not until tomorrow morning. You might as well leave now, this interview is over. Because that’s not the person I want on my team.
Donovan Brown:
The person I want on my team just geeks out over this stuff. Look at Abel Wang of my team. You bring up DevOps with Abel Wang, you will be talked to for about an hour about branching strategies and CI/CD and what we can do with Azure DevOps. You bring up Kubernetes with Jessica Deen, get comfortable, the girl’s going to go off on you about everything because she just loves that stuff.
Donovan Brown:
And I have people on my team and the people that I get around me are people that are just passionate. Some of them have degrees, some don’t. But when I spoke to them, I could tell that they loved what they were talking about and I needed that in my team. So don’t let a degree start or stop you. I think the best reason, the only reason I’m glad I have a degree. To me it’s a tiebreaker for me. I always said to myself, if I’m going for a job and all things are equal, that might be the tiebreaker. I have a degree and they don’t. Otherwise we’re the same person, that’s the reason I have that piece of paper. It gives you that peace of mind. Do I think in my 30 years now in the industry has it helped me? I don’t think it’s ever helped me once because I lead with a passion, I lead with Donovan, and they don’t give a crap about my piece of paper.
Mike Pfeiffer:
I really appreciate you sharing that insight because there’s a lot of people listening that are aspiring DevOps engineers or cloud architects or developers or whatever it may be. And there are probably, there’s a lot of them that are thinking, because I’ve had conversations with them where they’re like, they’re doubting that they can do it because they never finished or they didn’t go to school for that. And so everything you just said is super important. And I love that you brought up the fact that the people doing it for the money are always the ones, they’re your vulnerability. And to your point, if they’re not passionate, they’re going to be the ones clocking out right at 5:00. They’re going to be the ones basically punting the hard work anytime that comes up-
Donovan Brown:
The building could be burning down around you but it’s 5:00, we’ll put this fire out in the morning. No, that’s not how this is supposed to work. You should be amped up and ready to go and excited that we’re able to call off and do the cool stuff that we’re able to do. So yeah, just like I said, before we started, I’m an open book. So some of the things I say people agree with, some of them they don’t and that’s … I’m glad you’re enjoying it.
Mike Pfeiffer:
Yeah. And I think, there’s so many people listening that are wanting to get into this space. There’s a lot of talk about in terms of the technical side, working with the Azure DevOps suite of services. For somebody listening, what’s a good place for them to get started especially if they’re, maybe they don’t know a whole lot about DevOps in the past based before this episode. Maybe now that Azure DevOps is on their radar, how do they get started? What’s a good place for them to go?
Donovan Brown:
I got places they can go, first you can go to aka.ms/devops. That’ll take you to where we defined DevOps and a whole bunch of cool piles of information that can give you more of a theory around why you want to do this. And then you can just go to docs.com, D-O-C-S.com, and that’ll take you to the landing page of all docs Microsoft. And Azure DevOps is a tile on there and Azure is also a tile on there. And there it is just a rabbit hole of information that you can learn about continuous integration or continuous delivery, canary deployments or ACR, ACL, whatever you want.
Donovan Brown:
So the cloud and Azure DevOps are just these two tiles just waiting to give you all the information that you want. And the other thing is, believe it or not, my team is really active on social media. The number one way to get ahold of us is on Twitter. There’s a hashtag LoECDA. If you use that hashtag in any of your tweets, my entire team will see it and we will either answer you, we will add someone else from Microsoft who can answer that question for you. But that hashtag we always joke it’s like a Bat-Signal, when you throw it into a tweet, we’re all coming, we’re all going to read it and we’re all going to start trying to figure out a way to help you. So I would go to docs.com, I would go to aka.ms/devops, or go to Twitter and use the hashtag LoECDA and ask whatever you need to know.
Mike Pfeiffer:
I’m going to follow that advice personally. The documentation is amazing that Microsoft’s working on. I’ve been a big fan of it. I’ve been telling people that ask me what books should I get? I’ve been saying, hey go to the documentation because there’s an army of people literally working on a step every day. Like you were saying earlier, yeah, it’s open source so you can get in the game and then you can also look like you said and see when it was last updated.
Donovan Brown:
Exactly. And that’s another way that you can start to get your name out there as well. It’s funny, so I’m reading a lot about ACR lately and I went to a couple of tutorials and I was like, “Hey, that’s not right or that’s confusing.” And I just hit edit document up in the right hand corner, took me to get a repo, I toned it, made the changes, pushed it back in, it started to pull request. And then you hear the actual doc owner is like, oh, that’s great feedback, thank you so much. The next day you go to the doc and your changes are in the doc. It’s like, that is freaking awesome.
Donovan Brown:
And what’s in the icing on the cake is now my picture shows up at the top as one of the contributors to the doc. So now I look like an ACR expert. It’s like, this is awesome. I’m helping the doc to get better and now I’m actually getting credit for it as well. So your brand starts to get a little bit better. So yeah, our docs are getting a lot better. Are they perfect? No, but that’s why they’re open source, so there’s no excuse. If you see an error in there, you can definitely go back in and make it better for the next person.
Mike Pfeiffer:
I said that a few months ago on Twitter and I was like, “Hey, if you’re going to complain about the documentation, just stop and go in and issue a pull request. Don’t complain, get in there and help, contribute.”
Donovan Brown:
The next person is going to appreciate it for you. And what’s going to happen hopefully is if you keep paying it forward, you’re going to be the next person one time and you’re going to be glad that someone went in before you and fixed the document.
Mike Pfeiffer:
That’s right. Yeah, totally. So when it comes to … when people are getting started with this stuff, they go to this documentation. There’s a lot of great tutorials to get up and running. Is there a common thing where you’d see people running into problems or hitting confusing points? Anything that might mitigate some issues that newbies might run into?
Donovan Brown:
One of the things I think they need to be aware of, I don’t know if it’s a sticking point, is that a lot of people have the misconception that Azure DevOps is for .NET and Windows only. That’s one of the things I have to answer over and over and over again is like, no, it doesn’t matter what language you program in, it doesn’t what platform you target. You can use these tools, so also don’t let the name Azure DevOps confuse you. You can deploy to AWS, you can deploy to GCP, you can deploy on prem, you can deploy to phones, you can deploy IOT. The name is a misnomer. What you need to focus on are the features and the technologies inside which are, we’re kind of tracking for all your Kanban boards, backlogs, your task boards. There are source control, it’s basically like GitHub, but it’s private.
Donovan Brown:
And we also have centralized version control, which used to be really popular in the past and still really good for large binary type of versioning. If you have a lot of binary assets, it’s a great technology for that. So we offer two different versions of version control. We also have, my favorite feature is our pipelines feature. It’s our CI/CD pipeline, it’s freaking ridiculously good. And it works on Mac, Windows and Linux on prem or in the cloud, it’s just phenomenal. I’ve built, the most ridiculous demos in the world, are always centered around that product, and like watch what I can do and then I’ll go and push one button.
Donovan Brown:
There’s a demo I did recently, I got on stage and I walked through a disaster. Because every disaster starts with a phone call. So you hear the phone ring and someone’s telling me my website’s not working, like whatever, it’s just cache. So I go to the website and lo and behold, I type in the URL and the page doesn’t load. So I’m like, let me try the mobile app. And I show you, you can see my mobile app while I’m using it and I open the app and the app instantly starts crashing, you can’t even load it. I’m like, holy crap, what’s going on? So normal processes you go and you try to see what’s happening in your Azure resources. I log into my Azure account and there’s nothing there. All my resources had been deleted, everything. There is no resource groups, nothing.
Donovan Brown:
And normally this would be like fire up your dice.com or monster.com and go find another job because you’re about to get fired because everything is missing. There’s no way you’re getting this up on your own. So what I do is I click one button and I just start talking to you and lo and behold, it deploys all the infrastructure, deploys a new EKS cluster, calls into GoDaddy updates the IP address in GoDaddy to point to the new cluster that just got split up with an IP address, I didn’t know five minutes ago, hit refresh and the browser’s back, open my mobile app and I’m using the app again. I’m like, that’s what you should be aiming for.
Donovan Brown:
The entire system can be destroyed. You push one button and the entire system is back. IP address is updated in everything, so that a disaster recovery is just a deployment, that’s the goal. And that’s what Azure DevOps can do for you. It’s unbelievable when you see the potential of that product and that’s all done through pipelines, which is awesome. Then we have testing and we have artifacts, so it’s unbelievable. One of the things I have to tell people, like you say people get caught up on is, they think they can only do .NET on Windows and that demo does containers, it does mobile, it talks to all three platforms. I’ve build docker images on Linux. I’ve build a Xamarin application on a Mac. And I build web services and stuff on a windows machine and I’m doing all this stuff with the click of one button in a single pipeline, it’s unbelievable.
Mike Pfeiffer:
That is a pretty sexy demo. I spend a lot of my time in pipelines as well and I agree that that’s one of the most impressive offerings in the suite of services. I geek out on that stuff too. That’s mainly what we focus on in my business and my consulting stuff. And that’s just something I’ve seen you guys iterating constantly. Things are always getting better and it’s pretty compelling. It’s cool to hear that you actually tied in a third party service like GoDaddy into your pipeline. And you’re just calling their APIs through one of the [inaudible 00:32:49].
Donovan Brown:
Yeah, so what ended up happening is as I was thinking to myself, I’m going to destroy my cluster and I’m going to spin it back up and when I run my helm chart, I’m going to get a completely different IP address than I did before. So what am I supposed to do? I don’t want to manually go, especially I’m one stage at a keynote at BSI. I’m not going to run in to GoDaddy log in and try to update the IP and wait for it to go through, propagate through my DNS servers.
Donovan Brown:
So I went to GoDaddy and I looked to see if they had a REST API. Because as you should probably know by now playing with Azure DevOps, if there is a REST API or a command line that already exists, you can do that inside of your pipeline. If we just expose those as endpoints for you to go and talk to, it’s like, all right, cool, there’s a REST API inside of GoDaddy. And I’m a huge PowerShell fan and I wrote this module called VSTeam that uses the REST API from Azure DevOps, allow you to manipulate Azure DevOps. I thought, okay, what I’ll do is I’ll write a PowerShell module and it’s actually in the PowerShell gallery now and it’s called Trackyon.GoDaddy that allows you to call their REST API just using normal PowerShell. So I just pass in, here’s my key, here’s my DNS record and here’s the new IP address.
Donovan Brown:
That one line goes to Go Daddy, fixes everything and then it propagates through your pipeline. But I’m doing it now as a task in my pipeline. There’s no human intervention there. I grab the IP address that was just deployed as part of my pipeline. I know that it’s going to be peoplechecker.us. I mean that’s always the name of my URL. And then often using secure passwords inside the pipeline, and every time I run my pipeline, it’s a safe command to go back and say if it’s already the same, it’s just the same, it’s a no op.
Donovan Brown:
But now my pipeline literally does everything. So when I want to do that demo, I just literally, before I get on stage, I delete everything in my account and then I walk on stage and I’m ready to go. How cool is that? So yeah, pipelines is awesome.
Mike Pfeiffer:
Yeah, that’s really insanely cool. Now that you’ve inspired me to try something, an idea popped to my head so it’s going to be really cool. But for people that are listening that are maybe super brand new to this stuff, maybe we could kind of outline from a high level what does a full CI/CD pipeline look like? Because I think there’s a lot of people that obviously listen to show know what that is. But then there’s others that are here, the CI/CD pipeline and they’re like, not really sure what that is. Let me get stuck through it from a high level on maybe some of the services that are available from Azure DevOps and how you connect them all together to build that in pipeline.
Donovan Brown:
Yeah. Let’s talk about it without Azure DevOps. Because I don’t want it to feel like a sales pitch in the concepts of CI/CD are agnostic. You can find plenty of tools that can do this for you. And I’m a big fan of just go find the tool that works best for you. It doesn’t have to be Azure DevOps. I would investigate ours though because it’s awesome. But let’s talk about can CI, which stands for continuous integration. It’s the process upon which every time a developer commits code to a repository, and a repository is this central location where all your code gets version. So if I have a file and I change it five times, it’ll actually have five different versions and I could go back to one of those previous versions called a repository.
Donovan Brown:
And what a developer’s going to do is they’re going to make changes on their local machine and to share them with the rest of the team, they have to then commit them to that central repository. What’s really cool is that your CI system is monitoring that repository. So every time a developer makes a change, it recognizes that, oh, there’s been a new file, let me go back in and download all those files for you and try to compile them. Because what happens, and it happens a lot when I was younger, is a developer might have something specific on their machine that allows it to build for them, but not build for anyone else. They forgot to check in a particular file or they have a library dependency they forgot to register.
Donovan Brown:
And historically what would happen is everyone else on the team would go and grab the latest code and then they’d all be broken because they didn’t have whatever dependency or file was needed, and no one would know until all the developers were broken. What a CI system can do instead is it can be the person that gets broken while everyone else continues to work and then it’ll send up a flag saying everything is either safe or there’s something wrong, and then notify the person that, hey, your code doesn’t build, you must’ve forgotten something. Here’s the error that I got and then you’re, oh crap, sure, hold on, let me check in this other file. Now all of a sudden everything works and then everything’s happened.
Donovan Brown:
So a CI system, fundamentally it’s about integrating your code and making sure that it all works. Now you can do a lot more than just compile the code in a CI. You can compile the code, you can test the code, you can run linters, static code analysis. You can run security scans. There’s a ton of stuff you can put in there. At time zero, most people just compile it, make sure that it works, and then they try to copy it to a server somewhere using their release pipeline. But the landscape of CI continues to grow as our industry continues to change.
Donovan Brown:
There’s more things we need to do and what we call it shifting left is you want to do it earlier and earlier in your process, which is getting it either inside the ID that the developer is working on, which is about as far left as you’re going to get it, is it’s on the desktop with a developer. They’re doing the scanning, they’re doing the linting, they’re doing the unit testing, they’re doing everything.
Donovan Brown:
Well, just to the right of that is the CI environment. That’s where it comes to a Virgin machine that’s completely clean to make sure that every person should have the same experience, because you don’t want to do CI necessarily on someone else’s machine because they might have the dependency that everyone else is missing. You need it to be a clean common, I mean a clean machine that can be like, I am the truth, if it works on me, it should work on everyone, so that’s CI.
Donovan Brown:
Once you’re done with CI, the end result is usually some package unit of functionality or waterfall if you’re doing Java, maybe it’s a library or a package or a zip file or MSI, whatever the case might be. You’ve produced something that you now want to be able to give to your end users so that they can actually use your software. And what we do before we give it to our end users is we run it through a CI/CD pipeline. That CD part is I have a dev environment that I can then test installing everything on and then make sure it installs correctly, maybe run some more aggressive tests because inside of your CI system you run unit tests, which are completely isolated.
Donovan Brown:
Now that you’ve deployed everything, you can run what we call integration test, which is making sure all the parts work together as a unit. You can do that in your pipeline. Performance tests, you can do in your pipeline. Additional security testing, you can do in your pipeline now that the system is stood up. And that might be happening on a dev environment. You might then want to repeat a deployment to another environment where you’re going to let it sit for a while, while your manual testers have a time to look at it, your UAT environment, your QA teams going, they run manual tests that for whatever reason are too expensive or too hard to automate.
Donovan Brown:
So they’re going to go manually do some spot checking to make sure that the app looks good and then eventually you’ll just keep on repeating this until you end up in an environment called production. And that’s where the CI/CD come together is that, that can be fully automated, semi-automated, but the thing is that you’re going to automate as much of that process as you can so that your people can focus on what people are good at being creative and not the mundane, stupid, repeatable tasks that we don’t want them doing anymore. Hopefully that gives you an idea of what CI/CD is. Although sometimes people say delivery, other people say deployment. The whole point is that we’re trying to get your code into production.
Mike Pfeiffer:
I think it really is helpful. I think that a lot of people might overthink it or think it’s more complicated than it actually is. I think that explanation really helps a lot and unpacking that for people, I’ve done that kind of in the past, had that conversation. And I’m usually surprised by the fact that they’re, oh, that’s way easier than I was expecting. I think that that’s really helpful.
Donovan Brown:
What I think is really surprising and scary to me is that I was in Switzerland right before this call and I asked the audience, how many of you work on a team that does not have continuous integration? And I have yet to find an audience where someone doesn’t raise their hand. And I always think to myself, it’s freaking 2019, how are you working on a team that does not have continuous integration? And then I also asked, I said, “How many of you that raised your hand a second ago have actually tried to implement it or asked, try to convince your peers that it was a good idea?” And everyone raises their hand again. I’m like, “That’s your mistake. You asked for permission.”
Donovan Brown:
You asked for permission to do your job. It’s your job to continuously deliver value. Even if you don’t buy into my definition, that is your job. And you’re going to tell me that you know that this is going to make you more productive. You know it’s going to make you more efficient, yet you think you have to ask permission to do it. One little secret about CI, no one on your team has to know that you’ve enabled it. So why am I going to go have to ask permission to not bother you, to not interrupt your way of working and we give you the tools for free. So why am I going and asking people’s permission, just go implement it. And when someone else breaks the build, you’ll be able to continue to work because you know the build is broken, while everyone else is sitting there complaining because the build is broken and they all got the latest version of code.
Donovan Brown:
And so what’s going to be funny is the day they come over to you and ask you, how are you still working? And you get to explain to them what CI is, not try to convince them ahead of time that you should do it. That proof, those results that you’re going to be able to show immediately is going to completely change the conversation and everyone’s going to want to buy in on that. So come on, it’s free and it doesn’t take long, go set up CI.
Donovan Brown:
If you’re listening to my voice right now and you do not have continuous integration, just go do it for free and ping my team if you get stuck. I mean, I’m that passionate about that. It’s just, to me it’s ridiculous that we’ve made it this far and people still don’t have it.
Mike Pfeiffer:
That’s such a good point. The way to convince people is to show them and get their buy-in based off of, hey, that’s working, I should do that. Yeah. Instead of trying to, yeah, I love the bias for action, just diving in and solving the problem, adding value. I love the narrative there. One of the things I wanted to ask you about kind of personally biased because it’s something that I’m curious about. I’m spending a lot of my time writing ARM templates lately over the last couple of years, and a lot of people don’t like JSON. A lot of people complain about it. I don’t really mind it because I spent years doing cloud formation templates and AWS. And so when I hit ARM templates I was like, okay, I get it. It’s pretty verbose and I understand the pushback from people. So are we going to get YAML based templates or what’s up with that?
Donovan Brown:
Okay. It’s interesting that you bring this up, because I’ve been going back and forth with the ARM team recently. I’ve been pretty vocal on Twitter lately. I’ve written a couple of blog posts where I have started using the Azure CLI instead. Because not only is JSON verbose and our JSON is verbose. You setting up an ARM template, that’s not a trivial task. In my opinion, we simply do not have the offering right.
Donovan Brown:
The creation of an ARM template in a perfect world, you don’t have to see the JSON if you don’t want to. That’s the Holy grail. Because ARM is an extremely powerful technique and technology, it’s amazing. The fact that it can figure out your dependencies and deploy in parallel those items that don’t depend upon each other is much fashion that you’re going to do with even the Azure CLI. Because the Azure CLI doesn’t let all the tasks run asynchronously, but ARM can figure that stuff out for you. ARM is also determined, I mean the way that you, declarative versus like hear somebody say, this is what I want. You don’t have to tell it at all how you do it or what order to do it in. This is what I want and it’ll go make it so.
Donovan Brown:
It’s also complete, which means I can run it against the resource group that already has stuff in it that I no longer want in it and I don’t have to say delete it. It just realizes that it’s not in the ARM template and that needs to go be deleted. So ARM on all those levels, fantastic technology, offering it, miserable. It’s miserable having to go through a 300 line ARM template, trying to figure out what parameter you forgot or even knowing what shape that JSON is supposed to be and for the resource that you’re trying to create, it’s miserable.
Donovan Brown:
And I’m not even, I never bite my tongue on the fact that we have to fix the offering of it. The technology growing it, the offering miserable. And we have to fix that to the point to where, I remember the way I learned about the Azure CLI is because I had done some cool stuff with the ARM template. I think I had just written okay or auto greater for Azure DevOps using an Azure function and wrote an ARM template that actually deployed a key vault, a Azure function, some other cool databases, medical stuff, all with this one ARM template.
Donovan Brown:
And I think I tweeted, ARM is awesome. And I got blasted on Twitter that ARM is horrible. It’s the worst, it’s like editing sucks, you should be using Terraform, you should be using Azure CLI. I knew about Terraform but the Azure CLI caught my attention. I’m like, hold on, I need it to be item potent. And the guy said, Donovan, it is. And then I had my GitHub repository linked in the original tweet. And the guy looked at, it’s like 200 line ARM template and wrote seven lines of CLI that did the exact same thing. I’m like, “Holy crap.” He said, “Donovan, you can run this a million times in a row, if the artifact is already there, it does not air out.” I’m like, “No way.”
Donovan Brown:
And I’ve completely switched to where all the demos I’ve done lately are only using the Azure CLI. Given that, all the things I just mentioned about what makes ARM great, you have to manually do yourself. All right, so there is a trade-off there. My demos, and demos in quotes is like, these are throwaway demos, these are demos that I’m going to do on stage and then delete everything, so I don’t have to worry about what if I want to delete that resource in the future. That I’d have to actually script inside of my script. How do I get some of these tasks to be asynchronous where all of them don’t support it already? So there’s a trade-off there and I want to be very clear on that.
Donovan Brown:
If you’re already comfortable with ARM, I would stick with it. If you’re already really good at willing those things, more power to you, but it’s really tough to author. Now to your original question, when are we going to get YAML based ARM? You know there’s already an extension for the Visual Studio Code that’ll swap between JSON and Azure and YAML for you.
Mike Pfeiffer:
I have not seen that. That’s really cool.
Donovan Brown:
Yeah. I found that out when I was getting blasted on Twitter. [inaudible 00:45:37] was cool. That was such a fun tweet because it went on for way too long, but I learned so much stuff. I learned about all the extensions for Visual Studio Code that will swap between JSON and YAML. So if you prefer YAML, you can literally write it in YAML and when you save it, it scribbles out JSON. So you get the ARM template that you need for Azure, but you get to write it in a much more concise way using YAML instead. And it just swaps between them, that’s the one of them.
Donovan Brown:
The other one was there’s some IntelliSense plugins that you can use and that makes ARM a little bit easier. We obviously have the ARM resource group project inside of visual studio. And then I also found this website and remind me, I’ll get it to you for your show notes that literally shows you the definition in the shape of every resource that you need to put in your ARM template and every version of it. You can go to this website and say, I want to create an ACR and you click on the link and then there’s a sample blurb of JSON, versus you having to figure it out or go find a sample that already has it. We have a catalog of what all those things are supposed to look like in your ARM template, which makes life a little bit easier as well.
Donovan Brown:
But I still can’t get away the sheer readability of Azure CLI is so much better, because it’s just PowerShell. I can do comments in there. I can do a lot of cool simple looping structures, I can call them methods, I can load up the PowerShell script. It’s just like I have all the power of PowerShell and I’m using infrastructure’s code thanks to the Azure CLI. And that’s what I’ve been running with probably for, I don’t know, five or six months now.
Mike Pfeiffer:
Nice. Well, I think I might’ve seen the extension that helps you convert the JSON templates to YAML but I never went down the rabbit hole, so I’m going to double check that. I wonder maybe no if, because you can obviously go into Azure portal, export your resource groups to template that goes on in JSON. Can you take JSON and turn it into YAML if you already-
Donovan Brown:
You can. The way the extension works is that you give it a JSON file, it shows it to you in YAML, you modify it in YAML and then it always writes it back out as JSON. So it’s just an extension that goes into it.
Mike Pfeiffer:
Got it.
Donovan Brown:
Now you were talking … I used to do what you’re describing, but the JSON that you get out after you’ve deployed the resource is drastically different than what you would’ve gotten before you deployed. So what I do now, if I don’t know how to create something is I’ll start clicking through the wizard and you get to the very last age and there’s a button that says automation. If you click on it, it gives you a much cleaner JSON file to start from than the one that you get after you deploy, and then you get deployments are in there and there’s all this extra baggage inside the ARM template that you don’t need when you’re actually trying to create the template.
Donovan Brown:
So if you do want to go that route, I would recommend clicking the automation button before you click on create and get that ARM template and not the one that you get after you’ve deployed everything and then you export it. I found that second ARM template much harder to do.
Mike Pfeiffer:
That’s an awesome tip. I’ll circle back with you outside of this show and add that to the show notes, with that site that you were talking about that generates the structure for the resources, is that a Microsoft site or is that?
Donovan Brown:
Yeah, it is. It’s in our docs. I go and I meet a lot of our customers and I was there talking about DevOps and we had three different ARM experts in the room from Microsoft and one of them did a demo and that he brought up that site. I’m like, “Holy crap, where’s this been?” I needed this a long time ago because I have to go find samples or I do what you’ve done. I’m going, I’ll create it manually. But unfortunately, if what you want to set is a default, it’s still not in the JSON. It just omits those. I don’t know where in the object that value is supposed to be, so I can set it to whatever I want to set it to.
Donovan Brown:
But yeah, there’s that whole website. It’s a Microsoft website. I will find you the link and it shows you the whole catalog of all the resources are there, you click on it and even has the different versions of the API because you have to version the resource. It shows you each version and then what the shape of the JSON is for that version. Pretty cool.
Mike Pfeiffer:
Awesome. I’m going to check it out. I know that you’re super busy. I could go on in talking to you about this stuff all day, man. This is really fascinating. I love it. But as we wrap up here, I’m going to add a bunch of stuff to the show notes, your blog, all the videos you have on channel nine, stuff like that, the documentation that we talked about. Any other resources that we should point people to before we wrap it up?
Donovan Brown:
Like I said, docs.com is a fantastic resource to get to. Twitter again, my entire team is there, we’re extremely active. You can actually talk directly to us and get right to the product group and that is the number one way to get ahold of me or my entire team is just to get on, follow us on Twitter and let us help you.
Mike Pfeiffer:
Awesome man. Well, once again, I really appreciate you taking time out of your super busy schedule. Donovan Brown, principal DevOps manager for Microsoft. Thanks so much for being on the show.
Donovan Brown:
My pleasure, man. Thanks for having me.
Top comments (0)