 So, also thank you very much. In the, just for you, we have the enterprise channel. Track has been live and it's going on. The next session on the enterprise track would be GitOps challenges for the enterprise. Now, here on the community track, we have two awesome gentlemen, Lucas and Dennis. I don't want to pronounce their names wrongly. I will learn once they pronounce their names. They are joining us from, oh, I can't remember the country, but they are here joining us. And they will be speaking about rackets, racklets. They'll be introducing us to racklets. I think it's a new project. I'm definitely looking forward to learning more about it. So over to you, Lucas and Dennis. Hi, can you hear us? Or me? Yes, yes. Very well. And I'm going to share my screen. Let's see if I do a Chrome tab as well. And then rackletafricaslides. And then jump to the beginning. And off we go. Can you see the screen? And can you hear me as well? I can hear you. Yes, we can. We can see the screen. Perfect. Great. Then let's start. Hi, welcome to this presentation. And yes, as was mentioned here, we're today going to announce our new open source project called racklet. And we're joining you from Finland today and we're very excited to be at this conference. Cool. So the cloud. What do you think about when you hear the cloud? Is it someone else's server? Well, if it is, then it's also someone else's problem, right? To manage all of these servers. Like you just use it, that's great. What is the problem anyway with managing servers anyway? One can just go to the dashboard and deploy workloads instantly. And this kind of this mismatch here in like, we can do some of the things through dashboards without knowing what is underneath, what is happening in the real world. But sometimes you really need that kind of deeper understanding. So let's take an example here of how a web app is introduced in, say, when you're learning about these things. Then you have this kind of web app simplified model. It's talking to the database and that's all great. But in the real world, it more looks like this kind of murder mystery that you see here on the right picture. And that's just how it is. And how can we kind of bridge the gap of this kind of mental model issue that you have this simplification and then in the real world, it's much more complex. So when you learn about something for the first time, you often see it like kind of a black box. So like you don't know what is in there or how it works underneath. But in the reality, it's a system, for example, a cloud composed of many, many components. This we'll get into later. And as was found in this master's thesis from Kaspanissen and Martin Jensen at Orhus University in Denmark, they studied this kind of thing and wondered like if we have something tangible, something like learning cloud system and something you can touch, you can roll around with it and physically change the object between the students or the one that is learning and to get the full comprehension of the kind of large complex system. That is the case in these large cloud native systems these days. So we'd like to introduce Racklet, which is exactly this kind of mediator object. And we'll tell more as we go with this presentation what Racklet is. But first, we're gonna do a short story. So understanding a cloud in a holistic way is really hard. This year is a visualization of what you as the user or as the developer see when interacting with Gwynethys or deploying your applications, compared to all of the behind the scene complexity that is required to run a cloud. In today's ever more complex technology ecosystem, it is crucial to also see the bigger picture, for example, in order to understand error situations and to make better decisions when developing applications. So let's say that I'm in the market for a cloud. What options do I have? Well, the most common option here is to rent some cloud capacity from a provider, from a well-known infrastructure provider, for example, Google Cloud or AWS. This of course has running costs that scale with capacity. The other alternative that I have is to go directly to the enterprise server hardware vendors and just purchase a bunch of servers and network switches and build my own on-premises data center. This of course has very large upfront costs. Yep, exactly. So like for us, we are both students and that's not realistic to just go at some large corporation and say we want to buy all of these servers. That's not within our budget in any way. So what can we do? Well, we can build our own cloud from commodity components, for example, like Raspberry Pi and some other things of the logos listed here and that is much cheaper and much more accessible. So the next question is how do you build a cloud? This is obviously a large undertaking and you need to bind together many, many smaller hardware and software components and there's simply no end-to-end manual for doing something like this. So here is the infamous cloud native landscape where many of these components that if you build your own cloud, if you go that route, you're expected to integrate these things and it's just overwhelming. Like where do you start? You really need some good kind of glue to bind all of these things together. Okay, so what is the industry standard glue? Well, one very common way is bash, so shell scripting. You write something imperatively like run this command first and run that command, but it's kind of falls apart at some level of complexity where it just doesn't work well in error conditions and isn't as robust as it the glue needs to be for this kind of really complex and dynamic systems. And of course, because nobody likes it when that glue breaks, we aim to form a kind of a stronger glue with Rackless. So in other words, we aim to bind the technologies that we just showed you on the CNCF landscape together in a very nice way with the minimum amount of glue. Right, so let's start from the beginning. Who are we and why did we embark on this kind of journey? So hi, I'm Lukas Chastram from Finland. I'm a former Kubernetes maintainer and has also been a Kubernetes special interest group and working group co-lead. Now I'm studying at Ulta University, but I really find this cloud native community super nice and have been doing stuff with the community. For example, here in the Nordic countries we've run cloud native Nordics, so you might wanna check that out. But also I've been working on new technologies like QBDM and Weave Ignite. And hi, I'm Dennis. I'm a second year computer science student at Ulta University here in Finland. And I also enjoy working in open source a lot and have just recently entered the cloud native ecosystem and this kind of entire environment to develop new technologies like Weave Ignite and now I'm working on Racklet. I'm really excited to be part of this growing cloud native community. Very cool. So let's start by taking a look at how Lucas built a do-it-yourself cloud in 2015. Yeah, so when I heard about Kubernetes for the first time I was really amazed that the Google open source something that they had been working on for a long time. And I was like, okay, that's great. I wanna contribute. So I started to contribute and the first thing I did was to contribute porting Kubernetes to ARM so that it worked on my Raspberry Pis because the only Linux computers I had around were Raspberry Pis because they were cheap and accessible and that's why I did it. And eventually I built this kind of small cloud that you see on the picture. And it was fairly straightforward. I had a USB hub that was feeding power to all of the Raspberry Pis. Each Raspberry Pi had an SD card and then they were connected with a normal internet switch. So while your design was functional, Lucas, is there a way that we can make it more reproducible, more automated and also more secure? Let's first have a look at the hardware. So you used a structure constructed out of plexiglass and screws. And this is purpose built for the single board computers that you had on hand as we see from the picture. And there's really no easy way to simply replicate what you have constructed here. No, I know. So now that we're redoing this kind of thing again with Racklet with this open source project, we want this to be modular. It should be reproducible. And this we achieve by 3D printed casing. Also we want hot swap support so you can just drag the pies out of the thing when you need and replace them. Then problem number two with my old setup was that the power connectors, as you can see on the picture, were entirely non-standard. So I had to have all kinds of different power bricks and whatnot. And when sometimes the USB hub, which has all of the yellow and magenta USB connectors there, that was sometimes overloaded and couldn't handle all of the pies at the same time. So we need to find something more robust that is not a single point of failure. And to do that, more robust solution, we can utilize the Raspberry Pi hat standard. So hardware attached on top. So it's essentially a PCB that goes on top of each of the single board computers. And using this, we can power the Raspberry Pi and the other single board computers in a standardized way using the GPIO header. And this kind of standardized hat form factor also allows for monitoring voltage and current of each single board computer separately. And we eliminate the single point of failure. Next, we have the SD cards that are in the Raspberry Pi and the single board computers. As many of you probably know and also have experienced, constantly flashing them is very tiresome and their durability is limited. And additionally, we cannot guarantee the immutability of the operating system due to there being no kind of read-only switch. And that forces us to inherently do mutable infrastructure. We also have the additional issue that we cannot debug a non-booting single board computer in an easy way. Cool, so that's kind of a lot of problems. Let's take them in order. So first, the SD card, we swap out an SSD which give us better capacity, resiliency and also speeds. Then we switched using immutable infrastructure which means that when starting the Pi, we network boot a pre-made image from some kind of registry and then do all of the security stuff like cryptographic verification. And then to do this kind of secure network booting, we need some kind of hardware route of trust. So we need some kind of key to know is this secure or not. And that we place on this kind of hat that Dennis was talking about. We have the key there as you can see in this picture and that is managed by microcontroller. So now we kind of sold a fair amount of things because the microcontroller can communicate with the Pi and say, what is the power state and these kinds of things and what are the boot logs? But now we get to Kubernetes level. And this is, Kubernetes is kind of hard to upgrade and manage on its own. And I worked on QBADM as I said for quite some time previously. And while that went pretty well and now it's a staple in all of the bootstrapping scenarios, it's just a limited block, it's a building block on which you build larger things. So it's not enough to cover this whole scenario. So, and then when I was doing this, the way I managed it was I SSHed in some kind of IP and node and then run QBADM commands or something like that. And that is not really reusable. So how do we fix this? Well, to avoid this mutable and imperative pattern that you just described, we can bake Kubernetes right into the assigned operating system images. So it comes from the network preloaded and everything is set up. You can just need to fire it up. And we can also leverage GitOps to achieve a fully declarative infrastructure. So no more running imperative commands anywhere. And all in all, what this means is that in order to upgrade a node, for example, you only need to do one file change in a pull request and that's it. That's really cool. But then the next question is like, are these things that we have described, are they realistic? Is someone got to have thought about this before? So is that the case? Well, yes, someone has thought about this before the hyperscale as the large companies like Google and Microsoft and Amazon and Facebook, they are running into these problems as well and they have made really excellent solutions. They also have published parts of the blueprints of their data centers in open compute projects. And you can see one of the kind of designs here on the picture. And here, with Racklet, we have taken inspiration and want to make a scale model of these kinds of really large open compute project servers. We want to make something smaller, but still kind of have the same characteristics. And indeed, the architecture that we just described to you here with this visualization, borrows many concepts from the open compute project and also from their cloud native ecosystem. It has, for example, optimized power delivery. We have hardware and software security features and we also have a fully declarative configuration with immutable infrastructure. Cool. So that said, all of these things, these are aspirations that we can also say, you have probably seen this kind of learning curve picture before, we want to emphasize that we're really in the beginning of this journey, where we have been thinking about these things for a while now, but it's really like early stage. So we'd like to invite you to join us in journey to the top. And so to guide us on this journey, we've defined a set of values to drive the development of Racklet. Let's see what those are. So the first one, the first value is security. We emphasize security really highly in this and that's a main distinguishing factor between Racklet and some other projects. And we want to use the good stuff that has been developed in the cloud native ecosystem and also in the open source firmware ecosystem. So here are some logos with projects that we want to integrate. And once we've kind of fully wrapped our heads around these kinds of really great security projects, but also pretty complex, we want to share these findings with you on the Racklet blog to distill it down and to say that what they really do and how to use it. And as the second value, we have interoperability. And this is really important to avoid this very common XKCD standards scenario that's depicted here. And our approach to avoiding this is to combine upcoming and cutting edge standards with the least amount of glue possible. So this means that we want to explicitly avoid creating new and redundant standards that only apply to this project. Right, so one of the things we want to do is to do things declaratively. So we have controllers which, you know, have this observed if act loop to let you focus on the task at hand. So we say, what should the end result be? Not how to get there. And, you know, here we're going to use Kubernetes great API model and the whole ecosystem to be interoperable with other projects. And on the firmware level, we aim to explore integrating this set of observable and modern protocols and technologies. We want to explicitly avoid any kind of obfuscated and legacy protocols that are hard to comprehend and to debug. Cool, and we want to emphasize all of Racklet's source code, design files, documentation, everything is open source up on GitHub. And in addition to the public availability, the Racklet hardware design itself will be also as accessible and as reproducible as possible. So for example, we're going to leverage 3D printing, we're going to leverage 3D printing and an open source CAD workflow for all of the structural components of this project. Cool, and the schematics will be also made open source or open hardware in KyCAD, for example. We have a Markdown book online, docsracklet.io which is working progress where you can find the documentation for the software components and everything, all the rest of the stuff will be just off-the-shelf components, which means you can buy it in your local web store. And the fact that it's off-the-shelf also means that we need to focus on modularity and compatibility, which is our fourth value. So Racklet aims to be as modular as possible up to the point of supporting different single board computers that comply to the Raspberry Pi form factor. So we see this future where there's an ecosystem of Racklet compatible hardware and software. And we are also planning to implement multi-architecture support, meaning that you can use your existing X86 servers and hardware that you're flying around to run Racklet software. Cool, and one of the transparencies, one of the values as well, we want to demystify the cloud stack and make it more accessible. And that's why we're gonna use these kind of good cloud native projects like Yeager, Prometheus, you know, open metrics to make all of the things in the system observable. And after that, we have maintainability and upgradability as the sixth value. So the maintenance burden of keeping a Racklet cluster running and up to date should be really minimal, such that, for example, software upgrades should be very much seamless. We don't want to have an IT team specialized to just maintain this Rack. It should be able to be upgraded by anyone. And on the hardware side, we also support or aim to support hot swapping and then upgrades of individual components so that we can minimize e-ways that you don't need to throw away the entire Rack if you want to upgrade something. Cool, and the last one is affordability. We want to use cheap commodity components or inexpensive ones such that it's compared to, you know, like these large-scale servers, if you would buy a stack of them, Racklet is much more cost-effective. And also, thanks to the modularity that Dennis was talking about, you can also make Racklet fit your budget or local availability. And let's take a look at the use cases. So first of all, we envision Racklet to become a staple in the home labs of cloud-native and tinkering enthusiasts, mainly due to the affordability and hackability of the system. And this kind of open-source nature of Racklet also enables this community to contribute their ideas and innovations back upstream. Cool, and then we have education, which is super important in this field. We want that, you know, for example, universities and other educational institutes should be able to get a Racklet easily and use that for education of these cloud computing systems. And who knows, like using this kind of system, Racklet could be the start of someone's cloud-native career. As a sort of scale model of a real cloud, Racklet is also suitable for many research and development applications in cloud-native infrastructure as well as the cloud-native patterns and paradigms. And this kind of sandbox could lead to broader cloud-native research and thus increased adoption in the space. Cool, and edge computing is also a really, you know, booming field at this moment. And for that purpose, you need versatile tools. We think that Racklet, with its declarative infrastructure, high security and great interoperability, could be a great fit here. And Racklet is not just about hardware and software design. Our fundamental goal is to build an inclusive and diverse community around the project and an ecosystem. With the ecosystem, there's already a lot of great people advancing the state of art, a state of the art of these kind of systems. So here we are showcasing the work by Turing Machines Incorporated as well as Ivan Kuleshov. Both of these initiatives are super cool and we look forward to collaborating with their authors. Cool, and then we want to emphasize that we want to make the barrier of entry for learning cloud-native lower. So we want to get more people into this field and we think that this could be one way forwards. And that means maybe this is your path to mastering cloud-native. So with all this said, we focused on the mission planning of Racklet for quite a while and hence we have not written any code nor designed the actual rack yet. That work is on track to start this summer. So yeah, we're really just in the beginning. As Denny said, no code yet. We invite everybody that are interested in this to join us on this journey. With that said, we're going to leave you with this XKCD. Thank you. Thank you. Awesome presentation, awesome topic. And yeah, did you really get a lot about Racklet? Yeah, and I hope the audience as well get a lot as well. So yeah, thanks a lot Lucas and Dennis for the awesome presentation. And I think this is the time for Q&A. If you have any questions for either Lucas or Dennis please feel free to drop us on the chat section. And Lucas, if you don't mind, you would like to share a link to the open source projects that we're going to spend in chat so that our attendees can have easy access to the link. Yeah, absolutely. We'll do that in just a moment. And it's racklet.io and then the GitHub is Racklet as well. So do you have any questions from YouTube? I don't see them here. Yeah, so we are currently on YouTube. OK, so basically I think it was just basically positive comments. Motoraiers said very insightful. I hope to learn more. Yeah, we've not had any questions. Cool. We'll definitely also upload the slides afterwards so we can watch them and check it out. Awesome. Yeah, awesome. Great. Maybe we could just hang around for like a minute or two to see if anyone have any questions we'd love to ask. Let's see. Is there anything at the stage? Yeah, but I would want to ask, so because I didn't join in when you started, but I would want to know what was the motivation behind two workers and Dennis Racklet's project. So the motivation is to, well, learn more about this stuff because as we showed in the slide, like we're really on the beginning also having been in the community for some time, it's really just like the start. So we want to learn more. That is our personal motivation. But also we really want to, as I was describing, lower the barrier of entry to this field by doing these tangible things and making it easier to understand. And this is so complex, all of these cloud-native things. I have no idea how many CNCF projects there are these days. There's just so many every day coming in. And then that would be, this would, we hope, would be the perfect test bed for that kind of stuff. So you want to try something out, you just download it and see it, then you can plug wires and stuff and have it really tangible. That is why we started the project. But I said there's no code yet, just design. And these kinds of ideas and where we're open to all kinds of feedback from the community. Yeah, also. Dennis, you want to add something? Yeah, I can just add that kind of, we also felt that there was a huge discrepancy between what the hyperscalers were doing. They were going full steam ahead with their custom cloud solutions. And we kind of layman, normal consumer people here are just kind of left behind. So we wanted to research into this state of the art and kind of how can we bring this into home labs and education? How can we make people aware of these systems? So that was also one incentive behind this. Yeah, that's good to hear. Actually, we have a question. So, so I guess it is, can a person with no coding skills join Racklets? Sorry, I didn't hear the question. Can you say? Yeah, can a person with no coding skills join Racklets? Yes, yes. Yes, they can. So one of the great things about this is that as we go, we want to demystify things. So like as we learn the different projects, say, you know, the update framework I'm working on at the moment. So that is a very kind of complex, that is a very, you know, academic CNCF project. And, you know, some years ago I'd taken a look at it, but just like, you know, I can't do it after some time. But now I've spent some months and actually tried to understand it well. And what I'm going to do then is, you know, or what we're going to do as a team is make a blog post about this to say, like, okay, in normal terms, like, what does it mean and why should you use it and what are the benefits and that kind of stuff. And one way to contribute is, you know, using docs. So like, exactly in that way, you see some kind of nice project and then you're like, okay, I want to understand this more than you, you know, we can discuss it. We can, you know, have this kind of community. We talk about it. And then you write this kind of blog post that, okay. So here is what I learned. And, you know, if I knew these three things before I started it, looking into project X, that would have been amazing. And now I'm going to share that with others. So that is one of the great ways to contribute, but also, well, Dennis can comment on this more, like 3D printing, you know, like there's a lot of, you know, you need to be great at designing CAD stuff or electronics or microcontrollers or that kind of stuff. Or just community or like community management is a super important work, you know, you know, helping people find each other and these kinds of things. That's, you know, people, for example, in special interest group contribute or experience that Santoshi was talking about, it's like just amazing. So like that as well could be a place. And of course, if you're great at writing documentation or you want to learn more, then I also, or we as a team also highly encourage reading through the request for comments, documents of Racklet and kind of even small contributor contributions like fixing typos and improving wording and saying that this chapter is unclear, all of that is highly appreciated. So feel free, there's so many different things that you can do in Racklet and feel free to just come in and contribute. Yeah, and if you don't know where to start, just, you know, like join the Slack and ask where do I start? Like these are my skills. And then we'll find something. Help is important. We need to add this next to the slides as well. Yes, yes. Absolutely, absolutely. Yeah, look at some of my heads. So I just thought that there's another question. Is Nanopi from FriendlyElect supported? So, well, we don't have any code yet, so we don't support or there's nothing that actually implemented. No, we can't support. Right now we can't say that we support it, but let's just say that it is in the list of single board computers that we plan to support as a first party. So, yes. So we won't, but if you have a Nanopi, then, you know, a great way to contribute is also, you know, try, you know, when there's some code, then try it out and say that, you know, like this stack of errors, you know, came up because you hadn't thought about this. Then that's great feedback as well. Exactly. Yeah, I couldn't argue more. Wow, awesome. Awesome. So, yeah, I mean, I'm really glad that you actually mentioned the part where people can actually contribute to the docs, you know. Why do people hear about open source contributions? They just think it's just good. But, you know, you can contribute to docs, you can contribute to free typos of the docs, you know, anything, basically. So, yeah, awesome presentation and some conversations we've had so far. And, yeah, I think we are on time or out of time, I'd say, yeah, exactly. So, I would want to ask Dennis one question, but I don't know if we'll have enough time for that, but I think I will have to proceed anyways. So, Dennis, I see a student and we are also, I'm open source developer. So, like, how do you manage your time, basically? Because, I mean, like, the facts that you show and look us in the costume working on this project called Wracklet Mints, that's dictated a lot of time. So, Wracklet, as well as studies. So, how do you manage the time? Well, that balance is also kind of the reason why we haven't gotten to write any code or do any hardware design yet. So, it's kind of studying still is my primary job. And then, I do just open source wall contributions on the side when I had the time. Yes, really tight. But then, I hope that in the summer, I've kind of dedicated the whole summer to work on Wracklet so that we can actually get the project kick started. Yeah, that's also why it fit perfectly with this conference to tell people about it. That, you know, now we're just like starting to ramp up. We haven't, you know, said, as we said, like done much more than the idea part. And now, we're going to start doing stuff when we get a bit more time in the summer. Because, yeah, it's tight with university. Yeah, exactly. Awesome, awesome. So, yeah, thanks to Lord Dennis and Lucas for an awesome presentation. And yeah, Abu Bakar, if you want to take it off from him.