Screaming in the Cloud - Episode 21: Remember when RealNetworks used to-- BUFFERING

Episode Date: August 1, 2018

Are you about to head off to college? Interested in DevOps and the Cloud? Is there a good way for someone like you who is starting out in the world of technology to absorb the necessary skills? The Open Source Lab (OSL) at Oregon State University (OSU) is one program that helps students and serves as a career accelerator. OSL is a unicorn because OSU is willing to invest in open source. Today, we’re talking to Lance Albertson, director of OSL at OSU. OSL does a variety of projects to provide private Clouds that are neutrally hosted on its premises. The lab also gives undergraduate students hands-on experience with DevOps skills, including dealing with configuration management, deploying applications, learning how applications deploy, working with projects, and troubleshooting issues. OSL is for any student who has a general interest or passion for it, and a willingness to learn. Some of the highlights of the show include: Workflow focuses on what students need to learn about Linux and giving access to various repos; then they experience the lab’s configuration management suite Interview Process: Put out a posting, student submits an application online, each candidate is reviewed, student is given a screening quiz, If a student passes the screening process, they are brought in for an in-person interview for personality and technical questions Students tend to initially have the least amount of experience and most difficulty with a repository that has multiple people committing to it and dealing with PRs Spinning up VMs and understanding how configuration management is connected, how services communicate, and how to set up an application Round-Robins and System Sprint Meetings: Focus on discussing and documenting processes, issues, suggestions, comments, and other information Younger students are mentored by Lance and the older students; every generation has to evolve because the environment and industry evolve OSL made OpenStack work on POWER8, PowerPC, and PowerPC little-endian; gateway into Cloud - having OpenStack instance to offer services Vast majority of OSL’s revenue comes from donations; no direct support from the university; finding companies to serve as sponsors is beneficial to all Future of OSL: Providing more Cloud-like services; creating a more internal, private Cloud’ and containerized ways of running or deploying applications Links: Apache Software Foundation BusyBox Buildroot Chef Ruby Freenode OpenStack Sphinx Docker Neutron Seth Rackspace CoreOS Kubernetes Digital Ocean .

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This week's episode of Screaming in the Cloud is generously sponsored by DigitalOcean. I would argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as a managed service at

varying degrees of maturity. Others bias for, hey, we heard there's some money to be made in the cloud space. Can you give us some of it? DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they're using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans with root access and IP addresses. DigitalOcean makes it all simple. In 60 seconds, you have root access to a Linux box with an IP. That's a direct quote, albeit with profanity about other providers taken out. DigitalOcean also offers fixed price offerings. You always know what you're going to wind up paying this month, so you don't wind up

having a minor heart issue when the bill comes in. Their services are also understandable without spending three months going to cloud school. You don't have to worry about going very deep to understand what you're doing. It's click button or make an API call, and you receive a cloud resource. They also include very understandable monitoring and alerting. And lastly, they're not exactly what I would call small time. Over 150,000 businesses are using them today. So go ahead and give them a try. Visit do.co slash screaming, and they'll give you a free $100 credit to try it out. That's do.co slash screaming. Thanks again to DigitalOcean for their support of Screaming in the Cloud.

Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by Lance Albertson, who is the director of the Open Source Lab at Oregon State University. Welcome to the show, Lance. Hi, yeah, thanks for having me on. Thanks for joining me. So let's start at the beginning. What is the OSL?

The Open Source Lab is basically the Switzerland of open source hosting. We do a variety of things for a variety of projects from small to large. So we basically, you can think of this kind of like a co-location facility for some of the larger projects, like the Apache Software Foundation, to providing our own little private cloud that's hosted on-premises for smaller projects or projects that they just decide they want to have it hosted here because we have a neutral way of having things hosted. And so some of those projects include BusyBox. We host BusyBox and BuildRoot and all of those various components.

And so that's kind of what we're all about. We're about helping that. And then the flip side of it, probably the more important part, is we give undergraduate students at Oregon State hands-on experience doing DevOps-y kinds of skills, whether that's actually hands-on in the data center or dealing with configuration management, deploying applications, learning how applications are deployed,

working with projects, interacting with them, troubleshooting with issues, all that fun stuff that you really can't get when you're in school. What's fascinating to me about it, and I've talked about it on this show before with various guests, there's no good way for someone starting out in the world of tech today to absorb all of these things. You talk to people who are in my cohort, where 15 years ago, we were looking at a radically different world. The path that we walked tends to have closed behind us. So there's now not a great series of answers to how do I become you? How do I get to a job where I get to work with these things starting from scratch? And the OSL is one of those programs that I've been aware of for a while that tends to answer that question very efficiently.

So from the student side, when someone enrolls at Oregon State University, how does becoming involved with the OSL manifest itself? What does that look like? It kind of depends on the student. We have had some students specifically come to OSU because of the OSL. But we've also had some other students that never heard of us until they were maybe a lug meeting here on campus, or they had a friend that worked at the OSL or knows somebody at the OSL, and they hear about what we do, and they're like, hey, I'm interested in that. How do I get involved with that? And that's kind of how they get, it's usually like word of mouth of kind of understanding that.

And are these students generally involved in a particular program? Is it tied to a particular discipline at the university? Or is it more general than that, anyone who has an interest? I'll take anybody that has a general interest and has a passion for it and they have the willing to learn it. Historically, most of our students have been in the CS side of things, but we have had students that have had even anywhere from a range of the physics students to we've even had math students, but we've also had students, we had actually one student who came back from his previous IT career coming back to OSU into their fermentation science program, helping us as well. So, you know, we have a wide array of students that are involved here,

but a lot of them have some kind of a CS background. Gotcha. So someone winds up enrolling in the program, or getting hired by the program, since this does pay them. What does day one look like? Day one, well, it's like anything. We create all the accounts.

We make sure you can log in. We give you keys and all that. But then the next step is we have an onboarding process, kind of a new hire checklist. And we've worked on perfecting it. It's nowhere perfect still, but we keep improving upon it each time we have a student go through. And so it goes through having them learn about the infrastructure, about what we do. A lot of these students, they've just dabbled in Linux. And so we kind of have a workflow of like, okay, here's the basic things you need to learn about Linux, kind of a crash course on that. And then they also work with other students that kind of do that.

And then from there, it's just a checklist of we dabble them, giving them a little bit of access to the various repos, having them go through the workflow of getting approved on things, reviewed. Then we dive into our configuration management suite, which we use Chef primarily. We dive them right into Chef and Ruby and all of that. They obviously won't do that on the first day, but that's where we lead them off at the very beginning. What does the interview process look like for hiring someone? Historically, historically, when I've been in operational management roles, it's, oh,

it's easy. You just find people who've done all this stuff before. When you're hiring undergraduates who are never held a job, in many cases, that didn't involve deep fat frying or mopping things, it's not, you can't necessarily find that basis of experience. So what do you look for when you can't have did this thing? Yeah, that's, that's been an art that I think we've kind of figured out over the years. So what we do is we, you know, we put out the posting and then they submit their application online. And so we review each candidate and we kind of see where they're at. Just, you know, we don't look at their technical credentials as much as like if they at least have some experience, you know, that's really what we want. And then from there, we'll send them the screening quiz.

It's, you know, open book, open test. It's just kind of some basic stuff. And we have them send that to us in a plain text file that we put in a Git repository. We all internally review it and kind of say okay yeah it seems like they understand what this concept is um you know it goes from just very basic stuff to maybe we have them even do a little bit of a chef thing and this kind of weeds out those people that you know they'd heard about it and they maybe they don't want to go through the whole you know process of learning about it you know we need to know that um and so they go

through that screening process and once we've kind of determined that, then we, we bring them in for an in-person interview. And then the interview we've, we used to have it for an hour, but that was just way too long for this type of thing. So we've tried to pare it down to just like 30 minutes. And so I'd say about a third of that interview, or maybe even half of it is just kind of getting personality kind of questions, understanding what they're interested in, where they're going, what they kind of want to do, you know, do they, do they fit in with our organization, you know, and all of that. And then we start diving into technical questions and we,

I always tell them the very, when we get to that part, like we don't expect you to do all of that stuff. If you do, you're a rockstar, but you know, just think about it. We mostly look at their problem solving skills and like we help them along if we if we get them to uh answer something um or you know but quite get there like well how about this instead or that and so um we try to do a variety of systems and then a little bit of programming questions we used to do a you know some kind of a programming quiz but that really didn't really help what we needed you know we could figure that out in the end and so uh and then after that it's just a a termination of based on all those things,

what do we do? And the nice thing about all of that is I have my current students actually in there help being part of the interview as well. And so they get to see what it looks like on the other side of the table. So they learn that as well. So that's kind of what it's all about. As you're bringing people on board and exposing them to a whole raft of new concepts that are central to the ops, DevOps, SRE, whatever we're going to call it in the 20 minutes between now and the time this publishes,

because there'll be four new terms for it, of the entire arena of things that go into that space, are there any particular areas that you see that is more difficult for people to wrap their heads around than others? Let me think about that because I think there's a variety of things and it kind of depends on the student as well. I think a lot of the first initial thing that a lot of these students don't have a lot of experience in is dealing with maybe a repository that has multiple people committing to it and

dealing with PRs. You know, most of the time they've had some kind of a school project. And so it's usually just been them probably pushing to master and so forth. And now they actually have to go through a review process. And then some automated test comes back and says something failed and they have to fix that and figure that out. So that's usually like the first thing I've noticed the students kind of, you know, kind of have to figure out. And then beyond that is this kind of understanding how all of this works together. Like, oh, this is a VM running on a machine that's doing this, that has a storage connected in the backend, and just kind of understanding how it all fits together. And beyond that, it's just kind of understanding where,

how the configuration management ties into everything, how all the services kind of talk to each other. How does, you know, when you set up Apache or whatever, you know, how do you actually set up the application to do the thing? So it kind of depends on the various students and what happens. But, you know, at the level we're at, you know, we're not doing, you know, massive things like we're doing in the public cloud. We're just spinning up VMs, basically, is kind of the basic thing. And so understanding how that all works. Which is very fair. To that end, something that's fascinated me about the OSL for a long time is,

you first talked to me about this when you were hosting some stuff for the Freenode IRC network, where I used to be staff. I think that's how we met about 10 years back. And in that time, it was a very different world back then. Even VMs weren't so much of a thing back in those days. And now, not only have you gone past VMs, you mentioned earlier when we spoke previously that you're doing things with OpenStack, you're exploring things in the public cloud. And what's fascinating is that this pattern tends to manifest itself all over the place in large enterprises as they're going through their own digital

transformations. What's neat about the OSL comparatively is because you're staffed with undergraduate students, on day one of bringing someone aboard, there's an expectation that in several years, regardless, that person is not going to be there anymore, full stop. So you've been able to execute a transformational series of changes that have all been bounded on day one by the knowledge that this information can't live locked away in one person's head. How have you found that that manifests itself as far as how you approach documentation, as far as how you approach articulating tribal knowledge and recording that in a way that someone will be around to finish a project when the people who have started it have long since departed? Yeah, that's a really interesting question, and it's something we've had to tackle over the years, and I think we're still trying to come up with the best way of doing that, but I think the biggest change that's really helped us is we've tried to,

well, in years past, we kind of had students have a specific kind of area that they worked on, and so they would work on that, and it was great. You know, everything was awesome. And then when they left, it's like, oh crap, they didn't maybe document everything. How do we do that? More recently, we've kind of switched it to where we kind of do a round robin of where everybody kind of gets to understand how all the things work with all the stuff

the best they can. They still can specialize here and there, but they get to do that. And we've tried to set up, we have what we call a system sprint meeting. Well, kind of having a sprint meeting with ops people is kind of odd. But basically, we just have this trouble board, and we have various kind of top-level things we want to work on. And we have columns where we're currently testing and researching it, moving on, moving forward, and going through all of that. And so we've kind of even done that with documentation.

I'm like, okay, well, we need to document this now. I assign this person to work on it and do that. So we try to make sure everybody documents it the best they can where everything is going on. We internally use SphinxDoc for all of our documentation. And so we have everything in a Git repository. It's all in restructured text. So you just can use your editor and edit things.

And then we just put that in a pull request and we can get reviewed. People can see. We make adding documentation fairly easy for a lot of these things. And so a lot of these students, they'll run into issues where it's like, man, I wish this was documented better. Half the time it's me naively actually documenting it that well myself, unfortunately. And so I'll kind of teach them around what's going on and then they go through it and they learn it and they actually document it and go through that. So it's getting everybody to know kind of everything. And then there's this mentoring

process where the younger students get mentored not only by me, but by the older students. And then the older students help trickle that knowledge down. And each generation, as they go through, it kind of cycles and does the same thing help trickle that knowledge down. And each generation, as they go through, it kind of cycles and does the same thing and goes on through. Well, a counterpoint, too, is that if you take a look at where this started and where the world has evolved, every generation of student has to have evolved because the environment has evolved and the entire industry has evolved.

Back when I started working in operations myself, one of the rainmaking skills that changed everything was knowing the Ethernet B standard when we made our own patch cables. It turns out that that doesn't pay the bills quite like it used to in a cloud-first world. How has the program changed as the industry has changed? We've tried to embrace as much cloud-like technologies as we can. So the first step we did was kind of dive into looking into any service that's more API-driven. So historically, and we still use it, we use most of our virtual machine technology, we

use something called Ganadian, which is a project that came out of Google. This project came up way before OpenStack even was, but it's not very API cloud-friendly. It's good for just, I want a VM that's up, and it's always up, and I can manage it the way I want it. But we've had a lot of things come up where it's like, well, we need to have a service that's self-serving, that gives projects what they need, when they want it, and we finally started embracing OpenStack and getting that deployed. And then beyond that, once we got that deployed, we realized, oh, crap, we need to have a better way of handling storage in the cloud and how we manage things in OpenStack. So that meant we need to learn about SAF and getting that deployed.

And then all the networking behind all that as well with Neutron, when we switched OpenStack to the Neutron and all that, that was a big thing. And so probably one of the big success stories we've had more recently is a project we've had with IBM where, you know, for over 10 years, we've hosted some kind of a power server here for projects, but it's always been, you know, we give you shell access, so we spin up, God forbid, an LPAR using their arcane technology to make that work. Now, that's a name I've not heard in a long time. Yes, LPARs and HMCs. I'm still dealing with that somewhat. technology to make that work now that's a name i've not heard in a long time yes lpars and hmcs i'm still dealing with that somewhat but um you know we would set up lpars for projects so they

could you know build stuff on power um and they came to us i'm like hey we want to be able to do that we want to expand this and make this work better on power eight when it came out and they completely changed how their systems worked on power eight it actually boots up like an x an intel machine almost you know it actually boots up like an Intel machine almost. You know, it actually boots up normally somewhat. I can use IPMI, for example, and connect to it. Anyways, then the only way we could do that was making it cloud-like. So I work with IBM and their engineers, and we were bleeding edge making OpenStack work on Power 8,

on PowerPC and PowerPC Little Indian and getting that going. And now that we've done that, we have I think over it's got to be almost 100 projects that we have that are hosted on that platform. And so that kind of really gave us that feel of like, okay, OpenStack's working, we feel it's pretty good. And so now we just recently

finished spinning up our x86 cluster for just general projects. And so we've just started having some projects on there and getting them on there and so kind of my hope is is that's kind of our gateway into cloud so to speak is that we have this open access instance and we can offer some of the services we i feel like we're more robust that we can provide some of that um you know i'm also looking at having some kind of uh some kind of a container i service that goes with that as well just trying to see what we can make it do. But a lot of it is just getting anything we can have,

the API driven as much as we can. Because like any IT infrastructure that's been around for more than 10 years, we have a lot of cruft of things that need to be fixed. So we're still trying to work through a lot of that. A common and somewhat myopic view of folks who are involved in cloud-native environments, and I'm very frequently guilty of this myself, is to discount anything older than about four days as legacy and not worth paying attention to. If it works, it's not interesting. And that is a mistake in that for many of our listeners, as well as for

many of us who leave one company and then find out that when we're no longer working for a multinational tech company, that spending extortionate piles of money on infrastructure first is not somehow on the strategic roadmap. So being able to look at things that have been working for a long time and be able to address those is incredibly valuable. To that extent, some of the most impressive technologists that I've met have been OSL alumni. Do you have any examples of people that you can mention who've gone through the program and what they've gone on to do? Yeah, I think by far our most famous example is probably Alex Polvey and Brandon Phillips. They actually started here right when I started, or they were leaving here right as I was starting the OSL.

They were students here at the open source lab right when the OSL actually started. And Alex, he first created, I can't remember the name of that company now, but it was bought up by Rackspace. And then he created a second startup company, CoreOS, which a lot of people know about that recently now got bought by Red Hat. And so those two alumni, you know, they came through this program. They had that feeling of, you know, what really needs to happen. You know, beyond that, we have folks like Emily Dunham that has gone through this program. We have, I can't name all of the people we have, but we're scattered throughout the IT industry.

You know, we've had people that are, you know, whether at Red Hat, Ansible, you know, Microsoft, actually, you know, one of our students has been at Microsoft for quite a while. And she worked on a lot of the Hyper-V stuff and proudly wore her Mozilla t-shirt there, you know, in the early days. You know, we're out there and everywhere and everybody, it's a great community kind of hearing where people have ended up and what they've done and the experience and the opportunities they got.

You know, I almost feel envious because I wish that was me when I was at that point, you know, when I started out, but it's giving me joy seeing where they end up. Why is it that the OSL is one of the only programs like this in the world? Back when I was coming up, I would have given a limb to work on something like this. It would have given me such a leg up on this entire industry. Why is this a unicorn? I think there's a lot of things unique to us and just kind of it was the perfect time, the right time. So when the OSL started, it was post dot com boom in the early 2000s.

And at that point, a lot of open source projects didn't really have a lot of places to have their hosting. And so we had at that time, there was some dark fiber going up and down the valley that we could tap into and actually utilize a lot of bandwidth. Because back then, bandwidth was really hard to find for a lot of these projects. And so we kind of helped with that. And then at the same time, on the flip side of it, the organization here at OSU, they were willing to invest in open source. They kind of had their own little mini transformation in that time going from proprietary using more open source. And so the CIO at the time, he was really supportive of us and talked with the university president. So that really helped us getting up.

And then a lot of it is just trying to find that money. And then right at that point, we started actually getting word of mouth. And then we got some initial funding. Actually, do you remember Real Networks? Hang on. I'm trying to remember that, but I'm still buffering. Yeah, exactly. So back then, some of our students actually worked on adding some applications to the OLPC program that had come out. And so we worked with Real Networks to actually port, I think, some of their streaming stuff over there at that point. And they liked us so much that they gave us, I think it was like a half million dollar donation that kind of was able to get us going at that point. And then that kind of got the interest of some other companies like Google and so forth to kind of see what we're doing and how we're providing all this infrastructure and everything to the lab and everything. And so, I mean, if you do it at another university,

it's going to be really difficult because of university politics, funding. All of the funding we get is through soft funding through either donations. We do have some hosting contracts. It's mostly for the larger projects that we host that are able to pay for it or they want to pay for it in some way. But that just kind of covers it at cost. But the vast majority of our revenue comes from donations. So we don't get any direct support from the university.

So if you try to replicate this anywhere else, that's usually the showstopper. It's like you need a data center and you need to have money to pay for all this stuff. And then you need to have staff that has all this knowledge and know-how of how to do it. And then having the right people above and below you to work on all of that is just kind of the perfect storm to make that happen here. I don't know why it really hasn't happened to other universities, but that's kind of how it started here. Absolutely. And finding companies to sponsor stuff like this is incredibly important, if nothing else, just from a perspective of, well, we all got to where we are in this industry

because we stand on the shoulders of giants and people did favors for us. How do we help the next generation? But there are also tangible benefits to companies for being able to get involved in stuff like this, just from a perspective of publicity, of getting a pulse into what it's like

for people who are starting out new. Are there any current sponsors, for example, who've done interesting things in the context of leveraging their relationship with you folks? A variety. I mean, some of our sponsors are pretty much hands-off. They're just like, hey, just keep doing what you're doing. You're doing great. We'll keep sponsoring you. Just keep offering free hosting the projects and doing that, and that's great. That's all we need to know. And then other sponsors like IBM, they actually have an interest in having people get on their platform, switching it to running on their architecture.

And that big behemoth, it's really hard for them to kind of say, hey, you know, come over here on our thing and have access to it. And so they see the value of coming to us and being like, oh, hey, you know, they have the name, they have the relationships with the open source projects, they have the trust, you know, let's utilize that, and then we can maybe, you know, help get things going. So that's probably been probably the most hands-on group that we have as well. We've had some experience with Intel in the past, but that's kind of been an on-again, off-again thing.

At one point, we were hosting Mego, for example, which turned into Tizen and all that. That was that mobile platform that I think Samson or somebody eventually started using. But we did some of that. With Facebook, they actually, we had some connections back in the Prineville Data Center here in Oregon where they have their first big data center they created. I actually knew somebody that used to work at the state of Oregon that got a job there. And they were able to actually send us some hardware from over there.

So we actually have three racks here of their pre-production hardware that they run in their data center that's the open compute architecture. So we were able to get hands-on exposure to that. So that was kind of one unique area of like, hey, we could actually maybe use this outside of use this and kind of give exposure back to them. So it really depends on the company. A lot of them have been hands-off or they've been hands-off. One of the more memorable interactions we had was a few years back when I was running an ops team, and I asked you whether any of your students who are graduating soon would be interested in having a chat about potentially coming to work on my team. And it's a testament both to how well-mannered you are and the strength of our friendship that you didn't laugh in my face when you said, that's adorable, get in line.

What astounds me is what a career accelerator it is for students who go through the program. I don't think I've ever heard of someone who was in the program looking for work for longer than about 20 minutes or so. Yeah, that certainly is the case. A lot of these students, they set up and they have an internship at some point in their sophomore or senior year. And that's usually when they get that hook in because they'll come back. And that's usually if I know they're going that summer somewhere, I'm going to say there's a 50-50 chance that they're coming I know they're going that summer somewhere, I'm going to say there's a 50-50 chance that they're coming back and they're going to work the rest of the summer for me, or they're going to come back and they're going to maybe work part-time remotely for this other

company and finish out school. And then they already have their job set up for when they graduate. It doesn't always happen that way. If a student, I guess, if they were really lazy and they didn't actually do any of that, then maybe they would have a hard time. But yeah, that's usually how things go. They usually have a lot of options. I remember I had one student that kept going to a variety of companies having an internship and he'd already been here for five years. And I said, dude, graduate and get a real job. Because he's having so much fun doing all the various things. So yeah, it's incredible. They have a lot of opportunity and where they can get stuff. So as you look back at the past decade and all the changes that have happened to the OSL, what do you see when you look forward? What does the future look like for you?

For as you see the world continuing to evolve in a more cloudy direction as you see the skill set that people want to hire continues to evolve what are the what changes are on the horizon what do you see coming this is something that i have pondered a lot for the past year year and a half and and it's a really difficult question to kind of answer and i think the short answer is trying to provide more um cloud-like services for projects to use so a lot of what i see projects coming us what they need is a little bit more robust ci environment that can they can run long long jobs or larger jobs that maybe they can't fit on travis ci or whatever CI thing that you have running. You know, we don't have a problem with having,

we have enough hardware for the most part. It's just having the right amount of services set up for those types of things and getting that going. And so kind of getting that going and creating more of an internal private cloud for that type of stuff. I think finding, you know, I've been diving into more containerized ways of running and deploying applications. You know, I see us probably eventually diving into something like Kubernetes for maybe managing some of the applications that

we host for projects. And that'll be a great, I think, learning resource for a lot of the students here so they can kind of get a head start. You the thing that i'm trying to do is make sure that my students have enough modern relevant information and knowledge so that when they graduate they're you know employable usually it's not a problem but you know i don't want them you know working on things that oh yeah we did that 10 years ago so we're still going to do that now that's the way we do it you know i keep trying to evolve and you know i being a schism in schism schism in myself you know i find myself cringing of, I, I know this isn't the way we, you know, if I, my old crumungy, you know, SysAdmin way is like, Oh, I can't do this, but you know, I have to be open and just like, Oh yes,

let's do this. You know, software defined storage is a thing and it does work and it's not completely slow as long as you do it right. You know, that kind of stuff and just finding flexibility in how we deploy services and trying to move more to ephemeral-type ways of hosting applications for open-source projects. You know, I've heard a lot of projects having interest in, you know, maybe running a local GitLab instance, for example.

Maybe they don't want to be on GitHub or something, and, you know, we could be a resource for that. You know, or whether it's, whether it's having, like I said, the bigger CI experiment or having access to the quote-unquote exotic architectures. We have current access to power. I tried reaching out to ARM to maybe do something similar with them. I've also worked out with trying to see if I can even get some RISC-V equipment as well so that we have the space, we have the hands-on people, we can deal with these types of things, and we can give that access. It's really neat to see the ongoing evolution of education in this space.

There is most assuredly more than one way to do it, but it's very obvious that you've found a way that works. Thank you for taking the time to speak with me today. I deeply appreciate your time. Thank you for having me on. Lance Albertson, Director of the Open Source Lab at Oregon State University. I'm Corey Quinn, and this is Screaming in the Cloud. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at Screaminginthecloud.com

or wherever fine snark is sold.