Re:Role | The Sysadmin And The Script

  |  Compiler Team  
Sviluppo professionale

Compiler • • The Sysadmin And The Script | Compiler: Re:Role

The Sysadmin And The Script | Compiler: Re:Role

About the episode

System(s) Administrators don’t get enough credit. They set up systems. Maintain them. Make sure everything follows security best practices. All while having to know code and infrastructure and looking out for crises. And if you think you can automate away their jobs, you’re in for a surprise: They can do it better and continue to make other valuable contributions to your company.

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

Compiler team Red Hat original show

Iscriviti

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Trascrizione

Our startup team is really starting to grow. Everyone's working together on building the application. The CTO is setting the vision and coding some of the core application. The architect is helping with the stack and the designer is setting up the visual direction and making sure that the user experience flows well. Our developers have their hands full building out the prototype, but the application isn't functioning like anyone imagined, and we're starting to miss some internal deadlines. Our CEO's pretty frustrated, "What's the holdup?" It turns out that a lot of the problems are related to the infrastructure. Test servers are going down and it's taking developers away from their regular work to figure out the issues and resolve them, and they're out of their depth. With the launch looming, it's time to get serious about the hardware and make sure that everything can scale to meet the increased volume of demand when people start trying to use the software. Our CEO's a little confused, "But aren't we on the cloud? Isn't everything taken care of by the cloud provider?" Our developers tell us that no, it very much is not, especially when handling sensitive information like clients' financial data. They say it's time to hire a dedicated systems administrator. So how much does a sysadmin actually do? This is Compiler, an original podcast from Red Hat. I'm Johan Philippine. And I'm Angela Andrews. And I'm Kim Huang. We're following a fictional startup as they grow their business. We're calling the series, Re:Role. Any resemblance to real companies is purely coincidental and unintentional. As a company grows, it realizes it needs to fill new roles. Today's episode: The Systems Administrator. If you'd like to listen from the start of the series, check out our episode on the CTO. Producer Johan Philippine is here with our story. First off, we had a question, is it system administrator or systems administrator? Angela, how do you say it? You were a sysadmin once. Wow, you're making me think about that for a second. What was my title? It was a sysadmin, but I think it is called systems administrator. We managed multiple systems. You think about the scale, the apps, the hardware. There were a lot of systems at play, so I would put a plural on systems and call us systems administrators. Well, just because I'm that type of person, I looked it up and actually it's both. You can say either one: system administrator or systems administrator. Fair enough. So let's learn a little bit about what sysadmins actually do. We spoke with Gene Liverman, who's currently in SRE, or Systems Reliability Engineer for Puppet, which is a cloud-native automation software company. He got his start as a sysadmin. Most people have no idea what a sysadmin does, and most people only think about the sysadmins when their stuff is broken. It's that classic "What do we pay you for?" kind of mentality for the thankless job when things are running smoothly and getting the blame when they break down. Oh, yeah. That sounds about right. Mm-hmm. Let's put a pin in that for later in the episode. But on that note, Gene has heard some disturbing trends that people don't think they even need sysadmins anymore. News flash. So for the people who don't know any better, here's a quick summary of some of the things sysadmins do for you. Fundamentally, a sysadmin is responsible for the physical or virtual hardware that a system runs on. They're responsible for the operating system that runs in that machine, be it physical or virtual, and by being responsible for the operating system, that generally also means that they're responsible for keeping it updated and making sure it stays functional and for actually implementing security best practices on it and responding to any related kinds of configurations that if there is one, a security team tells them that they need to implement. And frequently, they're responsible for installing the software and sometimes even managing the software that is consumed by their internal customers or their external customers, be that a application developer or an application admin or a database administrator or a web content team. That sounds like a lot of work to me. It was. It is. You are responsible for all of those customers and their wants and their needs and the systems that their applications and databases run on. That is your responsibility and it's your job to make sure that things are patched and your uptime is up. You don't want systems going down. You have to do DR testing. There is so much that goes into being a systems administrator. It is such a thankless job, but it is a huge, huge responsibility. Yeah. And upon listening to what Gene was saying, it sounds like a lot of things may be kind of like front loaded or you're setting things up, but from what I understand, and Angela, you can expand on this a little bit, there's a lot of work beyond just that initial setup, right? It is. It really is. I mean, you think about when I turn over a server or a system to someone, I'm still responsible for patching the operating system. I'm still responsible for the security of that system, for the backup and restore testing, for the availability. I am still responsible for all those things. Yes, your application is your own and you can log into it and manage it as you see fit, but it is still the systems administrator's responsibility. Unfortunately, not everyone sees that or understands that, and Gene experienced firsthand what happens when the IT department gets cut. So I got my first big kid IT job, and immediately after getting hired, the university decided not to renew our contract, and so I went from having a lot of the IT needs taken care of for me by the university's IT department to, "Oh, in about a month we have to be not only out of this facility, but we need a network, we need computer labs, we need offices. Hey Gene, go make it happen." And so we had a couple of servers, but we didn't have any networking equipment because we used the university's network, and we didn't have any racks to put servers or networking equipment in, and we didn't have any cables, and so I had to go order a rack and networking gear, and I remember ordering three 1,000-foot boxes of patch cord. And we got to a new facility that was where we were going to be moving into and between setting up a little server room and pulling cable to the offices that we needed and everything else, I pulled, in less than a month, I pulled about 3,000 feet of network cable basically by myself. Wow. That's impressive. Yeah, I've done a little bit of that myself for my own home network. I don't think I could successfully pull that much network cable in that amount of time. No, not at all. So kudos to Gene for pulling that feat off. But he got it done. Among all the other things he's had to accomplish over his career, he learned that in order to be successful, he had to look at the job in a different way. And so between that and doing end user support, but especially on the retail side, I learned a lot about customer service. And what a lot of people don't realize is that even when you're a sysadmin or a network engineer or anything like that, you're in a customer service role. Just because you're not working the help desk doesn't mean you're not in a customer service role. Your customers are just internal, usually. And so if you approach it with a customer service mindset, well, one of the best things you can do is get to know your customers so that you can better help them. That part. He is preaching the gospel verse and chapter. It is a customer service role. I mean, just because you are not the person that someone may call on the other end of the phone, you have to understand your customers' wants and needs and their use cases, and when you're trying to support them, it behooves you to internalize that information because that really helps you do your job better. Communicating helps you do your job better. It is such a important skill that he's right, you don't want to overlook it. And one of the huge parts of that communication is it's really good to be able to speak to people who are not technical or who are even experts in technology, but in a completely different field. For example, if you try to talk about networking and systems administration details to a developer or help desk technician, they may not know everything that you do in as much depth. Listen, there's definitely a skillset there in being able to break down really high-level technical topics to people that don't really have that background because at the end of the day, they still have to depend on that technology to get their work done. So there is something to be said about that. This conversation sounds familiar to me. I think we talked about this before. We did. Being able to communicate across these disparate teams and skillsets because you know your job very well. You may not know someone's other job. So to be able to make that translation between the two and still get the point across and still get work done, yeah, that's clutch right there. Now, unfortunately, there is a, let's call it a stereotype about sysadmins and it's not entirely unfounded. Gene has met some people who are sysadmins who kind of take the exact opposite approach to their job. I've also met people who worked in systems administration and in other roles who think by making things mysterious and opaque that it provides some kind of job security by making themselves indispensable and they're the only ones who understands or knows anything about it, and that's just such a horrible way to approach things. One, it makes your day way less fun, and it's nowhere near as good of an experience for your customers, and most people nowadays don't stay in a job for 20 to 30 years, which means at some point, somebody else is going to have to pick up that stuff that you're doing now, and if you've never documented anything, you've never told anybody about it, it's a real pile of poo to pick up. He has a way with words. Definitely. But he's right though. I remember that persona where the grizzled sysadmin kind of kept everything close to the vest and didn't want to communicate and didn't want to share, and I just found that that was not the way that the company needed you to behave, and it didn't behoove you any because that means there were no days off. You couldn't vacation and turn over the keys because just in case, because no one else knows your job. No one wants that. So Gene has told us a bit about what the job is like for a sysadmin and the kind of mentality it takes to be successful. Now, he's been able to progress his career to become a site reliability engineer, or an SRE as it's commonly known. It's a kind of hybrid DevOps-y role that combines coding and IT, especially for companies working in the cloud. Our next guest is going to cover some of the skill development it takes to make that career track work. To learn a bit more about what it takes to be a successful sysadmin, we spoke to Jose Vincente[sic] Nunez. He's a sysadmin for a FinTech company in New York City. So we know what the nuts and bolts of a sysadmin's job is, but what else do they bring to a startup? Like everything, it starts first with a concept and probably the founders of the company, they just start pulling together a prototype and they don't even have an idea how many hardware they need or even the software they're going to use to put that idea into production. Now, to best understand what the IT needs of a company will be and to be able to contribute as much as they can, sysadmins with a more diverse skillset are increasingly in demand. For example, I noticed over the years that developers think or have this slight misconception that system administrators cannot code, and that's actually wrong. You need to know how to code. Probably maybe 20 years ago, people could get away as a system administrator just knowing Perl and Bash to get things done. That's not the case anymore. Literally, especially right now with all these complex environments where you have virtual machines, containers, and all sort of new technologies flowing around, you need to know a little bit of everything. You really cannot just rest on your laurels and say, "Oh, I know the systems." Now, Jose is 100% right. You better know some code too because the way that technology is going, code is king. It runs everything. It automates everything. It keeps your systems up and running. Now, Angela, correct me if I'm wrong on this here, but this is getting into a little bit about how DevOps works, right? It is. Infrastructure and development, they work much more closely together and the skills overlap a lot more so that there's that understanding of what each other needs and that they're able to work and kind of, pardon the use of the word here, but synergize and better work together and be more efficient. Yes, you're 100% right. That's where DevOps comes in. That's where this line gets a lot less blurry. There is no line, right? I mean, you have your responsibilities and I have mine, but the working across those silos, there are no silos anymore because we have to understand each other's language to a certain extent. I have to understand your responsibilities, not the nuts and bolts, but I have to be able to speak your language and vice versa. Again, we're talking about this a lot because this is just how technology is moving. It can't be like it used to be where someone opened a ticket and you can kind of go, "Eh," sit on it or whatever. No, technology moves too fast for that now, so Jose hit the nail on the head: you have to know a little bit of everything in order to get your job done. I'm going to take us back to an earlier point that Gene mentioned about when sysadmins get noticed. Jose's got a little bit to say about that too. You become invisible if you're doing a good job, and invisible in a way that when the system is actually working as expected and the system is performing, you can actually focus on other things and you can grow inside the company. On the other hand, if you spend every single day extinguishing fires and troubleshooting things that they were not supposed to break, it means that there is a fundamental problem that needs to be addressed. I believe that you need to have some room to wiggle for things that you cannot plan or you cannot prevent, like servers going down, network infrastructure breaking, bugs on the software that they were not expecting, and all of a sudden make the application go like this movie 2001 and start killing all the astronauts. I mean... I didn't see that! You didn't see 2001: A Space Odyssey? Oh, is that what that was? Yeah with Hal. No, I didn't, sorry. Yeah, yeah. Yeah, yeah, yeah. But going back to what- Going back to Jose's point, yeah. Yeah, going back to Jose's point, you become invisible when you do good work, but when something breaks and then you're constantly putting out fires, to Jose's point, there's something that needs to be done there because it's not right either. Yeah. I think it's a lot like what Gene was talking about where if you try and make it look like you're indispensable, it's going to backfire on you because if you're also fixing a lot of problems, there's that indication that maybe you're not doing your job as well as you could be, right? Someone else could probably do it better. You know? Hm, yeah. That's a double-edged sword there. Now, just to be clear and not to scare everyone away from the job, right? Oh no! The odd outage is going to happen every now and then and you're going to know how to deal with it and it's going to be fine, but like we've been saying, fighting fires all day, every day is not a good sign. Now, preventing those chronic issues takes deep knowledge of the hardware and the configuration side of things. It also takes good communication, like Gene was telling us earlier, and being flexible with the demands of the development team. You want to be a facilitator. Say that you have your developers and they need access or low-level access to the system. You cannot be a roadblock to achieve a task. If they need that kind of access for an application to perform at max capacity, it's up to you to figure out a way to provide that to them on a repeatable way because you don't want to do anything by hand. You want that to be automated, so if an environment gets destroyed, you can replicate it. You want it to be documented why we did this. It's not like six months from now, all of a sudden we remember, "Hm. Wait a second. Why does this application needs root access?" And then you start worrying and having nightmares. He said the key word. Yes. I know that I'm not a systems administrator, but this is the type of energy that I want to channel at my own job. The idea that you want to make it so that you can have an action that is repeatable. If you know that you have to do it, if you know that someone else needs access or they need something certain from your team or from another team, you want to make sure that as much as possible, those types of things are automated or at least templatized in some way, and most of all, you want to know that those things are documented for whoever comes after you. It's all about understanding why they're asking for these permissions and this access too, and then figuring out, number one, if they actually need it to accomplish their task. They don't. Very few people need root access. Let's be real now. I'm going to put on my sysadmin glasses here and I'm going to say- Spoilers. I can't tell you how many times I've had someone come to tell me and say, "Oh, I need root access to my system." "Why?" They can't explain to you why, and if they can't explain what their application or what their service is doing to the extent that they feel root is what I need, that's when you need to have a conversation. "Well, let's talk about what those processes are." I'm going to say it again: very few people need root access to a system. There, I've taken off my sysadmin glasses and Angela, the solution architect, is back. But I have a follow-up question to that, Angela. Yes, yes. So if you have a person, say it's someone like me who clearly does not need root access to something, what do you do to kind of facilitate that conversation? It's not just like a stonewall, right? It's like what needs to happen after that? Do you have to, as a sysadmin, dig deeper into what it is I'm asking? What do I need in order to do my task? Yes, exactly. You have to understand the task. What exactly needs to happen? What are you trying to do? What are you trying to accomplish? Show me what you're doing. There has to be this two-way communication because what you think is root could very well be, "Oh, I just need access to write to a folder." That's a huge chasm difference. That's a huge chasm. So when you think that's the answer, that's throwing out the principle of least privilege, where first and foremost, that is the most important tenant in being a systems administrator. You are not to give everyone the keys to the kingdom. The principle of least privilege means you give people just enough access they need to do their job. You're protecting the infrastructure, you're protecting the systems, you're protecting them from themselves when you do that. Yeah. And you're also acting as kind of a lifeline. You are. For people that need understanding or maybe need something else, whatever that something else is. They need that understanding of how something works or they need, whether it's something very simple like access, but you're helping them with a sense of empathy and effective communication. Is that right? For sure. Effective communication is key in being an systems administrator. It is key because this scenario right here just screams it. Someone's asking for something and you know in your heart that that's not exactly what they need. How do you clear that mess? You have to have a conversation. There's no other way around it. And to Jose's point, you want to be able to make it repeatable. When someone else comes along asking for access, you've done what you need it to do to document said requests and how do you implement? So all of these things kind of work together. They knit together in this cute little sweater and we put it on and we wear it. There are so many gems here. I'm really enjoying hearing what Gene and Jose are sharing today. Well, that last little point is going to lead us to the last little piece of advice that Jose shared with us. I believe the first thing that every system administrator needs to do is to be able to replicate any work that he's done on a system. In order to do that, you need to script it or you need to automate it, or you need to write up for him to do it for you, and you don't do things by hand. I mean, maybe you do things by hand once or twice, but if you see a pattern, it is like your duty to go and automate it and document it, probably with the code. Now, there's a big caveat to this that's sometimes trying to automate all the things can be a bit too much. Not everything can be automated. That's the other thing. I've been there and I'm guilty of that. You spend probably three hours to automate something that you could do by hand in seven minutes. We've all done that because this mantra, "Automate all the things." So you want to become so efficient, but remember, there are only 163 hours in a week. Only 40 of them are spent at your job. You have to figure out what makes the most sense and what makes the best use of your time. Is doing a task like this and spending two hours to code it, codify it, and automate it the best use of your time? That remains to be seen. What else could you be doing that provides that value, that moves the company forward? Some things can just be a click, click and you're done, and it's documented. Everyone knows that's the procedure. That's fine. But again, when we're talking about things that have patterns that are just simple, easy, you want to make sure that those things are automated. But there are some things that may not be worth the time on the outset to automate. So our final guest this episode is going to tell us about what's expected of sysadmins and their work, not what they do or how they work, but what the systems they build can actually accomplish. We spoke with Chad Hobbs. He's currently an Account Solutions Architect here at Red Hat, but he's also done a fair bit of work standing up systems for companies. He told us about his time working for a financial startup that unexpectedly won a large contract from the SEC. He was brought in as employee number 20 or so. Ground floor. Mm-hmm. What they decided to do was attempt to track what was occurring in our security exchanges, the various stock exchanges that are out there, the New York Stock Exchange, there's Chicago, Miami, and several others. There's a lot of trades that are going on, a lot of market potential manipulations that may be going on. There's things called dark money, dark pools, other things, and the Securities and Exchange Commission, the SEC, wanted to have more insight to that. So they decided, let's build a massive database. Let's collect all that data, be able to track all the trades throughout the day, throughout the week, throughout the month, throughout the year, and then be able to see if there are bad actors that are manipulating the market and potentially head off another collapse like we had back in 2008, 2009. Now, for the youths in the audience: the 2008, 2009 collapse, that was the collapse of the housing market that led to the Great Recession. But back to the task at hand, logging all of the transactions in the US stock exchanges is a lot of data. It's a lot of trades, and they would need a very performant system to do it well, let alone to comply with all of the regulations required by the SEC. Chad set out to build his team to get that done. Now, building that system would require input from beyond the domain of sysadmins and IT. So pulling in people from these other groups is really important to get to other perspectives. I might be honing in on, okay, great, they really understand this particular part of security, but maybe they're going to be throwing over requests to the developers that are unrealistic. They can't do this, or it impacts availability to the system. This has got to be a very performant system. How do we craft application security patches and things that are not going to bring the system down? So the other teams were able to bring in some perspective. On the other hand, they'd also need a system that was capable of incredible scale to make it all work. From the operations perspective, being able to scale up to demand. Now, most companies when they think about scaling, they're going to deploy to the cloud and use some of these cloud-native tools or do something like that. This was all being built in-house and in a secure facilities, it was a little more of a challenge to be able to scale, so it needed to be performant right out of the gate. So they had to squeeze every bit of performance out of every single machine that they had because from a systems operations perspective, availability is number one. If the system's not up, then the application's not running. So there were some challenges there, some technical hurdles to overcome. This is huge. I'm going to put my sysadmin glasses back on for a second. All right. And what I'm hearing is he was responsible, or his team was responsible for building out this system that was integral in watching bad actors and keeping track of all of these trades going on, and that's data. Data takes up space. Data requires processing power. And if this was so important to the agency, making sure that you built the system correctly from the ground up, and then making sure you could scale it out to be able to handle, say, 9:00 AM trades when things are usually at their juiciest. You want to make sure that this system can handle the scaling up and the scaling down. So this sounds to me like Chad had his hands full. Essentially, this company was 20 people, right? This SEC contract was huge, and they were not expecting to get it. They were expecting some other big player in the same FinTech space to get that contract, but the SEC decided to give it to this small company instead, and they essentially had to build everything from the ground up, the system and their own company to support that system. Now unfortunately, after months of work, there was a federal shutdown that meant a lot of their work couldn't move forward. And so that other big company, which happened to have some members on the startup's board, they used that opportunity to get them shut down. But as far as Chad and his team were concerned, they were able to successfully build and maintain that system, and in the way that they were asked to. The technical win. They got the win, although they didn't win the contract, sadly. Yeah, well, since it was the company's really biggest client at that point, it was kind of curtains for that company. Now, even for a team of dedicated and experienced sysadmins and DevOps engineers, this was a really tough technical challenge, and we're going to go back to the beginning of the episode where Gene was saying, well, people these days don't think we need sysadmins anymore. And when we see work like this, when we go over everything that we've talked over the episode, about what sysadmins do, what they can accomplish, imagine what your company can do if you don't have a sysadmin yet, what a sysadmin can do for you and your company if you give them the resources that they need and communicate with them in the way that makes everyone's job a little bit easier to do or a lot easier to do. And what's more, if your systems aren't secured properly, you could get into a world of trouble. We help people not get fired and not get sued. That's right. That's right. So I think we've uncovered that, yes, sysadmins are a necessary part in this startup. Oh, absolutely. I think we made that perfectly clear that it is such an important and integral role. It makes sense that we're talking about it now. So I'm excited. I'm glad we got to speak to Chad and Jose and Gene about this because it was a trip down memory lane for me, and I really did appreciate hearing their perspectives about this very important role that sometimes does get overlooked. I do want to bring it back to our startup at the beginning of the episode. So in that scenario, and maybe Angela, this is a question for you, I want to tie together the things that we've learned from each of our guests into that scenario where you're working for a company in a startup in FinTech, and you're trying to build this application. You have kind of the situation where you have the cloud, where the cloud provider is only providing security for the infrastructure, they're only making sure that that is taken care of, but they're not taking care of, for example, your company data. How does a systems administrator come into all of that and create, I guess, order from chaos? Well, being a systems administrator, you have to understand a lot of different parts. Networking: you have to be versed in networking. You have to understand hardware. You have to understand storage. You have to understand hard disk performance. You have to understand how a system reads and writes data, how much a system can read and write data, and what does that system have to look like in order to be performant for whatever application you're running. So I think people who've never dealt with the nuts and bolts and the system board, there's a little bit of a disconnect because you think, oh, cloud is just out there and it's just infrastructure that we don't have to contend with. But those same skillsets, that same understanding of the physical, it definitely translates into the virtual and the cloud realm. So these are skills that cannot be overlooked when you're looking for a systems administrator to help bootstrap your startup or your organization, and they really do need to be heralded because there are a lot of things that you don't even think about. Think about what Jose said. You have to know how to code. You have to understand it. Why? Because everything is code. Your infrastructure is code. Your application, there's code that brings your application through the pipeline. How do you write that? So I think we've learned a lot, that this is such a key role in this startup, and we're definitely heading in the right direction because we are bringing it in on the ground floor. It's so integral. You can't do your job any other way! For me, I feel what I've learned from this episode about sysadmins is that they play a key role, not just an institutional knowledge and internal knowledge within an organization. So they're coming from a place of, I know it sounds kind of strange, but they're coming from a place of customer experience, not just for customers of a company, but also internal folks who are kind of like customers themselves in those scenarios. You have to be able to communicate and disseminate information that a person may or may not have the skillset and the awareness or the knowledge to understand, and you also have to meet them where they are. When they are making a request, or if they need something, you have to kind of have the empathy to understand what they need and also understand what is important for the company, whether it's from a security standpoint or from an operational standpoint, and kind of figure out the answer for the problem somewhere in between that, and that's kind of what I've learned from all these different conversations we've had today. A lot of hard skills and definitely a lot of soft skills that go into being a great systems administrator. Absolutely. And it's just a lot of skills in general, right? Yes. The breadth of what we've been talking about today, it's just mind-boggling to me. It's one person. It's one person. I need you to understand that! It's a team, right? Hopefully. But right now, it's one person. Yeah. Yes, hopefully, but I've been that one person. It's a lot to put on a person's shoulders, but you have to love what you're doing to be in this role, you have to love serving your customers, working with this infrastructure. This has to be a passion, and I'm feeling really hopeful that our little startup is going to find someone that fits the bill perfectly for this. Well, next episode, Kim, you're going to tell us all about product managers, right? Oh, I am? Oh, I am. Yeah. So we've got our sysadmin and they are basically playing the part of Atlas, but there comes a time where something else really important has to happen when it comes to application development, and that is prioritization, and we're going to talk a little bit more about those priorities, about those different features and how to balance everything when we talk to some product managers. What did you think about this episode of Compiler? We want you to share your thoughts with us. Hit us up on Twitter @RedHat and use the hashtag #CompilerPodcast. We would love to hear what you thought about this episode, and if you are a sysadmin, please share what your thoughts are about this episode. We'd love to hear it. And that does it for The Sysadmin episode of Compiler Re:Role. Today's episode was produced by Kim Huang, Caroline Creaghead, and Johan Philippine. Victoria Lawton makes sure that we don't kill all the astronauts. Our audio engineer is Kristie Chan. A special thanks to Shawn Cole. Our theme song was Composed by Mary Ancheta. Thank you to our guests, Gene Liverman, Chad Hobbs, and Jose Vincente[sic] Nunez. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Brent Simoneaux, Nick Burns, Aaron Williamson, Karen King, Jared Oats, Rachel Ertel, Devin Pope, Matias Foundez, Mike Compton, Ocean Matthews, and Alex Traboulsi. If you like today's episode, please follow the show, rate the show, leave a review, and share it with someone you know. It really helps us out. Thank you so much for listening and enjoying this episode. Until next time.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Articolo del blog

Friday Five — August 15, 2025 | Red Hat

15 agosto 2025  |  Red Hat Corporate Communications

...

Articolo del blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14 agosto 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.