 And we are rolling. We are live. Ladies and gentlemen, my name is Michael Wait. This is another edition of the OpenShift Commons Briefings Operator Hours. And what I'm going to do right now is I like to say I'm going to share my screen. I'm going to click. It's now sharing. Now I'm going to ask the question that everyone wants to know. Can you see my screen? Hopefully the answer is yes. And today on the Operator Hours show here, we have J-Frog with us. And not just J-Frog, but we have Baruch Sadagursky, who is the head of developer advocacy at J-Frog. And very happy to have you here. And what's interesting is today's topic is going to be all about what is liquid software. So Baruch, thank you for joining us here today. What exactly did you mean when you titled this, what is liquid software? Because frankly, I want to know. That's good. That's good. Hey, Mike, thank you for having me. Everybody, hello. Yeah, so probably some of you heard about J-Frog and Armoto, the liquid software company. And I'm glad that people are asking about that because it's an interesting concept. The idea of liquid software is that we as an industry should strive to move towards software updates, continuous software updates, which are so frequent and so small that it looks like software flows from the development to the target and it almost looks like liquid. And this concept of liquid software is about switching from bulk and rare deployments into frequent and tiny continuous updates. Okay. Excellent. Good intro there. So let's talk about you. I understand from one, well, first of all, is that a little hot in the background there? I mean, you've got a fire on your wall. Yeah, yeah, technology, you know, switching to air conditioning. Yeah, yeah, the beauty of it is that it doesn't emit any, well, it doesn't meet some heat, but definitely never have to never have to stock wood in the thing. That's pretty cool. So how long, so you've been at J-Frog for quite some time. What exactly does it mean to be head of developer advocacy? So yeah, I've been with J-Frog for nine and a half years, almost. And for the longest time, most of this time for seven years, I was the only person in official developer relations capacity. The thing was developer relations that everybody do it. So I cannot say I was the only one who did develop relations because everybody do develop relations, whether they want it or not, whether they think about it or not. In the end of the day, we all affect the relationship between the company and the developers and the users. But I was the only one who had anything to do with developer relations in their title. I was the only developer advocate. Now we grew a lot and we have an entire team of developer relations which contain different roles, not only developer advocates, but also community builders and engineers, full-time engineers, and that deal with partners, integrations, and user experience. But I'm leading the developer advocate team. Okay, cool. And nine and a half years. Wait a minute. What's on your sleeve? Is that a J-Frog shirt? It is a J-Frog shirt. It is a WonderFrog shirt. And what is your shirt? It's kind of strange. I actually got up this morning and I put on this shirt that I got. I can save your binaries and you can save the world. I got this at a trade show in Portland, Oregon. I think there was like a docker con or maybe it was like one of the first Kube cons or something and I bumped into Raj. And I think I wear this shirt about maybe once every two years. It's unbelievable that we both picked the same day to be putting our shirt on. Well, we might think that Zack Snyder for it, you know, the Snyder cut and everything, kind of Wonder Woman is back to our minds. So maybe that's the reason. I gotta tell you, I don't generally take t-shirts from trade shows, but Raj, you know Raj, he's no longer there anymore, but you guys have the best t-shirts at trade shows. That's very true. When we get to go finally to KubeCon, which is the one coming up in LA, which hopefully will be in person, I think everybody should swing over to the JFrog booth. They honest to God, they have the best quality t-shirts and they're definitely worth wearing and not turning into a shop rag in your garage like most of the other ones. Absolutely. I hope our software is as good as our t-shirts. Let's put it that way. It's just an amazing coincidence that we both decided to have this shirt on at the same time. So JFrog, what's in the name? I mean, it's a frog. There's a J in front of it. Is it a Java frog? Is it, you know, John frog? What is it? You've been there for nine? How old is the company? I mean, is the company like 10 years old or what? Yeah, the company is actually more, the company itself has been around since 2009, so it's 12 years. But the name JFrog is even older. It's been around since 2006, when the first version of an Artifactory came out. And it's interesting how every time you have some kind of weird name or a fancy name, people always have a story, right? So the one that I keep thinking about is Black Duck, for example. So when we asked the founders of Black Duck, they told us a very touching story about the actual duck that was hurt on the property of one of the founders. He was a young kid and he kind of nurtured this duck to health and everything else. And since then, it's kind of a Black Duck. We try to come up with a story in hindsight when people started to ask, so why JFrog? But you know what, one of our founders in French and they have a weird relationship with frogs, they eat their legs. So we weren't sure if we can come up with something that will be authentic enough. Like what are we going to say? Fred ate some French frogs' legs and this is why it's frog. Doesn't sound so good. But truth to be told, when we just started, Joav Landman, another co-founder of JFrog, started this project in Artifactory. He looked for a name for kind of a space or an organization. There wasn't a company back there that will be catchy. We can play with graphics and social and stuff and also have a domain and a Twitter handle that was available. Jay, back then, really stood for Java. That's a right observation because before JFrog, we were all in the Java consultancy shop. So Java was our expertise back then and Artifactory is written in Java. And also back then, the only thing it did was supporting Java Maven build tool. Obviously, a lot of what are under the bridge since then, now it's incredibly universal. It supports 27 different package types all the way from development to the ops concerns and all the modern programming languages. And also all the package tools on the operating system side. And the new services in the JFrog platform are not even written in Java anymore. But yeah, JFrog has history. Okay. I wanted to point out that we're live on Twitch. We're obviously live here on this blue jeans bridge and we're live on YouTube. People can ask questions for Baruch put them into the chat down below and they'll magically pop up over here onto our bridge. So we'll be able to address them and and we'd like to we'd like to challenge everyone to this is called this is called stump. This is called the stump the Baruch hour. I'm told that there's no question too tough for Baruch and anyone who can stump Baruch is going to get one of their very own JFrog t shirts. It might not be this one, but we'll definitely get a 2012 edition JFrog sent off to anyone who can stump the Baruch. So I just made that up. I haven't talked to you. I have no idea that this is what it is, but let's do it. I just I just made it. So you're marketing people are going to be like, Mike, what are you talking about? We don't have anything like I'll pay for it. No, no, no, we have t shirts. We definitely am going to send t shirts to ever ask great questions. And that's that's on me. I'll take care of it. Okay, no problem. So first great question from me. Just bang the funny bone. Perfect timing. So you're here on our TV show, the open shift commons briefings operator hours. It's not a mistake. Right. I mean, your, your technical people have been working to ours to test and certify your software on the red hat portfolio. It's good for customers. It, you know, it sends that message of like, you know, the Reese's peanut butter cup moment of better together my chocolate your peanut butter. You know, J frog and open shift is, you know, better than slice bread. So, you know, we were interested in helping to promote your company, your agenda and getting visibility for your products on on top of our portfolio. What is, you know, your open source story? Yeah, I mean, every company has an open source story. You know, I'm at red, you know, we're at red hat. We've been here for I've been here for since 2002. So I guess like 21 years. And you know, red hat has a pretty solid open source story. You know, we're one of the one of the few companies that's been able to generate a billion dollars selling free software. What's your story. Right. So, um, we started, as I already mentioned, as as an open source tool. In 2006, Artifactory, and you can download it and have a proxy for your Maven artifacts and Maven builds. Since then, a lot of time passed. And we still have the open source version. And that's obviously the most downloaded and the most used in in all the software that the Jeff Rock provides is that is the Artifactory open source. It's still it's still most downloaded. What is that like 10,000 downloads 100,000 downloads like what is that we we stopped measuring downloads long time ago. We have this number and it's in the millions every year. It doesn't it doesn't mean anything. It doesn't mean anything just because, you know, as as our CEO used to say my grandma can download Artifactory, and he's right. But it's also a tool which is a part of a lot of pipelines and tool chains. And that means that there are might be a lot of robots that downloaded time and time again to set up their, their, their pipeline, the pipeline of the pipelines, if you wish. So, bragging about downloads doesn't doesn't really make mean anything. I was just trying to quantify. Yeah, big number. Yeah, it is a big number. It is a big number. But again, we don't know why we don't know how many of them using it and being like honest open source. We don't really know a whole lot about those users. We don't have any, you know, call home or they don't feel any. There is no paywall. So they just go ahead and grab it and use it. And this is the this is the open source part. Now, in as the time passed, we felt that, first of all, we, we, we went very, very cloud native. I think the or cloud first, should I say the first usage that you think about how do we use Jeffers software should be in our perspective, you use it in cloud you use it in service. You select the right cloud, and we support all of them, including obviously open shift, and you select the right region you select the right setup, and then you just consume it as a cloud. And this obviously conflicts with this downloadable open source version, right because downloadable open source means it's not as a service. So, and we started to think how can we maintain the accessibility and the ease of use of the open source version just download and use it with with the cloud. And this is how we now have the the free tier, which is fully blown artifact Jeffer platform for whatever it is cost if you buy it for on prem, but you can use it in the cloud for free up to up to certain limits. So this is kind of also what we try to give back to the community. Now, since we have that, and it's not really open source because it's a service, right. The question is, okay, how do we keep giving back to the open source community, because obviously, all of our software uses 80% open source components, like every other software component in the world. We use everything from a bunch of frameworks and and and libraries. And then we decided we want to give on top of free tier, even more, we want to give like fully functional with elevated limits, entire Jeffer platform for open source projects. And we run this program for many years. And we have very high, high visible open source projects in Apache and CNC F and the Linux Foundation, and many others used Jeff frog free for free under this project. And now we read we kind of changing this program to give the entire Jeffer platform for free for for open source projects, we're going to relaunch this program in our user conference. Jeffer swamp up, which is coming up in in May. And by the way, the conference is free. You're going to get some awesome Jeffer t shirts. There is tons of amazing content. Chris short, who was here briefly in the opening spoke, I think at least twice at swamp up. So he cannot test how great this conference is at least I hope. And yeah, during this conference, we're going to restart this program. So if you have an open source project, and you look for a platform that will help you release faster and get eventually to the liquid software concept that we spoke earlier. Definitely during swamp up we're going to have something very nice for you to use for free, just because you're not awesome and you do open source. We usually keep the promotions for events till the end for fillers. So it's good that I did not. I mean, I wanted to, I wanted to basically say though, like, like, what do you guys do. Right. I mean, you've been there for nine and a half years, you know what you do. I think the majority of the people out there, understand what artifact management is, but maybe not. Right. So like, what is it that JFrog does for the end user. So the way we phrase it is that we take care of your pipeline all the way from get to Kubernetes or to open shift. The reason by that is that once you pushed your code to get everything else, all the pipeline from this point onward will run on JFrog, JFrog platform. So we will build your code on JFrog pipelines, which is our CI and CD tool. Then you will have JFrog Artifactory as the backbone of your pipeline, and you will take this artifact, test it, whatever this test is, is it QA security licensing or whatever, you will test it. And when you happy with it, you are going to promote it to the next repository in JFrog Artifactory. The test themselves, the security and the licensing, we are going to help you testing your dependencies, your third party dependencies, both for security and vulnerabilities and for license compliant using JFrog X-ray. And in the end of the day, we again with JFrog pipelines, the CD part of it will deploy your, will distribute your application to whatever the end compute is. And if it's an open shift, it will be deployed, the containers will be deployed. If it's internal distribution, it will replicate to the right instances of JFrog Artifactory for other developers to use. If it's edge computing, it will be delivered to Artifactory Edge and then using P2P to the compute itself, whatever the distribution is, we will take care of distribution as well. And from source to the runtime, we can help you deliver faster. Why can't we just do that ourselves? Of course you can. I mean, that is, in the end of the day, it's just software. It's just something that people wrote. So probably other people can write it as well. The question is, do you want to spend your time now writing software for your pipeline or writing software for your users and customers? When I started here in 2002, I was a solutions architect and I was one of five in the whole company. And we would travel all around the world and I would be going and I'd do a tour through Singapore and then over to Japan and make my way back or maybe go through Australia or whatever. We actually, it was amazing back in 2002 and 2003 that, you know, we were going into customers and everybody, there was so many Linux experts everywhere, right? And everyone was trying to become their own Linux expert to create their value and build their career around, I'm the Linux guy here at Reebok or I'm the Linux guy here at this company. And the really savvy customers at the time recognize that they didn't want to be in the business of becoming Linux experts. They wanted to be in the business of focusing on their core business, which was whatever, commercial banking or building the best tennis shoes or whatever it was. So I totally get it. But, you know, early on in new technologies is always people who are like, I'm going to do it myself. I'm going to, you know, but, you know, having people like Jay frog who are like, you know, just use our tooling and then you guys go focus on your core business makes a lot of sense. That's your open source open source story. Who do you, who are the other companies out there? You know, are you the only one out there that makes you know, and is it fair enough to say that artifact management is the two words that sums up Jay frog and your tools. Yeah, yeah, pretty much you can say that you can say that absolutely because we get into the picture. Once the artifact is ready to be created and then take it through manage it all the way through and it's ready to go live into production. So yeah, pretty much. Okay. So, Howard house business. I mean you guys have one of the best t shirts around. You've got a tremendous amount of momentum, you know, there's a lot of, you know, arts being written about Jay frog but like, you know, house business or, you know, if you look at companies that were trending, you know, take Docker, for example, Docker the company not Docker the technology. You know, they were, you know, the shiny object for years, you know, Docker Docker Docker Docker Docker and you go to Docker con and you know Docker had this huge booth but they weren't really able to convert that into a viable business. So is Jay frog just a lot of hype. You guys just have, you know, nice, you know, purple backgrounds and frogs on shirts or are you folks actually becoming a dominant player out there that that customers can really rely on to run to help run their business. So I think that was, that was interesting question circa 2013. I think that the industry kind of gave gave its, its answer. We have more than 6000 paying customers. I think the overwhelming majority of whatever Forbes top 500 100 or whatever we're we're everywhere. When public about half a year ago, and I think not that I'm a big expert, it was a successful IPO. So, and today, when people think about artifact management, they think about either JFrog or JFrog artifact or in particular. So I think this this question has been answered profoundly in the last at least five, six years. And the most interesting answer to that is that now everybody are doing it. And I remember back in the day, the whole concept of artifact management was met with a lot of skepticism. Why do you even care about the binary artifacts? I mean, you have your source. This is the most important thing you have it in your subversion, and you can if you need, like, you just build it and put it in production done. There is no, there is no artifact to manage. And we along other players in the industry, I would say defined this domain of artifact management defined it with with a lot of sweat and blood. But in the end of the day today, it's something that you install JFrog factory or you get a service versus JFrog factory as the prerequisite for doing anything together with your GitHub account and whatever you want to use for a for continuous integration and your long term platform. This became a standard in how you develop software. And this is I think the biggest change that that happened in the last decade and in our in our corner of the industry, if you wish, and the fact that we are now that everybody are doing it and everybody are competing with JFrog in this area or another of this artifact management. I think that's the best proof that the business is good. But are you guys are you guys better than I mean there's there's other companies out there that do something similar. Right. So are you guys the, you know, the best. Well, why would I why would I want to use JFrog as opposed to, you know, one of the other. Yeah, so so if you ask me, I'm not. I'm obviously very, very biased and I will obviously argue that yes, obviously we are the best. There are some objective reasons to use JFrog. I'm comparing to to others. And one of the reasons that me personally is very important. I find it very important is I will give you maybe three reasons real quick. The first is universal, whatever technology you want to use, JFrog platform will support it. And this is very important because we don't want to dictate you as being just a part of your pipeline. We don't want to dictate you how you write your code, how you build your code, what stack are you running with, what is your deployment target, what cloud you want to use. None of those should be decisions that you have to compromise on, because a technology in your stack doesn't support what you want to do. Right. If you want to use Rust, if you want to use go if you want to use Java, if you want to use C sharp JavaScript, if you want to pack it in containers, or Debian files or RPM files. If you want to deploy it on the cloud, if you want to deploy it on Prem, whatever cloud you want to deploy, we have to be there supporting all of them. And this is what we do. So this is the first huge advantage. The second one is our obsession with metadata. One of the reasons why the shift from, hey, I just have a source code and I build it and I throw it in production. Actually happened to, hey, I need to manage my artifacts is the understanding of the industry that there are tons of questions that you might have to answer about your artifacts in any point of life. Before you deploy it during the pipeline, after you deploy it, when you operate it, when you monitor it, the more you know about your artifacts, the better. And this is why when Jeff Rock, poor tons of effort into getting you as much metadata about your artifacts as possible, how they were created, from what sources, using what tools, in which point, how the promotion went. With decisions that you make, why did you make those decisions? Who made those decisions? So when you need to answer questions like what is this artifact? How it came to be? Why it was deployed the way it was deployed? Why it was built the way it was built? You will have all those answers at the ready. And when you need to go back in time and find the right artifact for any reason that you might have, you have all this metadata there. And the third one is being truly hybrid or amphibious, as we call it, because frogs, in the way that you deploy it and use it. On-prem, in the cloud, any cloud, multi-cloud, hybrid between on-prem and the cloud, integration between any type of deployment of any part of Jeff Rock platform, this is something that also becomes very, very relevant. Kind of the same of the first one, we want to support you whatever your right to apology is, but not only for your stuff, but also for our stuff as well. The cloud, being cloud first and starting the conversation with, hey, here's a service, just use it, is obviously great and important. And that's another advantage over some of our competitors, but also being able to recognize, hey, you want it on-prem, here you go, we have that as well. This is advantage over other competitors and being able to say, hey, you know what, use it together. Use some of the Jeff Rock factory instances on-prem and some on the cloud and then combine them, replicate between them and work with them together. That's another advantage over any others. All right, cool. I know we had some people join late. I just wanted to remind people if you're watching on Twitch or YouTube or you're here on the bridge that you want to get one of these cool Jeff Rock shirts, drop a question in chat. It can't be anything like, do you think it's going to snow this weekend? And actually, by the way, speaking of snow this weekend, tomorrow we're getting eight inches during the day and another three. So we're getting 11 inches of snow tomorrow night. But any interesting questions that are not about how much snow Mike waits getting at his summer house, drop them in chat there. And we will ship a shirt off to you. If you do ask a question, then just shoot me an email. My email address is wait at redhat.com. That's just W-A-I-T-E at redhat.com. And be like, Hey, Mike, this is Sarah, you know, give me a shirt. I want to have a Jay Frog shirt like you and Baruch. So what about, you know, what about Kubernetes? And, you know, are like, this is one of the questions we talked about when you and I were going over this concept of doing the show a couple of weeks ago. You know, like it's sort of like, are we there yet? Like I said, I've been here. I'm as old as dirt. I've been here since when Red Hat had 260 employees and, you know, there was, you know, Linux was hot, you know, way back in the day. And then it became, you know, virtualization with Zen and KVM and VMware sort of, you know, ran away with the, ran away with that one. You know, then OpenStack became like the big hot topic and it was like the OpenStack conference and everybody was flying around. Those were hosted, you know, what were they, two times a year and Portland, Tokyo, all over the place. Then that kind of like just became this little niche thing for telco. And then there were containers and it was like Docker, Docker, Docker, Docker, Docker, Docker, Docker. And containers aren't really new, right? I mean, containers have been around for as long as me, right? I mean, there was Solaris zones that had containers. Just people couldn't figure out how to use them or manage them. And then, you know, containers kind of stopped being the focus. Now it's Kubernetes, right? Kubernetes, Kubernetes, Kubernetes and orchestration management and everybody was trying to get in on this game. Kind of like the OpenStack thing, right? This technology shows up and there's like 20 different vendors and everyone's going to become the OpenStack vendor. There was Morantis and HP invested millions and millions of dollars and it was a helium trying to become the OpenStack vendor. And, you know, Red Hat kind of just kept plugging along, building our open source technologies, delivering great product for customers and everybody kind of went away and forgot about it. Long story short, containers, same thing. You know, Docker company kind of like went poof. But now everyone's trying to become a Kubernetes vendor, you know, and, you know, you got Tanzu out there and all the other offerings as well. Do you think that where we are now, Baruch is just another sparkly moment? And do you think that like all this hype and everyone's getting ready, we're going to go off to KubeCon in Los Angeles in October and everyone's going to go get their new JFrog shirt. And two years from now, we'll be sitting there saying, wow, man, remember that? Like we all thought like Kubernetes was like the end game. And now we're off on to, you know, name your, like, are we there? That's my question for you. Very long introduction. But then again, I figured seeing as we're each getting paid by how many words we use today, I figured I'd get my quota in, you know. Yeah, I know that was that was real good. And that was a great description of the great evolution of the of the industry through like, I don't know how many years. What I wanted to point is that this is really all those peaks. They are really parts of the same process. In the end of the day, virtualization is built on Linux. Containers are not exactly built on virtualization, but learned a lot from virtualization. Kubernetes exists because of containers, et cetera, et cetera. So I don't think those are kind of things that we play with and this and then throw away those those are the things that we play with and then take it to the next level. And this trend will obviously continue. Kubernetes now is the hottest kind of thing that we that we play with, and it will become commoditized and like today we think about containers well containers everything is containers of course. And this is something that will be with with orchestration Kubernetes or not will say well containers obviously they're orchestrated of course and and the next thing will be will be something else. And I think personally I think that this next thing that we will all be obsessed with very shortly will actually be the edge computing. And and I think that's the next frontier if you wish distribution run times and billions of run times running everywhere and has been able to deliver the software there and then manage the software there and then update the software there will be the next frontier for all of us. This is what we are going to be excited about this is what about what we are going to be buzz about if that makes sense. Yep. Yep. So what about what about what about I'm going to throw I'm going to throw out. I'm going to throw this let's call this buzzword bingo. And you tell me, you know, if, if the buzzword bingo is fact or fiction. Okay, I am. This is this is this is my this is my Jesus I watched I watched that the, the tonight show with Jimmy Fallon last night. I don't know if anyone watched that but it was it was hilarious. You know, he does these things where he has people zoom in from their house showing off their talent. And there was like one woman was like, I can sound like a I can sound like a seagull. She was actually calling in from like Spain or something. Anyways, so this is our buzzword bingo fiction or fact. Microservices and serverless. Do you really think that serverless and microservices are fact or fiction. I have a problem with both terms. I have a problem with the term microservices because of the emphasis on the size, which I don't think is the most important thing in microservices architecture. Instead, there are more important aspects like the API centric, the serviceability, the being able to the resilience, the scalability and others, which are much more important traits of microservices than the fact that they are micro. But it's definitely a thing that the architecture this the microservice architecture is one of the cornerstones of being a cloud native, which is probably another one on your list will get to it soon. And serverless. I also have a problem with the name, because it implies that there are no servers, which is obviously a bullshit. There is a server, you just don't have direct access. It's abstracted from you. It's just somebody else's servers. Exactly. It's abstracted from you. And this is great. We love abstractions, and it's encapsulated from you and it's great. We love encapsulation, but it's again not the main part of it. So both concepts are great and very important. Naming is hard as we know. I find both of those names being suboptimal, but it is what it is. You know, I mean, the buzzword bingo, we could we should actually make that a standard part of this show every week. Absolutely. Absolutely. Maybe, you know, I mean, there's lots of like, let's talk about cloud native factor fiction. Yeah, again, cloud native is is a fact. And the name in this one actually annoys me a little bit less, although maybe it's still not perfect. For me, cloud native is a collection of patterns and microservices architecture being one of them that actually makes the application run better, I would say on the cloud. It's it's more suited for the cloud. And when I say the cloud, that's where the problem with the name is it doesn't necessarily have to be in the cloud. It's just set of practices of how we treat software, the fact that, you know, it's observable, and we can scale it and we can replace parts of it as as it moves. And we can commission and decommission and recommission part of it. So it's, it's gain set of practices that makes our software better. And the fact that we kind of came into this conclusion through the cloud is secondary, but it's stuck in the name. Okay. And, you know, the whole microservices thing I wanted to bring that up because we had, we did a show a couple weeks ago, we were talking about microservices and the partner of ours that was on, you know, made an API gateway and service mesh offering. And I believe that, you know, that type of tooling is going to be absolutely mandatory as containers do get smaller and smaller and smaller and smaller and smaller over time. It's like trying to manage an infinite number of galaxies, you know, and having, you know, service mesh tooling to do that doesn't make it helpful. But there were people on the bridge who were commenting that they see containers going the other way and that their containers are actually getting bigger and bigger and bigger and measured in like, you know, gigabytes in size, which I found, I found surprising. But then again, it was someone in the government space, so they probably have, they probably have very weird internal, you know, reasons for doing that. So what about, you know, for 18 months out, you know, we were talking about, are we there, you know, is is Kubernetes the container the open stack the Linux of the day, you know, where do you see computing being in 18 months. Our containers going to be tiny is a service mesh, you know, offerings going to be something that's going to be just like, you know, table stakes for doing business. You know, are there going to be new disruptive technologies coming down the road? What do you think we'll see in 18 months? Yeah, yeah, so I already mentioned edge computing, and I really believe this is where everything is going. And as a cloud that imposed the its own style of software development, what we call cloud computing, regardless of it's in the cloud or not, the edge computing will impose its own style of development, some that will call probably the edge computing. And this is what actually guarantees the minimization of images, if you like, just because the limitation of the edge devices. If you need to run software on a relatively small and not as powerful as all the cloud servers, you will do, you will have to do, you will have to adjust, and you will have to make your containers smaller. And the microservices really micro and everything that comes with those with those limitations. So I think they will edge will impose on us limitations that will make our software even better, and that will make our software development practices more robust because of the challenges. So think about, for example, the availability of the target. We assume now then whenever we want to go and do something with our services in the cloud, it's always there. We can update we can scale we can we can restart we can do whatever we like with edge computing, the availability of the target is not guaranteed. And once that happens, it brings a lot of interesting engineering questions, it might be the different edges within one cluster runs different versions of software, because some of them were unavailable when other got updated. How can we make sure that this cluster operates correctly when actually they run different types of different versions of software. There are very a lot of very interesting engineering challenges that come with the edge problem space, and it will definitely impact of how we develop our software for the for the better. We've got 12 minutes left, and I know that we wanted to talk about some aha moments and or, you know, war stories you're you're really well plugged into your business you're obviously, you know, being head of the developer advocacy, you know, team there at day for all you probably have heard a lot. Can you want to tell us about some aha moments or some, some, you know, war stories that you wanted to share with people. Yeah, so, and that will be more about the general developer relations kind of journey that that I personally experienced and my personal growth is you wish, which kind of goes into why I always I always thought I don't get those aha moments like a lot of them. Why, obviously, we have software that solves a real world problem. Right. I speak with people. I hear what problems they try to sell to solve. I see how our software clearly answers this need. And I explain to them how it helps. And this is where I expect rational human beings to think about and they say, Yeah, you know what you're right. This software is going to make our life easier. And this is my aha moment. And this is what I take back to the business and say, Hey, I just spoke with with Mike, and Mike said, It's great. That's exactly what they need. They're going to use it. And that almost never happens. Instead, what I've learned is that the only thing or most of the time, the only thing that I can do is make you, or any other people that I speak with, think about the domain. And then sometime later a month later, two months later, half a year later, they have the realization that hey, I need to look for some software that will help me doing it. And you know what I remember bark mentioned something about Jeff Rock. Let me check it. Oh, it fits. And then what a great idea. But that was the idea of this individual very, very rarely. If you look back to me and say, Hey, Baruch, remember this conversation that we had. You were right. Jeff Rock is what I actually need. And now I'm starting using it. Most of the time, it will be like, Hey, Baruch, you tried to push me this Jeff Rock stuff. When I didn't need it. It's good that I then kind of refused to use it because I didn't need it. And now the situation is completely different. And I by myself came to the conclusion that Jeff Rock is the right thing to do. So I did it and it's not kind of your, your achievement if you wish. And that's okay. I mean, I really don't mind as long as in the end of the day people come to the same conclusion. It's completely fine. And more of everything, it's the moment for me that you really cannot push the solution into a throat of other people, even if this is objectively the right way for them to do this realization should really come internally. And I think there is a movie about that called Inception. This is what I like to think about the developer relations is doing. Inception of the ideas in the heads of other people that then will come to the realization that this is the right thing to do without constantly being able to correlate it to some conversation that you had half a year ago. So that makes sense. Sure. Yeah. Let's talk about swamp up. It's it. I went there once it's it's a developer shows opposed to like bankers walking around people carrying suits and bags and stuff right. I know it was. It was at a, it was at a winery in Santa Barbara about four years ago. Do you remember that one? Yep. Yeah, it I went there. Yeah, it was that some some winery was really cool. Yep. What, you know, for people who go and again, it's not a customer conference. It's not people carrying, you know, suitcases, you know, like briefcases around. What's the overall experience at swamp up it's it's coming up here in the not so distant future and this this this is your chance to put in that gratuitous plug for you for your event here because. Yeah, so thank you for for building it up like officially. And, and yeah, so swamp up is is a user conference as opposite to a customer conference as you mentioned, and our users are developers are ops people are engineers in the end of the day. So this is the conference for them. And what I have the honor to be the head of the content committee for the last six swamp ups there were six. So all of them. And does that mean, does that mean that if I if I fill out a call for paper I get prioritization because I absolutely might absolutely you will have to wait for for for next year because this year's agenda is already built. But yes, I expect you to submit. I also have a very sweet spot for for for speakers from redhead and Chris won't let me lie on this one. So yeah, we try to make the content useful for engineers. That's that's our main goal. We have an amazing events team. And their main goal is to make it fun and pleasurable for for everybody attending a one when we could do it in real life. And four conferences out of five took place in the winery in Napa. And that's because we started to drink wine in the morning and we actually never stopped. Some people call that day drinking. Some people call that maybe you know might, you know, be a time to take things in moderation. I call it swamp up. So yeah, yeah, and and this year it's it's unfortunately still still online it's going to be awesome conference but you have to bring your own wine. Hopefully next year we will be able to meet again. I hope it will again be in Napa in a winery with this amazing experience talking about content. And this year was really hard. We got more than 150 submissions for I think like a 27 slots. It was it was brutal. The selection and and we obviously picked the best of the best and it's free. It's May 25th. Absolutely free to attend. Go to swamp up swamp up dot com or Jeff from swamp up dot com Google swamp up. It's it's an afternoon unique name and and then you know you sign up and and you're in. Okay, we have just a couple minutes left. What? What is the the one thing that you should be sharing with people that are watching live today and also for the ones that are watching the recordings on YouTube and LinkedIn and so forth that. You know, after we hang up here, your your major or your, you know, your CTO isn't going to call you and say, Baruch, you had an hour to talk about anything you wanted around architecture management, artifact management. And why didn't you talk about the following two things? What what is that? Yeah, no, I think I think we're good. I think they should be happy with me by now. We spoke about a lot of stuff, Jeff from related a lot of stuff, liquid software related, you know what, there is something. There is something that I really want to treat the the viewers of our show on top of t shirts that the concept of liquid software was explained in a book is the same name liquid software that was written by two co-founders of Jeff Rock, Fred Simon, you have London and yours truly. And I want to give this book for whoever wants to get it for for free. I will make sure to ship a physical hard copy to whoever contacts you Mike or contact the show through whatever whatever channels you you feel right. And you can also the DM me on Twitter. I'm edge a bar on Twitter and my DMs are open ping me. I will I will ship you a book so you will be able to learn more about liquid software. That's pretty cool. You're one of the one of the one of the co-founders of the company. I failed to mention that. Do you have a copy of it? You can hold it up here and put it, you know, in front of the camera. Yes, yes, I need to find it. Talk about gratuitous looks. I mean, man, this is like this is endgame right here. Yeah. No, I don't I don't see the round my desk is probably in the other room, but Okay, well, that would be embarrassing if you actually had, you know, signed copies sitting there in your office just my own. Yeah, that would be like a little bit a little bit unhealthy. But that's cool. So anyone wait a second, I have a solution for you. What I'm going to do here is I'm going to share the cover in the stream. Let me just open we have we have the technology to do that. It's amazing. You know what the technology is just it's the screen we're using blue jeans the screen share buttons up at the top. Yeah. Yeah. Yeah. No, I won't be able to because my Mac got updated between we when we did the our dry run and today so now it needs permissions to share my computer get my screen again. And this will require to restart the bridge and we're not going to do it. No, no, that's fine. But but to just rehash anyone who wants a copy of Baruch's new book liquid software. Shoot me an email. Just wait at red hat.com W A I T E red hat.com. And we'll be sure to get a copy of his latest book out to you. We are coming up on the end of the hour. So I'm going to do what I like to call. I'm going to share my screen. And we're going to pop up this that's pre prepared from from from you. Baruch Sudersky nine and a half years at JFrog. You know, well entrenched even before that with the other founders of the company. Thanks for thanks for being on our show here today. I'm really hoping that we can do a podcast with you. We've got a red hat X podcast series that we do two or three shows a week. So I'd really love to have you on our podcast show. Anyways, thanks for thanks for joining us here today and thanks for people joining our show. Come back and see us next Wednesday at noon Eastern time. And that's all for now. Mike, thank you very much for having me. Thank you.