 This is open source demos, industry conversations and the latest updates from around the global open infrastructure community. And we are broadcasting this every Thursday at 1500 UTC on YouTube, LinkedIn, Facebook. Wherever you like to log into your streams, we're going to try to get there and bring you all back together on this show. This has been an awesome way for us to connect with the community while we haven't been able to travel and get together in person and we're excited that we're continuing it on. We started it last year and, you know, we, because it's live, have an opportunity for anybody out there who's joining the stream to ask questions. So go ahead and jump in the chat, start telling us where you're joining from. It's always incredible to me how many different countries we hit people participating from, why you're excited about this topic or any questions you have. And we can get to those questions throughout the show. So at any time, you know, feel free to start, start telling us kind of what's on your mind or what you think about this topic. So with that, let's talk about the topic. So today's episode is Loki. Now this is something you may have heard of. We talked about it a little bit a few months ago and we introduced this concept. But before we kind of get back into refreshing everyone's memory about what this actually is as a concept, I thought it would be fun to talk about the origin story. Now, like all good origin stories, it starts with scientists and a lab, okay? Now in this case, they were data scientists. So maybe different than what you would expect in most of these origin stories. But really all started with the data and I love data. And when we looked at the patterns in the market, we talked to users, we did surveys, we just really analyzed what are people doing with infrastructure, where the open infrastructure summit, we want to know what people are doing with it. And one of the things we found, looking at, for example, the OpenStack user survey, is that 97% of all OpenStack users are running it on Linux or with Linux. And we'll talk a bit more about kind of the concept of the stack and whether it really applies here, but we think of this as kind of a stack. And so not a big surprise here. We know Linux has been fundamental to the creation and success of OpenStack. So nobody should be too surprised by the stat. But the other stat we found and looking at the user survey is consistently year after year is 70% of users who are running OpenStack are running it in combination with Kubernetes. And so when we looked at this set of projects and we said people are running them together, these pieces of software, they're incredibly critical to the modern cloud infrastructure, whether you're talking data center, edge, people are combining these all over the place. And so really what we thought of is what happens when you put these together, you get Loki, meaning Linux, OpenStack, Kubernetes infrastructure. And to be clear, this is not an open source project. These are obviously individual, very, very active open source projects. We'll talk about this a little bit of the stats on that in a minute. So really, this is an acronym or a stack similar to the LAMP stack. It is not its own open source project. I think that's sometimes a few people have questions about that. I know there are open source projects called Loki. Grafana has one. There's another one that's been out for several years. So this is not to create confusion around these other projects. There are many projects out there actually that they call themselves Loki. This is an acronym or a stack or a concept to describe a pattern that we're seeing in the market. And what we want to talk about today is kind of what are people actually doing with these? How are they doing it? What are the use cases? Why is this such a common pattern? And Loki just gives us kind of a fun way to think about it and talk about it. And in terms of these three projects, one of the things that is amazing to me, if you look across all of open source, what you find is that these three projects are three of the four most active open source projects in the world in any category. And so if you look at the contribution statistics in terms of the amount of code that's coming in every single year to these projects, in terms of changes being merged, you see that about 80,000 changes are merged from the Linux community, which is just incredible, far and away, you know, the most active out there. And then of course, OpenStack and Kubernetes are neck and neck in terms of like changes coming in. So what's amazing to me is that we're, this actually shows you that the infrastructure layers, the cloud computing sort of building blocks are some of the most active in terms of contributions, innovation, investment, developer time, lots, all the companies around the ecosystem that are putting these together. So when you add that up, it's, you know, 150,000 changes throughout the year. So when we think about these coming together, again, they are different communities, they are different pieces of software, but there's a lot of cross community work. There are a lot of people that actually work across in multiple of these communities. And we think that putting these together, of course, will not be simple. And people are already doing it, but we want to hear more about how they're doing it, what they're struggling with, where they can have more success and kind of why this pattern is become really the open interest standard. You see Linux, of course, is the standard and kind of operating system layer. And you have OpenStack as a standard and kind of open source infrastructure as a service layer. And then of course, Kubernetes, everyone knows is the standard when it comes to the industry's adoption of container orchestration and et cetera. So when you put these together, we see this as a really compelling pattern. So let's actually bring on our guests to talk more about this and see what's actually behind this pattern. So joining us today, we have Maria, who's joining us from Red Hat. And we also have Phil, who's joining us from Canonical. So when we talk about Linux, OpenStack, Kubernetes, it's hard to think of two better sources than folks like yourself. So, Maria, welcome to the show. Why don't you introduce yourself to our open and for live audience? Hi, Mark. Hi, everyone. I'm Maria Braccia. I'm the manager of the product management team at Red Hat, covering OpenStack as well as some areas of shift as well. And I'm really happy to be here to talk to you and the community about load. Hey, Phil. Hi, everyone. My name is Phil Williams. I am a product manager at Canonical. My day-to-day is actually more on storage and Cef and the products in that world. But I've had a long time being involved with OpenStack. And I kind of think of it as a secondary area that I still like to keep tabs on. And everything in infrastructure is always interesting. Good, good. Yeah, I mean, you've mentioned Cef. There's obviously just such an incredible world of open source out there. And people are putting these building blocks together. In terms of this kind of Atlantic's OpenStack Kubernetes, are you seeing your customers kind of adopting these together? Maybe start with you, Phil. How do you see, are your customers actually combining these things? Yeah, it's really interesting. It's funny. We've developed this new name. But it's actually something that's been happening for a while. Think back to the Magnum project. That was the first attempt of containers within OpenStack. It's kind of this layered infrastructure that the acronym kind of spells out. But yeah, we see customers who, you know, they have today's applications that are very much tied to like a VM type infrastructure. But then they have new developers who are developing the next gen of their business applications and they're focusing more on containers and how they can have some of those containers in private clouds on-prem. Some containers in public cloud. How do they manage this new hybrid world together? So yeah, we see both that both super popular. OK, Maria, what's your perspective on this? Are you seeing this with your customers? Yeah, so when you look at this low key acronym, you know, look at the first rail came out 28 years ago, then OpenStack in 2013, Red Hat OpenStack, and then OpenShift really in 2011. But it really went all in into Kubernetes in 2014. And we never look back. So we've been doing this for a while. We've been doing this sort of internally. Obviously, we ship out our distributions with, you know, we put them together, but we've also seen different building blocks of how this has been resonating with customers, how new use cases are being deployed, and also the workloads that are driving the different ways on which this, you know, are built together to form the infrastructure, to support them, because it's all around the workloads for us. Yeah, that's great. And actually, I have to say that Maria introduced me to the concept of a acronym, which I didn't even realize we had created one when we when we kill this low key concept. But apparently, that's the more accurate description than acronym, so always learning new terms. So I guess, you know, what I'd like to ask next is why people are combining these kind of what's the what's the motivation or the main reasons that you see people putting these together. Maria, do you have some some perspective on that? Yeah, I mean, you know, we've seen this in how sort of natural evolution and right. How that's we work in, you know, we're born in open source. We work and collaborate in communities. So I would say the first thing is that once you're in the community, you start seeing sort of some of these use cases and where things are sort of going. So and how they start putting it together. I would say it's born at the community level first. Some companies that will open source redhead is completely open. Obviously, there's alternatives that are not open to to, I guess, the lucky infrastructure. But because we live in this completely open world, it's very common that we ended up where we are. So, you know, for us as a development model, but also the values and principles of how we work and how we continue to collaborate with with communities. So Linux as the base for over ahead of price Linux as the base of in the ground for for running applications, but then also base for building the infrastructure to run it in the case of OpenStack and with OpenShift being I had the next little chorus. It was very clear that depending on the use cases and the workloads, it would be aligned in different in different ways. And you at the beginning of this call or program, you are showing sort of attachment rates, meaning some Kubernetes users. There are also OpenStack users and also Linux users. But obviously, those are numbers that we also see in our customers and how it is being used. And not necessarily in the order that that the acronym calls it also Linux OpenStack Kubernetes, but also, you know, sometimes in some cases, some Kubernetes under the OpenStack fees. And then, you know, depending if you're going to the edge, you know, you can you can do that with, you know, a piece of OpenStack distributed or a piece of only Linux or a piece of Kubernetes is just having that freedom to see what best suits each particular use cases is great. And that's a really good point that, you know, I think we like to think of it as a stack. And it's the idea is kind of analogous to the lamp stack. And it's like building blocks you put together and it helps kind of people do more and sort of comes as a pattern. But obviously, you know, when we actually called a stack, it in a distributed system, the idea of a vertical stack is pretty much like fiction. So it's like a useful fiction, but it's not at all like always in one pattern. And many, many people run OpenStack on Kubernetes. We actually demoed that, I think the Austin Summit like six years ago or something. So I'm really glad you point that out, which is like, this is not a literal sort of like, it's more like architecture than architecture. But, you know, it's about combining these technologies. And certainly it's Linux all the way down in terms of every layer. There's going to be Linux in the VMs and in the host OS. And so, yeah, it's a nice acronym or background. But yeah, I think it's important we get into the details to talk about the exact ways people combine them. It's simply, it's definitely not just like a really neat stack because it's like a complex distributed system and edge will be different than data center, everything. So all good points. So Phil, I guess the same question for you, kind of what do you see as the drivers or reasons people would want to or are already combining these projects and production? I just want to echo one point you made about 30 seconds ago. It's like this one size doesn't fit all. You know, in certain locations, you have certain limitations so you don't necessarily want lots of infrastructure or lots of infrastructure overhead. So in those kind of places, it might make sense to lay down bare metal, run Kubernetes natively. You know, directly on that bare metal don't have any virtualization layer in between. You might have a larger premise where you already have OpenStack, you already have a chunk of infrastructure. You have spare capacity run Kubernetes on top of that, it makes logical sense. You then might want to expand out into public cloud, run Kubernetes in, say, AWS, but not use AKS, who's gonna say AKS? One of the products of Amazon. So you may want to, again, use the VM model layer but keep the same tooling so that you have a multitude of locations but all managed in the same way. So yeah, it's definitely not one size fits all. And it's very evolutionary. You have applications today that built the third way. You have stuff that's being built for the future. Again, different paradigms. It happens again on the cat. Yeah, that's great. And I think, I said at the beginning, tell us where you're joining from. We've got people from all over the world and also drop questions in chat. And I think we actually already got a question. I think this might be directed at Maria, which is Ram said I'm from Hong Kong and I lost it. There it is. It'd be really great if Red Hat provides Kubernetes stacks for developers, which can be installed in commands, et cetera. So maybe, yeah, you can. Yeah, absolutely. Hi, Ram. Thanks for the question. I can point you out to the try.openshift.com which you can see the many ways that you can try running OpenShift which includes our distribution of Kubernetes, fully compliant, as well as other components to help better operationalize it or use it. The other thing I would point out, and I would be remiss if I don't call it out, at Red Hat, again, we're all open source and in the OpenStock community or the Open Infrastructure community, we also support the distribution of RDO, RDO which is our midstream distribution of OpenStock which is also free for developers. And we have a similar path in the Kubernetes world which is called OKB. So again, free for developers in use in. So you're welcome to try. Thanks. Yeah, and for everybody else on the stream, keep jumping questions in and we'll throw them out as we go if we have time but I think we'll have some more time here. So in terms of these combinations, I think there are always customer requirements and I don't know if you all have any thoughts on that in terms of what types of requirements would lead to a customer or user out there to wanna seek out these particular tools. I think Maria looks like she's ready to answer so I'll throw it to you. Well, let's answer the obvious use case that really took or transformed or disrupted the world of telecommunications with this community really which is the adoption of OpenStock in the whole telecom stack. It's huge, is a dominant technology for 4G. It's deployed anywhere and everywhere in the world for running VNFs or virtualized network functions. It's all about the workloads and that's the particular workload that really benefited from the robust and stable OpenStock stack as well as the networking that it provides. So I would say that that will be like the first thing to go and then in the same community, the workload again, so the move to 5G and workloads that are more closer to the edge and that are now containerized kinda drove the adoption of more of a container manager system, which is Kubernetes and then that drove the need to say, well, existing telcos, have their deployments in 4G, now they have this new need of new technology of 5G, how to, how can they play along, how can they bring my new with my existing as well as continue to grow because we've seen in our customers that they're existing, we have many huge customers all over the world that 100% depend on Red Hat OpenStock to run production workloads and their deployments are, in some cases, at the early stages of deployment, they're only gonna continue to grow. Mark and the community have seen just how much the scale of OpenStock has been such a great topic for us. So that's one thing, so as 4G continues to grow, 5G calls out for Kubernetes, how do these two come together? That's one way of how the Loki Stack is sort of represented in the telco vertical. Yeah, that's a great point, I think. We always come back to infrastructure as basically compute storage and networking, how do you automate all this? And obviously that's just a massive, massive problem space and specifically these use cases around networking. It's incredible how much OpenStock is really the adopted standard there. Like you were saying that every mobile phone call, every mobile connection in the United States goes through an OpenStock-powered network today, like every single one, and we have nine out of 10 of the largest telecoms in the world, so billions of subscribers every day, you know, pick up their phones and they probably don't call people, nobody calls anymore, but you know, WhatsApp, text, whatever, telegram, and it goes over a data connection that in somewhere in that architecture is powered by OpenStock, so, and as people like you said, want to adopt container technologies for all the obvious reasons, then that drives people to adopt them together. So really good example of the market sort of demanding that we make these things work. So Phil, what are your thoughts on this? What do you see as kind of either verticals or requirements that are kind of driving people to say, you know, make these work together? So Telco, again, is such a big, you know, use case the world over, but then we see other like pockets of interest. So think to more like regional CSPs. So those countries where you don't get an AWS, you don't get an Azure, you have local ISPs, local cloud providers who are using the stack to offer this infrastructure service, container as a service type offerings within their regions. These regions are not particularly big, you know, from an Amazon or large scale cloud provider perspective, but for these, you know, local companies that they're scaling up super quickly. And I think the other side of it is really the educational, you know, the R&D that happens within universities. These are the people are really pushing the boundaries of what the current tech can do. They're going to be the people making the next gen tech and having this mixed stack as we keep talking about gives them so much flexibility when they're doing their, you know, their research projects for their PhDs and coming up with the new stuff. Yeah, that's a good point. And there is so much interesting use cases for open source and infrastructure technologies together for all kinds of research out there. You know, we probably have used the CERN example to excess, but it is obviously fundamental physics research. But as you said, you know, genetic research, biological research, all kinds of really interesting cutting edge research is happening on using these tools. And it's pretty cool to think of kind of all this open source as being essentially like part of the scientific instrument that ultimately is leading to different breakthroughs. So I always get excited about those use cases. So in terms of maybe getting into more detail or more examples of users, or, you know, in your case, they would be customers. I wonder if you all have any customer names you can mention. Maria, do you want to drop any names here? Just to give people more of a flavor who's actually running this stuff in production. Yeah, absolutely. So we talked about Telco. I would, you know, Telco also has an aspect of sort of internal cloud or private cloud that they use for their enterprise. So also within Telco, I have several cases of company is a Telco, but their use case is a private cloud for enterprise running workloads. So I think OpenSec is perfect for that. Through whatever reason, security, governance, compliance, they need to keep their sources local. So they run OpenSec to do that. In terms of customer examples, so you mentioned that every call in the US go through OpenSec. I would say touches Red Hat OpenSec. So I won't touch US customers, but Vodafone Daya, one of India's leading Telcom provider, they use Red Hat OpenSec platform Red Hat has a storage, Red Hat Ansible Automation and Red Hat Enterprise Linux today to transform the distributed networks of data center into open standards. So this is really the, one of the key drivers is when customers kind of go into the open standards just to see basically open interfaces based on this universal cloud. And then they also extend and serve third party workloads for others. And then another customer just to go over to Europe, Proximus. The Proximus group is Belgium's largest Telco provider and they are replacing a very costly bare metal server environment was just more flexible, more scalable on network function virtualization or VNFs. And then the approach that by standardizing on Red Hat OpenSec platform, they use Red Hat OpenShift and Red Hat Seth Storage, Red Hat OpenShift being the Kubernetes portion of the bits and they use also running VNFs and they use Red Hat OpenSec platform and Proximus can scale the voice and data applications as needed. And they're doing it at 20% lower the cost compared to the just bare metal deployment. They now have the ability to scale flexibly according to demand. And if they experience peak activity in one particular domain then they can allocate those compute resources for a particular amount of time until the demand decreases and then scale down. They can use that as community servers and just much more effective than just trying to customize your own Telco background. Nobody does that, why would you do that? Nobody has that. Good, those are awesome examples. And I'm sure most people are probably familiar but obviously Red Hat OpenSec is your OpenSec product. Red Hat OpenShift is the way people would get Kubernetes from kind of the Red Hat product portfolio. I'm not gonna try to do it justice and explain it but just to kind of give people that pointer in case they hear all the terms of how they fit together but obviously correct me if I'm wrong. But in terms of canonical and Phil maybe you can kind of give you the same question here which is, who are some of the customers that you know of that are running a Loki stack today? Yeah, so sticking with the theme of Telco, a company from my home country, British Telcom they are using what you would class as a Loki stack so OpenStack again for NFE, tag workloads you know, more stateful workloads but then also have a level of containerization stuff going on there. They also use Ceph, all of our products are delivered as charms so we use Juju as our model driven operations tooling so you create a model and that then allows very rapid deployment of the various services. Thinking about education, so a recent customer of ours is the King Abdullah Science and Technology University in the Middle East. Again, same sort of mixed stack and then there is an ISP in Pakistan called Nyotel and so they are the sort of example I was using around a CSP so again they use the full stack to deliver the infrastructure as a service as well as a container as a service type product to their end users. You know, what I love about these examples is just how incredibly global these communities are. The Linux, OpenStack, Kubernetes communities are just incredibly global and I think it just goes to show you the value of building these things in the open as it allows people, anyone in the world to contribute anyone in the world to kind of take these technologies to market and benefit from them and you know, if you look at just like the open infrastructure foundation in our communities we have over 120,000 people in 180 plus countries so just always reminded of how the power of working together across countries and across communities is that so many different use cases can bloom but also just all around the world and all these different countries. So in terms of the community side maybe this is a good time to talk about that a little bit so I mentioned before that these technologies are all developed by these upstream communities that are incredibly vibrant, you know the three of the top four open source projects in the world happen to be used for infrastructure which is a great sign by the way the fourth for anyone is curious is Chromium which is like the Chrome OS, Chrome browser so people probably use that infrastructure a little bit but these other three obviously are big so thinking about these communities, you know how do we encourage more I guess collaboration? You know, what is the key here in terms of what we need to be doing to kind of make sure that when we get all the way down to these companies running in production that they have a good experience right because obviously it doesn't just happen by magic so does anyone have any thoughts on kind of how we can make sure at the very upstream community level that we're doing the right things to build bridges and build technologies that work well together? Sure, I'll dive in. So it's quite interesting this open world so my original tech background was very proprietary I worked for a large storage company everything was very developed in house there was no chance of ever seeing any source code and then I made this career change a few years ago and got into the open source world and just this idea of being able to understand to the minute detail of what is actually going on what you're putting into production and then when it doesn't work being able to fix it and then being able to share that back with the people who actually created this super powerful and I think that like mindset change is something that we really have to publicize to more traditional businesses who go and buy a thing they have a service agreement for it they don't ever think about how they're gonna fix it they just open a ticket and a patch will come in three months time you know this idea where you can contribute to this open world is super powerful. Love that, love that answer. Maria, I know you're very passionate about this and you work with lots and lots of engineers who contribute to all these different communities so what do you think? Yeah, I mean, the risk of signing try it right like developers, developers, developers all about the technologies that we use at the end of the day are created by people and just making sure that we can continue to work together and collaborate for the benefit of humanity without even trying to sound corny but that's what we're doing we're just with this technologies we're changing the world and hopefully improving it so we need to be able to make sure that we can work together going back to kind of what Phil was saying with his background like I just remember my first as a customer I was working at the time of Tata communications and maybe I'm gonna be booted out of this call because it was years and years ago Bokenstock wasn't even near a thing and we needed to launch the first public cloud in India and we standardized some cloud stack, sorry they didn't know you better at that point however, that's when I got my first taste of we didn't get a good feedback from the vendor at that time and we just thought, well, this is open source can we go to straight the community? And we just started getting the collaboration that we needed from third party vendors from storage partners, from networking partners and we just started to see that more in the open and it was such a relief I remember as a customer they have to live over a service for your end users and to continue to provide a service for the company that was just so comforting to be able to see that everybody was kind of working together through the power of open source so very similar right now with what we see with customers when they're get super excited about not just, because we're talking about the Loki stack so they would get Linux and they would get in a form of rail they would get open stack and form of rail had open stack and Kubernetes in the form of OpenShift and Red Hat but it's just so much more, right? There's networking partners and storage partners and et cetera, et cetera, et cetera the only way to work together and to continue to build on those and not just create snowflakes that will never see the light of day but just really truly great architectures and use cases and then be able to replicate that with others with minimum amount of work or less amount of work if you were trying to build it from scratch yourself that is super powerful so we need to continue to make sure that we continue to encourage that I have seen it can happen in both ways I guess it can happen from the communities itself coming together I have seen it forcefully enforced by customers basically you need to make this work you need to make the stack work for me as well as all integration or I need a particular feature to work across all of these and we see several that touch all the way from Linux to OpenStack to OpenShift to Kubernetes so it can happen for many all those forces and it can happen from developers just knowing what needs to be done Yeah, that's a great point I think you get kind of the best actions we can take kind of on the foundation community mark management side is bringing people together upstream and trying to figure out how to make the technologies work together and in terms of the snowflake issue absolutely I think you see that within individual projects and if you're going to put them all together which is required today plus as you said much, much more it's not just these three projects that the snowflake problem is actually that the biggest problem and one of the reasons we wanted to kind of coin this backernum if you will was just kind of highlight more of how dependent these technologies are in each other and how dependent really the customers are and I love your point about like a lot of times the sort of demand to work together get these things working together comes from the customers and they're just demanding customers are a good thing ultimately, right? They know what they need to serve their end customers and I think just to make sure we're keeping up with some of the questions in chat I was going to mention one here that came up a couple of minutes ago which is what is the main difference between a Loki stack and using OpenShift from Red Hat? So we might be able to pop that up on screen from Steve and that would seem to be for you Maria. Yeah, so the Loki stack refers to just your open source projects created by the community backed by hundreds of community members as well as companies like Red Hat for example but ultimately they're all available in the open. When you purchase or when you get OpenShift from Red Hat OpenShift is Kubernetes, so the K piece of it running on Red Hat Core OS as well which is Linux based and so the difference is you're getting a distribution from Red Hat. So we contribute upstream Red Hat always first upstream and then we do either additional testing packaging OpenShift in particular is also a ton of other projects that are part of the CNCF which is this other foundation and sort of build together and ready to use for you in an enterprise type of way. If you can also kind of do it yourself and I want to address a phenomenon that I see here. There's a lot of phenomena that we see in the kind of Kubernetes community or CNCF or Kubernetes adoption model that we have already seen if you've been in OpenStack for a long time especially as we've been with OpenStack for a long time and like, oh, I remember when we used to do that and they stopped. So part of it is they're at the beginning of OpenStack there were a lot of like do it yourself like even large enterprises that had a ton of developers they would go and sort of curate their own distribution from upstream and instead of getting Red Hat OpenStack or from canonical, they would sort of use their own parts. I wanna not know if I can say like calling out like putting them together and curating them themselves. The problem with that is then you end up maintaining that infrastructure and all of the basically maintaining that technology instead of building on whatever it is that you're building or the applications or the services that you're using for your company or your business. So really the difference between the LookStack and OpenShift is that with OpenShift you're getting the curated version of Kubernetes by Red Hat and instead of just creating your own when you get it from the community. Obviously there's examples of company that are perfectly capable to do this because they also contribute and they are active participants of the community. I think the biggest mistakes is when I see companies that try to sort of do it yourself but they do not contribute to the upstream communities that's a recipe for disaster. Yeah, I think, you know, we have seen definitely over the years in the OpenStack example of sometimes there's a temptation and I'm sure this applies to all forms of open source really in this stack and others but there's a real temptation to kind of like make a few changes because it's so easy to make changes and sort of customize it to your environment and then what you end up finding is that it becomes much harder to upgrade just as an example of where people get stuck on old versions and then they didn't necessarily contribute those changes upstream. So then the next version of OpenStack or any of these popular projects comes out it doesn't have your feature in it because you didn't contribute it and then all of a sudden you're like, oh, how do I upgrade? And then you find yourself like on a three year old version and all the things that you were frustrated weren't in the project when you first adopted it. They're all in there now but you don't have access to them and there are a lot of ways to kind of try to avoid that fate but I think it is very wise to try to avoid it in my opinion because we have seen just a lot of people kind of give in to that temptation to like customize it to your heart's content and then you're happy for a little while but you kind of, a lot of the benefits of being aligned with these upstream communities that again, three of the foremost active projects, right? We have a hundred thousand plus changes a year you want access to that not just the moment you install it but the next year, the next year, the next year like that's the bet on open infrastructure and you don't wanna sort of find yourself one day missing out on, it's like FOMO of the future. I don't know, I'll have to work on that one. So that question was really for Red Hat but I would give you a chance, Phil, if any of these just concepts come to mind anything you wanna add and then we can maybe look at some more questions in the chat. Yeah, so conceptually Canonical delivers a curated open stack and a curated Kubernetes Red Hat and ourselves we do very, very similar things with these open source projects we're both country backers as much as various organizations can and that kind of thing but the one thing that I thought was really important that you mentioned about was really around the upgrades. If you look at the maturity of an open stack upgrade now compared to like three, maybe longer, four, five years ago you had some people who'd gone off and built their own clouds and like you said, fell behind so things then became like migration to catch up. They build a new cloud with a new code with the features that they actually wanted that they kind of shoehorned into their previous environments and they're doing full scale migrations and like backend storage migrations just to catch up whereas if they contributed that stuff in the first place they would have had a much smoother process and honestly the community would have been much better off. Yeah, good point. And I think that looking back through kind of our questions here there was one question that I'm not completely sure if I understand it but I'll put it on there anyway we'll see if we can get an answer to it but the question was, love to learn more about how ISPs are using open stack versus just enterprise and I guess ISP could mean different things I'm not sure if that's their meaning. And a service provider I would say and that fits on the case of that we're talking about telcos and how telcos just use it as just a cloud provider basically, yeah. And I guess the other things out there is traditionally where you'd have like a managed firewall from an ISP site at the end of at least line now that's just a VM it's something that exists in a virtualized environment they don't have to worry about deploying a thing and having somebody can plug stuff in it's so much more it's easier to deploy and it's more dynamic. So that could be part of what the question was around. Sure. And I kind of made a leap that may have been wrong but what I thought of as public cloud providers which are sort of CSPs I guess to use a different acronym but certainly there are lots of public cloud providers that are powered by open stack and of course Linux and Kubernetes together and we see that today the public cloud footprint of open stack powered clouds which I think pretty much all of them are also running Linux and Kubernetes right so you could think of it as low key stack public cloud footprint and it's actually in more data centers that footprint than even like an AWS so the aggregate power of the community the aggregate power of like this global ecosystem where there's cloud providers all around the world and I have no doubt that they're all running technologies from your companies as well to get to market so that may or may not be what you meant by ISP but that was good to just mention that note because often when people say is it just enterprise there's a knowledge gap or people are curious well what about like a cloud providers and it's often kind of people that the big three public cloud providers in the US sort of our sort of overshadow in the mind's eye what's happening in the market but if you look all around the world there are many, many cloud service providers running running these technologies so I'll just get that plug in there. I think another question that came up was around kind of the future of these technologies so when we think about how to make these infrastructure technologies work well together you think that a lot of the future work we need to do or the things that are right in front of us are more from the lower levels like hardware support trying to get more support in the hardware layers or more like up the stack like do we need to be focusing more on what the upper layers are like where is the kind of most important work kind of from an open infrastructure community foundation area? Yeah, I guess I can take that a bit so when we look at sort of Linux as being the more mature technology out of the stack that you're proposing then open stack being the second more mature and then Kubernetes being sort of the more obviously when there's more maturity you have to do sort of less development just to guarantee basic functionality and just to make sure that it works but we still see that through again workloads we're getting a ton of requirements to improve on the sort of we have pressure from customers to improve on networking features as well as hardware enablement. So bringing in new hardware and the way that we do that is certain new inversions of Linux that are supported with open stack and then they're getting supported with open shift. So I wanna point out internally we call it a shift on stack or open shift on open stack or Kubernetes on open stack so we're doing a lot of work on this shift on stack it's always a shift on stack on Linux but the Linux is kind of obvious with Red Hat and we do a lot of work to make sure that the networking works across the board that the storage workloads can also reach down all the way to the infrastructure and things like that but there's one particular area that as we build all of these together needs to also come together and that is I guess observability is one that I would call out we have tooling for observability for workloads and that's fantastic we have tooling for observability for the open set side for the Kubernetes side for the Linux side making sure that all of that kind of comes together in a way that can be considered by a human is would be really beneficial I think there's a lot of work that can happen in that to really bring it to life. That's great insight and Phil do you have a take on this? Obviously there's gonna be lots of work in every direction but do you have an instinct on this? Yeah I was just thinking about the above side of things so we obviously are thinking here very much infrastructure but then when you start to think about how you deal with applications so one of the things that we do with Jujube and Charms is we also charm applications so you have the same tooling to deal with hardware the same tooling to deal with the open stack bits the Kubernetes bits but then what do you do for the application on top? Do you want to worry about how you scale an application and how that ties to containers and ties to underlying VMs or underlying hardware? You almost want to get rid of all of that complexity so that's one thing that the Charmed applications bring us is that you can start to ignore the underlying and let the machine deal with all of the resource allocation and you just ask for more units of an application and if you deploy this application if it needs something else that supports it there's automated relations between the two and it will deploy both applications so yeah, how we start to abstract away from hardware is kind of interesting too or maybe not even hardware but the infrastructure itself Yeah, I think it's in my conversations with operators and just people all over the world that are involved in kind of open infrastructure and open stack and looking at where there's still a lot of work to be done I find a lot of it is kind of in that hardware enablement side and because I think what we're seeing is this rush of new hardware architectures or they're not necessarily new but they're new to the data center they might be coming from mobile phones, ARM architectures, things like that or from gaming consoles in the form of GPUs and now we have things like SmartNX and DPU is kind of the new term that's been coined out there for I guess data center processing unit so all these kind of unique ways to optimize performance and energy consumption for different workloads that stuff doesn't just magically work out of the box and so as you talk about abstracting away that hardware so that the applications don't have to worry about it that is more work that needs to happen in Linux and open stack and presumably to some extent in Kubernetes as well which is just kind of maybe the bias of the people I talk to but what do you all think about kind of this proliferation of new say just the chip side of it including like SmartNX and things like that I mean it does seem like that is a growth area which brings new capabilities but also new complexities Maria you're nodding along so maybe all nodding vehemently yeah these are discussions that we have all the time like whenever you put the stack together and you're saying where do I put the investment in which sort of project so that then ultimately the workloads can benefit from it do we do the work in open stack only do we do it in Linux can you kind of get all the way down if I put it in this configuration if I put in this other configuration the fact of the matter is we need to test in all of them so we need collaboration across the board so and we do do that and that's why you know our like our networking team is a network is a hybrid platform or cloud platform networking team is not just the open stack networking team or just the core net is OpenShift networking team so we look at all of those together and work sorry closely too with the networking team at Ralph because those decisions impact in the stack so yeah we see we definitely see the work that needs to happen needs to happen in all communities Yeah and I think you know the tendency to reinvent the wheel sort of sort of was kind of hinted out earlier but it just seems to be human nature I don't know but the more we can not do that and sort of learn from you know reuse code or reuse learnings or realize that all these concepts exist at you know whatever we want to consider the layers and the more things need to kind of be able to talk to each other across these sort of styles of environments from containers to VMs and down to bare metal like that just it's a big priority I think it should be for all these different communities working together and I guess you know Phil to ask you the similar question in your customer base are you seeing increase in demand for things like arm architecture or you know GPUs I think are kind of like table stakes these days they've been quite common for different use cases for a while but maybe it's FPGAs I mean are you seeing more demand for that or is that more like just you know pie in the sky a hike for five years from now are people actually wanting to run some of these different architectures in your customer base today? So the GPU one yeah it's super easy yes I've been for a long time it's you know it was something that I remember yeah a number of years ago I've been there oh we need to get the GPU pass reworking that's done just it and out of the way right? The big thing now is around smartNICs and the GPUs how can we actually get the functions exposed up the stack and I just on I think it was Tuesday morning I was talking reference architectures for storage clusters and the company I was talking to and if you have an ARM architecture absolutely share it with us it's something we're super interested in I think the biggest challenge we have right now is actually getting hold of hardware not just ARM but just in general but yeah getting the interop underlying work done is super important right now for those new shinies. Yeah it's a good point I guess we would be remiss at this day and age not to talk about supply chain problems now I'm kidding but yes getting hold of hardware is certainly getting hold of anything these days seems like harder than it used to be but yeah I think that's another thing we can help with as a foundation cross foundations is bringing people together for test environments and things like that there's a lot of real-world work to be done and collaboration coordination so as we kind of wrap up here I guess I just want to ask you all for any closing thoughts on where you see the future of Loki going Phil I'll just go back to you first Yeah I really like the idea of adding another another letter to the acronym as we start thinking about the application side of things and the abstraction you know I don't know what the letter would be because Loki A doesn't sound great but yeah thinking about that and that next level of abstraction or you know the next level of the infrastructure would be where my head's at Maria what do you think? Oh that's interesting yeah obviously we see this as going and going and going maybe the level of development or just sort of rapid change you know happening at different stages and in different places with Linux and OpenStack being just so standard now in many industries I mean it's off telco but I wanted to also mention banking they're less vocal than telcos than a more private in general they do get together in sort of round tables and talk about their infrastructures because you know there's the big banks that have the you know the big money and effort to sort of contract this large infrastructure then they have their lessons learned and then they publish the reference architecture for others to see and then others benefit from that sort of smaller banks also start using those models so also Automotive is another one and then you know you are absolutely now the growth to the edge so Loki stretches out also to the edge where you know we just see different use cases being being used so as long as we keep the communities going I think we're going to continue to see use and we have many companies that 100% have been on these infrastructure running for a long time that's wonderfully I love that you know reminder that the banking world is extremely invested in and in production with trillions of dollars flowing through these systems that are built on these technologies so we have a big responsibility to keep improving for that use case Automotive is extremely common as well and as you said you know Loki to the edge I love that well I want to thank Phil and Maria today for joining us and just to have a few closing thoughts here on our show and what's happening next in the open info community I want to actually thank all of the member companies who are members of the open infrastructure foundation their support makes it possible for us to do what we do organize the communities that write software that runs in production including the two guests today or from from the two of these awesome companies that provide us support and speaking of getting together and solving hard problems testing new architectures we are going to Berlin for the open infrasummit in June this is very very exciting many of us have been missing all of you missing each other being able to get together in person all these hard problems we're talking about we can make more progress if we can get together in person so I really hope all of you can join you know we have the URL here openinfra.dev slash summit you can find out about registering what's happening as we're putting the schedule together sponsorships are still available we've got a ton of companies that are planning to have a have a presence perhaps you would like to have your company have a presence there as well so again we're going to Berlin we're going in June it's at this amazing convention center that we just went back and toured a couple of weeks ago and it was it was awesome so we're really looking forward to that other things that we're looking forward to our future Open Infra Live episodes and so an upcoming episode we have planned is how OpenStack is used in academia so you can go to ideas.openinfra.live to submit your ideas for talks for shows future shows of Open Infra Live and you can also go to openinfra.live to learn more about all the upcoming shows and just the back catalog as well so we have tons of episodes from the past and lastly I want to just say thank you for joining us for Open Infra Live and we would like for everybody to be able to join any future episode and and I should also mention joining the foundation it's free for individuals your company can also find out how to support the foundation's work at openinfra.dev slash join and with that we wrap today's episode and I just want to say I hope that you all have a good time with Open Infra