Nigel Kersten and Michael Stahnke share insights on the state of the DevOps industry and key trends in 2021.
Hear about the behind-the-scenes process of creating the 2020 State of DevOps Report. Nigel Kersten and Michael Stahnke dive deep into the data that drives the narrative of the report and take us on a journey dissecting numerous conversations with IT DevOps practitioners and decision makers alike in this episode.
Learn more
Demetrius Malbrough [00:00:20] Hey, everyone, thanks for joining this episode of Pulling the Strings podcast powered by Puppet. I'm delighted to be your host. My name is Demetrius Malbrough and I'm on the product marketing team here at Puppet. I'm really excited today to talk with Nigel Kersten and Michael Stahnke. Nigel has been a leading coauthor on the industry-leading State of the DevOps report for the last nine years and works with Puppet's largest customers on the cultural and organizational changes necessary for large scale DevOps implementations. He loves cognitive science, synthesizers, and Test cricket. Also, Michael is VP of Platform at CircleCI, running SRE, Security and Tooling, and prior to this, he worked at Puppet running Puppet Enterprise Engineering, Platform Engineering, as well as SRE. He is an established author, where he has coauthored State of DevOps reports and State of Software Delivery. He's also a popular speaker and has attended various DevOps days, CTO summits, Puppetize conferences and more. And he founded the package repository EPEL and wrote a book on SSH in 2005. So great bios and it is a pleasure to have both of you on Pulling the Strings. Nigel and Mike, how are you today?
Nigel and Michael [00:01:48] Doing well, doing great. Thanks for having us.
Demetrius Malbrough [00:01:50] All right. Well, fantastic. Let's let's see if we can rally up everything within you to have a very exciting conversation about several things. So one State of DevOps report and also some of the things that that you found out, you know, researching and writing about details on that report, et cetera. So let's dove right into some questions. So why is it important to measure the State of the DevOps industry right now? Mike, let's start with you.
Michael Stahnke [00:02:23] Well, I think measurements, you can't improve what you don't measure, I guess, is it was a common saying in a company I used to work at the may or may not be sponsoring this podcast. But if you're not measuring things, you don't know how you're doing. You can't improve, you don't know where to spend your time, and where you want to move. And so for us, we've been measuring for ten years or I guess 2021 it'll be the tenth year that we're doing this. But this is about the 2020 report. We've been measuring for nine years on what's going on in DevOps. And we'd like to look at trends over time, look at what's change, what's improved. But right now, the things we're trying to measure are, we kind of evolved early on from: Is DevOps the right thing? Is it something we should believe in? Does it have good outcomes? And then it went to, OK, we're pretty sure that most places are convinced that DevOps is a thing and it's a good thing. But how do they get there and how do you get more prescriptive? And so in 2018 we pivoted a lot more to measuring, what are the things that indicate success versus just what is high performing DevOps versus not. So right now we're really looking for what are the things that breakthrough and what gets you to the next step in your DevOps evolution.
Nigel Kersten [00:03:26] So to jump onto that, I think, you know, the thing you said there about you can't improve what you have or you aren't measuring. To be pretty blunt about it, things are pretty bad out there, right. In general, like DevOps practices have made a big difference. You know, there's a bunch of people and bunch of organizations that have significantly improved. And we've seen individual teams inside organizations improved dramatically by adopting these practices. But what I see over and over again and what we've seen from the last few years of the report and just from anecdotes from the industry is that people are really struggling with how to succeed organizationally. And those problems are really, really difficult. And so I'd say the reason it's really important for us to do a State of DevOps report each year and to keep looking at the space, seeing what people are actually doing is we've got to work out how to get ourselves out of this mess. You know, people are doing really good greenfield deployments using DevOps practices, but the number of companies that are actually really knocking it out of the park and taking their legacy environments, all of their existing processes and reinventing them in light of new capabilities and new ways of thinking about things, is pretty darn small, I'd say. So I think it's really important that we do this each year and we start to try and work out, as Mike was saying, give people a more prescriptive path for getting out of the being stuck in the middle of the evolutionary journey as we've been talking about it.
Demetrius Malbrough [00:04:51] Yeah, that's fantastic. And so being stuck in the middle and the journey that they're on. So just pulling something from the report, it looks like 64% of respondents say their company has at least one self-service internal platform. Could we dig into that a little more and maybe share a little color or maybe something that was not shared on paper that is interesting?
Nigel Kersten [00:05:16] So one thing, I'm going to jump in on that one, because I'm pretty passionate about this topic. I think 63% of respondents say they have at least one self-service internal platform. But is that really, you know, built in the way and operated in the way that we know is incredibly required to be really successful at this? And that is to do things with a product mindset? You know, you could answer yes to that question if you were offering a pretty traditional self-service enterprise catalog, so to speak, where you might go to a Web page and click on a bunch of different menu items. And it's all relatively opaque and difficult to modify and really difficult to collaborate and share around. The companies that we're seeing who are being really successful at the platform team approach are really collaborative with the users, they're out there looking for what are the problems, how do we actually solve them and they're exposing those things via APIs. And I think this thing is really, really critical. And I know this is a subject near and dear to Mike's heart, because this is how you can take advantage of it in your shell scripts, inside your programing languages, and for what is increasingly becoming the sort of backbone of the infrastructure fabric in big organizations, the CI/CD systems.
Michael Stahnke [00:06:26] Yeah, I mean, this is this is exactly what people are looking at it when they're doing internal platforms. You know, you ask kind of about self service to start with. And that was the same thing that we asked about as we were doing this research. We thought, wow, you know, the ultimate evolution here is self-service. And then as we ask more questions and talk to more practitioners in the field, it really, self-service is not the end journey. That's actually a characteristic of the end journey. That's not the actual thing you want. What you want is a platform with a bunch of capabilities that other people can consume. And that way you've abstracted out the, I guess the boring things, maybe not the boring is the right word, but like the things that don't need to be unique across different teams that are delivering value, you know, things like connection, going to a database, or how you consume KUZE or do you have persistent KUZE or do you have resilient logging or just a bunch of kind of infrastructure type components. And if those can be all abstracted out or self-service available or your persistence layers or self-service, then it's much more about what the developers need to do their business work and you know, can each team be working on only the things that differentiate them from the next team over and not, well, I wrote a connection pooling thing in the next team over well I had to write a different connection pooling thing because I had a slightly different use case. And to me that's really what the value of an internal platform comes from. And if you circle that back with what Nigel was saying for product management mindset, if you treat your internal developers or your internal technology teams as those customers and you kind of say, well, what's in your way? What's the prevention of what's in your way? Why are you not delivering the value you want to deliver at the cadence you want to deliver that. And, you know, that's what the internal platform can really step in to do. You know, if you can have 80 percent of all things in the internal platform, then you're only worrying about a 20 percent differential versus maybe an inverse of that in a lot of cases.
Nigel Kersten [00:08:07] And I think that word abstraction that you brought up there, Mike, is really key to a lot of this, because one of the big design issues, I think, with internal platforms is what level do you create those abstractions at? And if you think of the analogies being like API design, you can really easily fall into the trap of creating these really high level abstractions that solve a relatively large problem. But then you're giving up on the opportunity of making those self-service capabilities you're exposing composable and reconstituted in different ways by your users. And I think this is one of the things that we've really seen from successful platform teams is they managed to build those APIs at the right level of abstraction. So they're getting rid of that sort of stuff that you don't have to think about. And it's not really a differentiator like the connection pooling Mike was talking about. But you still have freedom and sort of the ability as an end user to go, well, actually, I can take these four or five things, glue them together in a slightly different way. And now I'm solving a whole new problem, like, for example, maybe provisioning a particular cluster in a certain way with a certain specification. I can take that along with an API to grab a specific version of an application and deploy it. And now I can give someone a higher level. Let's do a regression test against a particular application, a particular bug. So I think that's one of the key reasons why you need a product mindset that you need to design these solutions so that not only are they solving real problems, but they're low enough level that your technical user base can actually reconstitute them to solve new problems.
Demetrius Malbrough [00:09:35] Yeah, and let's also address the elephant in the room. You know, from 2020 was a really interesting year and, you know, the pandemic hit as well. And some of the top challenges to just providing an internal platform, you know, things around lack of technical skills within the team and lack of standardization, lack of time, etcetera. What are some of the patterns that you saw after, you know, digging into some of the research and maybe some things that surprised you as you were kind of walking through the data and also some of the other things that you happened to see.
Nigel Kersten [00:10:10] So I guess one of the things, you know, I'm not making light of it in the terrible situation many, many people in most of the world's actually in with the pandemic right now. But one of the things I have heard from a lot of practitioners that I work with is they actually have a bit more freedom to get work done. And there's fewer meetings and they get sort of longer chunks of time to actually think about things. So I think there is some people are getting some small positives out of this changes in ways of working. And, you know, many people who've been proponents of remote work for a long time are starting to see that some of those benefits do actually come across to organizations. The biggest problem I see with platform teams is it's often envisaged as the next evolution of centralized IT. So it's either just they're paying lip service to the concepts around it and they're just trying to reclaim authority from development and value delivery teams like that. Or and this is even worse, if they're combined together, it's under a project based funding scheme, so internally it's like we're going to spend this much money, this period of time, and then at the end we will have a platform and then we don't need to think about it again. But this is really an area where you need to do continuous investment and it can't really be project based funding. It needs to be a cost center that's being funded continuously to deliver value continuously because the wins are not going to be really quick at the beginning. Even if you're going after the low hanging fruit, there's this exponential rate of return. Once you start getting more and more development teams and more and more infrastructure teams making use of those capabilities.
Michael Stahnke [00:11:42] Yeah, I was thinking a lot about ROI, I guess when when you were talking and also when the initial question was posed about, you know, what was different this year. And I think when people want to make a platform investment, you want to think about how do you know if it's working and what does it mean to be successful? And then how do you measure that? And, you know, in the State of DevOps report, we have, you know, a couple of different sidebars on ROI. And I even modeled my own organization is one of them, because I can tell you that the conversation I'm in with other executives on a very regular basis is what's the ROI of this engineering work or it's rather expensive. But the things that you can show out at certain points are it's, you know, at some layers it is, if I hire one engineer in a platform area, that might mean that I don't need to hire six engineers on development teams. If development teams each need an engineer to do kind of common practice and common scaffolding, or I hire one person and a platform organization to write that and make it reusable, that's a way better investment. That's leverage. And those are the things that we need to be able to demonstrate over and over again for a platform org and so Nigel's right, you don't want to run it as project based funding. I don't like the word cost center attached to it either. But that's just because I think coming up from an IT background, the word's "cost center" just don't feel good no matter how they're said. And so to me, like, I want to make sure that, you know, we're providing the maximum amount of value and it's the right amount of value for value delivery to everybody delivering technology. But it's centralized like, you do want to centralize the things that can be centralized so that you don't have nine variations of how to do database connections or, you know, talking to a queue or whatever your platform requirements are.
Nigel Kersten [00:13:12] I think of it, Michael, as you want to centralize the patterns and the processes that people are using, but you don't have to centralize the authority around using those things. And you really want to try and distribute this. Back to my earlier point about people recomposing. You want to let your users come up with solutions. And I think that was much of the frustration people had with traditional centralized IT, where your technical developers, who often have a reasonable understanding of a certain level of infrastructure, just felt completely hamstrung by what they were doing.
Michael Stahnke [00:13:42] Yeah, I think there's a lot there. Like if you look kind of at the classic centralized IT, you know, you go back to the BOFH days and all the meems on Slashdot and then now today it's much more like the default stance isn't, no; it's you can do what you want, but we've made certain things really, really easy. And you'd be kind of silly not to do them this way.
Nigel Kersten [00:13:58] Which I think speaks to the thing we talked about, about how critical it is for you to evangelize your platform capabilities. Like we're not in a world where you can build things inside a large organization and just order people to use it. You know, the tech landscape is way too fragmented. There's too many teams operating at different speeds. You've got to actually go out there and sell it to people internally. And that's actually part of your job as someone running IT in an organization these days, like that, you can't just be demonstrating value in those meetings you were talking about, Mike. You want to have it happening organically back from the people who are actually your customers and users telling their managers this capability makes my job better.
Michael Stahnke [00:14:37] Yeah, I mean, we have people that are saying, hey, I want to adopt this common tooling, because when I do that, the security batches are all taken care of for me. You know, it's things like that. I can get this toil off my plate if I'm using patterns that are supplied to me by a platform organization. And so most of developers, once they find a couple of those benefits, are very pleased to kind of build upon those those foundations.
Demetrius Malbrough [00:14:55] Now, also, gentlemen, what about change management, since it was a key theme running through the report, change management in the DevOps era, what do you have to say around change management? And do you have a philosophy as to what you see change management delivering and I guess how it's changing in especially 2021?
Nigel Kersten [00:15:16] My quick, pithy one, I would say, is that almost everyone I see who's complaining about their change management process hasn't actually done the job of reaching across the aisle and going and talking to the people who run those processes and going, hey, we have these capabilities inside our organization, we have these needs. Let's work together on actually fixing them. And every single person I've ever talked to who has made that effort has succeeded because these people tend to be very rational, very process driven. They understand evolution of things, but too often inside organizations, they;re just in silos that don't talk to each other. So I think there's a lot of details in how you can improve your change management process. But step one is literally just go talk to the people who own that process in your organization.
Michael Stahnke [00:16:00] Yeah, I think I do think there's a lot there. I think the way people are incentivized about change management is the thing that I usually come back to is people that are very ingrained in a change management process. A lot of times, they're actually they're doing a lot of work to not allow change. That's their whole goal. And somebody else's goal might be, but I want to make lots of changes. And if that's where you're incentivized at and you're at odds, that kind of needs to be squared before you can go make your next steps. Like if the goal of change management is to stop change and somebody else's goal is to make a bunch of change, like that's the conversation you have to have first, is like, what's the real business goal here? And I mean, change management by definition is basically a process to prevent change, which is one of the reasons I kind of hate it. But we've dug into that, you know, a lot of different ways. And I think the thing that was really interesting about asking a bunch of questions about change management this year was not everybody's doing it in this classic kind of ITIL molded, you know, with the same in 1998 as it would be today process. You know, we are seeing pockets of areas where local approval or local authority is really the way people are moving forward. They can move rather quickly. You know, we're seeing changes that maybe are orchestrated or delivered through, you know, CI/CD technology, kind of don't have the same level of scrutiny or CAB meetings or, you know, the same level of, I guess, overall barriers to entry onto the production fleet of software or whatever. And so we're just starting to see some things break away and move faster. And I think that's where the differentiation happens. You know, speed to market is everything, and even that's for internal customers. If you can keep moving, you can keep everybody else moving. And so, you know, we had four different categories for change management and we had kind of this, you know, engineering driven and Ops led and then like pathological, you know, around approval's like there were so focused on approvals, but not actually the outcome, and all the other ones just very ad hoc, where it was like you almost had no change management process at all. And that was usually at much smaller firms where you can just lean over and say, hey, I'm going to deploy this. And Sally leans back over and says cool, I'm on it.
Nigel Kersten [00:18:07] You know what I found fascinating, though, Mike, was that when we analyzed people from their sentiment and how effective they felt their that change management process was, for all of the complaints about these heavy processes and how terrible they are, most of the people inside those organizations with really heavy, slow processes, both were happier with their change management and thought it was more effective when it wasn't actually, which I thought was amazing.
Michael Stahnke [00:18:32] I don't know if I thought it was amazing. I thought it was like exactly what I would have expected if I had sat down and thought about it for a couple minutes, because, like the people that when your whole job is like I'm a change coordinator or I'm the change manager or whatever, that that role is like, that's all you live in. So you think you're great at and you think you're doing so much about it. But it's like, what if that role didn't exist?
Nigel Kersten [00:18:52] No, no. But I think the thing was because people were responding from organizations and all sorts of roles, like I understand the change managers themselves having that attitude, but we were getting that the signal was strong enough that it was IT practitioners who may be more victims of change management. And I think that says something about how the fact that David Graeber used to has this whole thing on bullshit jobs and the fact that we fill our days up with busywork. And sometimes that's what we get our sense of worth out of, in certain kinds of highly corporate environments. And this feels like one of those things where there's a certain kind of you're just rubber stamping bits of paper saying yes, saying no. But at the end of the day, like, I ticked off a whole bunch of things that, you know, really sort of questioning what's the actual value being provided, I think speaks to the speed to market stuff you're talking about.
Michael Stahnke [00:19:37] Like, yeah, no, I completely agree. I think there's a lot there of, you know, what's the real value in this roller, in this process or in the steps in the process? And that kind of circles back to the initial point you were making is like, can you have a conversation about like what are you incentivized on? What are you aligned on? What's in the way? And start just chopping away things that are problematic. And, you know, the thing is, those complicated change processes, they're all there for good reason. You know, every statement, every approval was put in because something went wrong at some point. And this was the safety measure that was installed to prevent that. But the thing is, you need to ask is like, when's the last time that safety measure worked? What's the cost of that safety measure? You know, can we accept a different level of risk? You know, maybe it's even for only certain types of work versus other types of work, but maybe it's for all work. And I just feel like the change management process is one of those things that people have always been afraid to go after. And I think you're right, if you do go after it and work on it, you can make pretty decent headway. My time, my time in Enterprise, I was what I did, so.
Demetrius Malbrough [00:20:34] Michael, you also said that people maybe sometimes are afraid of change management. What would you say to people that are still on the fence about automating their change management processes and really kind of coupling everything together to have, like, this automation workflow around it?
Michael Stahnke [00:20:49] I mean, I would say that computers produce more predictable and accurate results than humans ever will. So automation is usually good, I guess.
Nigel Kersten [00:20:59] Let me jump in that one, because I think one of the things I've learned from a few customers and people making these changes is, so I was being a little pithy when I said the first step should be go and talk to them, MIke's totally right that you want to try and make sure you're aligning incentives first. But one practical bit of advice I'd have would be, go and learn the terminology that the change management folks are speaking, because often we talk a lot in DevOps, or we used to in the early days, around empathy being a fundamental building block of DevOps. And I think you've really got to build, assuming that the people listening to this are more on the side of IT practitioner side who see themselves as victims of change management, build empathy for these people because they have a role and their role is to reduce risk in the organization. And rather than going and talking about some slow, terrible bit of work that you're being forced to do, go and talk to them about ways that you could minimize risk in a more efficient manner and start looking at the terminology that they are actually using to describe their own work and adopt that when you're trying to advocate for change. No pun intended.
Demetrius Malbrough [00:21:59] All right. So you mentioned risk and you can't you can't have a conversation nowadays, especially on a podcast, without mentioning security. Right. So security is key because they had things running around like ransomware and malware, and these are continuing to increase in organizations. So what's your stance on integrating security into the software delivery process? And is there anything or any trends that you have seen around this?
Nigel Kersten [00:22:27] Well, I mean, first, you know, it's amazing computers work at all, given everything that's going on out there in the world and all the different threats they're facing. But I think, you know, and I know Mike has a lot of thoughts on this as well. It's a shift left has been almost has almost become a bit of a cliche. But the reality is it's a lot easier to fix issues early than it is when, like before they're deployed, than when they're actually in production. And I think the same thing goes for infrastructure. We often talk about shift left in terms of application development security, but the same goes for INFOSEC and for all of your operations, security as well. If you can get security people to collaborate with you in the design phase and to do so in the form of code in some sort of infrastructure is code, policy as code. Anything where you can formalize the social contract between two different teams and buyer automation, that's how you can actually build trust really quickly, creating those collaboration spaces around code early on as part of the design process. And I just see that trend continuing to increase because there's a lot of improvement I think the whole industry could make in terms of tooling and capabilities there.
Michael Stahnke [00:23:33] Yeah, I think from from the security point of view, you know, Nigel's right. You want to shift this earlier into the process. But I also don't think that means you want to remove it from later in the process. Like shift left is a little bit disingenuous for some of these things anymore where you really want to shift it wide, you want to start early, but you also want to keep your security monitoring and validation going. You know, whether it's a thing that is running in production is, you know, an online tool or it's being delivered to a customer or whatever, you want to continuously validate that from a security perspective.
Nigel Kersten [00:24:03] Absolutely. Yeah.
Michael Stahnke [00:24:05] And I think that that's one of the more difficult things, people are, you know, saying, well, I'm going to move on my testing left that way I know early on. Well, great. You should you should do all that. But that doesn't mean take away the testing that you do in production or the penetration testing you do or the blackbox testing that you have maybe a red team do or or whatever like security is, it's a very challenging field and it's a game that's ever evolving. And I think that it needs to just go as wide as possible, I guess, it's not just shift left early, like you should shift left early, but there's more to it than that. I think the other side of that is everybody needs to be understanding that there's a level of risk we all have to live with. And, you know, where are we comfortable with that level of risk and have we identified it? And do we know what it looks like? And, you know, there are things going on all the time. And then the last thing would be, I think the thing that was most frustrating when we studied security two years ago in the State of DevOps report, we really did a deep dive on, was a lot of people seemed to know what the right things to do are and they just don't do them. And so how do you prioritize the you know, hey, I know I'm supposed to patch this thing, but I haven't gotten to it or I know I'm not supposed to allow this thing to talk to this thing without authentication. But it was the easy way we got it set up and I never fixed it. You know, the equivalent of CHMOD 777 to make something go, like those things happen all the time. And that's where things break down. You know, the advanced hacks you read about, or see in the movies, those aren't like that common.
Demetrius Malbrough [00:25:32] Yeah, that's a totally different beast. Right. And just to incorporate everything that that we spoke about today, just overall, like where do you see Cloud as being a big component of these trends? Or, you know, what are some things that that you want to emphasize as we move into like this increasingly, you know, hybrid cloud or multi cloud world?
Nigel Kersten [00:25:54] I have a quick one, which is going to be that I think a lot of the cloud teams that we see in enterprises that I interact with are getting to move quickly. Because they're being ignored by processes such as change management and compliance, or they're being asked questions, but they're not particularly the detailed questions right now. So I think it can sometimes be a false dichotomy when people like on premise infrastructure moves really slowly and the cloud teams move really quickly. And a lot of the times it's because the rest of the processes, those sort of organizational scar tissue, the "if" statements that Mike was talking about in terms of process and change management and compliance, they're not as formalized for these teams. So they're given more freedom. Now, that actually also increases risk as well. So I think we're going to see many people doing a lot more work in the cloud compliance space and starting to solve problems there. And we're going to have to necessarily accept a little bit of slowdown to mitigate risk as more critical core banking, etcetera, applications move towards the cloud. But I think it's a necessary tradeoff.
Michael Stahnke [00:26:54] Yeah, I mean, I think you're right. There's this there's like I want to innovate. And so you're in a giant company and you kind of give some startup rules to a team that's maybe the cloud team or something, something like that, the digital transformation team. And I think that's the question that I always want to come back to is why can't you give that set of rules to everybody else? Like, why can't everybody else move at that speed? So those are usually the challenges that, you know, when we're in conversations with other leaders that we'll challenge leaders and ask those types of questions. And sometimes we'll get great answers and sometimes we'll get amazing anecdotes of why they can't.
Nigel Kersten [00:27:22] You've stolen my thunder, actually, because what I was going to say is I think the next evolution is going to be, we're going to see a more agile approach to change management and compliance become de facto standard in the cloud space. But then if if we're not idiots, we'll import those practices to on premise and not just leave that world to rot in 2000s' era process management.
Michael Stahnke [00:27:43] Yeah, I mean, I think the other thing is, you know, success and failure in the cloud is going to be at different speeds and different paradigms for different companies. You know, some people are very into, I want everything cloud native. I'm going to build all my applications that way. Some people are, I want to take my applications that exist today and put them in a cloud environment, which opens up different avenues of concern. And then you also have people that are going to put everything in the cloud and then get a bill and say, I don't like this unpredictable cost model. And that's a big problem for my business. It's a huge risk. And I want to, you know, have more control over this. So I'm going to go put it back in my own data center or I've done I split out this monolith into 65 microservices and it turns out, keeping 65 things online is way harder than keeping three online. And those are all things that people are going to run into at different levels as they go either through cloud adoption or cloud native application building. And I just think we haven't seen all the backlash of all those things hit publicly yet. But you're starting to see it in small groups and I think you'll see it more and more as larger, I would say less technologically forward and proficient companies, you know, like not Google and not the other FANG companies, you know, are they doing big cloud adoptions and we'll start to see some of this stuff come back.
Nigel Kersten [00:28:53] I heard some of the other day use the phrase lift and shift for their legacy cloud environment to the new cloud environment. That is like, wow, I'm getting too old to be hearing these terms.
Michael Stahnke [00:29:08] You can create legacy code today if you try hard enough.
Demetrius Malbrough [00:29:12] Now, if I was to sit down at a computer, that's exactly what I would create is legacy code. All right, gentlemen, so I appreciate all of the insights that you have brought to Pulling the Strings. Michael, how can listeners reach out to you on social media?
Michael Stahnke [00:29:29] I am @stahnma and pretty much every service on the Internet. That was a user name I got right out of school and it's pretty unique. So I use it everywhere.
Demetrius Malbrough [00:29:41] All right. What's the story behind it?
Michael Stahnke [00:29:43] It's my last name, with like it was the first five characters my last name, first letter of my first name, first letter of my middle name.
Nigel Kersten [00:29:52] Ah, when usernames could only be eight characters.
Demetrius Malbrough [00:30:03] And Nigel, what about you?
Nigel Kersten [00:30:08] I made the unfortunate mistake of using my real name on Twitter early. So let's go with @nigelkersten. I really do wish I'd picked a much cooler pseudonym.
Demetrius Malbrough [00:30:19] Well we'll give you a pass on that one this time. So, yeah, I truly appreciate the conversation and I would like to thank you both for sharing with us on Pulling the Strings podcast powered by Puppet. Thank you.