 All right, welcome to the February webinar. I am excited. This is my first opportunity to host the CloudSmith webinar. My name is Sean O'Dell. And I just want to welcome everybody. Thank you for joining us today. We're gonna be talking about containerization or containers or whatever terminology or verb or noun or adjective, whatever you might want to use to talk about this subject. And it's really about best practices and getting started. And so with that, I'm really just excited to have everyone here today. Couple of things before we introduce our guest of honor today, I want to mention if you are out on Twitter, or out on LinkedIn, on the social networks, please repost the live stream. Really, we do this for a couple of reasons. Number one, obviously to get more folks involved. And number two is to give you an opportunity to be a winner. And we definitely want everybody to win. At the end of the show today, at the end of the episode, we're gonna be doing a giveaway. And so stick around. We would love for you to ask questions in the chat. If you have any comments, anything like that. And as always, because I'm a fan of the emoji, please. Say hello with an emoji and welcome from where you are. If I was not doing this, I would actually post a welcome from the great state of Texas with a cowboy hat emoji, but I can't. So enough about me and let's get on to today's show. I want to welcome really a fantastic guest, a knowledgeable, a guest that I think will bring a lot of insight to the conversation of containers and containerization. And I'm gonna bring in Rory McCune from Datadog. Rory, welcome to the show today, man. Glad to have you. And if you don't mind introduce yourself a little bit more because I obviously did not do enough. Hi Sean, great stuff. Thanks very much for having me along. I'm really glad to be here. Yep, so I guess I've been in containers for a while now. I've been doing container security for about seven or eight years now. So it has been a while. And I've been working around with Docker, Kubernetes, and a lot of different containerization and container security tech. I'm doing a variety of things there. So, you know, it's been a while. Now, very cool. And we're glad to have you. Did you ever do any work with Mesa at all at any point in time? I didn't. I kind of came into Docker just as it was taking off and then that kind of led to Kubernetes. So I just kind of saw that container orchestration war from the outside and didn't really get too heavily involved with the other ones. Yeah, you know, there's obviously a lot. There's a variety of flavors. I mean, even Amazon has a variety of flavors of how they implement Kubernetes and containers and containerization, right? And really every organization does it differently. Yeah, oh yeah, it's amazing. I think that's one of the biggest challenges I see when people say things like, oh, Kubernetes security, I say, which of the 140 different Kubernetes did you mean when you said that? Because they're all different to some extent and that is part of the challenge. Yeah, absolutely. And we're going to get into some questions here today and really just a dialogue about containers. And before we do that, can you give a little bit of, you mentioned this a little bit in your introduction and I'll close out a little bit with it later on. But if you can kind of tell us a little bit about your involvement in Kubernetes and KubeCon and some of the SIGs and a little bit about your knowledge and depth there. Yeah, so Kubernetes, I've been doing for a while now. I said this has been about 2016. I've probably gotten involved and I've done a number of things. There's a couple of things that could be interesting. I've done the CIS benchmarks. So people haven't come across the CIS benchmarks. They're a vendor neutral hardening guide and I've been helping out the Kubernetes and Docker ones for about five years now. And that's been very interesting to see how that's evolved and changed. And yeah, I've been lucky enough to present at KubeCon a couple of times. And I think as my claim to fame, I'm a member of the only unofficial Kubernetes SIG who have ever keynoted KubeCon, which is SIG-Honk. So that was a lot of fun and we've had a chance to do that a couple of times now. That's a honk for anybody in the Kubernetes world. There's some fun connotations and some interesting individuals behind that and just love to have that when, we were having a little bit of dialogue, obviously getting prepped for the show. And I noticed SIG-Honk and I was like, I've got to bring that up and let it be a part of the conversation. My background in Kubernetes is extensive as well. Having been a part of VMware, really when the rise of Kubernetes began, it was interesting, even pre-Heptio, pre-pivotal. We were doing things within the Kubernetes space focused on even creating our own Kubernetes engine. There was an announcement made at one time and I happened to be on the beta of that from an internal team perspective. So it's always interesting when we talk Kubernetes, we talk containers and talk containerization. Now, the other thing, I think we'll kind of hear about today is you can do containers without Kubernetes. This is nothing new for everybody on the call today. You're on the webinar today. You're probably like, no, we started here and we started there. Oftentimes these terms, these phrases, really just the different things that we're discussing around this space often kind of mesh and sometimes they don't have to. And so to the conversation on that. No, I think it's interesting actually because you say that and it's a good point. A lot of times I used to be a pen tester and I used to advise customers about containers and container security. And they'd say, no, we're doing Kubernetes and I would spend time with them and go, you really, really need Kubernetes because it's quite complicated. Could maybe just start with Docker and get some containers out there. I think that for a while it's been that sort of thing where it's become, Kubernetes is very front of mind. People start there and perhaps sometimes, yeah, start with something simpler. Start with serverless containers, start with Docker. You might find that does what you need. And if it doesn't sure that Kubernetes is there, it's not going away. Absolutely. And you find we already mentioned serverless and containers and Kubernetes and orchestrators versus Docker, right? At the end of the day, there's a lot of ways to solve challenges, problems within the space. And I think that's what this conversation is about today. So let's jump into it. My favorite question by far is, what is containerization or what are containers and a preface to that? What is the 2023 definition? Because that's going to be the interesting one. So go for it. Yeah, so let me try and see what I can think of. For this, containers always come across to me the way they've ended up. They've been used for lots of different things but it's all about delivery and management of apps and being this portable, independent way of doing that. And what I always think of containers or dockers being a containerization is like the Goldilocks solution. So it's lighter weight than virtual machines and physical servers, but anything lighter than that and you start to have to manage, you have to change your app and change the way it works. Whereas I think that the light of containers, the reason I like them so much is you can take pretty much any application, drop it in a container and it'll work. So you get that kind of like, it just works feeling. And that's honestly where I said, even now after all these years of containers, it's like that's the real thing. It's like, yeah, I did this network, which is nice now. Yeah, and I appreciate the fact that you started the definition off with the why we are doing this anyway. It is the delivery and management of applications. If I was to, look, everybody's had this conversation whether we were in a KubeCon or talking with other peers or different customers and so on. But at the end of the day, we often have a lot of opinions about the technology. We have to have a lot of opinions about why we love our certain piece of technology. But really we are talking about delivery of applications and we were talking about management of applications. So why make that distinction in your mind that the fundamentals of this is about application delivery and bringing value versus let's just jump to the tech. Yeah, I mean, I think, I suppose, I kind of caught up on that point of view because that's, it's a use case. It's what you actually want to get out of at the end of the day. And I love the tech as much as everyone else. I can spend hours tinkering around with the details of exactly how you configure them. And for me, it's like how you secure them or break them, all that sort of stuff. But yeah, I think you can lose yourself there. And I think whatever you do, it's about solving a business problem and that is to me, that's the business problem container solve. And hopefully the one they will, I don't see it changing. You know, you kind of get this hype cycle affair, we'll be like, you know, it's gonna go up and it's going down. For me, containers have come through that now. And it's a steady state where I don't see anyone saying, we're gonna replace containers. They don't know what you've replaced them with. They're here to stay. Yeah, absolutely. You know, and it's funny, you come from your point of view, I'll bring my point of view. I started as an infrastructure admin and architect, right? And really my entire world was central or was centralized and focused on infrastructure. And I think what's occurred over history, I always laugh because, you know, look, I worked in a Fortune 150 organization, my job was infrastructure and security and enterprise management. And there was definitely a little bit of a love, hate relationship with application owners and application teams at the time. But what's evolved is there's now almost a, I don't wanna say a marriage, but there's a closer knit, you know, relationship between the infrastructure and the applications that has occurred, just whether it's technology or, you know, bringing down of barriers and so on. But I actually think containers have actually helped bring that closer together, right? That marriage or that partnership is even more solid today between the application owners and the infrastructure or now even DevOps or platform teams. So I love to talk about kind of the maturity of containers and containerization. Yeah. I mean, my partner I go back far enough was in IT security and banks. A world where, you know, everything was on-prem. The concept of cloud was that. And you're right, the move there, I mean, I also remember that when we did projects there, you would talk in months to do a prototype and years to get a project. And now it's hours or even less than hours to launch an entire application in a cloud account using a container, you could have it done in, you know, 10, 20 minutes tops, no problem. And that change is just vast. And that, and it's good because it obviously means everyone could do things quickly but as a security person, it's bad because things change so quickly. Knowing what's going on is much more difficult than a world in which you could have static firewalls where there's a change request that goes through to change it. That world was long gone. And I think hopefully now in people in kind of the world I come from have kind of realized that's not becoming back, right? We're not going back to that world level. Yeah, I have no desire to go back to the weeks or even hours of time it takes to get applications and infrastructure deployed and provisioned. And since we're talking about dating ourselves, you mentioned it earlier. I was working on CIS benchmarks over 20 years ago for physical servers and Windows and Linux machines. So, you know, it's funny how the technology changes but as I mentioned applications and management of those applications and providing value to the business as you said is really what this is all about. So, very, very good. What one last comment on that? Not I think, I think, yeah, well actually I thought the other thing you asked about containers and what they are now and it's funny how the other thing that struck me is the complete merging of terms. So, if you look at serverless, serverless containers used to be distinct and now they're not distinct anymore, right? Because you can run containers in Lambda quite happily and any other serverless service you choose to use, most of them will now allow containers. And that's where it comes down to this piece of it literally being this app packaging because the underlying tech is now, yeah, pick your underlying tech. There's a hundred different ways to run containers. But what remains constant is what you're using them for or should be what you miss constantly. Yep, it's getting back to the basics. So, that leads to kind of this next question, right? Containers are nothing new, but in some cases whether it's culture, whether it's you're new to the industry or you're new to the space, where does somebody get started with containers and where do you believe they should begin? You can be a little bit opinionated here and we'll just kind of flesh it out. So, where do you think folks here get started with containers? If it was me and I was getting started with containers, where I'd start is with a virtual machine running Docker, right? Docker was originally meant to run on Linux VMs that was where it came from. That is the simplest and least interfering solution because you're not putting any more layers in place. You can go and inspect everything. One of the great things I love about Docker is it's all just Linux. So, you can use Linux tools to expect exactly what that container's doing. You can build that understanding before you start adding those extra layers of complexity, before you start trying Kubernetes or server or anything like that. I'm a great fan of the traditional. And it doesn't feel right calling it traditional, but it has been a while now. So, maybe it's traditional Docker VM solution. I'm not gonna, I don't even know where to comment on the word traditional. Some folks may not like it, but it's been around for a few years, right? So, Docker is the starting place, right? Simple getting started. Let's take it even up a little bit further. If you're an application developer, if you're looking to get started, create a small service, whether it's a, I don't know, simple API request, whatever you're looking to get out of it. Besides Docker, what are some of the areas that you would focus on in kind of that initial journey of creating your first container and creating the first application in that case? I think I probably would start off with, like looking at how you build your application into a container. Look at the Dockerfile. Do I actually like, again, Dockerfile syntax gets a bit of hate and a lot of people will talk about it and say, oh, they want to do something different. But I actually like Dockerfile syntax because I can read them. And I'm a great fan of simple tech. Make it as simple as you possibly can because when you come to debug it, you're going to be happy you did. And so I would keep it really simple, get a Dockerfile, get a basic base image, and then just start adding statements and like trying to run up each container. That's what I used to do. You'd run up, add a new statement and say, what does that do with my container? Does it work? Does it fail? Nice and fast. And then once you've got that base running and you've got your image the way you want it, then you can start thinking about compose and you can start thinking about, like, I want a database. I want multiple containers. But just slowly building that up from that kind of solid base. But do take time to understand like Dockerfiles. I wouldn't just take them off the shelf and just reuse them. It's not that my harder syntax, I think. So it's worth doing. Absolutely. And you know, we're talking Docker, we're talking containers getting started, right? There are so many containers or artifacts that vendors have provided that different providers have created and developed whether it's for databases or observability or any of the tooling in and around this space. And obviously at CloudSmith, the concern is definitely the proliferation of packages, including Docker, including everything that goes into a container or into an application, right? It's the artifacts, it's the package management. So what are some of the things that you think, in that getting started, right? Besides obviously using Docker in the kind of the beginning of the journey, what are some additional areas that may be outside of Docker or even into maybe some of the open source areas that fit into this space that maybe somebody should begin to look at? Maybe is that next step beyond Docker? Yeah, I think the next step beyond Docker, I suppose, well, it depends on your goal at that point. I mean, if you wanted to go into the cloud, then you want to start looking at basic cloud stuff. How am I going to hook these things together? Because a container on its own probably isn't going to do everything you want. So you're going to start looking at that and start trying to build up. One thing I would say, because you mentioned, kind of like, there's a lot of artifacts that come from lots of places, the issue there starts to be this issue of trust as soon as you head towards production, be super careful with trust in container images because a lot of people get this one wrong. There's ever eight million different images on Docker Hub and there's about 150 ones you might be able to trust depending on how you feel about it. Be super careful with that. So that's my security person's hat. I can't talk too long about IT without my security person's hat going on a little bit. So always be careful there. But then it's about kind of building it up and saying, well, you know, do I need to do balancing? Do I need, and how would I do that? And then it's kind of, I feel you kind of split your journey there, right? Because you probably want your cloud of choice. So everyone's got a cloud of choice and at that point, you get to that very, very complex world of cloud. But that's where you probably end up next, trying to start scaling, to start saying about how am I going to do this, how am I going to break to production? I mean, it's a production app rather than, you know, something, say, on my desktop. You see I as well and all that kind of stuff. There's a lot to think of. There is a lot to think of in, I think in a follow-up episode, we're actually going to dig deep into the security topics. But the one thing I heard there is, while there's so many, you know, available images out on Docker Hub, you probably can't trust too many of them. And we're starting to see more and more attacks and more sophistication in that. And so, you know, I think going back, actually you said it, my security hat will come on pretty quickly too. So no matter what you're doing, whether you're creating an application and service in a container or in a traditional monolith perspective, right? Security is always at the forefront. So my next answer would be, as always take security is kind of that next step. You know, especially once you get a production and you start looking at issues like clouds and, you know, where am I going to be running this? You know, IoT in the industry four area looks for things even more, you know, kind of expanding and the expansion there, right? So it's interesting as we get started in this that, you know, let's start simple, but quickly it's going to expand to other areas that are valuable, important and we definitely need to think about. So that leads me to the next question. Some of the folks watching today and that will be watching in the future, they are seasoned, they are veterans, right? You use the term traditional for Docker, which I think is still funny, but let's take those folks who've been using and building applications in and around the container ecosystem. Where should they think about, what should they think about? And what are some of the next steps that they should take on this journey? I think there's obviously a lot going on and it's one of the great, it's benefits and challenges of container ecosystem is how fast it moves, how fast new and the constancy of the new things. You know, I do this thing every four months there's a Kubernetes release and I go and troll through the changes every single release to look for interesting ones. And this one coming up in April, there are 90 new changes coming through. So it's a huge quantity. In terms of things I've seen interesting which I think if you're seasoned they are worth looking into. One is we have this concept of containers being ephemeral, right? We all know that containers are ephemeral, they come and go. But Kubernetes clusters, maybe not so much. I've seen a lot of people unfortunately have gone to this trap of clusters being like pet clusters. This is really, I think again, security hat going on, this is a tricky one, not just security though from maintenance point of view, people need to get practiced at destroying and recreating clusters, trying to get to this like cat clusters as cattle concept because without that, maintaining and upgrading becomes a nightmare. And if you've got a lot of clusters, you know, you see organizations trying to go back. And I, one of these things I do one of my kind of little hobbies is I scan the internet every day for Kubernetes versions because a lot of clusters explodes the versions. And the number of clusters are falling off the supported curve and I've been going into unsupported versions because they're not at this kind of practice. So that one of like, you know, how do I maintain these things is a really, you know, I think a key one. Another thing that I suppose I would be investigating is a bit more into like mixing serverless and things more into your clusters. So this idea of different workloads could work differently. And I think personally, just a personal opinion, I think a lot of people will end up with Kubernetes plus serverless containers as their eventual solution to get away from a lot of the management headaches and a lot of the problems that underlie can like maintaining, again, this maintenance problem and trying to get down the amount of time you have to spend on maintenance. It has its own sets of problems, but I just have this feeling that the happy place will end up being there. So if I was, you know, I had clusters and I was thinking what I want to do this year, I'd be investigating serverless containers if I hadn't already. I think that's kind of an interesting area. Yeah, you know, it's, you know, we talk about businesses, you know, needing applications and delivering of applications from an application delivery perspective. You bring up the topic of just because you think you need to run it on Kubernetes or on this particular piece of infrastructure doesn't necessarily mean it has to. I mean, there's even a question in the chat, you know, and the question is from, I believe it's Bivik, if I'm mispronouncing it, I apologize. For a front end app using React, do we use a container or a CDN? Now, I don't think there's a perfect answer for this. I don't think you're gonna be able to be like you should use X or you should use Y, but I think what's interesting, and we'll talk about this a little bit, I'm curious your opinion. I've always been a fan of run the application where it makes the most sense for your business, for the requirements, for the security, right? For the tut, I like, there's just obviously the, you know, data resiliency, there's lots of things that go into it. But that being said, just because you're running or creating an application, it doesn't necessarily have to be a container or maybe it is serverless or maybe it's a function or maybe it's, you know, those types of things. So what are some ways that not only the audience, but just in general, we in the space, what are some steps we can take to get to the right answer or to the closest to the correct or right answer for our organization? I think you end up having to look at the trade-offs you're gonna make, and there are not quite a few of them. So in the advantage of containers, and this is the big promises, you can run the app in test and dev and CI all the same way. Serverless, that's trickier, but serverless has huge advantages for bursty applications. You know, I want to do, suddenly I need to do a thousand requests where previously it's running quite slow. And that's the kind of thing where you start thinking of it's to do with, you know, the style of application. What sort of coding are you using? Is it Greenfield or are you legacy? Are you porting a legacy? In which case containers or VMs is probably going to be your answer because that won't take being put to serve. That's why I always think with serverless is like where serverless has its place, I could never see it replacing containers or VMs until everyone gets rid of legacy. And I love to be in that day when all the legacy IT goes by. Don't think I'll see that one ever. No, I don't think legacy is going anywhere. It would be nice. It would be really awesome, but there's a reason mainframes and AS 400s and all of these things are still sitting in data centers. And hey, it is what it is, right? We have to, we have to, I think that's the key, right? We're still trying to solve business problems, deliver value to the business, but at the end of the day, just because we need it to run in Kubernetes doesn't mean it needs to run in Kubernetes, right? And I actually put that in one of my, I wrote a predictions blog a couple of weeks ago and in that I actually talked about, we have made our lives so complex just because of our opinions or our technical choices which has nothing to do with what we're actually trying to do which is deliver applications. Yeah, the complexity point you make is really, really good. And it's the one that always worries me because even Kubernetes and the important thing to know about it is it's not a full solution. By design, they say certain parts of this stack are not our concern. You need to go and get additional things. So you're gonna need CNI, you're gonna need storage, you're gonna need networking, you're gonna need authentication solutions, you're gonna need admission control. There's just a whole stack of additional. And I look at that and go, that's horribly complicated for a new company. And that's come to this point of probably don't wanna start with Kubernetes unless you kind of have to start with something, some way of running containers. You know, a constable container solution that'll let you scale. It doesn't have all the additional complexity. And yeah, so the complexity one probably is the bit that would worry me the most about how people are doing containers is I've been doing this for, I said, but you know, eight, nine years now containers, I still learn things every week. You will never solve. Well, it's interesting, you didn't even mention observability and monitoring and traces and all of that fun stuff. There really is, right? You know, I've had an in-depth view of the service mesh world for years now. You know, obviously, you know, observability and the different components of pieces. Complexity is not necessarily a bad thing. And I wanna be careful with that. Actually, as I reread my predictions blog after I got posted, I was like, wait, some folks might actually see that I was negative in some way towards containers or Kubernetes, or you know, in that sense. But at the end of the day, delivering value to the business and helping reduce that complexity, however you choose to solve it is always the right answer for the organization. And obviously we have opinions and there's gonna be trade-offs and we've been doing this for a long time. And so it's definitely fun to see kind of the maturity, but really that is kind of that next step in the, for the seasoned veteran is how to maybe reduce some of those complexities and make their lives a little bit easier. You know, you mentioned something, and I wanna go back to this because you actually said containers or the ecosystem, whether it's Kubernetes or serverless or all of the necessary components in and around containers, it moves so fast. What are some practical ways that you have found to stay on top of the very fast, you know, moving, I would call it a large ship at this point. Sorry, Kubernetes joke in there. But what, you know, how do you handle that? What are some tips and tricks for moving so fast and staying on top of it? I guess it depends on like how focused you are on it. If you're super focused on it, weirdly one of the best ways is actually participating in the project. So if you actually, there's, there are slacks for Kubernetes and you can join six. So if you're like intranet of Kubernetes with the best ways to actually find it, I found so much information I wouldn't find otherwise by being in the right channel on the Kubernetes Slack. And there's some really great people there who are very helpful. That's a good one. Social media is a perennial favorite, whichever social media platform you're on these days and there are, you know, there's people in different ones, but places like LinkedIn, Twitter, Mastodon started to become more popular, I've found certain, you know, technicians. The challenge there is now you've got like three to four different social networks to hang out on. And even places like Reddit as well, you know, the Reddit's a great, there's lots of good information. If you find the right subreddit, there's good info. So it is kind of this journey where you're just like sucking in information and then it's like, where do I focus? Because you can't cover it all. And then just like trying to nail it. The other one, if you get super, like if you get super deep with Kubernetes, especially and Docker as well, is you will find GitHub is weirdly the best, sometimes the only place to find your answer. I have on multiple occasions now spent some hours in either GitHub issues or the code itself, for looking around, trying to find what I want. So that's like, that's generally, you know, if you really want to know the depth, that's probably where you have to hang out is GitHub and actually start looking at PRs and issues, which, you know, you have to be kind of like either very interested or, you know, really needing that information though. Speaking of social media, this would be a good opportunity to plug your, what's your Twitter handle, if you don't mind, and mess it up. Right, my Twitter handle, and generally my handle almost is the same thing. It's Racine, which is R-A-E-S-E-N-E, for a very geeky reason, which is basically when I started getting into, to collect the internet, it was a handle of a game I was playing. That was a name of a game. And it was the one thing I could find that no one had taken. So you could go to any given website and have that name. And that lasted me like for, you know, in the last 20 years. So it's been, you know, it's worked out pretty well. You don't have a very common, you know, name I would say in the tech space. Neither do I by chance. Maybe because of our lineage and heritage in where we come from. My handles are not as cool as yours. I chose my handle because there was a photographer who beat me to it at one point in time. He had Sean, or at Sean O'Dell. So I am the Sean O'Dell. That was long before anybody edited the before. So I'd like to consider myself, I was cool in that sense. But that mind does also stretch across mask down, GitHub, LinkedIn, all of the, you know, necessary mediums and platforms. So definitely Rory is a great follow. I'm kind of a terrible follow at times because I like to delve into other things that have nothing to do with technology. But you should follow anyway. It's always kind of fun. All right, let's get back to the topic at hand. What are some of the challenges? And this is so broad. So I almost wanted to narrow this down because even in the chat, some of the folks are actually already articulating some of the challenges that they are saying, but what are some of the, let's start with two top challenges that still remain with containers and containerization. And then how do you think they will be solved or overcome? So let's just start with one. Let's talk about the first one. We'll discuss it and then we'll shift to the second one. So, I mean, I think to be honest with you, we've already covered, I think we've touched on these because I think that these go all the way through it. The one that I'd probably find the hardest to, or the one that's the biggest challenge is complexity is that we're building ever, and every month that was by, we had a new thing that comes in and it's more complexity. And I think that there's gonna have to be a point where companies, you know, they rationalize and say, actually, do I need this 20, you know, and you said before, it's like, if it's building business value to the business rate, but is there some of that complexity that maybe isn't bringing value to the business or maybe could we do it in a more simple way? That from my money is how I would be, what I'd be thinking about because I just look at some of the stacks now and go, how does anyone, you know, get their head around, get that into their head and understand what's going on. They have a massive team attempting to solve the infrastructure operational platform challenges instead of focusing on their core business value or just delivering applications, right? It's, I know that one gets on some people, when you start to talk about that, like we might have overdone some of this in a lot of ways. And, you know, we talk about challenges. I think that's actually true. You mentioned, you know, whether it's complexity, right? We've talked a little bit about security. We're not gonna dive too far down into that one, but security comes up in every conversation every day. There are so many different surface, you know, attack points. There are new, you know, whether it's, you know, benchmarks or new findings or new this, right? And it moves fast. So if you wanna, let's talk a little bit about security. We'll actually look at this a little bit in the follow-up question as well, but just what are some things that if you were to look at the security challenges of containers today, can you rattle off a few of those that you think might be super valid and important? You don't have to go too far in the weeds, but just kind of at the surface. What are some of those challenges that you see? The first one, I mean, the first one that is kind of a, everything exposed on the internet is the kind of way I would put it to begin with. So we've gone for this world where things were not directly exposed. And the problem with everything exposed on the internet, Kubernetes is a good example. So there are around 900,000 Kubernetes hosts directly connected to the internet. And that means that one mistake in your authentication, one mistake or one bug in Kubernetes, right? It's a software, everything, a CV, some bugs, that will get you into trouble. And that we've gone from this very hyper-connected world. And quite timely at the moment, you've seen companies essentially like losing staff and they've been revoking their access, thinking, well, all your clusters are right there on the internet. So, you know, how careful are you being? So there's lots of different threats. We've seen a lot of attackers doing things like compromising developer laptops as a way. Again, all your stuff's straight on the internet. So before you could maybe cut off all their access by getting rid of a VPN, right? That was the old way. It used to work everything with the VPN. Now you can't do that anymore. If someone compromises on your developers' laptops, you're gonna have to scramble across how many systems do you even know where they are? Do you mention observability? Do you even know every service that your people have got access to them so that when that happens, you can react quickly? So that part of a combination of exposure plus attackers is big. The other one, which obviously is getting a lot of press and rightly so at the moment is supply chain, which it's another complexity problem because we've got all these applications to have hundreds of libraries as you're sitting underneath the actual code you've written. And now it turns out that attackers have worked that out. Weirdly, I always think of security people, you're like Cassandra, but you make prophecies that no one will believe. And I actually did a talk in 2015 about this exact problem, about supply chain security and what happens if an attacker takes out one library that you use and how there's really no great solution. Luckily, there are people working on that now and it's getting better, but still that's the one that like, do you know about every application library that's written? Do you know who wrote it? Probably don't know who wrote it. Do you know what their situation is, who they work for, what their background is, how secure are they? No, you don't know that either. You don't probably know who they are, even if you know all of the versions you've got. So it's that kind of lesson of the complexity problem. Those are the two ones I think that really, I think about a lot when we're looking at this space. Yeah, absolutely. And obviously Cloud Smith, from our perspective, this is the question we get asked on a hour to hour basis talking with customers and prospective customers and prospects and all of that. Look, supply chain is like in some ways we solve some complexity challenges with CI CD and continuous integration, continuous delivery, continuous testing and building run books. And we actually solved a lot of the complexity by automation, but when you inject, as you said, one compromise library, that entire process and pipeline and supply chain is now compromised. And the challenge I see is nobody has a clue where it is. Where did this happen? Why did this happen? What systems are affected? How many containers do I have running out there that are now compromised because of this? And so this is probably, I don't want to go too far in this guy, we could sit here and talk for hours about this specific subject in our followup to this. We will actually dive deep and actually drill into some of those challenges and talk about a lot of the intricacies. I mean, we haven't even mentioned S-bomb yet. We've actually mentioned the concept we haven't talked about or the components of an S-bomb, but we haven't actually talked about it in general, right? So it's interesting how all of this goes back to just kind of a new introduction of technology in this containers. We've solved a problem here, then we introduced a little bit more complexity, then we solved another problem here, right? And it's just this continual process that we're on, which I think is a good thing, but at the same time, it can also be a struggle and a bad thing. So any final comments on the topic around container security, the problems that we're trying to solve and obviously supply chain attacks that you mentioned? I think, yeah, we've got supply chain problems right now. It's good to see, and I'll mention the open SSF, if people haven't looked into open SSF, good foundation, they're doing a lot of great work on trying to address this problem. It's not a quick fix. This is the thing that I think is the big challenge with supply chain is no one can tell you just do this and you fixed it. They can help, they can provide you with tools, they can provide you with advice, but they cannot fix it quickly. It's gonna be a problem for forever. And again, I actually would bring it back to the message I had before about complexity and trying to reduce complexity. I tried to think of library dependencies as being kind of like, it's like nuclear power, right? It's great, you use them, they get you there faster, they do something for you, but then you have to manage the radioactive waste and that's all the maintenance you have to do on all of these libraries. So every time you had another library to approach it, think about it, that's the more radioactive waste I then have to manage. It's a cost, and hopefully that might, I think for me, one of the best things you can do to help your supply chain security is say, do I need 500 libraries here? Can I maybe get that down by 100? If I have, then fantastic, I've just made my life easier. I will not have that report that says, hey, you've got these maneuvering abilities, it'll be somewhat smaller. So all of that journey is trying like, would you share complexity again? Yeah, limiting the attack surface is the biggest challenge in that sense. So to close things out, right? We have, we've talked a lot about containers, Kubernetes, obviously exploring serverless containers and really just in general about application delivery and the challenges in and around the space. So as you kind of last question, I'll give you an opportunity to kind of open this up and just talk about your remainder for 2023. What are some things that you're going to be focusing on in and around this space that maybe we've talked about, but if you could detail maybe where you are looking to focus or maybe some of the things that you're hoping we solve in and around this ecosystem based upon these challenges we've discussed? Yeah, I think in terms of the focus I'm gonna have, it's gonna be your own intended complexity One of the things I'm actually interested in and I talked a bit about fundamentals is I actually started doing some posts around fundamentals. So try and do some stuff around here as containers and here's how they work. Because I think the best thing I ever did when I learned containers was went down to the basics and worked my way up. Because now when I get a new thing, it's just like a little bit extra and I kind of have this space to sit on. So if I was advising people, that's the thing to do is to work from that base and work your way up, know what's going on underneath the covers. In terms of stuff, that will be one for me is trying to explain more to people about that. I think the other thing is just trying to keep up with Kubernetes. There's a new, so the way Kubernetes does admission control there's a new inbuilt version of that coming along which is going into alpha in the next release. So it's gonna be that constant process of what's coming with Kubernetes now and can you keep up along with keeping up with all the other things I think we've been doing. Yeah, there's just so much to do in finding that focus. And I think you actually said it a couple of times is nobody can solve every problem, right? There are a variety of challenges. Some of them take very specific focus and niche. I laugh back in the day when we started getting into traditional monitoring tools and the Microsoft's mom and just kind of the build out of all of those tool sets. There was always this idea of having a single pane of glass and I've never prescribed to that. I do not believe in that. It's nearly impossible. And so as we go into 2023, I look forward to every organization, every open source project, whether commercial organizations, right? Governing bodies or SIGs, obviously CIS and really just everybody in this ecosystem is solving what they know best. And focusing on that, obviously some folks are far better at different areas than others. Different individuals have different, all of us have different expertise and different focus. And so to me, that's gonna be the biggest thing for 2023 is not trying to solve every problem, but trying to solve each of the little, kind of here and there. And as we solve each of those smaller problems or chunks, it's gonna take a big effort by a lot of different folks to do it. But I think we can get better than where we are today. And so that will definitely help out in this idea and in an area around containerization. So really, really excited, really for what is happening in this space and really wanna thank you for the time coming in and talking. And as I close out today, I wanna bring up a few things, especially for you, Rory, because we have KubeCon coming up in April. So if you don't mind, kind of tell us about what you're gonna be doing at KubeCon. Any sessions you might have a part of or any of the SIGs and the different things that you will be taking part in. So yep, the main thing, I will be doing a talk at KubeCon with a SIG honk. So it's myself, Brad Giesemann, Ian Colwater and Duffy Cooley. And we're gonna be talking about container vulnerability scanners and how potentially to work out what it's called malicious compliance or talk. And it's about how could the clever people try and get past all those nice controls that we put in place or container vulnerability scanners and controls. So it should be interesting. I'm looking forward to that. Absolutely. Yeah, I am as well. And obviously you mentioned some fantastic folks besides yourself on that team. I had the privilege of working with Duffy at VMware. Fantastic. And obviously Ian, well-known, well-respected. And if you ever see Ian, obviously honk is very, very important to them. And so we definitely bring that up. A couple of other things, you know, from a CloudSmith perspective, we obviously are super excited and thankful to have all of you here today. And some of the things we are gonna be doing, we will be at KubeCon as well. I will be there, I'm looking forward to that. We as an organization have updated our Terraform provider so you could manage CloudSmith with Terraform. And then a fun one is as we continue to add and expand into upstreams, which is something that we're looking to do. And we've had an NPM and Python from an upstream perspective. They're both in early access. And, you know, as of now, we support 28 different packages and we're gonna continue to expand that and obviously offer upstreams in that. And so it really excited, you know, our customers are loving that. Really, it's becoming a common theme. Hey, we need upstreams, we need X, right? And so it's good to hear. And then the other thing is not only will we be at KubeCon, we will be at the London Tech Show next week. And then I will be in lovely New York City the week after. But the other thing that we want to announce today, and actually I'm gonna hold on, I'm gonna do the winners first and then I've got one more big announcement. So our winners for today is Jonathan Burlback. He is getting a prize pack. Congratulations to Jonathan. That it looks like Swin or, I'm gonna say Swin. I'm gonna have totally butchered that name. Abicbyte, a prize pack as well. And then Wiley Lange, prize pack and Matthew Griner, a free lunch. And Hilary will be reaching out to all of you for that. But the big announcement is this. We are announcing Unpacked. Unpacked as a conference that we are excited about. The class myth is putting on focused on DevOps, package management, supply chain security. And this will be virtual and we're gonna be having this in a couple of months. So if you go to unpackedconference.com, we would love to have you sign up. You know, go check it out. We haven't announced the full speaker list yet, but we're gonna be getting there. I'm excited about that as well. And so with that in mind, Rory, I just wanna say thank you. You've been a fantastic guest. Appreciate the opportunity to speak with you and have you provide your expertise today. Thank you so much for having me along. Absolutely. Well, thank you everybody. Have a great rest of the day wherever you are morning, afternoon and we look forward to seeing you next time. Cheers. Cheers.