 Hi, I'm Alex Chalkias, Kubernetes product manager at Canonical. Last KubeCon, we ran a survey that asked a question that went something like, what can you not do with Kubernetes? The most popular answer was, make coffee. Now, we all thought that was funny, to put that as a possible answer in the survey. But we kind of did not expect people to run with it. So there we were, with our Kubernetes and Cloud Native Operations Survey, and abundance of useful data about where the technology is going, which you can check in the link shown below, what challenges people are facing, and a clear sign that coffee is still the fuel that is powering the clouds. Then we started thinking about this as a story. Kubernetes, Cloud Native, Coffee. If we were to make coffee using Kubernetes, how would we do it? And how could we leverage Cloud Native Technologies and Kubernetes operators to build an open source, multi-cloud, Kubernetes-loving coffee machine? That sounds like unnecessarily over complicated fun. And this is where my friend Pedro came in. Yeah, so Alex came to me and he asked if I was up to make some coffee with Kubernetes. And I loved the idea. I really believe that there is no project that is too silly, provided you want to work on it and you learn something new at the end. And first, I thought about maybe it could run some part of Kubernetes in a microcontroller, but that was a bit too optimistic with 32K of instruction run and the time that we had to work on this project. Then I thought about using one of those huge professional coffee machines and they just press the buttons on the touch screen and the coffee starts pouring down. But those things are fully-fledged Linux systems. They're more powerful than my laptop. That would be totally cheating. So we came up with our own way to make coffee using Kates. But before that, let me just introduce myself. My name is Pedro. I've been connecting things to the internet since before the term IoT was widespread. I also work as a product with the Canonical and the publishers of Ubuntu and help the Kubernetes, the IoT, the cloud teams with some special projects, including making coffee with Kubernetes, I guess. But all the projects that I'm gonna show, all the tools that I'm gonna show today, they're all open source. They're free, they're community-driven and they welcome contributions from anyone. And as you can see in the title or the subtitle, this is not a story about Kubernetes on the edge, it's a story about Kubernetes beyond the edge. So how we interact with the cluster from microcontroller point of view or from hardware engineer point of view. So how do we feed information to the cluster? How do we interact with our environment with the information generated in the cluster? Before I got started on this project, I set a few ground rules. First of all, I wanted to make real coffee, no virtual coffee, no commands, just coffee it in. The tools had to be open source and my server had to be hosted on Kates, this is a Kates convention after all. And I wanted to avoid vendor lock. And for that, I'm using a project that I'm part of in Juju and I'm gonna talk a bit more about Juju later and how I leveraged some of its technologies to help this project to be vendor lock free. And now so, most importantly, I wanted this to be a fun experience that I've learned a bunch of new things at the end. So this is the fun stack that we came up with. But seriously, we are using a bunch of open source projects and this is also a celebration, I wanted this machine to be a celebration of all the communities that support this project. So thank you very much. And you can find links for these communities in our website that is at the end of this presentation. But let's simplify this just a tiny bit. Okay, maybe that's a bit too much, but you get the idea. We want to make coffee, we want to order coffee and we want to involve Kubernetes. Let's see how this actually works. So we have a touch screen where you can place your order, the command to start the order, to make the order, to execute the order, goes to the Kubernetes server and from there, it goes to the machine or to a microcontroller that is controlling the machine. But as well, there is no physical connection between the touch screen or the app that is running on the touch screen and actual machine. You could might as well just have this in two parts of the planet and it was to have coffee at the end, quite useless coffee, but anyways. So why Kubernetes? Well, first of all, this is a Kubernetes convention and also because of all the good things that Kubernetes offers and you all know about, it's flexible and robust and it could very easily scale the server or scale this device quite easily. And also the survey and apparently Kubernetes operators, human operators still like coffee as Alex put it very well. But getting coffee from this machine is not so simple. Although it is simple, it's not so simple. First of all, we need to choose where you want your stack of apps to run. To prove that this is a truly vendor lock-free project, you can select what coffee you want and also what cloud is gonna be hosting your server. And the same stack of apps is gonna work on any cloud regardless of what vendor you're using and it doesn't require any special configurations. It's the same stack on different cloud vendors and you select that on the touchscreen. But let's dive into each of these parts here. First of all, let's talk quickly about the touchscreen. I'm quite happy about the stack that I put together there. It's running on the Raspberry Pi 4 which is a miracle of technology. I was like, I love to think about if I could show a Raspberry Pi to an Apollo project engineer they would probably start crying. And I'm running Ubuntu Core as an operating system and it's a sandbox operating system so it offers a very good level of robustness. And then I'm using Ubuntu Frame to give me a full-screen shell. It's based on Wayland and there's two things, the Ubuntu Frame and Ubuntu Core to help me to avoid this blue screens of death that you see at airports or train stations. And then the actual app, the actual interface is run with Flutter and it's a snap app. And I'm using Flutter because I wanted to explore a bit more and learn a bit more on building user interfaces with Flutter. So that's why. On the second version of this project I'll probably implement, I'll also install an inbox to run the KubeCon app and this way I could scan the badges and have some sort of stats then like of CTOs like Lattice more than then CIS admins or people from this company prefer tea rather than coffee. I don't know, just some silly stats, but I like it so whatever. But let's talk about Kubernetes, the actual server running on Kubernetes. You may have noticed that at some point I had to choose between HTTP and MQTT. And some people will say that you should pick one of them and they're probably right for most applications, but I really like the MQTT client for DSP and I've used HTTP with Dart and Flutter before. So I just decided to go with both to make an experiment and see what a server that accepts both protocols would look like. And these are the projects that the tools that I've implemented in my server running in my Kubernetes cluster at the HTTP is handled by Flask and the publishing and subscribing to the broker is handled through PAHU. And the information that goes through my server is also stored in the database that feeds Prometheus and some nice Grafana dashboards. As my MQTT broker, I'm using Mosquito and Mosquito is just phenomenal, it's an open source project that, it's the kind of thing that you deploy and you forget it's there, it just keeps working. But I really wanted this to be deployable on any cloud vendor or any infrastructure that you wanted. So if at any moment I wanted to decide, hey, I don't like the prices of this vendor or I like to bring this to my local data center, I could. So how did I implement that? So that's where I used Juju and operators or more specifically charmed operators. So the way, long story short, the way that Juju works is you bootstrap Juju to your cloud or to your infrastructure, it can be a VM as well. It's not an operator for Kubernetes in the Kubernetes sense only. And once Juju is bootstrapped, it creates this logical layer of abstraction. It's not an actual layer, but it allows you to install any app, any stack. You have bundles that you can easily deploy with the same commands on any clouds. So you can create your own operator or you can just choose one of the hundreds that are available at charmhub.io. And Juju will work, will give you the same experience regardless of the vendor that you're using. You do not need to use canonical charmed Kubernetes, although I think that Alex will be happy if you do. But you can use whatever is your favorite flavor of Kubernetes. Another cool thing about Juju that makes life of a hardware engineer quite easy is that the integration, which is a big pain, can be done with a single command. So if you have two charmed operators that are compatible with each other, you can just run Juju relate these two operators. And if you would prefer another one, you can, they're interchangeable as long as they're compatible, as long as they have compatible endpoints. And once they're related and integrated, they will work across a multicloud or hybrid cloud kind of scenario and Juju will handle that for you. And this is another cool thing. Once you deployed things inside your Juju model, you can reach them through one single one common Juju CLI so you can configure your Grafana with the, it can create a new user in your Postgres with the same CLI that you create a new dashboard in your Grafana deployment. And that's quite useful because, well, you know where you're, you actually have control over your whole stack and you don't need to dive into a sea of YAML to understand what's going on. And that's, these three slides are very high level view of what Juju is. And I invite you to visit Juju.is slash brew to get some more information about how we leverage some of the Juju technologies into this project and also to learn a bit more about Juju. But let's talk about the actual coffee machine and the electronics and the cool stuff. So there is a coffee machine and it makes coffee. It's controlled by an ESP8266 and I love this board. I think has enabled so many people to interact with their environments. And so many people have created such cool and creative projects with the ESP and it's a really cool board and really accessible as well. I also wanted to give a big shout out to the maintainers of two of the libraries that I've used for this project. The first one is the PubSubClient, which is a very simple but super useful MQTT client for the ESP, just works. Those kinds of libraries that it just works and it takes for granted. But today I wanted to give a big shout out to the maintainer of that project. Then there is the ESP Software Zero library. And the thing about a Software Zero or zero pins in microcontrollers is that usually microcontrollers, the tiny ones like the one that I'm using, they only have one zero interface and I'm using that for my zero to USB converter so I can upload code into the microcontroller. And it's all very good practice to use one zero pin to different purposes. So I had to use one of the GPIO pins as the zero pin to talk to my LCD screen. Does it make sense? So bear with me. The thing is that my LCD screen, the 16 by two LCD screen that shows the bug information from the microcontroller has a Spartan backpack that converts the parallel pins to a zero interface. But my microcontroller only has one zero port that is connected to my, well indirectly connected to my USB in my computer. So by using the Software Zero library, I can use one of the GPIO pins in my board to control my tiny 16 by two LCD screen. The thing is that this library works super well for Arduino and it's super well maintained but it doesn't work for ESPs. So a champion just a port to that to ESP and is maintaining that. And thank you so much, you make our lives much, much easier. Then I'm actually pressing the buttons on the machine using PWM and I'm getting the information from the sensors in the machine using SPI. But we're gonna talk about that next. Well, before that, if we have to give a reparability score to this machine, it would be 30.5, it would be a terrible score. Out of the box, you need some Torx screws to remove the case in this machine. But once you get inside, it's a really fun appliance to hack. Mainly because of two things, the buttons, they are capacitive buttons. So capacitive buttons, they work a tiny bit different from actual physical switches. Well, they use a physical effect as well but they're different from the switches that move. They measure the capacitance in a certain area and when you put your finger close to it, well, the water in your finger in your body will act as a dielectric of this capacitor and they will change the capacitance in this sensor, in this capacitor, a capacitor, a capacitor sensor. And the controller in the coffee machine's board will sense that and will consider that a button press. And why do people do that? Well, that's the same reason why we have touch screen interfaces. That's exactly the same physics concept that is applied on your phone. It's the change in the capacitance on the screen that allows your phone to know where you're touching and what pixel you're trying to activate at that moment. In this case, of course, you don't want to send the capacitance information, the rock capacitance information, the signal, sorry, to your microcontroller through the guts of the machine because that's super noisy, has a lot of electromagnetic noise. So what the designers of this machine have done is they're converting this into PWM before sending it down to the controller of the machine. And once it is PWM, I can just tap in with my microcontroller and inject my own signal there. If capacitive buttons are quite hard to hack because you need to simulate, they're designed to simulate, designed to actually measure the capacitance change provoked by your finger getting close to the button. So it's very hard to simulate a finger, a human finger. So it was much easier just to inject the PWM signal that is generated by the machine. As a sensor, so the machine has a bunch of LEDs on the top and those LEDs report at the state of the machine. So it would tell the user if the machine has enough water, it would tell the user if the machine has enough coffee beans or if there is a door that shouldn't be open in the machine. And there are two ways to do that. There are two ways to light these LEDs and control them. You can use eight wires for the eight LEDs and drive them directly from eight GPIO pins. That's extremely inefficient. It's using eight wires that are gonna go through the guts of the machine and then your PCB is gonna be huge and that's totally inefficient. So there's a smarter way to do that. You can use SPI. SPI uses two pins, one data and one clock. And what the data pin actually transfers is the, it's like a bit, it's a binary signal, right? So after eight clock cycles, you're gonna have eight bits of information. And for this use case, one is the LED state on and zero is the LED state off. So what is the disadvantage of using the system? Well, it's a serial protocol, right? So you need to wait for the eight bits to arrive before transferring them to the LED. Well, we don't need to wait, but in this case this machine waits. And so that's eight times lower than parallel eight wire communication to the LEDs. Who cares? Like in the morning when they're trying to make a coffee you're not gonna detect and we're gonna perceive the microsecond, the machine to extra microsecond, the machine to light indicates its status. So it's perfect for this application and it's super cool. You can use the wire library in Arduino and just to the Arduino wire library in the ESP and just getting this information and try to provoke the LEDs to light on or off and then you see what is the signal. And then at the end you just have a conversion table to inform the microcontroller exactly what is the state of your machine at that point. So that's a lot of talking, a lot of theory. Let's see this machine making some coffee. Okay, so this is the actual coffee machine we came up with. There is a Raspberry Pi just behind the touch screen here and the screen is wired to the microcontroller. I remember that the Flutter app running here does not talk directly to the ESP8266. The commands I'm gonna tap here to go to the server that is deployed in case and then they'll be executed at the machine. So let's make some coffee. I was actually planning to take this machine to the convention. So we could all have some coffee together but well, that all went virtuoso. And here is the actual core of this project, the fact that it can deploy the same stack of apps on whatever cloud you choose. So I'm just gonna pick Google Cloud here. And then I can double tap the screen just to load some stats from the machine. So what I'm actually doing is requesting the ESP2 read the sensors from the machine and they are reporting the machine is healthy apparently. And yeah, I can say here who I am and I just wanted to create some nice stats showing who likes what kind of coffee and then I'm gonna make an American. I need the cup, quite a good coffee. Yeah, so I've talked a lot about my project here and about how I'm using electronics to hack into the coffee machine but now I want to invite you to look around and think about appliances that you can hack at home. If you do not know anything about electronics, I wanted to give you some tips on how to get started. First of all, get yourself an ESP8266 that's a super useful microcontroller board that has a wifi built into and out of the box you can connect your server and super easy to use. You can program with the Arduino IDE. You can use most of the Arduino libraries and there are tons of communities out there willing to help you. They're available by themselves or you can buy in a bundle and people will generally tell you to avoid the bundles but I would actually encourage you to buy the bundles and they will make you curious to use the sensors and the components in your projects and you're gonna learn a bunch if you're getting started. Also, do not get only sensors and get actuators. Get a servo to interact mechanically with your environment. Get a relay board to actually control high power appliances. Get a multimeter. It doesn't need to be a good multimeter. Good multimeters are expensive. It just needs to measure DC voltage and it needs to measure the conductivity between two points to check if you're not shorting anything. Also get yourself a breadboard so we don't need to be soldering all the time or you don't need to learn how to solder if you don't know and they're pretty decent for most of the projects involving microcontrollers anyways. So that's it for me. Thank you very much for listening and thank you very much for all the maintainers of the open source projects that we used in this project and you can find the details about them and the link at jujuas.brew and thank you. Thank you. If you have any questions, feel free to use the chat here or reach out to us on mannermost, discourse or social media for which you can find all the links on this slide. Also, we are running the second version of the Kubernetes and Cloud Native Operations Survey and would appreciate your time filling it in. The results and raw data will be available on the jujuas website in a month. This presentation, the code used to deploy these services and some interesting metrics will also be available at juju.is forward slash brew.