In this episode I catch up with Michael Levan on his journey into cloud and DevOps, and we share some ideas on how you can do the same.
Resources from this episode:
Michael on Twitter
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
How to Make the Transition to DevOps Engineer
Don't forget to subscribe to our mailing list at cloudskills.io/subscribe for weekly updates, exclusive training, and advice on how to amplify your career.
Mike Pfeiffer: Hey, what's up everybody? It's Mike Pfeiffer and you're listening to the Cloud Skills FM Podcast.
Mike Pfeiffer: What's up everybody? It's Mike Pfeiffer. Welcome back to another episode of the Cloud Skills FM Podcast. Super excited to have you here as usual and today in this episode, got Michael Levan on the show. Michael, what's up man?
Michael Levan: What's going on, man? How are you?
Mike Pfeiffer: I'm doing good. It's Friday and I'm ready to stop the day, but we got to do this. I'm pumped about it though.
Michael Levan: Me too. I've been looking at it all week.
Mike Pfeiffer: How's your week going?
Michael Levan: It's going good, man. Busy. Staying busy, learning a lot of good stuff. Keeping the work going.
Mike Pfeiffer: That's right. Yeah. I can feel you there. So, why don't you tell everybody who you are, man, in case they don't know who you are.
Michael Levan: Yeah. So, my name is Michael Levan. I'm the chief engineer, CEO, founder, whatever you want to call it, of CloudDev.Engineering LLC. Pretty much doing 50% consulting and 50% content creation right now. So, pretty much my idea behind my company was to be able to go out and teach people how to do quality engineering in all of their work, whether it be in Azure, AWS, on prem, whether they're shipping software, whether they're creating virtual machines and storage and networking, whatever they're doing pretty much. So, that's been my goal so far for the company.
Mike Pfeiffer: Nice. Yeah, it's definitely a lot of opportunity out there these days with this stuff. How did you get into doing all of this?
Michael Levan: Yeah, so my background is originally in more of operations. So, when I started out my career I started off standard help desk stuff, moved up to assist out in a role, got really heavy into virtualization in hyper V, in ESXi. And then eventually moved over to cloud engineering and got heavy into developments. So, I was writing a lot of Python Code, writing a lot of APIs, working a lot with Flask and all that stuff.
Michael Levan: And then it just moved to me to DevOps because I started to work a lot of CI/CD stuff, a lot of orchestration. I'd actually ship my code, how to build my code, and then I'd just smoothly transitioned into DevOps.
Mike Pfeiffer: Nice man. That's a pretty interesting path. So you started as a CIS admin. How did you get into Python? How did that happen?
Michael Levan: Yeah, so originally my first programming language was PowerShell, I was working in a heavy Windows environment and in the beginning I was super scared to write code. Maybe I thought maybe I wasn't smart enough or I didn't think that I'd be able to retain it or whatever the case may be.
Michael Levan: And then, I started writing heavy PowerShell and then after that I moved more into a Linux and AWS environment. So, it was just a natural shift from PowerShell to Python.
Mike Pfeiffer: That's interesting. There's a lot of people talking about Python and in our community, when I our committee I'm talking about the cloud skills community. So, many Microsoft focused people. Not everybody is, but big PowerShell community and I know you know a lot of people around the community and have done a lot of PowerShell work. And so it's interesting that that was the gateway into Python.
Mike Pfeiffer: Do you have any tips for somebody that's itching to learn Python? Maybe they're coming from a similar PowerShell based background.
Michael Levan: Yeah, absolutely. So, I would say the first thing, let's say you're in a Microsoft background, like you're working a lot with Azure for example. One, I would say, start off with the basics of Python. Learn how to do a four loop, what variables look like, what you're doing when you're importing libraries, which is modules and PowerShell, right? And how to do the general syntax. And then after that, start doing whatever you're doing today in PowerShell and Python.
Michael Levan: And what I mean by that is, and this is something that I've been focusing a lot on as well and putting out content, is if I'm doing something in PowerShell like creating a storage account or listing storage accounts or listing virtual machines, I'll take that and I'll do the same thing in Python versus doing it in PowerShell.
Michael Levan: So, the same way that people get into PowerShell, taking their manual tasks and automating them. You can do the same thing with Python and Azure has a really rich SDK for Python as well. It's pretty good. I really love it.
Mike Pfeiffer: Nice. So, what projects you worked on these days, man?
Michael Levan: I'm all over. So, I'm doing consulting right now. I'm helping an organization get their DevOps up and running from a source control perspective, from a building code perspective, using a ton of Azure DevOps and in Azure as well. I'm creating a lot of content around Azure lately. A ton of DevOps topics like CI/CD with Jenkins, with Azure DevOps, with GitHub actions, GitLab's CI, trying to do a little bit more coding in my content. So, a lot of Python, a lot of PowerShell, a lot of Terraform, just going down that path.
Mike Pfeiffer: Got it. Yeah, that's a lot of interesting work and when you were talking earlier about just getting your customer set up and going, it seems like that's really common. Lots of companies just getting started with version control and getting the basics going. Is that something you're seeing as well in the field?
Michael Levan: Yeah, absolutely, 100%. I think the biggest thing that I'm seeing right now is everybody trying to figure out how to use the tools that are out there. So, the problem right now is there are so many tools that do so many different things and so many verbiages and so many different ways of explaining things or using things.
Michael Levan: So what I'm seeing a lot, for example, is people are building code. They're using a CI process, they're bringing their scores control and they're building an artifact out of it. But then they're deploying one artifact in dev and then another artifact in UAT and another artifact in prod. And so then they're defeating the purpose of staging at all. So, I'm seeing a lot of that. I'm seeing a lot of confusion around how the tools are supposed to be used.
Mike Pfeiffer: Yeah, I see that a lot too. A lot of confusion and I think there's maybe a misunderstanding sometimes when it comes to some of this stuff and thinking that there's a cookie cutter approach that you're always supposed to take. That's one thing I've been talking a lot about lately, is just trying to get people to recognize and remember it's almost like a canvas and you're using all the tools at your disposal, different colors and the brushes, to create whatever it is you're building. That's kind of how we've been looking at it the last couple of years because it is really that.
Mike Pfeiffer: Sometimes with these capabilities, the sky's the limit. Right? Your imagination is really the only thing. That's what it is, right? You're just coming up with ideas and people get stuck thinking that they got to do everything prescriptively every single time.
Mike Pfeiffer: What's the most creative solution that you've seen, like in your customers or you've deployed in your job?
Michael Levan: Yeah, so I would say from a creative perspective, what I'm really loving right now is using multiple CI/CD platforms. So, it's very much like the multi-cloud approach. Whether you're using Azure and AWS or you're using Azure and GCP or whatever the case may be. Each platform is very good at some things and then there's some platforms that strive at others. And it's very much like that with CI/CD platforms.
Michael Levan: So, what I'm seeing a lot of is, for example, people using Azure DevOps for the wiki pages, for the work items, for the Kanban boards, for the CI process, for the build, storing the artifacts. Because you have Azure repos right there. So, you ... I hate the term single pane of glass, but you have a little single pane of glass there. And then for example, they're using Octopus Deploy to take that artifact and deploy it out to their windows environments or they're kind of doing something similar where they're building in Jenkins, they're using something like Artifactory, to store their artifacts or nexus and then they're deploying the Azure DevOps.
Michael Levan: So, the thing is, it's hard enough to use one, right? So, I really liked the fact that a lot of organizations and a lot of people are starting to use multiple at the same time. That's been the most creative thing that I've been working on so far.
Mike Pfeiffer: Yeah, that's pretty out there for a lot of companies. And that's really interesting. And there's probably a lot of what you said there that may even be confusing to a lot of folks listening right now because the reality is lots of enterprises are coming from a traditional server infrastructure pattern. Now they're getting into this for the first time. So, maybe we could back up and talk about some of those other components.
Mike Pfeiffer: We've talked a little bit about Azure DevOps on this show in the past and stuff. You mentioned GitHub actions earlier. It's going to be important, right?
Michael Levan: Yeah, no, absolutely. So, I think the biggest thing about GitHub actions, so obviously Microsoft owns GitHub now. And they have Azure DevOps. So they already have a CI/CD platform. Now I think with GitHub, the main key there is going to be that pretty much every developer, every person that's written code or that's writing code, has put something in GitHub.
Michael Levan: So, now they're making it just easy for somebody to test their code and maybe not even deploy it to production. But just to see if it builds and it works. So, they're making it just easy for everybody that already has their code up there anyways. I think three or four years ago, they had something like 10 million public repositories, or was it 10 million or 10 billion? I forget.
Michael Levan: So, there's obviously a lot of code up there and the problem with that was you had to take GitHub and tie it into Jenkins or tie it into GitLab or tie it into Azure DevOps. But now you don't need to do that. And the other thing too is that everything is YAML based right now and that's the direction that everybody's going in. With Jenkins, you have Jenkins files. With Azure DevOps, you have YAML pipelines, with get hub, you have YAML as well. So, they're starting it off fresh and saying "Nope, no UI, just do everything via YAML."
Mike Pfeiffer: Right. Yeah, GitHub actions is going to be important to keep watching. There's some details, different things going on right now in the industry. Obviously everybody knows Microsoft bought GitHub. But you start looking at GitHub actions and you start realizing this is very similar to Azure Pipelines in a lot of ways.
Mike Pfeiffer: And GitHub Actions will be something they pay attention to. I think everybody in our community and the Microsoft side of the house should be paying more attention. Actually anybody in the industry. I think what I'm getting at is we're going to see more investments in that from Microsoft, and I think it will be an important technology for all the DevOps practitioners to pay attention to.
Mike Pfeiffer: And then circling over to one of the other things, there was a lot there, so when it comes to working with YAML, a lot of people are learning that for the first time, and on the surface, if you're looking at it, if you're a traditional scriptor or programmer, you're like, "Okay, this is very simple to work with." So, my feedback has been, "I'm not super hot on all the white space and navigating it that way." But what is your thoughts on YAML? Because this seems like-
Speaker 1: But what is your thoughts on YAML, because it seems like there are people who go back and forth?
Speaker 2: Yeah. I write in Python, so I'm pretty used to white space anyways. Yeah, in terms of the white spacing, here's the thing. It's definitely annoying, especially when you're ready to run it and it says, "Nope, you got a tab here and a space here," or something like that. Or it doesn't like the syntax itself and how it's formatted. And I don't think anybody remembers how it's supposed to be formatted. Pretty much what I do is I always work out of VS code and I always do just Alt-Shift-F or Command-Shift-F on my Mac or something like that, and it just automatically formats it for me. The white space thing is kind of annoying, but there's just so many tools out there that make it easy that you don't have to care about it at this point, that I'm kind of just "whatever" about it.
Speaker 1: Yeah. And that's kind of one of the things that I also get into when I'm talking to people, because I get a lot of pushback about JSON. We're seeing less now in favor of YAML, but then you start getting a little pushback on that. But to your point, the extensions and the tooling in the IDEs, especially the S code with extensions, that's your savior, right?
Speaker 2: Right. Yeah, absolutely. And the argument between JSON and YAML is always there. I'm personally, I guess, one of the weirdos that like JSON more. I think it's easier to read and I think it's more structured. I like the key value approach. I like the fact that I know what I'm looking at. I know what the value is supposed to be and I'm able to pull the key or pull the value from any environment. I've always been more into JSON anyways.
Speaker 1: Yeah, I'm the same way, man. I grew up doing infrastructure templates in JSON, so to me, they make sense. And I've heard a lot of people push back on that because it's so verbose, and that is a problem with it, especially when you format it nicely. It's very long from top to bottom. But to your point, man, it's like the relationships of the objects are very apparent when you're looking at a JSON document, especially when you're working in a nice IDE that's got good support for it, which pretty much anything does these days. And I'm in favor of JSON too first over YAML personally, just because like I said, the relationships are easy to see. And I wonder if people with an object-oriented background, like programming background tend to think that way. I don't know, but to me, that's my take on it. But your original point was spot on. Using the tools at your disposal is really the way to go.
Speaker 1: I shared something earlier this week on LinkedIn. Joe Duffy, the CEO of Pulumi was on this show last year, and I shared something this week which was from their blog, which showed using their platform, Pulumi, to build their YAML manifests for Kubernetes in a traditional programming language which is kind of nice.
Speaker 2: Right.
Speaker 1: You mess with any of that kind of stuff?
Speaker 2: I actually haven't, but in my little OneNote page here for the things that I want to be working on, Pulumi is on my list for sure. I want to jump into that. I think it's a really cool idea to just be able to write any type of object-oriented programming and be able to move it into your infrastructure as code. That's a pretty solid idea and it's going to make things a lot easier for people, because I've spoken to back-end developers, front-end developers that they'll write in ARM templates, they know how to do it, but they really don't like it. They'd prefer to be writing in one of their preferred languages. I think it's going to be a game changer for sure for a lot of people.
Speaker 1: Yeah, definitely for the dubs that already know those programming languages. That's a natural approach. AWS has something called the Cloud Development Kit or something like that. The CDK, which is their native way of doing that. Curious to see if Azure does it. But on that point, do you think when it comes to programming itself, and you're a big obviously PowerShell guy, Python guy, do you think people need to worry about if they're making a transition right now from a traditional infrastructure person into dev ops, do they need to worry so much about programming or is that just something they should focus more on scripting right now, and not worry so much about getting into the depths of things like C sharp or Java or things like that?
Speaker 2: Yeah, that's a tough question, because what I would say is it depends on where you work. I think the first thing is if you're getting into dev ops or if you're getting into cloud engineering or even just standard infrastructure engineering at this point, you need to learn a programming language, whether it be PowerShell, whether it be Python, Go, whatever you want to learn. Anything that you can work with in your environment, you have to learn something at this point. It's inevitable. You can't get away from it right now. We see it every day where there's a ton of companies that are like, "Hey, hit our API," or "Hey, use our SDK," because they're trying to not have people hit their UI. That's just the direction that we're going in.
Speaker 2: In terms of understanding things down to a programming level, like an object-oriented level, it's going to depend on where you work. You're going to work in environments as a dev ops engineer or a cloud engineer that you're just doing scripting. You're just doing a ton of automation in PowerShell or Python, doing a ton of infrastructure as code, whether it's Terraform, ARM templates, Ansible, whatever. But then you're going to work in hardcore environments that there's developers. Their code isn't building properly. It's in CI CD platform, so it automatically falls on dev ops, and then you have to go in and be able to take a look at that code and see what's going on.
Speaker 2: You don't have to be writing the next operating system in whatever language, or you don't have to know how to write the next Linux kernel, but you have to know how to be able to look at code and see what's going on. And a lot of the things that you'll learn in a scripting environment, it's going to move over. Variables are still variables. Functions are still functions. Loops are still loops. That stuff doesn't change. You're going to have an understanding of what's going on regardless of the code that you're looking at.
Speaker 1: Yeah, I like that, man. I like that point. And also maybe there's an element of maybe starting before you're ready completely with that, and I think that's an important underline. You don't have to master the whole language. Just get in the game. If you understand the basics of computer science, very basic computer programming 101 class of, "Oh, here's if statements and variables," all that stuff. Yeah, that's what you want to focus on is get the real basic core foundations and then maybe fill in the gaps as you work through these real world projects, right?
Speaker 2: Right. Yeah, absolutely. And to your point, nobody knows everything. Nobody masters everything. If you're a PowerShell expert or you're a Python expert, I can guarantee that there are a ton of experts out there that know 60, 70 percent of the language, but if you're not working with certain SDKs or you're not working with certain libraries, you're just not going to know everything. It's utterly impossible at this point.
Speaker 1: What kind of opportunities you're seeing out there? I know that you've worked in various roles and done some different dev ops projects. You've worked in a dev ops role, official. What kind of opportunities do you see out there for people that maybe they're not quite as skilled up to where you're at right now? Because you're working with a lot of emerging technologies and a lot of people haven't had the opportunity to really do that at work yet. And I'm wondering what kind of opportunities are you seeing out there that people may be able to start plugging into?
Speaker 2: Yeah, I would say look out for two things. One is if you're on LinkedIn or you're on Indeed or something like that, look out for the roles that they'll quote and say junior dev ops engineer. In my opinion, there's no such thing as a junior dev ops engineer. I don't think dev ops is a junior position. However, people are looking for that because that's the direction that the industry is going in, and typically those positions are going to be more of a senior CIS admin to a junior developer type of role. But that's the type of role you want to be in, because you're going to be around all the technologies. You're going to be around all the people. You're going to be around all of the senior team. It'll be a good way for you to learn.
Speaker 2: I think the other thing too is, and this has been my approach, it's not for everybody, but my approach has always been as I was learning, try to join startups. And the reason why I say that is because you're going to go into a startup and every startup has the same problem. They don't have enough people to do the things that they need to get done. And because of that, you're always going to have more opportunity to touch more versus in a big organization, you're going to be siloed. Regardless of your dev ops or not, you're going to be siloed in a specific technology. That's typically my number one thing to everybody is try to get into a startup. Be prepared for crazy hours and crazy stuff going on and things that don't make any sense, but it's the best way to learn.
Speaker 1: That's awesome advice. My version of that 20 years ago was go work at a consulting company, especially at a smaller medium-sized one, because just like you said, they're going to throw you to the fire and that's how I really got to the point where I could embrace being thrown in the fire and I think that not everybody's up for that. And I agree that's not always awesome, but if you're starting from the beginning, it's kind of like you have to be thrown in before you're ready. Consulting was the way I did that, but I'd agree with what you said. Startups is a great place to start. It's also a good place for a transition if you're tired of the traditional corporate red tape and all the bureaucracy. I was just on a webinar before this podcast and I was telling people about that, where the guy was like, "I've been in corporate IT 20 years." He's like, "Where can I go where the politics aren't so terrible, office politics?"
Speaker 1: And I was like, "Well, go work at a startup because it's totally different there. Maybe you'll be on every single team." Now obviously, it's not going to be the right choice every single time, but the culture is completely different, right?
Speaker 2: Right. Yeah, for sure. I think it also depends highly on what type of startup it is or what type of organization, right?
Speaker 1: Yes.
Speaker 2: In terms of getting thrown into the fire, like you said, it's not for everybody, but it's the best way to learn. I remember I was in a startup. It was my second week, and I came from a Windows background, so I was just getting into Linux and stuff like that. I was there the second week. The senior guy was on vacation. I was the only one, and a 16-node Redis Cluster went down. And everybody's like, "It's down." And I'm like, "I don't know what to do, but I'm going to go in and figure it out." And it took a really long time, and nobody expected me to be able to figure it out right away, but we went in. We figured it out. I was in the office for 19 hours straight. That was fun. But the point is is that that's the type of mindset for me. That's the type of mindset that I think people need to have is be ready to get thrown into the fire because-
Mike Pfeiffer: -need to have is be ready to get thrown into the fire because even if you're not doing a startup, like you're going to be thrown into a fire if you're studying for a certification and you have to study five, six hours a day if you want to hit a certain time or if you're going into a new job or whatever the case may be, there's always going to be some sort of quote unquote fire. And at the end of the day, it's really just about what do you want to do to succeed? If you want to get out of that role, that's just admin role or something like that, you got to be willing to put in a time and that's it.
Michael Levan: I have a similar one that I can reflect on and think about, long time ago, being thrown into something where I had no perspective, it's not really DevOps related, but this was probably 2003, and the consulting company I was working for was like, hey, we just sold a Novell NetWare, or no, it was Novell GroupWise email migration to Microsoft Exchange." And that was kind of in the early years of me doing, I became the Exchange guy reluctantly because just like you said, it hit the wall and I was like the only guy around and ended up getting Exchange stuck to me.
Michael Levan: But so anyways, I'm doing this consulting company and they're like, "All right, we sold this project that's Nobel GroupWise to Exchange." And I'm like, "Oh great. I have no idea that this is going to work." Probably not going to, like I didn't know anything about it, and in the culture back then, and in a consulting company, it's just like succeed or die, it's up to you, was your thing. And if you didn't go in there and get it done, like you still were held responsible for that. Right? Even if you didn't get to go to training.
Michael Levan: And so I think that mentality has helped, and I agree if you end up going through that it will make you more resilient in the future. But it's definitely no way to operate. I was more stressed out than I've ever been in my life when I went trough that, and it was remote, so I had to like travel to this other city, and it was multi-week. And I remember the customer, I was really resisting, because I didn't want to do it, because I didn't know anything about GroupWise, and the customer was not happy about me resisting so much.
Michael Levan: And I remember we didn't really have a great relationship, and I remember he was so surprised when it was just like a seamless migration at the end. I got lucky. I have to admit, I mean I put the work in, like you said, I stayed up all night working on stuff, and then it went through. But I could tell he wanted me to like have to work for it little bit more. And it didn't work out that way. But that was kind of one of my situations where I ran into that.
Michael Levan: It's kind of interesting man, going to this mindset of really pushing yourself outside your comfort zone. Can you talk about that a little bit? I'm sure there's been lots of moments, outside the other story, learning all these things, because you're covering a pretty good amount of ground here.
Mike Pfeiffer: Right, yeah. So I would say I'm just kind of used to it at this point. Honestly, every job that I've gotten I've always walked in knowing maybe 20% of what I needed to know, and I just picked up the rest of the 80% by studying and working hard. So terms of getting out of the comfort zone, striving for success, moving forward, I mean at the end of the day, it's really just about mindset. And like you said, it's not ideal, it's not ideal to burn yourself out. Nobody wants to burn themselves out, nobody wants to stay up 19 hours. It's obviously not logical, and there's no way to keep up with that. But at the same time you have to carve out time, three to five hours a week to study, or three to five hours a week to do labs, or pick up that Azure subscription, pay a few dollars a month for it, or get that new book or something like that.
Mike Pfeiffer: There's always going to be times where you're going to have to just continue to move forward and you shouldn't be comfortable. If you're comfortable, you should get out of whatever you're doing. You never want to be comfortable. I mean, when I started this whole venture, just working for myself, it's been the craziest experience of my life so far, and it's only been a month, but everything that I've done prior, it's like I'm so used to doing things that I don't know how to do it, that it's just kind of normal to me. You know what I mean?
Michael Levan: Yep. Yeah. I think that's a good point, man. Being uncomfortable is definitely the new normal.
Mike Pfeiffer: Right.
Michael Levan: If you're going to be in this business, and there's going to be levels of discomfort that aren't terrible, and there's going to be really bad ones. But yeah, we do need to manage our energy and stuff, but there is times where you just got to like push it. So I think that's an important conversation.
Michael Levan: Switching gears just a bit, when it comes to some of the things that's we've talked about so far, these technologies, what do you think is the most important for somebody that's coming from, whether it's a developer or an infrastructure person that hasn't done a whole lot in the whole DevOps space, what are some of the things you would recommend people start working on right now? Especially if they're like real green, very new to this stuff. How would they start in your view?
Michael Levan: Yeah, so I think in a perfect world it's going to be two things, and it'll probably split 50/50. Is one in terms of DevOps itself, like learn about the culture, pick up the Phoenix Project, a really good book, pick up the DevOps Handbook, pick up Accelerate by Dr. Nicole Forsgren. A lot of really good books on understanding what DevOps is as a whole, without the technology aspect, just understanding how to implement it in an organization and in a team.
Michael Levan: And then the other side of it, people say DevOps is in tooling, and I agree it's not, but you need the nails and the hammer to build the house. So they kind of go hand in hand. With that being said, I would say the two things that you want to focus on, if you're super green and you're just moving into it right now is some cloud technology, because DevOps, you can practice it on prim, like I have CICD pipelines that are hitting ESIX boxes for virtual machines. Like you could do that, it's perfectly fine. The only thing is is that organizations 80% of the time are going to want it to be done in the cloud. So I would say pick a cloud. I personally like Azure, I've been focusing a ton of time in Azure. I used to focus a ton of time in AWS, but Azure is kind of my thing right now. So you know, either Azure or AWS, they both have free trials, they both have free resources, they both have free learning resources, there's a ton of books on each thing.
Michael Levan: And then the second thing is, pick a programming language, and go with it and learn it. I would say if you have a solid understanding of what's happening in the cloud and a solid understanding of how to automate it, you're 60% there in terms of the interview and then everything else, don't be scared because there's a ton of technologies out there. I certainly don't know all of them and I'm certainly not a master in all of them and nobody expects you to be.
Michael Levan: So I would say just pick those two things. Go Azure and PowerShell, or Azure and Python, or AWS and Python, whatever combination you want to go, and then drive down that path. And then once you get down that path, it's going to start to open up other doors for you. You're going to be automating and then you're going to run into this thing called Docker or you're going to run into this thing called infrastructure as code, and it's all going to start to come into play once you hit the ground running.
Mike Pfeiffer: That's good advice, man. So as we close out this episode, going to start to wind things down here. What are some things people can do, like on a nontechnical side, do you think? You mentioned culture, is there any specific advice there? I mean those books are really good. The Phoenix Project's a great one, I've got Accelerate here sitting on my desk. That's important. Anything beyond that?
Michael Levan: Yeah, I would say the biggest thing is understand how to communicate with people in multiple teams. So pretty much the idea, and this is again, depending on the culture and depending on the organization, but really the idea is when I go into an organization, whether I'm a full time employee or I'm a consultant, and I'm in a DevOps role, what I want to do is I want to get everybody to work together. So I want the front end team to work with the back end team. I want the back end team to work with operations. I want back end and front end to work with security, right? I want everybody to be able to work together and be able to be in stand ups together, be able to, go on one-on-ones together to give yourselves feedback and stuff like that, and ultimately, even be in a Slack channel together, like whatever the case may be. Anything that you can get your teams working together to come to the end goal, because the end goal for everybody is pretty much the same, ship quality software. And with that being said, you know it's much easier to do that together than to do that segregated.
Mike Pfeiffer: I love it, man. It's important stuff. We need to have more conversations about that topic. So coming out of the show, where should we send people to find what you're working on?
Michael Levan: Yeah, absolutely. So my website where I post a ton of my content and then recordings like this will be at clouddev.engineering, and on Twitter I'm pretty active. It's at the New Jersey, the NJdevopsguy. And in terms of other social media, that's pretty much it. Just Twitter.
Mike Pfeiffer: Cool. We'll link it up in the show notes for everybody. Appreciate you listening. Michael, thanks for being on the show, man.
Michael Levan: Thanks for having me.
Mike Pfeiffer: Want to keep up with what's going on in cloud computing? If so, subscribe to my weekly newsletter, and get my top five tips every week for staying on top of Azure, AWS, and Google Cloud. Just go to askmike.io/subscribe to join today. Every week I'll send out information about cloud architecture and development, containerized applications with Docker and Kubernetes, DevOps and automation, and strategies for getting the latest cloud computing certifications. So if that sounds awesome to you, go to askmike.io/subscribe to join the list today.
Get exclusive access to special trainings, updates on industry trends, and tips on how to advance your career in the tech industry.