 Welcome everybody to the March webinar or Tech Talk as I like to call it. My name is Sean O'Dell. I am the Head of Developer Relations at CloudSmith, and I am really excited to have everybody here today listening in. I've got some fantastic speakers, some folks that I know really well, and we're going to be talking about the second phase or the 102 of containerization. Today, we're going to focus on speed, optimization, and probably far more security than any of the other two. Before we kick things off, I just want to mention a few things for everybody in the audience, and I think these are super important. If you are watching on Twitter or LinkedIn, if you repost this live stream, you get a chance to win a free lunch, and I think that's always exciting if you're hungry or plan on getting hungry at any point in time. The second thing is we also give away some prizes at the end of the session, and so let us know you're here, but drop an emoji in the chat and I will announce the winner of the free lunch and some prizes at the end of the session today. Lastly, before we kick things off and get to the topic at hand, I am excited to introduce to all of you Unpacked Conference. Unpacked is the first ever user conference from CloudSmith, and this is going to happen on June 20th, 2023, and to help everybody understand, this conference is really for DevOps professionals and engineering leaders who are interested in learning more, hearing more, and hearing from peers and industry experts about securing and scaling software delivery. In the fun tagline, I actually like to repeat it, the conference is virtual, it is global, and it is free. Feel free to jump in the chat if you are on the webinar platform and choose the link and register, and obviously we'll be sharing via socials and others. Now let's get to today's program. I am excited to introduce two speakers, two individuals to the floor today, both Marino Vijay and Robert Circea, and a little bit about Robert. He is the head of Community and Evangelism at Susei and Marino, which I have known for a long time, both as a peer and as a friend. Marino is a developer and platform advocate at Solo I.O. Gentlemen, welcome to the show. Thank you. Thank you very much. Robert, I'll start with you, man. Tell us a little bit about yourself. I spent my entire career as a developer, written, code, and the past couple of years, I flipped over to the Evangelism and Community role, which I don't feel that it's almost one and the same, and so I'm the head of Community Evangelism for Suse, a part of the Suse and Rancher community, so what I'm doing. Nice. Glad to have you on board today, Marino. How about yourself? Yeah, yeah. Thanks, Sean. And I will say that I haven't been a developer. I would say I spent most of my time in the world of infrastructure and networking, and as much as I try to escape this world of networking, I feel like it just keeps pulling me back into it, so I did spend a lot of time doing the consulting, the presales, architecture, all that fun stuff, but then to Rob's point, I just really like just getting out there in front of people and talking about all this cool stuff, and I found myself in an evangelist slash advocacy role, so I've been doing it for about a year. It's been interesting. You learn at a different pace, you see so many different perspectives, and it's just like all in your face, so yeah. Now, glad to have you both. My background's a little bit different. I actually call myself a reformed infrastructure architect, which is actually where I got started. I managed, where I guess enterprise managers, if you want to call it that, and security patching for a large Fortune 200 organization here in the United States, and oftentimes on the infrastructure side, I had angst for application owners and developers because I was, it was done the wrong way, like I was instructed incorrectly, right? And I've learned from my mistakes, and that's why I believe what we do, and really even today's conversation, having a background in security with infrastructure, but now with applications or containerizations or microservices or Kubernetes and whatever moniker and acronym you wanna throw out there today, we are gonna be jumping into this wide topic, but really focusing on the security aspect. So looking forward to this guys. So to begin, and there's so many questions I could ask here. I'm just gonna ask kind of a simple one, and I think this conversation will jump from here. Where should people be looking when they're getting started with container security? Now, I'm gonna preface this, I know you're both gonna go in different directions and that's okay, just with your backgrounds and your understanding, but I'm really curious to see where we'll start. And I'm actually gonna start with Robert, where people be looking when they're getting started with container security. I think the low hanging fruit is understanding where your images are coming from and knowing that one. That's I think the easiest way to get started with that and then people miss it and they're going through like, oh, I need to be BF today. And I'm like, hold up here. Do you know where your images are all coming from? Well, no, I just pull them off the internet and that's, I think that's an easy, safe way to start. So you start with package management or package awareness or package ability or capabilities, right? Is that an easy task in today's society when we have a variety of locations that we're pulling artifacts from? No, because of humans, right? Like I would say the human factor would be the hardest part, right? Getting people not to pull them down from Docker Hub and not saying Docker Hub is not secure, right? But just anywhere on the internet, I just pulled it, I Googled it and found the first search. And I think that's where it's just developing a policy and getting the humans in your organization to follow that particular policy is I think the hard part. And Robert, I appreciate the fact that we didn't even have the conversation of where to start with that answer but you just gave a great plug for Cloud Smith. So we'll just leave it at that. Fantastic job. Marino, I'll let you answer this question, man from your perspective, where should people be looking when they're getting started with container security? You know, there's this notion of, okay, I'm gonna go pull whatever I can off the shelf or maybe I'll just build it. And I think when it comes to building it and then deciding where you're gonna store it, it really comes down to the maintenance and the constant custodial efforts you need to provide to making sure that that image that you built is always secure. And so there's a couple of things that I would think about initially is, okay, how do I pick a good base image? One that has very limited vulnerabilities. And then once I've picked that and I decide, okay, let's build my container image and store it somewhere. What can I do to constantly scan for vulnerabilities? Let's say today I use a good golden image today and then three days down the road, I find there's a vulnerability, right? So it's an element of picking both your trusted image as well as the place you store it to Rob's point, but also having some sort of artifact scanning going on so that you know when you need to swap out the base image or implement this into your CI pipeline so that now you have something much more cleaner to work with. But then there are so many other areas too. Like I come from a networking background and once you've got those containers up and running, how do you protect the network and how do you protect one container from doing something to another container? Yeah, you actually bring up a couple of points. Number one, I don't think it's three days before the vulnerability shows up. Oftentimes it's about 30 seconds later. At least that's what I have found. Maybe I'm just the only one or maybe I've got some terrible ideas out there. But man, vulnerabilities show up quickly, right? And we're gonna jump into like, I think the other thing is when we look at container security, there's, I go back to the old analogy, right? When I had a physical server, right? There were multiple ways to secure said physical server, right? We do the same, we did the same thing with virtualization. We need to do the same thing with containers, right? The principles still apply. And so the attack surfaces is massive. It comes from different angles. It comes from a variety of angles. So to your point, Marino, you know, talking about attack surfaces, what are some ways where container security and networking has matured over the, and obviously this could be a long answer, but where has it matured over the past couple of years that you have seen, you know, the two working together? Maybe we're in the past, they haven't. I think it really comes down to automation. We decided a long time ago that it just makes no sense to do everything by hand. So let's say 10 years ago, you started with one container and you decided, I need to network this to another container. And then now all of a sudden you have 1,000 of them having to deal with some level of bash to be able to push out container networking configurations or networking namespace configs. Makes no sense. But because of what people have attempted to do manually and then also because they tried to drive it with automation, now we have orchestration systems that have this like this container networking layer much, you know, if you've ever worked with Kubernetes, which I'm sure like everyone at this point knows, you're working with a container networking interface and that has all the necessary pieces for you to just get containers talking. But then it also offers up that layer to just provide zero trust or eliminate your surface attack area because now you have this opportunity to profile your network, see who's talking to who and then say, now we can, you know, deploy a baseline policy and now we have our zero trust. But you start to realize that things change so quickly that you're constantly having to change that. So you now need to also think about observability. What is changing and then how do we adapt to that? Yeah, and when it comes to container security rate, we could hit a couple of facets. And I think in some of the subsequent questions we'll actually get to it because I know Robert's got some opinions on this too. But before we go deeper into the, what I would say is the layers of container security, I wanna focus on something that both of you articulated, right? Package management, package delivery or software delivery and really just the application lifecycle. And look, I'm not a big fan of buzzwords, but unfortunately our industry does this. And so the buzzword of supply chain security is something we all hear in supply chain attacks, right? Even the example you gave, Marino was a supply chain attack, right? Where I go grab a package, that package so happens to have a vulnerability when my CI pipeline picks it up. Guess what? I'm automating the deployment of vulnerabilities. It's a novel concept, right? So I'm gonna ask this question of you, Robert. When we look at supply chain, when we look at supply chain attacks, supply chain security, how can people at the base, kind of at the base level mitigate risks with using containers? And it sounds weird that I'm saying, how do you mitigate risk with using containers? Because containers are innately a good thing, but humans are often malicious and all that sort. But how do you start to building the foundation of a secure container or a secure container strategy? I think Marino started, I think he mentioned that base container image, right? And then, I'll go back to the hardest part about it is getting people to adopt it and building upon what your business needs are from that perspective and then allowing a change control for particular packages to come in. One of the things that scares me to death, especially just NPM, if you were like, it's just NPM, it's what's the big deal. I'm like, yeah, but you don't know what that's doing. Like you're just, it's on the browser, it's running. And I know it's not a container, but for a front end developer, their container is a web browser, right? And so it's the same thing, but they arbitrarily do that is to have a way where you're pulling in the right packages that you might need and then having a process to quickly change it if a vulnerability is found, right? We're gonna have a really good point is that observability, I said that correctly. What does that look like when you find something and how do you fix it as fast as possible? But that's starting with that base image and being like, that's our gold image. We did this, we do the same thing in virtualization, remember we create that Windows server that was our, that's the gold image. If you guys, and I knew, because I used to hear about it, you know, the infrastructure guys, and they're like, did you update the gold image? All right, it's safe to update it, let's update it. We'll do it all this weekend and the infrastructure team would do it. We didn't understand from the developers, we didn't understand what the hell they were talking about. So it was just one of those, whoa, what is this? But that's the, we did the same thing. It worked then, it kind of worked the same way now. Yeah, you did scare me when you mentioned the word change control. So I think all of us, whether you're a developer or whether you've been on the infrastructure side of the house does not matter. We've all had horror stories of change control. And so let's talk a little bit about that, right? How does change control work? And what are some ways that you've seen it work within this new paradigm that is a really good mixture of controls, but freedom in some cases, either one of you, I don't care. I'll divvy over to Marina. Yeah, so back about 10 years ago, 15 years ago when I used to do network cutovers and whatnot, change controls were everywhere. And it's because you wanna do something to an environment that has impact to the business in some way, shape or form. But that impact is supposed to be positive. It's supposed to optimize something, make something better, make us move forward with another project, something along those lines. But then when you decide you want to make this change, you need to go through multiple levels of approval. And what's fascinating about that is you sometimes might not even make your change window because you're still sitting at approval levels. And that was always a frustrating thing because someone would pipe up and say, oh, what about this? And then you start to realize you've missed a whole bunch of considerations around using, I don't know, certain protocols. But then today, it's a lot more collaborative. I mean, we make changes in a very, very small fashion that we don't necessarily have to wait for someone to sign off. As long as we can test this beforehand, we see viable output, things that basically say, okay, this is going to work. This is going to make sense. This is going to be beneficial. Then that's our approval process. And that has sped up our deployments in so many ways. And to see that paradigm move over or that shift altogether means that we've definitely left behind that whole change control process. But the elements of it are still here. They still exist primarily because, look, we still need to have some mechanism to track these changes because if something goes wrong, how do we roll back? How do we work our way backwards? I think tools like Git and GitHub and GitLab have made this so much easier for us to be able to revert our changes. But I'll tell you what, like 10 years ago, you forgot to put in that restart in 20 seconds. You're locked out. Oh, yeah. Yeah, makes sense. Go ahead, Robert. So I guess from a developer standpoint, we've started with automation and some of the platforms that we use, we've been able to have smaller incremental changes, right? And to piggyback on what Marina was saying is those changes are just so common now that it's really not change control. It's just this continuous push, right? Where you're like, oh, you got it done. Get it into the next thing. The CI will hit. It's Friday who cares for pushing. And a lot of automation has been done to help roll things back. So it's just like the changes are not as big and drastic. They're just con. This is like a constant fluidity of new and improvements that were there when you hit some breaks. And oh, stop, rollback, right? Absolutely. And you both mentioned tooling as a part of the answer, but I'm gonna say that really it's probably people and process far more than tooling when you want to secure a container. And I know that sounds a little funny because it's still technology at the root of a container, but all of the things that we've been doing over the years, whether it's the initial ITSM or change board situation, moving into automation, then adding that collaboration layer to improve that lifecycle or to improve the cycle is I think actually where you start to mitigate the risks, right? It's a combined effort, but obviously tooling is important, but people who implement the tooling, I think are far more important. Anything to add to that? I wanna be a controversial and say developers need to start owning part of that process of containers. We've never really owned that to us. It was just like, yeah, it's just like the PM. We don't care. And that abstraction really should go back to the solution architects, maybe the enterprise architects were where they stand in an organization. And when I say developers, I'm not saying engineers, those are two fundamentally different things, but the developers really need to start having some ownership of that. Because part of that change needs to start with them, going like, hey, does this new container image break my stuff? And it was like, well, it shouldn't, but it could. You don't know. Yeah. I'm gonna go on to disagree with that a little bit, primarily because I don't think we should put the onus on developers to manage container security. I think we should work towards providing them a platform that inherently provides this container security. We should be able to define the kind of parameters we need for policies, for the types of base images we wanna allow, and let them work with that. Because now we're putting this additional pressure to go learn something else. Like do they even wanna learn Kubernetes? No, we should be the ones that care about it. They should only care about, let's just get this container open or get this to a point that it's actually a container. You go deal with it after the fact, right? But to make this even better, if we gave them an internal developer platform where it would just automate the whole provisioning of you've got your container image, it's now married to a whole bunch of others. Now this is a full-on application that gets deployed on top of some app service. Could be Kubernetes under the hood or something else. But that's all they need to be worried about. And I feel like if you start to load on extra technology domains that they don't really need to care about, you start pulling away from their expertise in developing good applications. I guess I would rephrase it more. If it, we used to hear it and you guys in the infrastructure side works on my machine, right? Well, if it has to work in the container, right? And so you have to take some little ownership where it works in the container. I wouldn't expect them to go anything outside the container, but a new image comes, right? They should own the, you know, hey, this is breaking anything. You know, what we're switching from SleeBCI to whatever, it doesn't matter. The developer should be part of that process, that's all. That's fair. And I'll be controversial and I'll actually agree with you both in parts. So I go, I know it's such a crazy thing. So I go back to the days, you know, as an enterprise architect focused on infrastructure, our application developers would bring us business requirements, foreign application all the way down to libraries, all the way down to tools and they would even provide us with the requirements from an operating system perspective, right? They weren't the ones creating it. They weren't the ones who were building the operating system, you know, whatever Windows Server 2003 build or whatever it may be, but they would tell you, I'm going to need this particular service. And innately the security team, the infrastructure team and in collaboration with the application team knew exactly what was going on, right? So it's a combined effort, right? It's a collaborative effort. Look, developers don't care about Kubernetes as much as we want to have, as much as the industries tried to say this, developers only care about actually the software and the artifacts and the packages that are required to deliver their application. It's not this hard. We can do everything we want from a marketing perspective, but that's just the case. So then the question becomes, right? Mitigating risks is a part of the solution, but having the collaborative effort and this goes back to the people process, look, I don't know that you need something from NPM and I can't go secure NPM if you don't tell me, right? Or I don't know if you need this particular version of Node.js or whatever library it may be, right? Without that collaboration, you just don't know. And so to me, I think you start mitigating risk people process tooling, but start with people process. Any last comments on that topic? We all slightly disagreed. You know, I actually agree with the fact that it has to start with people, right? People are the ones that are making decisions based off of what they're finding out in the market, what they're finding out from their peers, seeing success stories from the blog posts that they read and all the different news releases. And so it does come back to people, but I think to your point, right? The collaborative effort comes in from when you actually have decision makers coming together and saying, look, we need to build this. How can you support us to be able to build this? And then you'll get to a point where there is a common ground so that both sides of that coin went good. Yeah, it's interesting when we as classmate, when we talk to our customers and community members, they never actually ask us about the infrastructure layer. They really care about the artifacts and the software that goes along with the application, right? But then to even Marina's point, this actually leads me to my next question. And actually somewhat with what Robert was going, they have had to learn about the infrastructure layer, right? There is a, look, modern infrastructure, whether it's serverless, whether it's Kubernetes or containers or microservices, like there's a blending, like there's a very close line that the boundary is a whole lot closer today than it ever was. So when organizations, when developers, platform teams begin looking at containerization, container security, where do they start when it comes to the Kubernetes layer, right? Where do those two work together? And maybe where do you see some division? Rob, you should take this one first and then I'll provide my perspective. I got about a half of what he said he broke out there. So quick, quick, quick, if you don't mind. Sorry, Robert. No, no, no. So when you look at the kind of blending between Kubernetes and application security, where do you think companies should start or developers or platform teams should start and kind of merging those two together? I'm not sure it'd be the best idea to merge them, but I think for application teams is continuous scanning of their packages, continuous scanning of what's going on with that. And then from an infrastructure platform perspective is anything to lock down Kubernetes. Kubernetes is complex for some, not so much for others, but it's not natively secure. I'm not saying it's not secure, but there's still things that are wide open that allow you to ease of use that really, I mean, Maria can talk about networking and what probably needs to be locked down to Kubernetes that I would just, ah, it looks good, leave it open, I don't care. That, I mean, like he's laughing, but here's me, I'd be like, yeah, it's normally finding Kubernetes, but so those things I was thinking, this is, you know, how do you get to that platform part? My developer perspective is that constant scanning, right? Because when Log4j hit, most companies didn't know until the news hit it because they weren't scanning. And that was, that was scary for me. Like, how did you not sketch that? And they're like, well, we weren't scanning. I think that's where, from a developer perspective, and then I hate using the buzz phrase zero trust, but on the zero trust for that platform is like, how else can we lock it down to make it almost unusable, usable to a point where it's secure more than the default installation of Kubernetes, I should say that. I think there's many facets to, you know, bringing security to the realms of a developer that should care about it, as well as, you know, infrastructure and platform teams. So there's been a lot of advancements over the last few years, especially when it comes to containerization and orchestration tools. You know, Kubernetes is much more secure than it was five years ago. There are a lot more tools that you can deploy and layer on top of Kubernetes that help with containers, that help with understanding the processes that are running inside of containers. The EBPF, for example, has become a very recurring theme in a lot of conversations and a lot of presentations and even technologies because of how it's able to identify processes and provide security, but at the kernel layer, not necessarily at the operating system layer. And that becomes very important, especially when it comes to optimization of how your apps perform, being able to cut back on unnecessary resources, et cetera. This opens up a whole nother door and another conversation, but because of these advancements, now you start to see that you don't have to lean on the developer to develop secure containers. What you want them to do is implement their security practices in the way they build their code. You know, obviously, let's make sure that we don't have any buffer overflows. Let's make sure that we're not exposing our keys inside of GitHub or any of those locations, using all these necessary pieces to be able to create that secure application and then push it over to the app or sort of the ops teams to say, look, okay, you've got one layer of security, let's add the additional layers to achieve defense in depth. So, okay, on the physical side, you're locking down your physical host because you're not going to use Ubuntu and then deploy Kubernetes on top of that. You're probably going to consider using something like Talos so that you're using the secure distribution of Kubernetes. Then you're going to realize, okay, the containers that I build with, maybe I'll use something like Wolfi that ChainGuard just recently came out with because that's a very highly secure base image which they constantly check for vulnerabilities and publish new images on a consistent basis. And then you have the network security layer where you're thinking about authorization, identity, authentication, implementing things like TLS for secure encryption and then policies to basically say, you can't do this to that object or whatever. And then you're thinking about Arbrak, who has access to these environments? Who should have access? Should your CI pipelines be the only thing that deploy to your clusters or should you have your entire team doing it? So, these are all decisions that people have to make. It's not necessarily a system that's going to be able to solve it all. And there isn't a system to solve it all. I think VMware might have tried this with their Tanzu offering, but I don't know how far they've gotten because there's so many moving pieces when it comes to the Tanzu platform. And it doesn't take into the account that anytime you add, if you look at the landscape and you add something to the landscape, you've increased your threats. I don't want to say astronomically, but anything you add to a cluster from that landscape, now you've increased what can go wrong, where your vulnerabilities are. I was trying not to use astronomical, but it's not the case. But I mean, it does go up and people don't realize that like, oh, I can put Prometheus here, not saying it's not secure, but now you are worrying about vulnerabilities there. So anything you add to that particular cluster, I think even though it's part of the landscape, we need to know that there might be a vulnerability and expect it. And then what do you do when it does happen? I think the last thing I'll add is, I think everyone gravitates to using open source technologies and forgets all the additional features they need to add or build or codify into whatever they're building. This is why enterprises exist. I mean, we've addressed these particular gaps, especially when it comes to security. And so you want to be using enterprise technology, not open source because it's free and oh, I'll just use the issue feature to be able to try and get some troubleshooting or something along those lines, right? Yeah, that's a challenge for another day. And I'll actually, I want to pick up on a word that Marino used. And I think it actually applies to a lot of the conversation, right? It's optimization. Whether it is optimization at a security, from a security perspective, optimization from a package download or repository perspective all the way to optimization of network and speed and delivery, right? When you could have thinking about the, just the past few years, right? Whether it's containerization, infrastructure or artifact and package management. What are some other ways that maybe optimization, we either have already started down the path of or maybe we should look at a little bit more and maybe not optimization of security, but maybe optimization in terms of usability rather than complexity. Any thoughts or comments? I don't want to say the word standardization, but what I hear a lot from people in the community and when I say community people who are users of open source is best practice, right? And we don't really do a great job of communicating what that best practices are. And if that is something that could be addressed, not necessarily from the open source perspective, but just from a technology perspective, is what are those best practices? Like if Marina put up a thing on properly locking down your network on your cluster, I'd be the first guy there just sitting there going like, okay, where's my notes? Okay, I don't know what that means. What's level two to three? I would be just completely lost, but I would be like, because you don't know what those, and it's not necessarily gonna save you anything, but it's a starting point for someone to take that next step with security, right? It's like, hey, I learned that the best practices in networking, I should do this. And what's that? And it becomes more, and I'm not picking on you, Marina, just you're there on screen. So it's just like using the networking example, because I'm terrible with networking. I will tell everybody that, but it just, what does that look like? Because it's optimization, right? Like I'm optimizing what I know and what I need to know. And then all of a sudden it's kind of built upon those things. And sometimes I don't need to know. And I'd rather just leave it to an expert, but there's times I should have a cursory idea of what it should be like. Yeah, got it. Marina, anything you wanna add there? No, I think Rob covered it pretty well. I spoke to death about, you know, my perspective on, you know, how you can increase the surface attack area pretty easily. And just the fact that people need to be there to make these right calls. But the thing is you're also gonna realize that these same people have made these mistakes before and they're coming at it with all of those experience. Let's just not do this again because there's so many better ways to do it. One last thing I'll add though, is I think what has happened over the last little while, especially with the rise of containerization is that networking has become a very different thing altogether. Like yeah, networking is still there, but then there are so many additional layers. And so, you know, let's say you decide you're gonna deploy a Kubernetes environment by yourself without any sort of managed service. And then you decide, okay, let's use a CNI like Selium. And then you decide, let's also layer in a service mesh like Linkerdee or Istio. But then you realize you have all of these different pieces you have to manage on your own. And then you also have to manage the vulnerabilities that pop up, which then drive issues around, okay, we've just found a vulnerability in Istio D, which is gonna impact the data path and the control plane for everything that exists inside of my environment. When can I do this? Oh, I can't do this. I can't take an average. How do we get around that? So a lot of these same patterns are starting to pop up again. So it's not like anything's truly changed, but I will tell you to Rob's point, the more you layer on, the more responsible you have to be. Yeah, I have a common phrase I use. Kubernetes is not complex. It's not. When you start to add everything on top of it is where complexity and speed and optimization and security really becomes a challenge. Like go back to Robert's example about, standardization or best practices, excuse me, right? I can go read a how-to on deploying Kubernetes. It's actually pretty simple. It's really easy to use, but that's not a real world scenario for me at the end of the day, right? And so I need to add some additional pieces on top of it. I think one more quick question. I'm gonna each give you guys one minute. And I wanna hear what you believe is the greatest or biggest challenge today that we face with containers or containerization and container or container management platforms. One problem, one challenge, you've got one minute. Go ahead, whoever wants to go first. I'll take it. Go for it. I'm just gonna say, the more you do, the more complex it's gonna get. But here's the other thing too, as more and more complex the system gets whatever you're building, you start to realize tools like AI could possibly help with this. ChatGPT has entered the chat, but then you start to forget the fact that ChatGPT doesn't have updated information. It could be using incorrect configuration. You might be relying on it to develop your security stance in your environment. You throw that in there, deploy it. Oh yeah, KubeCut will apply YAML. And then all of a sudden a week later, your entire environment's been infiltrated, bank account's trained, right? So the question now actually becomes, do you want to use ChatGPT or similar tools as a superpower to enhance your platform engineering and how is that gonna translate to using things like Kubernetes and containers? It's really just gonna change the paradigm altogether because now you're gonna have a mishmash of varying opinions as well. Marino jumped to my last question, but we're gonna get to that in just a second. Robert, what's your one challenge that you see today is the greatest or biggest challenge that we're facing in the containerization or container platform landscape? Not everything can be containerized and people need to accept that. Oh, shocking. Like we, to be perfectly, like we will hear just throw it in a container, throw it in a container. It's not gonna solve all your problems. There's applications that are not designed to be containerized. There's applications that even if you figured out how to containerize a COTS application, it can't run in an environment with many instances running, right? Because it doesn't know how to operate. It wasn't built that way. I think that's one of the things that we just have to, if it's up there with developers love Kubernetes, that's the one myth. The second myth is not everything can go in a container or should. It's okay, right? I mean, is Oracle DB, is that running in a container now? I don't know, or I'm pretty confident if it's not, Oracle doesn't want you to do it. So don't think it's going through. It just needs to be in a VM. Let it be in the VM, it's okay. Yeah. What do you mean I can't download? I was just gonna say, like what do you mean I can't download a 10.7 gigabyte container image anymore? So like, this is the other interesting thing because when you see how developers build their containers, they're not breaking it down into tiny, tiny pieces. They're building this massive, massive thing. And then they're the ones that are completed. Well, okay, maybe I shouldn't say that, but you start to realize that these container images are gonna consume unnecessary network bandwidth and then your application is not gonna come online in the time you expect it to. So it's funny that we actually didn't even talk about this, how do you empower developers to build smaller containers? Anyways, different conversation, but this is something. Going back to that one. Yes. Okay, so you both answered your biggest challenge. Robert, you mentioned a couple of funny monikers, like developers love Kubernetes. And I would also say that DevOps is not dead, but hey, we'll have a little bit of fun with that. I had to throw that in there. It's always a good one. You're SRE now, I think. Aren't you guys called, like they just renamed you or something? Or it's basically where it is. Yeah, exactly. Okay, so Marino brought up the topic and I actually wanted to end today's talk with kind of a forward-looking conversation. So we've got about two or three minutes to close this out. Where do we see newer technologies, AI, chat GPT, all of these new, I mean, look, we're technologists, right? We've been at this a while and we've been following technology for a while. This one might be a fundamental game changer that we've seen in a long time. And it goes beyond just an infrastructure layer. So from both of you guys' perspective, where do you see things like AI, chat GPT, supporting, helping in, you know, container security in the infrastructure space around containers and containerization in general? I think you need to look at the problem with Marino touched on it, is the data is old within any of these AI programs. It's old, right? And so it needs to be refreshed and updated and we need to, you know, consume it. And we don't know what data's being put in there, right? So is it having a, you know, specific focus on X and we're not looking at the wider picture? That's the problem. It's like, it's almost like the consultant you hire who's an expert in AWS, but you're running in Azure, right? Sure, there's gonna be a lot of things that cross over, but if you don't know the nuances of Azure, you're gonna have some of those problems. I think that's where my concern with AI would be. It's like you don't know what it's that thing's learning from. And so without a control of that, then really what are you putting your trust into? You know, because you really don't see that. Okay, Marino, anything to add? I totally agree with what Rob said. I also will add the fact that it's a great tool to help you learn and understand things. But where it can start to really go wrong is if you're heavily reliant on it. I think what needs to happen is as these machine learning models get better and better, they need to be trained to also verify the information that they're using, right? I mean, they're just pulling information from the worldwide web to dark web, even who knows? And to make sure that it's legitimate is one concern. The other concern is who owns the output? Do you use something like ChatGPT to generate ideas to help you kind of build your playbook? Or do you actually use ChatGPT to build that playbook? And then does ChatGPT own it? Is the bigger challenge? So it comes back down to, if you built your entire organization, your technical organization with, let's say, infrastructure as code, and that was all originated from something like ChatGPT, who really owns your network at that point? Yes, and that scares me. And I have so many questions and no answers to that at this point. Guys, I want to close out and first of all, just say thanks for your participation and your willingness to have a fun chat. Disagree a little bit. I'm surprised we didn't even talk certain activities, Rob, because you and I have some similarities when it comes to non-technological things. I will mention we're big fans of some sports teams. We are. Yes, but real quick, Marino, tell us a little bit about next couple of months for you and for Solo, and maybe where you or the team will be at. Yeah, so I'm going to be heading out to Raleigh soon to deliver a talk at DevOps Days, and then literally I'll be flying back home so that I can fly the next day to Amsterdam because I'll be there for KubeCon, doing a few talks there. Solo is hosting something called Application Networking Day, which unfortunately is already sold out, but you can still register to get on the waitlist if you want to get it on the action in case some people don't show up. But as one last thing I'll share, I'm running a conference in Toronto called KubeHuddle, and it's happening in May, May 17th, 18th. Go to kubehuddle.com and go check it out. We have some excellent speakers lined up. We have some excellent keynoters, excellent sponsors have come through, so it's going to be a great event. I hope to see you all there. Awesome, thanks, Marino. Rob, you're up, my friend. Two announcements I could talk about. One would be the Rancher 2.7. We have a lot of awesome things. We bring extensions where anybody can write their own extension that runs within Rancher and gives you kind of a window into other services that you'd need to CLI for. Now we give you a place to run that web extension. So I'm really excited about that. And then at KubeCon, we have a huge announcement. I'm going to tease a little bit here, but a lot of big changes happening within our community. So I haven't talked much about it because I've been busy building content for what that is. But that will be announcing that April 19th through a couple of live streams. So I've been working, that's why I'm not in studio. The studio is actually in pieces, getting ready to ship to Amsterdam. Very cool. Yeah, and from a CloudSmith perspective, a couple of things that we think are important. Number one, we actually just released an integration or an enhanced integration with Datadog. So we're excited about that. We're bringing some fun things around policy management. We've started adding those capabilities, Docker vulnerability scanning, yes, containerization. Talk about vulnerability scanning today. That's available now in the CloudSmith platform. And then everybody's favorite word, Sbombs. And we're looking at Sbombs for containers and specifically via Cosign. So that's just some of the product things we've got going on at CloudSmith. More importantly, the team will be at AWS Summit in Paris in a couple of days or a couple of weeks. And then lastly, just to go along with both Marino and Rob, the team will be at KubeCon in Amsterdam enjoying not only the city, but also enjoying the community and I, and you were talking about Networking Day, everything is sold out at KubeCon, everything, all of it, the show, the pre-days, everything, like there's no chance at this point. And so it's gonna be a fantastic and crazy few days. Gentlemen, thank you. Yeah, once again. I was just saying, if you're there, you need someone to hang out with, just hit me up on Twitter because I'll probably be in the hotel lobby because I can't get into anything. It is sold out, 10,000 plus people are gonna be there. This is the first time ever. So it's a lot of exciting stuff for these people, I'm sorry to interrupt. No, you're good, man. Give your social handles if you don't mind. Yes, I am Robert Cirque on Twitter. Actually, I'm Robert Cirque, pretty much everywhere. R-O-B-E-R-T-S-I-R-C. There you go, Marino. And I am virtualized six with the number six. I've actually dropped it in the chat in case you all actually really need to figure out what that means. But yeah, you don't follow us on Twitter. Reach out, we'll definitely be at KubeCon, come hang out and say hi. Awesome, and I'm at the Sean O'Dell. But lastly, the most important thing, who are the winners today? Martin Chin, you are the winner of our free lunch. Rodrigo Schneider, you, and I said it right. You are a winner of a prize pack and Edna Sexton, you are a winner of a prize pack as well. Thank you, thanks everybody for joining today. Guys, thanks for joining and we'll see you next time. Have a good one. Cheers. Thanks everyone, bye.