Yeah, so I'm from IKEA. I work as a senior systems engineer at IKEA retail, also known as the Inca Group. So what is the Inca Group exactly doing? It's operating close to 400 stores in 32 countries. It's also responsible to be employing 170,000 co-workers. There's some numbers on the 2021 terms of the visits to the IKEA website, including downloads. We have 4.3 billion visits to the IKEA website. And we also have around 700 million visits to our stores. So it's quite a bit of an enterprise. If we're looking at what I'm part of the digital organization within Inca, it's handling 3,000 employees that is doing all of the technical development that supports most of our business, including... I've lost it. That's good. It's been a while since I've been on stage, so that's maybe why. But anyway, we also like a lot of other people looking for... people to join our forces to actually deliver on our journey. So let's go into why we're here today. Let's actually talk about the project that I'm working on. It's part of our modernization efforts in terms of modernizing our enterprise. That is a lot of other companies or enterprises that are in the same situation as us. We're not just modernizing the IT landscape. We're also modernizing the business as a whole. We're moving towards more circularity and reusability of our products. But in terms of the technology, we are moving from a lot of operational-focused operations to more agile and DevOps approach. As part of that, we're also moving a lot of our workloads from our data centers into the public cloud. But it's not all workloads that are movable in our situation. Since we're operating in that many markets, we're also operating under regulated environments, so that there's a ton of that that needs to be handled in a good way. So we're setting up this private cloud initiative in our data centers in order to get the same kind of operational experience or developer experience that you will have in the public cloud. So what is needed from the private cloud initiative is that it should be easy to use, just that you would experience with any other public cloud. It needs to have a cloud-like consumption model in our data centers. And also, we need to build trust to our consumers of the private cloud and consumers in this context. It's not IKEA customers going to the stores. It's our developer community within INCAP. So we are also one of the initiatives that is really needed for this is that it's multi-tentancy, meaning that multi-tentancies within different developer communities in INCAP. And also, we are putting a lot of effort in the Zero Trust initiative so that we can run application with confidence in a multi-tentancy environment. And from this private cloud, we looked at different options, like there's a lot of enterprises has been down the open stack platform, but we're kind of building this environment to support our needs of tomorrow, not as such as a cloud provider as such. So we decided on moving or leveraging the Kubernetes infrastructure initiatives. So it gives us this possibility of actually extending the APIs a lot with different types of CRDs so that we can get, for instance, we can run QBird as an operator to handle VMs in this environment. There's also a very highly demanded interoperability between our current environments that has been built many years ago and this environment. So we have a need to actually be able to coexist these environments for a long time before the old systems has been modernized in order to fit this new environment. So from our design thinking point of view, it's an open source first platform, meaning we kind of went away from dealing with traditional vendor approach where they deliver something that we can use and operate. It's been needed at least for some time that we actually have lots of flexibility in terms of picking and choosing from the different components in the CNCF initiatives so that we can gain speed and flexibility that way. And we have been looking at how a lot of the public cloud providers has been doing their infrastructure with regions and availability zones. In our context, the availability zone is a Kubernetes cluster. And then we can have one or more in a region. We have load balancers as a shared resource and the same with the storage. And since we are building this environment for being ready for tomorrow, we're also looking at running this as an IPv6 single stack and also we're looking at multi-home parts in order to support some of the more traditional workloads. And to tie these zones together, we're using the Asilium cluster mesh because it provides us with some nice integrations to running this multi-cluster environment that we have been trying to do the same type of thing before with CoreWiz. It actually supports having cross cluster lookups. And you can do writing your own network policy operator to make that work. It seems to be a lot easier when it's all built into the Asilium tool. And the last piece for this environment is that we're doing BGP routing within our data centers. What it gives us is a lot of flexibility. And you can actually move your workloads around much easier in our opinion. And also this gives us the possibility to scale out the environment both in terms of the number of nodes and clusters, but also if we're running low in the data path, we can scale up or add an additional layer of leave switches in the top of this that will bring us more bandwidth within the total environment. Why is this important? It's because we're moving from a scale up solution into a scale out. We also need to have the possibility to scale out networks. And with this setup, we can actually fairly easily get our reusing egress gateways as well to connect to the legacy environment. We can use these egress gateway IPs fairly easily to get this all tied together. And then you get global port routability, pod IPs, and what's not to like about that. And then we're looking more into this networking and the Cilium piece, as well, why people are here today, I guess. So I guess this, Thomas had a slightly more updated version of this. But in essence, we think that or see that EBPF is gaining a lot of traction. And since we're building this environment for tomorrow, I think it's a right time to actually address some of the challenges that we see today with actually some of the technology that is really picking up today. So it becomes actually one of the key things for us as a team is that it makes it easier for us to deliver a trusted environment when we're going in this path. And the next, at least it's no secret that our team is not really developers or kernel developers. So we have teamed up with ISOLevent in order to co-create some of the features that we were missing in the Cilium product. Firstly, we started out this project of the private cloud, started out two years ago, more or less. In that setup, we were leveraging our on-prem load balancers with Live and its operator in order to control it from Kubernetes cluster. It's more or less a traditional load balancer setup where you access the cluster from through an F5 load balancer outside your workload. This is a fairly straightforward environment, but it also brings the need to actually run your load balancers outside, either on a physical device or through a VM. And in this environment that we're building, it's actually also meant to run inside our stores. So it should be able to run at any scale, so from a small environment with one cluster to a larger data center deployment. So we're looking at the XTP, the express data path that allows us to actually bring the load balancers back inside the Kubernetes cluster. And what we were missing in this earlier adoption phase was actually that we were running, as mentioned, with Multinic ECMP through the BGP integration. And when we started looking at Syllium, it didn't support Multinic XTP. So luckily, we worked on that together with Iso Luven to get that into our stack. We're not quite there yet. We hit other problems with XTP. We found that apparently it's not that simple to get it working, even though we're looking at some of the supported NIC or network device drivers. We ran into this kernel bug that we're currently working with the vendor to get resolved. It locks up our nodes. But for now, it's doable, at least to run our current testing and continued work on moving forward. The multi-homing piece is a different story. It's where you actually can get multiple IP or networks attached to your pods inside your Kubernetes environment. This is interesting for us to support some of the multi-tentancy problems or problems that what you want to say about it. You can easily end up in situations where a tenant will actually consume all of your bandwidth with doing things like data migration or AI workloads that consumes a lot of bandwidth to consume data. There's a tool, Multus, that supports this. It's actually, in our opinion, it brings also a lot of operational complexity. It's not just one networking component that you need to run. You need to run multiple different ones to solve your problem. And then from a zero trust slash multi-tentancy point of view, it doesn't really bring network policies. Again, we teamed up so that we can actually run multi-homing inside Syllium. It's currently a proof of concept that we are doing. And it's where we have the possibility to run two different sets of networks, the default Kubernetes Pod Network and a different network with the same kind of feature sets. So you can have service discovery and network policies on your secondary interface. And in our BGP backend, we can then route this through different nicks and different paths in our networks in order to not have network conjunction. We also have the possibility to have this network manager that was also discussed earlier. And there's been some work put into that that makes it even better so that we can actually even further tighten or secure that the different tendons in our environment doesn't really break things. So that's really nice. And in terms of the IPv6 single stack, we think that the time is right to actually move into that direction since it's a new platform, but also since IPv6 has been around for that long. And other projects that we're using, Cube Word, for instance, is also bringing IPv6 single stack support. So currently, we're not really routing IPv6 within our data centers. So we have some outstanding things that we need to address. For instance, we need to isolate this environment so that we can actually get NAT64 and 4.6 working. So we're working on that feature together with Isolavent to actually be able to have the translation happening at the load balancer node so that the environment could run IPv6 and everything that is communicating to it will be addressing it as IPv4. So this brings us closer to be able to roll out our IPv6 moving forward. And to connect all the things, it's quite simple to actually connect your network from your Kubernetes environment into your BGP environment. We're using BERT as the routing daemon on our nodes. And it has a nice integration to local host. That's like for those, you cannot really do multiple BGP sessions out of a single node, so you need to kind of correlate them on your node. So that's the integration piece. For the observability piece, I was actually thinking of doing a demo, so I hope that will work. So as mentioned, we were implementing this dual-necked XWP XDP support in order to actually look at how things were going. And how do we then test this when your old-time sysadmin is trying to use your TCP dump, and it shows you nothing? It's quite interesting. I think our setup is that we have these nodes and maybe it would have been easier with a different mic. It'll help. That was actually why I was a little worried that it's working. Our VPN was just two minutes before this, so the node that I'm on now is actually one of the clients. That's not it. That's not the client, sorry. That's the it would have. Live demos are hard, people. Give them a hand. Thank you. We've been out of practice at this. It's going to take a while. I don't know if all of you remember the excitement and butterflies of standing on stage. They've gotten worse after two years in no practice, least in my opinion. So the top screen is my client. And when I'm trying to look at, in my button left screen, look at TCP dump, that's at least my go-to tool when doing network debugging. Apparently, when you query, it's not doing anything. In particular, you cannot see it's actually getting this request coming through. So it's going to my node port service. And then it's hooked into HTTP. So that's not really going to give me anything in particular on that. So luckily, Syllium has this tool that's the Hubble Observe that will actually give you some of that back. And you can use your Hubble Observe to actually look at traffic coming. The app will record. That's my mistake. It's you can record the traffic flow coming in. And you can see that for some reason something else happened. Yeah, I think it's a bug in the system somehow when you start this up, the recorder, it actually needs to get to this stage in order to not show things and be recorded. So you can see that you're picking up the packages in this scenario. And then you can get back to your actual. So I have a cheat sheet or not. I cheated a little bit like in the pre-baked your cookies in order to not spend all your time on downloading things. So if you're looking at it and you at least go to, whoa, but anyway, you can see the traffic from our client going to the node that hosts the node pool. And then you can see that traffic is actually leaving towards the pod IPs. So if we exclude this one in order to see that will go. So the source MAC address is one of the nicks on this machine. We can exclude that just to verify that it is actually using also a different source. So you can see that's a different MAC address. So in that case, we can verify that we are actually leveraging both nicks leaving this there. So that was kind of the demo. The one thing that we are still kind of investigating a little bit is actually how do we get these data into some more convenient tooling than doing a Hubble record and then looking at them in Wireshark. It would be really convenient to have them. We're using the Grafana stack to do metrics together with Prometheus, but it would be really nice to have a way to actively to get this into this stack so that we can actually support our developers in their journey on being self-serving on also networking components. So yeah. Do I have a mic? Oh, I do have a mic now. Here you go. Hi. Hello. I wondered, you mentioned the BGP thought advertising to your network. I was wondering, I also saw the small YAML paste there. So I was wondering, how is that integrated with the rest of the infrastructure? Because there has to be a service discovery and different things. You mentioned the bird demon. How is that integrated? So bird is connected to our BGP infrastructure. So it's advertising the IPs to the switch BGP demons. And in that case, it's routing the traffic. We are using the service type load balancers to actually run services inside our network. And that's where we are needing the net 64 and net 6546 in order to actually do the integration perfectly. OK, other questions? No? Oh, yeah. Thank you. I love that everybody is helping me. This is awesome. Hello. How do you handle multi-tenancy in this, like you mentioned? So we're doing multi-tenancy based on namespaces. And then we're installing the network policies in order to ensure that everything is blocked by default. So that's kind of our current way of thinking. In order to ease it up a little bit, we are actually thinking on leveraging the namespace for the hierarchy plugin. OK, thank you. Oh, more questions. I love this. Active audience, you in the back. Think of questions. Thank you. Can you please talk more about the CordianS cross cluster plugin? Sure. So CordianS, at least when we did it, it has a cross cluster plugin that you need a service account in the other cluster in order for it to do this service discovery. And then you can actually specify what we did was to have different types of cluster domains. So we had different types of cluster domains. And we can leverage that for our service discovery. And then, of course, you need to have that cross cluster functionality in all your clusters. The second part of that is also having your part network routed. But I guess that's a different story. Thank you. All right, so now I'm looking at the back half of the room. Any of you have questions or want to point me to someone that you know has a question but hasn't raised their hand? No? OK. Oh, hands here. I missed the middle bit. So how do the developers interface with Cilium? Can they use Cilium to observe traffic and to debug their applications? Yes. So we're using Hubble, and we're allowing all team members to view what's in Hubble. We also have been using the Hubble Hotel integration to actually have network traces inside our Grafana tempo instance so that they can look at that. We have briefly been playing around with actually doing metrics based on traces and see if we can actually further enrich data and also give them much more insights into specific networking components. OK, I think we've got this last question. Thank you so much, Karsten, for a great presentation. I was wondering about your multi-homed network interfaces and how do you handle asymmetric routing for that use case? You said you were using ECMP together with the network stack, or are you only using one interface at the time? Yeah, we're using ECMP in order to gain that it can pick any path, basically. So it doesn't really matter since it's routed network. So either way, it can pick any interface, both in and out. Our announcements is for the multi-homed. We are announcing different networks on different NICs. So that's how we are handling that. So POD is never using both networks at the same time? So the initial use case for the multi-homed thing is to be able to, if anyone has been trying to run an elastic stack, there's HTTP transport and then there's the transport layer. We want to separate those two so that the search queries goes in on the separate NICs, where that in our environment is the client facing interfaces. And then all the transport is handled on the back end networks. And you can handle that with being able to have multi-homed pods. Thank you so much. Thank you so much, Karsten. Can everyone give him a big round of applause? Thank you. Thank you. Thank you. Thank you.


What's the biggest backroom's entity? Well, to answer that, I would have to scroll through the wiki for hours on end and compare sizes of creatures over and over until I find the biggest one. Oh, that's my job, I forgot. The Strider is a huge creature in the backrooms, which is a large eye-shaped being that lives on level nine deep inside the suburbs. These things have six eight feet long arms, which propel them to be about eight feet tall. They can run really fast up to 100 miles an hour. And while eight foot tall does sound pretty big, it's nothing compared to the actual biggest backroom's entity. La Camiloa is an entity that lives inside the murky waters of level 4,000. Takes the appearance of a humanoid made out of stone and it's set to be around 100 feet tall. It's extremely rare to encounter it though, so that's pretty good. Anyways, the actual biggest entity is Broogly's bald head.


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.  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.  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.  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.