>>mhm Yes. >>Hello and welcome back to the cubes coverage of dr khan 2021 virtual. I'm john Kerry hosted the Q got a great cube segment here. Simon Maple Field C T Oh it's technique. Great company security shifting left great to have you on Simon. Thanks for thanks for stopping by >>absolute pleasure. Thank you very much for having me. >>So you guys were on last year the big partnership with DR Conn remember that interview vividly because it was really the beginning at the beginning but really come to me the mainstream of shifting left as devops. It's not been it's been around for a while. But as a matter of practice as containers have been going super mainstream. Super ballistic in the developer community then you're seeing what's happening. It's containers everywhere. Security Now dev sec apps is the standard. So devops great infrastructure as code. We all know that but now it's def sec ops is standard. This is the real deal. Give us the update on what's going on with sneak. >>Absolutely, yeah. And you know, we're still tireless in our approach of trying to get make sure developers don't just have the visibility of security but are very much empowered in terms of actually fixing issues and secure development is what we're really striving for. So yeah, the update, we're still very, very deep into a partnership with DACA. We have updates on DR desktop which allows developers to scan the containers on the command line, providing developers that really fast feedback as as early as possible. We also have uh, you know, new updates and support for running Docker scan on Lennox. Um, and yeah, you know, we're still there on the Docker hub and providing that security insights um, to, to users who are going to Docker hub to grab their images. >>Well, for the folks watching maybe for the first time, the sneak Docker partnership, we went in great detail last year was the big reveal why Docker and sneak partnership, what is the evolution of that partnership over the year? They speak highly of you guys as a developer partner. Why Doctor? What's the evolution looked like? >>It's a it's a really great question. And I think, you know, when you look at the combination of DACA and sneak well actually let's take let's take each as an individual. Both companies are very, very developer focused. First of all, right, so our goals and will be strife or what we what we tirelessly spend their time doing is creating features and creating, creating an environment in which a developer you can do what they need to do as easily as possible. And that, you know, everyone says they want to be developer friendly, They want to be developer focused. But very few companies can achieve. And you look at a company like doctor, you're a company like sneak it really, really provides that developer with the developer experience that they need to actually get things done. Um, and it's not just about being in a place that a developer exists. It's not enough to do that. You need to provide a developer with that experience. So what we wanted to do was when we saw doctor and extremely developer friendly environment and a developer friendly company, when we saw the opportunity there to partner with Yoko, we wanted to provide our security developer friendliness and developer experience into an already developed a friendly tool. So what the partnership provides is the ease of, you know, deploying code in a container combined with the ease of testing your code for security issues and fixing security issues in your code and your container and pulling it together in one place. Now, one of the things which we as a as a security company um pride ourselves on is actually not necessarily saying we provide security tools. One of what our favorite way of saying is we're a developer tooling company. So we provide tools that are four developers now in doing that. It's important you go to where the developers are and developers on DACA are obviously in places like the Docker hub or the Docker Cli. And so it's important for us to embed that behavior and that ease of use inside Dhaka for us to have that uh that that flow. So the developer doesn't need to leave the Docker Cli developer that doesn't need to leave Docker hub in order to see that data. If you want to go deeper, then there are probably easier ways to find that data perhaps with sneak or on the sneak site or something like that. But the core is to get that insight to get that visibility and to get that remediation, you can see that directly in in the in the Dhaka environment. And so that's what makes the relationship so so powerful. The fact that you combine everything together and you do it at source >>and doing it at the point of code. >>Writing >>code is one of the big things I've always liked about the value proposition is simple shift left. Um So let's just step back for a second. I got to ask you this question because this I wanted to make sure we get this on the table. What are the main challenges uh and needs to, developers have with container security? What are you seeing as the main top uh A few things that they need to have right now for the challenges uh with container security? >>Yeah, it's a it's a very good question. And I think to answer that, I think we need to um we need to think of it in a couple of ways. First of all, you've just got developers security uh in general, across containers. Um And the that in itself is there are different levels at which developers engage with containers. Um In some organizations, you have security teams that are very stringent in terms of what developers can and can't do in other organizations. It's very much the developer that that chooses their environment, chooses their parent image, et cetera. And so there when a developer has many, many choices in which they need to need to decide on, some of those choices will lead to more issues, more risk. And when we look at a cloud native environment, um uh Let's take let's take a node uh image as an example, the number of different uh images tags you can choose from as a developer. It's you know, there are hundreds, probably thousands. That you can actually you can actually choose. What is the developer gonna do? Well, are they going to just copy paste from another doctor file, for example, most likely. What if there are issues in that docker file? They're just gonna copy paste that across mis configurations that exist. Not because the developer is making the wrong decision, but because the developer very often doesn't necessarily know that they need to add a specific directive in. Uh So it's not necessarily what you add in a conflict file, but it's very often what you admit. So there are a couple of things I would say from a developer point of view that are important when we think about cloud security, the first one is just that knowledge that understanding what they need to do, why they need to do it. Secure development doesn't need to be, doesn't mean they need to be deep in security. It means they need to understand how they can develop securely and what what the best decisions that could come from guard rails, from the security team that they provide the development team to offer. But that's the that's an important error of secure development. The second thing and I think one of the most important things is understanding or not understanding necessarily, but having the information to get an act on those things early. So we know the length of time that developers are uh working on a branch or working on um some some code changes that is reducing more and more and more so that we can push to production very, very quickly. Um What we need to do is make sure that as a developer is making their changes, they can make the right decision at the right time and they have the right information at that time. And a lot of this could be getting information from tools, could be getting information from your team where it could be getting information from your production environments and having that information early is extremely important to make. That decision. May be in isolation with your team in an autonomous way or with advice from the security team. But I would say those are the two things having that information that will allow you to make that action, that positive change. Um uh and and yeah, understanding and having that knowledge about how you can develop security. >>All right. So I have a security thing. So I'm a development team and by the way, this whole team's thing is a huge deal. I think we'll get to that. I want to come back to that in a second but just throw this out there. Got containers, got some security, it's out there and you got kubernetes clusters where containers are coming and going. Sometimes containers could have malware in them. Um and and this is, I've heard this out and about how do how that happens off container or off process? How do you know about it? Is that infected by someone else? I mean is it gonna be protected? How does the development team once it's released into the wild, so to speak. Not to be like that, but you get the idea, it's like, okay, I'm concerned off process this containers flying around. What is it How do you track all >>and you know, there's a there's a few things here that are kind of like potential potential areas that, you know, we can trip up when we think about malware that's running um there are certain things that we need to that we need to consider and what we're really looking at here are kind of, what do we have in place in the runtime that can kind of detect these issues are happening? How do we block that? And how do you provide that information back to the developer? The area that I think is, and that is very, very important in order to in order to be able to identify monitor that those environments and then feed that back. So that that that's the kind of thing that can be that can be fixed. Another aspect is, is the static issues and the static issues whether that's in your os in your OS packages, for example, that could be key binaries that exist in your in your in your docker container out the box as well or of course in your application, these are again, areas that are extremely important to detect and they can be detected very very early. So some things, you know, if it's malware in a package that has been identified as malware then absolutely. That can be that can be tracked very very early. Sometimes these things need to be detected a little bit later as well. But yeah, different tools for different for different environments and wear sneak is really focused. Is this static analysis as early as possible. >>Great, great insight there. Thanks for sharing that certainly. Certainly important. And you know, some companies classes are locked down and all of sudden incomes, you know, some some malware from a container, people worried about that. So I want to bring that up. Uh The other thing I want to ask you is this idea of end to end security um and this is a team formation thing we're seeing where modern teams have essentially visibility of their workload and to end. So this is a huge topic. And then by the way it might integrate their their app might integrate with other processes to that's great for containers as well and observe ability and microservices. So this is the trend. What's in it for the developer? If I work with sneak and docker, what benefits do I get if I want to go down that road of having these teams began to end, but I want the security built in. >>Mhm. Yeah, really, really important. And I think what's what's most important there is if we don't look end to end, there are component views and there are applications. If we don't look into end, we could have our development team fixing things that realistically aren't in production anyway or aren't the key risks that are potentially hurting us in our production environment. So it's important to have that end to end of you so that we have the right insights and can prioritize what we need to identify and look at early. Um, so I think, I think that visibility into end is extremely important. If we think about who, who is re fixing uh certain issues, again, this is gonna depend from dog to walk, but what we're seeing more and more is this becoming a developer lead initiative to not just find or be given that information, but ultimately fixed. They're getting more and more responsible for DR files for for I see for for their application code as well. So one of the areas which we've looked into as well is identifying and actually running in cuba Netease workloads to identify where the most important areas that a developer needs to look at and this is all about prioritization. So, you know, if the developer has just a component view and they have 100 different images, 100 different kubernetes conflicts, you know, et cetera. Where do they prioritize, where do they spend their time? They shouldn't consider everything equal. So this identification of where the workloads are running and what um is causing you the most risk as a business and as an organization, that is the data. That can be directly fed back into your, your your vulnerability data and then you can prioritize based on the kubernetes workloads that are in your production and that can be fed directly into the results in the dashboards. That's neat. Can provide you as well. So that end to end story really provides the context you need in order to not just develop securely, but act and action issues in a proper way. >>That's a great point. Context matters here because making it easy to do the right thing as early as possible, the right time is totally an efficiency productivity gain, you see in that that's clearly what people want. It's a great formula, success, reduce the time it takes to do something, reduced the steps and make it easy. Right, come on, that's a that's a formula. Okay, so I gotta bring that to the next level. When I ask you specifically around automation, this is one the hot topic and def sec ops, automation is part of it. You got scale, you got speed, you've got a I machine learning, you go out of all these new things. Microservices, how do you guys fit into the automation story? >>It's a great question. And you know, one of the recent reports that we that we did based on a survey data this year called the state of a state of cloud, native applications security. We we asked the question how automated our people in their in their deployment pipelines and we found some really strong correlations between value from a security point of view um in terms of in terms of having that automation in it, if I can take you through a couple of them and then I'll address that question about how we can be automated in that. So what we found is a really strong correlation as you would expect with security testing in ci in your source code repositories and all the way through the deployment ci and source code were the two of the most most well tested areas across the pipeline. However the most automated teams were twice as likely to test in I. D. S. And testing your CLS in local development. And now those are areas that are really hard to automate if at all because it's developers running running their cli developers running and testing in their I. D. So the having a full automation and full uh proper testing throughout the sclc actually encourages and and makes developers test more in their development environment. I'm not saying there's causation there but there's definite correlation. A couple of other things that this pushes is um Much much more likely to test daily or continuously being automated as you would expect because it's part of the bills as part of your monitoring. But crucially uh 73% of our respondents were able to fix a critical issue in less than a week as opposed to just over 30% of people that were not automated, so almost double people are More likely to fix within a week. 36% of people who are automated can fix a critical security issue in less than a day as opposed to 8% of people who aren't automated. So really strong data that correlates being automated with being able to react now. If you look at something like Sneak what if our um goals of obviously being developer friendly developer first and being able to integrate where developers are and throughout the pipeline we want to test everywhere and often. Okay, so we start as far left as we can um integrating into, you know, CLS integrating into Docker hub, integrating into into doctors can so at the command line you type in doctors can you get sneak embedded in DHAKA desktop to provide you those results so as early as possible, you get that data then all the way through to to uh get reposed providing that testing and automatically testing and importing results from there as well as as well as other repositories, container repositories, being at a poor from there and test then going into ci being able to run container tests in C I to make sure we're not regressing and to choose what we want to do their whether we break, whether we continue with with raising an issue or something like that, and then continuing beyond that into production. So we can monitor tests and automatically send pull requests, etcetera. As and when new issues or new fixes occur. So it's about integrating at every single stage, but providing some kind of action. So, for example, in our ui we provide the ability to say this is the base level you should be or could be at, it will reduce your number of vulnerabilities by X and as a result you're going to be that much more secure that action ability across the pipeline. >>That's a great, great data dump, that's a masterclass right there on automation. Thanks for sharing that sign. I appreciate it. I gotta ask you the next question that comes to my mind because I think this is kind of the dots connect for the customer is okay. I love this kind of hyper focus on containers and security. You guys are all over it, shift left as far as possible, be there all the time, test, test, test all through the life cycle of the code. Well, the one thing that is popping up as a huge growth areas, obviously hybrid cloud devops across both environments and the edge, whether it's five G industrial or intelligent edge, you're gonna have kubernetes clusters at the edge now. So you've got containers. The relationship to kubernetes and then ultimately cloud native work clothes at, say, the edge, which has data has containers. So there's a lot of stuff going on all over the place. What's your, what's your comment there for customer says, Hey, you know, I got, this is my architecture that's happening to me now. I'm building it out. We're comfortable with kubernetes put in containers everywhere, even on the edge how to sneak fit into that story. >>Yeah, really, really great question. And I think, you know, a lot of what we're doing right now is looking at a developer platform. So we care about, we care about everything that a developer can check in. Okay, so we care about get, we care about the repositories, we care about the artifact. So um, if you look at the expansion of our platform today, we've gone from code that people uh, third party libraries that people test. We added containers. We've also added infrastructure as code. So Cuban eighties conflicts, Terror form scripts and things like that. We're we're able to look at everything that the developer touches from their code with sneak code all the way through to your to your container. And I see, so I think, you know, as we see more and more of this pushing out into the edge, cuba Nitties conflict that that, you know, controls a lot of that. So much of this is now going to be or not going to be, but so much of the environment that we need to look at is in the configurations or the MIS configurations in that in those deployment scripts, um, these are some of the areas which which we care a lot about in terms of trying to identify those vulnerabilities, those miS configurations that exist within within those scripts. So I can see yeah more and more of this and there's a potential shift like that across to the edge. I think it's actually really exciting to be able to see, to be able to see those uh, those pushing across. I don't necessarily see any other, any, you know, different security threats or the threat landscape changing as a result of that. Um there could be differences in terms of configurations, in terms of miS configurations that that that could increase as a result, but, you know, a lot of this and it just needs to be dealt with in the appropriate way through tooling through, through education of of of of how that's done. >>Well, obviously threat vectors are all gonna look devops like there's no perimeter. So they're everywhere right? Looking at I think like a hacker to be being there. Great stuff. Quick question on the future relationship with DR. Obviously you're betting a lot here on that container relationship, a good place to start. A lot of benefits there. They have dependencies, they're going to have implications. People love them, they love to use them, helps old run with the new and helps the new run better. Certainly with kubernetes, everything gets better together. What's the future with the DACA relationship? Take us through how you see it. >>So yeah, I mean it's been an absolute blast the doctor and you know, even from looking at some of the internal internal chats, it's been it's been truly wonderful to see the, the way in which both the doctor and sneak from everything from an engineering point of view from a marketing, from a product team. It's been a pleasure to, it's been a pleasure to see that relationship grow and flourish. And, and I think there's two things, first of all, I think it's great that as companies, we, we both worked very, very well together. I think as as as users um seeing, you know, doctor and and and sneak work so so seamlessly and integrated a couple of things. I would love to see. Um, I think what we're gonna see more and more and this is one of the areas that I think, um you know, looking at the way sneak is going to be viewing security in general. We see a lot of components scanning a lot, a lot of people looking at a components can and seeing vulnerabilities in your components. Can I think what we need to, to to look more upon is consolidating a lot of the a lot of the data which we have in and around different scans. What I would love to see is perhaps, you know, if you're running something through doctors can how can you how can you view that data through through sneak perhaps how can we get that closer integration through the data that we that we see. So I would love to see a lot more of that occur, you know, within that relationship and these are kind of like, you know, we're getting to that at that stage where we see integration, it just various levels. So we have the integration where we have we are embedded but how can we make that better for say a sneak user who also comes to the sneak pages and wants to see that data through sneak. So I would love to see at that level uh more there where as I mentioned, we have we have some some additional support as well. So you can run doctors can from from Lenox as well. So I can see more and more of that support rolling out but but yeah, in terms of the future, that's where I would love to see us uh to grow more >>and I'll see in the landscape side on the industry side, um, security is going beyond the multiple control planes out there. Kubernetes surveillance service matches, etcetera, continues to be the horizontally scalable cloud world. I mean, and you got you mentioned the edge. So a lot more complexity to rein in and make easier. >>Yeah, I mean there's a lot more complexity, you know, from a security point of view, the technology is the ability to move quickly and react fast in production actually help security a lot because you know, being able to spin a container and make changes and and bring a container down. These things just weren't possible, you know, 10 years ago, 20 years ago. Pre that it's like it was it's insanely hard compared trying to trying to do that compared to just re spinning a container up. However, the issue I see from a security point of view, the concerns I see is more around a culture and an education point of view of we've got all this great tech and it's it's awesome but we need to do it correctly. So making sure that as you mentioned with making the right decision, what we want to make sure is that right decision is also the easy decision and the clear decision. So we just need to make sure that as we as we go down this journey and we're going down it fast and it's not gonna, I don't see it slowing down, we're going fast down that journey. How do we make, how do we prepare ourselves for that? We're already seeing, you know, miss configurations left, right and center in the news, I am roles as three buckets, etcetera. These are they're they're simpler fixes than we than we believe, right? We just need to identify them and and make those changes as needed. So we just need to make sure that that is in place as we go forward. But it's exciting times for sure. >>It's really exciting. And you got the scanning and right at the point of coding automation to help take that basic mis configuration, take that off the table. Not a lot of manual work, but ultimately get to that cloud scale cool stuff. >>Simon, thank you >>for coming on the cube dr khan coverage. Really appreciate your time. Drop some nice commentary there. Really appreciate it. Thank you. >>My pleasure. Thank you very much. >>Simon Maple Field C T. O. A sneak hot startup. Big partner with Docker Security, actually built in deVOPS, is now dead. Say cops. This is dr khan cube 2021 virtual coverage. I'm sean for your host. Thanks for watching. Mm.

>>and hello, we're back. I've got my panel and we are doing things real time here. So sorry for the delay a few minutes late. So the way let's talk about things, the reason we're here and we're going around the room and introduce everybody. Got three special guests here. I got my evil or my john and the normal And we're going to talk about get ops I called it future office just because I want to think about what's the next thing for that at the end, we're gonna talk about what our ideas for what's next for getups, right? Um, because we're all starting to just get into get ups now. But of course a lot of us are always thinking about what's next? What's better? How can we make this thing better? So we're going to take your questions. That's the reason we're here, is to take your questions and answer them. Or at least the best we can for the next hour. And all right, so let's go around the room and introduce yourself. My name is Brett. I am streaming from Brett from that. From Brett. From Virginia Beach in Virginia beach, Virginia, United States. Um, and I talk about things on the internet, I sell courses on you, to me that talk about Docker and kubernetes Ive or introduce yourself. >>How's it going? Everyone, I'm a software engineer at axel Springer, currently based in Berlin and I happen to be Brett Brett's teaching assistant. >>All right, that's right. We're in, we're in our courses together almost every day. Mm john >>hey everyone, my name is john Harris, I used to work at Dhaka um, I now work at VM ware is a star field engineer. Um, so yeah, >>and normal >>awesome by the way, you are streaming from Brett Brett, >>I answered from breath to breath. >>Um I'm normal method. I'm a distinguished engineer with booz allen and I'm also a doctor captain and it's good to see either in person and it's good to see you again john it's been a little while. >>It has the pre covid times, right? You're up here in Seattle. >>Yeah. It feels, it feels like an eternity ago. >>Yeah, john shirt looks red and reminds me of the Austin T shirt. So I was like, yeah, so we all, we all have like this old limited edition doctor on E. >>T. That's a, that's a classic. >>Yeah, I scored that one last year. Sometimes with these old conference church, you have to like go into people's closets. I'm not saying I did that. Um, but you know, you have to go steal stuff, you to find ways to get the swag >>post post covid. If you ever come to my place, I'm going to have to lock the closets. That >>that's right, That's right. >>So the second I think it was the second floor of the doctor HQ in SAn Francisco was where they kept all the T shirts, just boxes and boxes and boxes floor to ceiling. So every time I went to HQ you just you just as many as you can fit in your luggage. I think I have about 10 of these. You >>bring an extra piece of luggage just for your your shirt shirt grab. Um All right, so I'm going to start scanning questions uh so that you don't have to you can you help you all are welcome to do that. And I'm going to start us off with the topic. Um So let's just define the parameters. Like we can talk about anything devops and here we can go down and plenty of rabbit holes. But the kind of, the goal here is to talk about get ups and get ups if you haven't heard about it is essentially uh using versioning systems like get like we've all been getting used to as developers to track your infrastructure changes, not just your code changes and then automate that with a bunch of tooling so that the robots take over. And essentially you have get as a central source of truth and then get log as a central source of history and then there's a bunch of magic little bits in the middle and then supposedly everything is wonderful. It's all automatic. The reality is is what it's often quite messy, quite tricky to get everything working. And uh the edges of this are not perfect. Um so it is a relatively new thing. It's probably three, maybe four years old as an official thing from. We've uh so we're gonna get into it and I'll let's go around the room and the same word we did before and um not to push on that, put you on the spot or anything. But what is, what is one of the things you either like or either hate about getups um that you've enjoyed either using it or you know, whatever for me. I really, I really love that I can point people to a repo that basically is hopefully if they look at the log a tracking, simplistic tracking of what might have changed in that part of the world or the environment. I remember many years past where, you know, I've had executive or some mid level manager wants to see what the changes were or someone outside my team went to see what we just changed. It was okay, they need access to this system into that dashboard and that spreadsheet and then this thing and it was always so complicated and now in a world where if we're using get up orbit bucket or whatever where you can just say, hey go look at that repo if there was three commits today, probably three changes happened. That's I love that particular part about it. Of course it's always more complicated than that. But um Ive or I know you've been getting into this stuff recently. So um any thoughts? Yeah, I think >>my favorite part about get ops is >>reproducibility. Um >>you know the ability to just test something and get it up and running >>and then just tear it down. >>Uh not >>being worried that how did I configure it the first time? I think that's my favorite part about >>it. I'm changing your background as we do this. >>I was going to say, did you just do it get ups pushed to like change his >>background, just a dialogue that different for that green screen equals false? Uh Change the background. Yeah, I mean, um and I mean I think last year was really my first year of actually using it on anything significant, like a real project. Um so I'm still, I still feel like I'm very new to john you anything. >>Yeah, it's weird getups is that thing which kind of crystallizes maybe better than anything else, the grizzled veteran life cycle of emotions with the technology because I think it's easy to get super excited about something new. And when I first looked into get up, so I think this is even before it was probably called getups, we were looking at like how to use guest source of truth, like everything sounds great, right? You're like, wait, get everyone knows, get gets the source of truth, There's a load of robust tooling. This just makes a sense. If everything dies, we can just apply the get again, that would be great. Um and then you go through like the trough of despair, right? We're like, oh no, none of this works. The application is super stateless if this doesn't work and what do we do with secrets and how do we do this? Like how do we get people access in the right place and then you realize everything is terrible again and then everything it equalizes and you're kind of, I think, you know, it sounds great on paper and they were absolutely fantastic things about it, but I think just having that measured approach to it, like it's, you know, I think when you put it best in the beginning where you do a and then there's a magic and then you get C. Right, like it's the magic, which is >>the magic is the mystery, >>right? >>Magic can be good and bad and in text so >>very much so yeah, so um concurrence with with john and ever uh in terms of what I like about it is the potential to apply it to moving security to left and getting closer to a more stable infrastructures code with respect to the whole entire environment. Um And uh and that reconciliation loop, it reminds me of what, what is old is new again? Right? Well, quote unquote old um in terms of like chef and puppet and that the reconciliation loop applied in a in a more uh in a cleaner interface and and into the infrastructure that we're kind of used to already, once you start really digging into kubernetes what I don't like and just this is in concurrence with the other Panelist is it's relatively new. It has um, so it has a learning curve and it's still being, you know, it's a very active um environment and community and that means that things are changing and constantly and there's like new ways and new patterns as people are exploring how to use it. And I think that trough of despair is typically figuring out incrementally what it actually is doing for you and what it's not going to solve for you, right, john, so like that's that trough of despair for a bit and then you realize, okay, this is where it fits potentially in my architecture and like anything, you have to make that trade off and you have to make that decision and accept the trade offs for that. But I think it has a lot of promise for, for compliance and security and all that good stuff. >>Yeah. It's like it's like the potentials, there's still a lot more potential than there is uh reality right now. I think it's like I feel like we're very early days and the idea of especially when you start getting into tooling that doesn't appreciate getups like you're using to get up to and use something else and that tool has no awareness of the concept so it doesn't flow well with all of the things you're trying to do and get um uh things that aren't state based and all that. So this is going to lead me to our first question from Camden asking dumb questions by the way. No dumb questions here. Um How is get apps? Not just another name for C. D. Anybody want to take that as an answer as a question. How is get up is not just another name for C. D. I have things but we can talk about it. I >>feel like we need victor foster kids. Yeah, sure you would have opinions. Yeah, >>I think it's a very yeah. One person replied said it's a very specific it's an opinionated version of cd. That's a great that's a great answer like that. Yeah. >>It's like an implement. Its it's an implementation of deployment if you want it if you want to use it for that. All right. I realize now it's kind of hard in terms of a physical panel and a virtual panel to figure out who on the panel is gonna, you know, ready to jump in to answer a question. But I'll take it. So um I'll um I'll do my best inner victor and say, you know, it's it's an implementation of C. D. And it's it's a choice right? It's one can just still do docker build and darker pushes and doctor pulls and that's fine. Or use other technologies to deploy containers and pods and change your, your kubernetes infrastructure. But get apps is a different implementation, a different method of doing that same thing at the end of the day. Yeah, >>I like it. I like >>it and I think that goes back to your point about, you know, it's kind of early days still, I think to me what I like about getups in that respect is it's nice to see kubernetes become a platform where people are experimenting with different ways of doing things, right? And so I think that encourages like lots of different patterns and overall that's going to be a good thing for the community because then more, you know, and not everything needs to settle in terms of only one way of doing things, but a lot of different ways of doing things helps people fit, you know, the tooling to their needs, or helps fit kubernetes to their needs, etcetera. Yeah, >>um I agree with that, the, so I'm gonna, since we're getting a load of good questions, so um one of the, one of the, one of the, I want to add to that real quick that one of the uh from the, we've people themselves, because I've had some on the show and one of things that I look at it is distinguishing is with continuous deployment tools, I sort of think that it's almost like previous generation and uh continuous deployment tools can be anything like we would consider Jenkins cd, right, if you if you had an association to a server and do a doctor pull and you know, dr up or dr composed up rather, or if it did a cube control apply uh from you know inside an ssh tunnel or something like that was considered considered C. D. Well get ops is much more rigid I think in terms of um you you need to apply, you have a specific repo that's all about your deployments and because of what tool you're using and that one your commit to a specific repo or in a specific branch that repo depends on how you're setting it up. That is what kicks off a workflow. And then secondly there's an understanding of state. So a lot of these tools now I have uh reconciliation where they they look at the cluster and if things are changing they will actually go back and to get and the robots will take over and will commit that. Hey this thing has changed um and you maybe you human didn't change it, something else might have changed it. So I think that's where getups is approaching it, is that ah we we need to we need to consider more than just a couple of commands that be runnin in a script. Like there needs to be more than that for a getups repo to happen anyway, that's just kind of the the take back to take away I took from a previous conversation with some people um >>we've I don't think that lost, its the last piece is really important, right? I think like for me, C d like Ci cd, they're more philosophical ideas, write a set of principles, right? Like getting an idea or a code change to environments promoting it. It's very kind of pipeline driven um and it's very imperative driven, right? Like our existing CD tools are a lot of the ways that people think about Cd, it would be triggered by an event, maybe a code push and then these other things are happening in sequence until they either fail or pass, right? And then we're done. Getups is very much sitting on the, you know, the reconciliation side, it's changing to a pull based model of reconciliation, right? Like it's very declarative, it's just looking at the state and it's automatically pulling changes when they happen, rather than this imperative trigger driven model. That's not to say that there aren't city tools which we're doing pull based or you can do pull based or get ups is doing anything creatively revolutionary here, but I think that's one of the main things that the ideas that are being introduced into those, like existing C kind of tools and pipelines, um certainly the pull based model and the reconciliation model, which, you know, has a lot in common with kubernetes and how those kind of controllers work, but I think that's the key idea. Yeah. >>Um This is a pretty specific one Tory asks, does anyone have opinions about get ops in a mono repo this is like this is getting into religion a little bit. How many repos are too many repose? How um any thoughts on that? Anyone before I rant, >>go >>for it, go for it? >>Yeah. How I'm using it right now in a monitor repo uh So I'm using GIT hub. Right, so you have what? The workflow and then inside a workflow? Yeah, mo file, I'll >>track the >>actual changes to the workflow itself, as well as a folder, which is basically some sort of service in Amman Arepa, so if any of those things changes, it'll trigger the actual pipeline to run. So that's like the simplest thing that I could figure out how to, you know, get it set up using um get hubs, uh workflow path future. Yeah. And it's worked for me for writing, you know? That's Yeah. >>Yeah, the a lot of these things too, like the mono repo discussion will, it's very tool specific. Each tool has various levels of support for branch branching and different repos and subdirectories are are looking at the defense and to see if there's changes in that specific directory. Yeah. Sorry, um john you're going to say something, >>I was just going to say, I've never really done it, but I imagine the same kind of downsides of mono repo to multiple report would exist there. I mean, you've got the blast radius issues, you've got, you know, how big is the mono repo? Do we have to pull does the tool have to pull that or cashier every time it needs to determine def so what is the support for being able to just look at directories versus you know, I think we can get way down into a deeper conversation. Maybe we'll save it for later on in the conversation about what we're doing. Get up, how do we structure our get reposed? We have super granular repo per environment, Perper out reaper, per cluster repo per whatever or do we have directories per environment or branches per environment? How how is everything organized? I think it's you know, it's going to be one of those, there's never one size fits all. I'll give the class of consultant like it depends answer. Right? >>Yeah, for sure. It's very similar to the code struggle because it depends. >>Right? >>Uh Yeah, it's similar to the to the code problem of teams trying to figure out how many repose for their code. Should they micro service, should they? Semi micro service, macro service. Like I mean, you know because too many repose means you're doing a bunch of repo management, a bunch of changes on your local system, you're constantly get pulling all these different things and uh but if you have one big repo then it's it's a it's a huge monolithic thing that you usually have to deal with. Path based issues of tools that only need to look at a specific directory and um yeah, it's a it's a culture, I feel like yeah, like I keep going back to this, it's a culture thing. Does your what is your team prefer? What do you like? What um what's painful for everyone and who's what's the loudest pain that you need to deal with? Is it is it repo management? That's the pain um or is it uh you know, is that that everyone's in one place and it's really hard to keep too many cooks out of the kitchen, which is a mono repo problem, you know? Um How do we handle security? So this is a great one from Tory again. Another great question back to back. And that's the first time we've done that um security as it pertains to get up to anyone who can commit can change the infrastructure. Yes. >>Yes. So the tooling that you have for your GIT repo and the authentication, authorization and permissions that you apply to the GIT repo using a get server like GIT hub or get lab or whatever your flavor of the day is is going to be how security is handled with respect to changes in your get ups configuration repository. So um that is completely specific to your implementation of that or ones implementation of of how they're handling that. Get repositories that the get ups tooling is looking at. To reconcile changes with respect to the permissions of the for lack of better term robot itself. Right? They get up tooling like flux or Argosy. D Um one kid would would create a user or a service account or uh other kind of authentication measures to limit the permissions for that service account that the Gaddafi's tooling needs to be able to read the repose and and send commits etcetera. So that is well within the realm of what you have already for your for your get your get um repo. Yeah. >>Yeah. A related question is from a g what they like about get apps if done nicely for a newbie it's you can get stuff done easily if you what they dislike about it is when you have too many get repose it becomes just too complicated and I agree. Um was making a joke with a team the other week that you know the developer used to just make one commit and they would pass pass it on to a QA team that would then eventually emerging in the master. But they made the commits to these feature branches or whatever. But now they make a commit, they make a pR there for their code then they go make a PR in the helm chart to update the thing to do that and then they go make a PR in the get ups repeal for Argo. And so we talked about that they're probably like four or five P. R. Is just to get their code in the production. But we were talking about the negative of that but the reality was It's just five or 4 or five prs like it wasn't five different systems that had five different methodologies and tooling and that. So I looked at it I was like well yeah that's kind of a pain in the get sense but you're also dealing with one type. It's a repetitive action but it's it's the one thing I don't have to go to five different systems with five different ways of doing it. And once in the web and one's on the client wants a command line that I don't remember. Um Yeah so it's got pros and cons I think when you >>I think when you get to the scale where those kind of issues are a problem then you're probably at the scale where you can afford to invest some time into automation into that. Right? Like what I've when I've seen this in larger customers or larger organizations if there ever at that stage where okay apps are coming up all the time. You know, there's a 10 X 100 X developer to operations folks who may be creating get repose setting up permissions then that stuff gets automated, right? Like, you know, maybe ticket based systems or whatever. Developers say I need a new app. It templates things or more often using the same model, right of reconciliation and operators and the horrific abuse of cogs that we're seeing in the communities community right now. Um You know, developers can create a crd which just says, hey, I'm creating a new app is called app A and then a controller will pick up that app a definition. It will go create a get a repo Programmatically it will add the right definitely will look up and held up the developers and the permissions that need to be able to get to that repo it will create and template automatically some name space and the clusters that it needs in the environments that it needs, depending on, you know, some metadata it might read. So I think, you know, those are definite problems and they're definitely like a teething, growing pain thing. But once you get to that scale, you kind of need to step back and say, well look, we just need to invest in time into the operational aspect of this and automating this pain away, I think. Yeah, >>yeah. And that ultimately ends in Yeah. Custom tooling, which it's hard to avoid it at scale. I mean, there's there's two, there's almost two conversations here, right. There is what I call the Solo admin Solo devops, I bought that domain Solo devops dot com because, you know, whenever I'm talking to dr khan in the real world, it's like I asked people to raise hands, I don't know how we can raise hands here, but I would ask people to raise hands and see how many of you here are. The sole person responsible for deploying the app that your team makes and like a quarter of the room would raise their hand. So I call that solo devops like those, that person can't make all the custom tooling in the world. So they really need dr like solutions where it's opinionated, the workflow is sort of built in and they don't have to wrangle things together with a bunch of glue, you know, in other words bash. Um and so this kind of comes to a conversation uh starting this question from lee he's asking how do you combine get ops with ci cd, especially the continuous bit. How do you avoid having a human uh sort of the complaint the team I was working with has, how do you avoid a human editing and get committing for every single deploy? They've settled on customized templates and a script for routine updates. So as a seed for this conference, this question I'm gonna ask you all uh instead of that specific question cause it's a little open ended. Um Tell me whether you agree with this. I I kind of look at the image, the image artifact because the doctor image or container image in general is an artifact that I I view it that way and that thing going into the registry with the right label or right part of the label. Um That tag rather not the label but the tag that to me is like one of the great demarche points of, we're kind of done with Ci and we're now into the deployment phase and it doesn't necessarily mean the tooling is a clear cut there, but that artifact being shipped in a specific way or promoted as we sometimes say. Um what do you think? Does anyone have opinions on that? I don't even know if that's the right opinion to have so mhm. >>So um I think what you're, what you're getting at is that get ups, models can trigger off of different events um to trigger the reconciliation loop. And one way to do that is if the image, if it notices a image change in the registry, the other is if there's a commit event on a specific rebo and branch and it's up to, you are up to the person that's implementing their get ups model, what event to trigger there, that reconciliation loop off of, You can do both, you can do one or the other. It also depends on the Templeton engine that you're using on top of um on top of kubernetes, such as helm or um you know, the other ones that are out there or if you're not even doing that, then, you know straight. Yeah, mo um so it kind of just depends, but those are the typically the two options one has and a combination of of those to trigger that event. You can also just trigger it manually, right? You can go into the command line and force a a, you know, a really like a scan or a new reconciliation loop to occur. So it kind of just, I don't want to say this, but it depends on what you're trying to do and what makes sense in your pipeline. Right? So if you're if you're set up where you are tag, if you're doing it based off of image tags, then you probably want to use get ups in a way that you're using the image tags. Right. And the pattern that you've established there, if you're not really doing that and you're more around, like, different branches are mapped to different environments, then triggered off of the correct branch. And that's where the permissions also come into play. Where if you don't want someone to touch production and you've got your getups for your production cluster based off of like uh you know, a main branch, then whoever can push a change to that main branch has the authority to push that change to production. Right? So that's your authentication and permissions um system same for the registry itself. Right. So >>Yeah. Yeah. Sorry, anyone else have any thoughts on that? I was about to go to the next topic, >>I was going to say. I think certain tools dictate the approach, like, if you're using Argosy d it's I think I'm correct me if I'm wrong, but I think the only way to use it right now is just through image modification. Like, the manifest changes, it looks at a specific directory and anything changes then it will do its thing. And uh Synchronize the cost there with whatever's and get >>Yeah, flux has both. Yeah, and flux has both. So it it kind of depends. I think you can make our go do that too, but uh this is back to what we were saying in the beginning, uh you know, these things are changing, right? So that might be what it is right now in terms of triggering the reconciliation loops and get ups, tooling, but there might be other events in the future that might trigger it, and it's not completely stand alone because you still need you're tooling to do any kind of testing or whatever you have in terms of like the specific pipeline. So oftentimes you're bolting in getups into some other part of broader Cfd solution. That makes sense. Yeah, >>we've got a lot of questions about secrets or people that are asking about secrets. >>So my my tongue and cheek answered the secrets question was, what's the best practices for kubernetes? Secrets? That's the same thing for secrets with good apps? Uh getups is not last time I checked and last time I was running this stuff get ups is not has nothing to do with secrets in that sense. It's just there to get your stuff running on communities. So, um there's probably a really good session on secrets at dr concept. I >>would agree with you, I agree with you. Yeah, I mean, get off stools, I mean every every project of mine handles secrets differently. Uh huh. And I think I'm not sure if it was even when I was talking to but talking to someone recently that I'm very bullish on get up actions, I love get up actions, it's not great for deployments yet, but we do have this new thing and get hub environments, I think it's called. So it allows me at least the store secrets per environment, which it didn't have the concept of that before, which you know, if you if any of you running kubernetes out there, you typically end up when you start running kubernetes, you end up with more than one kubernetes, like you're going to end up with a lot of clusters at some point, at least many multiple, more than two. Um and so if you're trying to store secret somewhere, you do have and there's a discussion happening in chat right now where people are talking about um sealed secrets which if you haven't heard of that, go look that up and just be versed on what sealed secrets is because it's a it's a fantastic concept for how to store secrets in the public. Um I love it because I'm a big P. K. I nerd but um it's not the only way and it doesn't fit all models. So I have clients that use A W. S. Secrets because they're in A W. S. And then they just have to use the kubernetes external secret. But again like like like normal sand, you know, it's that doesn't really affect get ops, get ops is just applying whatever helm charts or jahmal or images that you're, you're you're deploying, get off. It was more about the approach of when the changes happen and whether it's a push or pull model like we're talking about and you know, >>I would say there's a bunch of prerequisites to get ups secrets being one of them because the risk of you putting a secret into your git repo if you haven't figured out your community secrets architecture and start diving into getups is high and removing secrets from get repose is you know, could be its own industry, right. It's >>a thing, >>how do >>I hide this? How do I obscure this commit that's already now on a dozen machines. >>So there are some prerequisites in terms of when you're ready to adopt get up. So I think is the right way of saying the answer to that secrets being one of them. >>I think the secrets was the thing that made me, you know, like two or three years ago made me kind of see the ah ha moment when it came to get ups which, which was that the premier thing that everyone used to say about get up about why it was great. Was its the single source of truth. There's no state anywhere else. You just need to look at git. Um and then secrets may be realized along with a bunch of other things down the line that is not true and will never be true. So as soon as you can lose the dogmatism about everything is going to be and get it's fantastic. As long as you've understood everything is not going to get. There are things which will absolutely never be and get some tools just don't deal with that. They need to earn their own state, especially in communities, some controls on their own state. You know, cuz sealed secrets and and other projects like SOps and I think there are two or three others. That's a great way of dealing with secrets if you want to keep them in get. But you know, projects like vault more kind of like what I would say, production grade secret strategies. Right? And if you're in AWS or a cloud, you're more likely to be using their secrets. Your secret policy is maybe not dictated by you in large organizations might be dictated by CSO or security or Great. Like I think once if you, if you're trying to adopt getups or you're thinking about it, get the dogmatism of get as a single point of truth out of your mind and think about getups more as a philosophy and a set of best practice principles, then you will be in much better stead, >>right? Yeah. >>People are asking more questions in chat like infrastructure as code plus C d essentially get ups or C I rather, um, these are all great questions and a part of the debate, I'm actually just going to throw up on screen. I'm gonna put this in chat, but this is, this is to me the source, Right? So we worked with when they coined the term. We, a lot of us have been trying to get, if we talk about the history for a minute and then tell me if I'm getting this right. Um, a lot of us were trying to automate all these different parts of the puzzle, but a lot of them, they, some things might have been infrastructure as code. Some things weren't, some things were sort of like settings is coded, like you're going to Jenkins and type in secrets and settings or type in a certain thing in the settings of Jenkins and then that it wasn't really in get and so what we was trying to go for was a way to have almost like eventually a two way state understanding where get might change your infrastructure but then your infrastructure might also change and needs to be reflected in the get if the get is trying to be the single source of truth. Um and like you're saying the reality is that you're never gonna have one repo that has all of your infrastructure in it, like you would have to have, you have to have all your terra form, anything else you're spinning up. Right. Um but anyway, I'm gonna put this link in chat. So this guide actually, uh one of things they talk about is what it's not, so it's, it's kind of great to read through the different requirements and like what I was saying well ago um mhm. Having having ci having infrastructure as code and then trying a little bit of continuous deployment out, it's probably a prerequisite. Forget ops so it's hard to just jump into that when you don't already have infrastructure as code because a machine doing stuff on your behalf, it means that you have to have things documented and somewhere and get repo but let me put this in the in the >>chitty chat, I would like to know if the other panelists agree, but I think get apps is a okay. I would say it's a moderate level, it's not a beginner level communities thing, it's like a moderate level advanced, a little bit more advanced level. Um One can start off using it but you definitely have to have some pre recs in place or some understanding of like a pattern in place. Um So what do the other folks think about that opinion? >>I think if you're if you're trying to use get out before, you know what problem you have, you're probably gonna be in trouble. Right. It's like having a solution to it probably don't have yet. Mhm. Right. I mean if if you're just evil or and you're just typing, keep control apply, you're one person right, Get off. It doesn't seem like a big a big jump, like, I mean it doesn't like why would I do that? I'm just, I'm just gonna inside, it's the type of get commit right, I'm typing Q control apply. But I think one of the rules from we've is none of your developers and none of your admins can have cute control access to the cluster because if you can't, if you do have access and you can just apply something, then that's just infrastructure as code. That's just continuous deployment, that's, that's not really get ops um, getups implies that the only way things get into the cluster is through the get up, get automation that you're using with, you know, flux Argo, we haven't talked about, what's the other one that Victor Farsi talks about, by the way people are asking about victor, because victor would love to talk about this stuff, but he's in my next life, so come back in an hour and a half or whatever and victor is going to be talking about sys, admin list with me. Um >>you gotta ask him nothing but get up questions in the next, >>confuse them, confuse them. But anyway, that, that, that's um, it's hard, it's hard to understand and without having tried it, I think conceptually it's a little challenging >>one thing with getups, especially based off the we've works blog post that you just put up on there. It's an opinionated way of doing something. Uh you know, it's an opinionated way of of delivering changes to an environment to your kubernetes environment. So it's opinionated were often not used to seeing things that are very opinionated in this sense, in the in the ecosystem, but get apps is a opinionated thing. It's it's one way of doing it. Um there are ways to change it and like there are options um like what we were talking about in terms of the events that trigger, but the way that it's structured is an opinion opinionated way both from like a tooling perspective, like using get etcetera, but also from a devops cultural perspective, right? Like you were talking about not having anyone access cube control and changing the cluster directly. That's a philosophical opinion that get ups forces you to adopt otherwise. It kind of breaks the model and um I just I want everyone to just understand that. That is very opinion, anything in that sense. Yeah, >>polygamy is another thing. Infrastructure as code. Um someone's mentioning plummy and chat, I just had actually my life show self plug bread that live go there. I'm on Youtube every week. I did the same thing. These these are my friends um and had palami on two weeks ago uh last week, remember uh and it was in the last couple of weeks and we talked about their infrastructure as code solution. Were actually writing code instead of um oh that's an interesting take on uh developer team sort of owning coding the infrastructure through code rather than Yamil as a data language. I don't really have an opinion on it yet because I haven't used it in production or anything in the real real world, but um, I'm not sure how much they are applying trying to go towards the get up stuff. I will do a plug for Solomon hikes. Who has a, the beginning of the day, it's already happened so you can go back and watch it. It's a, it's a, what's it called? Q. Rethinking application delivery with Q. And build kit. So go look this up. This is the found co founder of Dr and former CTO Solomon hikes at the beginning of the day. He has a tool called dagger. I'm not sure why the title of the talk is delivering with Q. And built it, but the tool is showing off in there for an hour is called dagger. And it's, it's an interesting idea on how to apply a lot of this opinionated automated stuff to uh, to deployment and it's get off space and you use Q language. It's a graph language. I watched most of it and it was a really interesting take. I'm excited to see if that takes off and if they try that because it's another way that you can get a little bit more advanced with your you're get deployments and without having to just stick everything in Yemen, which is kind of what we're in today with helm charts and what not. All right. More questions about secrets, I think. I think we're not going to have a whole lot of more, a lot more about secrets basically. Uh put secrets in your cluster to start with and kubernetes in encrypted, you know, thing. And then, you know, as it gets harder, then you have to find another solution when you have five clusters, you don't wanna have to do it five times. That's when you have to go for Walton A W. S secrets and all >>that. Right? I'm gonna post it note. Yeah. Crm into the cluster. Just kidding. >>Yes, there are recordings of this. Yes, they will be later. Uh, because we're that these are all gonna be on youtube later. Um, yeah, detects secrets cushion saying detect secrets or get Guardian are absolute requirements. I think it's in reference to your secrets comment earlier. Um, Camels asking about Cuban is dropping support for Docker that this is not the place to ask for that, but it, it is uh, basically it's a Nonevent Marantz has actually just created that same plug in available in a different repos. So if you want to keep using Docker and kubernetes, you know, you can do it like it's no big deal. Most of us aren't using doctor in our communities anyway, so we're using like container D or whatever is provided to us by our provider. Um yeah, thank you so much for all these comments. These are great people helping each other and chat. I feel like we're just here to make sure the chats available so people can help each other. >>I feel like I want to pick up on something when you mentioned pollux me, I think there's a um we're talking about getups but I think in the original like the origination of that I guess was deploying applications to clusters right, picking up deployment manifest. But I think with the gloomy and I obviously terra form and things have been around a long time, folks are starting to apply this I think I found one earlier which was like um kub stack the Terror Forms get ups framework. Um but also with the advent of things like cluster A. P. I. Um in the Cuban at the space where you can declare actively build the infrastructure for your clusters and build the cluster right? We're not just talking about deploying applications, the cluster A. P. I will talk to a W. S. Spin up, VPc spin up machines, you know, we'll do the same kind of things that terra form does and and those other tools do I think applying getups principles to the infrastructure spin up right, the proper infrastructure as code stuff, constantly applying Terror form um you know, plans and whatever, constantly applying cluster Api resources spinning up stuff in those clouds. That's a super interesting. Um you know, extension of this area, I'd be curious to see if what the folks think about that. >>Yeah, that's why I picked this topic is one of my three. Uh I got I got to pick the topics. I was like the three things that there like the most bleeding edge exciting. Most people haven't, we haven't basically we haven't figured all this out yet. We as an industry, so um it's I think we're gonna see more ideas on it. Um what's the one with the popsicle as the as the icon victor talks about all the time? It's not it's another getups like tool, but it's um it's getups for you use this kubernetes limit and then we have to look it up, >>You're talking about cross plane. >>So >>my >>wife is over here with the sound effects and the first sound effect of the day that she chooses to use is one. >>All right, can we pick it? Let's let's find another question bret >>I'm searching >>so many of them. All right, so uh I think one really quick one is getups only for kubernetes, I think the main to tooling to tools that we're talking about, our Argosy D and flux and they're mostly geared toward kubernetes deployments but there's a, it seems like they're organized in a way that there's a clean abstraction in with respect to the agent that's doing the deployment and the tooling that that can interact with. So I would imagine that in the future and this might be true already right now that get ups could be applied to other types of deployments at some point in the future. But right now it's mostly focused and treats kubernetes as a first class citizen or the tooling on top of kubernetes, let's say something like how as a first class citizen? Yeah, to Brett, >>to me the field, back to you bret the thing I was looking for is cross plane. So that's another tool. Um Victor has been uh sharing a lot about it in Youtube cross plane and that is basically runs inside a kubernetes, but it handles your other infrastructure besides your app. It allows you to like get ops, you're a W. S stuff by using the kubernetes state engine as a, as a way to manage that. And I have not used it yet, but he does some really great demos on Youtube. So people are liking this idea of get off, so they're trying to figure out how do we, how do we manage state? How do we uh because the probably terra form is that, well, there's many problems, but it's always a lot of problems, but in the get outs world it's not quite the right fit yet, It might be, but you still, it's still largely as expected for people to, you know, like type the command, um, and it keeps state locally the ss, clouds and all that. And but the other thing is I'm I'm now realizing that when I saw the demo from Solomon, I'm going back to the Solomon hikes thing. He was using the demo and he was showing it apply deploying something on S three buckets, employing internet wifi and deploying it on google other things beyond kubernetes and saying that it's all getups approach. So I think we're just at the very beginning of seeing because it all started with kubernetes and now there's a swarm one, you can look up swarm, get office and there's a swarm, I can't take the name of it. Swarm sink I think is what's called swarm sink on git hub, which allows you to do swarm based getups like things. And now we're seeing these other tools coming out. They're saying we're going to try to do the get ups concepts, but not for kubernetes specifically and that's I think, you know, infrastructure as code started with certain areas of the world and then now then now we all just assume that you're going to have an infrastructure as code way of doing whatever that is and I think get off is going to have that same approach where pretty soon, you know, we'll have get apps for all the clouds stuff and it won't just be flexor Argo. And then that's the weird thing is will flex and Argo support all those things or will it just be focused on kubernetes apps? You know, community stuff? >>There's also, I think this is what you're alluding to. There is a trend of using um kubernetes and see rDS to provision and control things that are outside of communities like the cloud service providers services as if they were first class entities within kubernetes so that you can use the kubernetes um focus tooling for things that are not communities through the kubernetes interface communities. Yeah, >>yeah, even criticism. >>Yeah, yeah, I'm just going to say that sounds like cross plane. >>Yeah, yeah, I mean, I think that's that's uh there were, you know, for the last couple of years, it's been flux and are going back and forth. Um they're like frenemies, you know, and they've been going back and forth with iterating on these ideas of how do we manage this complicated thing? That is many kubernetes clusters? Um because like Argo, I don't know if the flux V two can do this, but Argo can manage multiple clusters now from one cluster, so your, you can manage other clusters, technically external things from a single entity. Um Originally flux couldn't do that, but I'm going to say that V two can, I don't actually >>know. Um I think all that is gonna, I think that's going to consolidate in the future. All right. In terms of like the common feature set, what Iver and john what do you think? >>I mean, I think it's already begun, right, I think haven't, didn't they collaborate on a common engine? I don't know whether it's finished yet, but I think they're working towards a common getups engine and then they're just going to layer on features on top. But I think, I mean, I think that's interesting, right, because where it runs and where it interacts with, if we're talking about a pull based model, it shouldn't, it's decentralized to a certain extent, right? We need get and we need the agent which is pulling if we're saying there's something else which is orchestrating something that we start to like fuzzy the model even right. Like is this state living somewhere else, then I think that's just interesting as well. I thought flux was completely decentralized, but I know you install our go somewhere like the cargo has a server as well, but it's been a while since I've looked in depth at them. But I think the, you know, does that muddy the agent only pull model? >>I'm reading a >>Yeah, I would say that there's like a process of natural selection going on as as the C. N. C. F. Landscape evolves and grows bigger and a lot of divide and conquer right now. But I think as certain things kind of get more prominent >>and popular, I think >>it starts to trend and it inspires other things and then it starts to aggregate and you know, kind of get back into like a unified kind of like core. Maybe like for instance, cross plane, I feel like it shouldn't even really exist. It should be, it like it's a communities add on, but it should be built in, it should be built into kubernetes, like why doesn't this exist already >>for like controlling a cloud? >>Yeah, like just, you know, having this interface with the cloud provider and be able to Yeah, >>exactly. Yeah, and it kinda, you're right. That kinda happens because you do, I mean when you start talking about storage providers and networking providers was very specific implementations of operators or just individual controllers that do operate and control other resources in the cloud, but certainly not universally right. Not every feature of AWS is available to kubernetes out of the box. Um and you know, it, one of the challenges across plane is you gotta have kubernetes before you can deploy kubernetes. Like there's a chicken and egg issue there where if you're going to use, if you're going to use our cross plane for your other infrastructure, but it's gotta, but it has to run on kubernetes who creates that first kubernetes in order for you to put that on there. And victor talks about one of his videos, the same problem with flux and Argo where like Argo, you can't deploy Argo itself with getups. There has to be that initial, I did a thing with, I'm a human and I typed in some commands on a server and things happened but they don't really have an easy deployment method for getting our go up and running using simply nothing but a get push to an existing system. There's something like that. So it's a it's an interesting problem of day one infrastructure which is again only day one, I think data is way more interesting and hard, but um how can we spend these things up if they're all depending on each other and who is the first one to get started? >>I mean it's true of everything though, I mean at the end of that you need some kind of big bang kind of function too, you know, I started running start everything I >>think without going over that, sorry, without going off on a tangent. I was, I was gonna say there's a, if folks have heard of kind which is kubernetes and Docker, which is a mini kubernetes cluster, you can run in a Docker container or each container will run as a as a node. Um you know, that's been a really good way to spin up things like clusters. KPI because they boot strap a local kind, install the manifests, it will go and spin up a fully sized cluster, it will transfer its resources over there and then it will die itself. Right? So that, that's kind of bootstrapping itself. And I think a couple of folks in the community, Jason to Tiberius, I think he works for Quinyx metal um has, has experimented with like an even more minimal just Api server, so we're really just leveraging the kubernetes ideas of like a reconciliation loop and a controller. We just need something to bootstrap with those C R D s and get something going and then go away again. So I think that's gonna be a pattern that comes up kind of more and more >>Yeah, for sure. Um, and uh, the next, next quick answer to the question, Angel asked what your thoughts on getups being a niche to get or versus others vcs tools? Well, if I knew anyone who is using anything other than get, I would say no, you know, get ops is a horrible name. It should just be CVS office, but that doesn't or vcs ops or whatever like that, but that doesn't roll off the tongue. So someone had to come up with the get ups phrase. Um but absolutely, it's all about version control solutions used for infrastructure, not code. Um might get doctor asks a great question, we're not gonna have time for it, but maybe people can reply and chat with what they think but about infrastructure and code, the lines being blurred and that do develop, how much of infrastructure does developer do developers need to know? Essentially, they're having to know all the things. Um so unfortunately we've had way more questions like every panel here today with all the great community, we've got way more questions we can handle in this time. So we're gonna have to wrap it up and say goodbye. Go to the next live panel. I believe the next one is um on developer, developer specific setups that's gonna be peter running that panel. Something about development in containers and I'm sure it's gonna be great. Just like this one. So let's go around the room where can people find you on the internet? I'm at Brett fisher on twitter. That's where you can usually find me most days you are? >>Yeah, I'm on twitter to um, I'll put it in the chat. It's kind of confusing because the TSR seven. >>Okay. Yeah, that's right. You can't just say it. You can also look at the blow of the video and like our faces are there and if you click on them, it tells you our twitter in Arlington and stuff, john >>John Harris 85, pretty much everywhere. Get hub Twitter slack, etc. >>Yeah >>and normal, normal faults or just, you know, living on Youtube live with Brett. >>Yeah, we're all on the twitter so go check us out there and thank you so much for joining. Uh thank you so much to you all for being here. I really appreciate you taking time in your busy schedule to join me for a little chit chat. Um Yes, all the, all the cheers, yes. >>And I think this kid apps loop has been declarative lee reconciled. >>Yeah, there we go. And with that ladies and gentlemen, uh bid you would do, we will see you in the next, next round coming up next with Peter >>bye.

>>Welcome welcome back to the cubes coverage of dr khan 2021. I'm john for a host of the cube. We're here to talk about observe ability in the enterprise, enabling developers. Fabian lang VP of engineering and co founder of Istana, now part of IBM. Fabian, Congratulations on everything and great to have you on the cube here for dr gone. >>Thank you. Thanks for having me. >>So I'm in Palo Alto, you're in Germany were doing the remote thing obviously virtual second year in a row for dr khan. Soon real life is coming back. Uh no real impact of developers as they continue to be more productive than ever. The hottest conversation topic being discussed, being funded by venture capitalists and private equity is observe ability. This is an area you guys are playing in aggressively and you got some product observe ability. What's the big deal about Docker con Docker containers observe ability kubernetes, Why is observe ability at the center of all these conversations and the center of the value. >>So observe ability basically means you understand what's going on and today it's more important than ever to understand what's going on because there is so much more going on. If you think back five years maybe before Dr even was featured prominently, you had very little things that you needed to control that you need to understand and then micro service and coordinative became more popular and became really more important to understand what all those moving parts are doing. And that's where observe ability was born out of what we have been doing before at that time it was called application performance monitoring A PM. It's now called observe ability. It's really understanding all those parts of your architecture, of your stack of the application and in the end of the end user experience, you want to know if a user is experiencing a slow service and what's the reason for that? Because today, so many things are moving so many things that maybe even outsourced into cloud providers, it's more important than ever to know what's going on. >>Well we're here at Dunkirk on 2021 virtual. I want to get you to take a minute if you don't mind explaining to the folks why Dr and Dr Khan is important to Astana. >>So I, I said we were founded like six years ago and at that time Doctor was the rising star. It was promoting a lot of new technology. It was giving developers new abilities to develop applications in a very agile away. Microservices were enabled by Doctor before you had to deploy those things somehow it was a city Rome and then you needed to install >>debian >>package but with microservices you have so many more things to install. So it was really, I would say instrumental to the success of microservices to have a platform like docker that was really the next gen of technology that helped to enable those applications. And for us it was really an important driver to understand the whole stack, the traditional tools where eyes are oriented to infrastructure monitoring. So you understand the quality of your host if it's running slow or to look into application of an application was throwing errors but everything was disconnected and unique functionality of Astana is to connect all those bits and pieces of the application together and for that containers. And now kubernetes is a really important part to understand because it is part of this whole picture. >>Did you talk about the problem that you guys solve? Um obviously with those availability, I mean the general concept, we kind of get that great, great overview on your part, but when you start to get into devoPS teams, you start looking at def sec off, start looking at cloud native applications. I see Docker containers provides all that goodness and kubernetes, orchestration, etcetera. What problem do you guys solve? And um what's the benefit? >>The main problem that in stana solves is getting all this understanding that I said is required to provide a good experience of to your users, to your end customers uh without requiring you to do all the instrumentation work or the capture and configuration work because in stana is very automatic, it automatically sees all the works lords that are running in your communities, for example, that are running in Dr containers, but it also connects to legacy databases, fully automatic. So no configuration required also means that with a high rate of change that some of those applications hard have is that we will see all those change happening in real time. And you can't forget to make a configuration to enable your observe ability. So it's really return of investment on the viability solution that we provide and we provide a lot of this insight uh that you can get and that enables you to provide better service for your users. >>So you guys aren't just a doctor monitoring service and company, you guys actually run on Docker. Right, is that true? >>That's correct. So we are not only monitoring doctor and all these things connected to applications, but we are running on a doctor or platform as a service. SaAS software as a service. We run for you so you don't need to operate and stana, we are running it on managed kubernetes clusters and uh, IBM cloud and amazon cloud in google cloud. We have all that and it's it's all running on docker containers and that gives us so many features that are really great with DACA. So all the configuration that specific to microservices are being baked into the images and you can just roll it out, especially for monitoring products that is dependent on the data, that the performance depends on the data our customers send. Um, these ease of scalability with doctor is just so much bigger than it would be with a traditional deployment type. We can just add worker notes to our cluster and have ports auto scale to new notes and this is functionality that wasn't there before and that's great and that's important, essential for our business. >>You know, one of the conversations that's being talked about here at dr khan and in the industry at large is this idea of happy developers and everyone wants to keep developers happy. I've been hearing that conversation, have many chats with folks, you know, productivity and innovation, um but productivity and happy developers of the concept, but also, you know, on the, on the business side or on the developer side, it's more accelerated pipeline. Right? So, so how do you manage to flow, keep that productivity going, But also enabling happy developers, what do you guys do to help there? I mean what if someone asks you, hey, how do you make my developers happier and accelerate my pipeline? >>Well, that's really dependent on what makes the developers happy. I think most developers really want to get their functionality. They are working on their passionate about into production into the hands of end users. So um, skipping out a lot of the manual configuration work that's boring and not really appealing to develop us, helps everything is pre packaged and configured automatically. So that's a big, big plus. And the standard monitoring as I said, uh, is also automatic. So you don't need to configure it, your, your application on how to monitor it. So developers can just focus on delivering features and whenever there is something we will tell them, I think they enjoy that >>innovations creates great, that's a benefit. Can you talk about the on prem version of installing a, that's something that you guys are talking about and featuring um what is that about? Can you take a minute to explain beyond prem version of in Astana for dr containers? >>Yeah, it's a, it's an interesting topic, especially at the conference like dr khan, where it's all about virtualization, container realization and going into the cloud, that there are still companies, enterprises government mental entity that are very heavily invested on an on premise solution. They want to have control or are legally required to have control over what they have been deployed. So we knew when we founded in Astana that our solution, unlike our competitors, can't be only software as a service. We want to have a fantastic software as a service product and experience, but it should be equally good on premises as well. And when we were looking at ways how to actually do it, how to deliver an architecture that a little bit complicated to on premises customers to have themselves as the solution. We saw that doctor solves a lot of problems for us. We don't need to manually petra around operating system that customers, we don't have different versions of packages installed. It's all the same and actually it's not only all the same for all the deployment of all our customers, but it's also the same technology that we run as a software. As a service customers can run it now on their own. So we have feature parity, it's not lagging behind and this is also ease of support for us. >>So why was it, what was the motivation behind that was just customer demand? Um, more efficiency? What was the motivation behind moving on, supporting the on prem version? >>Uh, so for a start up, it's all about addressing the market share. Right? So you wanna have everything you can get, you don't want to spend any extra money on it. And as I said, the enterprise market is big. There are still many players that want to have the data in house. This is potentially sensitive data that's being tracked. So an on premise solution having, it was really instrumental to the success of in Stana because we were able to target and help those customers even in a fully adapt scenario, for example where they don't even have internet access. >>Take me through the process of DACA rising the product sitting on prime product that you get the thing going on there, like okay, let's do this. What does that look like? How did that work out? >>So as I said, we looked at this from the beginning and we picked DACA as a technology from the beginning, so there wasn't really like a shift and left type of scenario that other customers might be having. We were doing it from the beginning and we were aligning our architecture so that there are no fundamental differences between an on premise solution and anti size solution. That's of course configuration, that's different. But that configuration we just put into a single configuration file and that turned out to be a great idea because this is how you nowadays configure your application kubernetes, you'll make a customer resource for example, and then have an operator run the product, any kind of product, but also in stana, you run on premises with an operator that just works on the single configuration that you give it. And this is actually great because our customers are used to operating products like that, their own software, everything customers are running in dhaka in kubernetes, they are used to operating it that way. And that helped us because our customers now get the same functionality that we offer as a, as a service on premises very easily very quickly. And that make them happier. We talked about developer happiness that makes them happy because now they are not lagging behind but it also enables us to give better quality support, lot fixes faster and helps us to no longer support very old presence because they don't exist. They are frequently updated. I think this is really a benefit of container realization is also how easy it is to upgrade because you just stop apart and start a part in the new version and then you have a new verse. >>That's also great insights may be great to chat with you on that. I got to ask you on a personal note, you've been in the industry for a while and your leader, um you know, that's a performance geek, you'll have to build fast code. I was been chatting with other VPs of engineering and we were talking about the shift in engineering and with devops you've got kind of s our reaction, you have some just straight up application coding, just modernize that cloud native applications and you've got a kind of under the devoPS as the world's shifts. It seems like there's more of an architectural systems engineering approach or a systems mindset and that seems to be changing the mindset of a developer from Iterate fast. And then the line I heard was you can iterate and pump out code fast, but it might not be good, might be crap. So, so this notion of iterating code and crafting good product because with now this module Ization with containers, you're doing a lot more design work. So craft seems to be coming back to coding. Uh, I don't think it's coming back, it's been there, but it just seems more of like, hey, let's do this, right? And it's not just ship code. What's your take on that? >>So I think this always was there. It's just that traditionally companies approached software engineering similar to how companies approach manufacturing. So somebody writing a designs back and somebody verifying it and then it's going onto the line to mass production. But software doesn't work that way. We make way more changes, it's way harder to understand it up front. So the developed the iterative and exile development that has been ongoing is really, is really what people want and develops well. There is this notion of being a being waking up in the middle of the night and that's what developers don't want. So you need to prepare your application, you need to make it resilient against that. And developers are very eager to build in functionality that helps them to troubleshoot to make their application available. With a high rate of change. There is a high rate of risk as you said and I think the ability to deploy 1000 times per day is great but you don't necessarily need to do that. I think it's also important for your users that you find the right pace of when you deliver functionality and when you deliver fixes. >>I was just talking to a friend the other day and we were just talking about organizations and teams and yeah, we always riff on the the two pizza team or having more agility and you have this democratization because of the agility is also a benefit for any developer to add value if they have the right perspective or creativity. But it kind of disrupts the kind of the old way of thinking. I'm the principal engineer is my job. No, I'm the chief architect. So you have these titles and you have roles, the roles are changing and sometimes just the arguments. Oh wait, that's my job is that I'm this kind of changes. What's your thoughts on, how do you manage that dynamic? Because as you have more, uh, I won't say surface here more democratized engineering with virtual teams and whatnot You have compose ability with, with with code. You have more of a systems are a lot more going on. It's not your standard engineering mindset. What's your thinking on this as a leader in engineering and visionary? >>Well as we know the architecture of a software full of the organization that the company has. That creates. All right. So I think what you want when you want to have a micro service architecture, you want to have a micro service teams. You want to have teams, we call him at and standard delivery teams that work more or less independently on a certain set of features and are responsible for them and to end. So my engineers, they are talking to our customers figuring out how to make a feature better. They are then designing this with our user designers and then they are developing and deploying it and this really entry and responsibility. And we don't really have those titles like architect anymore. I think those roles are still there but it's more like a shared responsibility. So you of course want an architecture, you want to have your components talk to each other in an efficient way and it's more really communities of practice that are establishing. So you will find out that you have people and your teams who have specific skills who like to work on architecture. Some of them like to work on continuous delivery systems And then you you form those cross functional teams dynamically and when it's no longer hit this bands. And I think that's a major difference to assigning a person to a road. >>Yeah and and also that with you have new trends like observe ability, enterprise observe ability you know new things are happening um And new net new things like new architecture and also new roles and responsibilities. I'll see new patterns to with the data you have services being stood up and turned down all the time. You have a lot of dynamic environment. So you know having a happy developers one eliminate the manual work what you do but also giving them good work assignments to work on some good hard problems. So what is what are those hard problems that engineers like to work on these days? Is it like design? Is it coding? I mean I know it depends as you mentioned on the personalities but generally speaking as dev ops def sec Ops becomes much more of an agile edge hybrid play. What's the hard problem? >>I think big data is not really a new term but I think this is still a very interesting territory because you can apply various aspects to it. You have this data science aspect to it to understand how to detect pattern in it. And then automation is actually artificial intelligence. Right? So you automate data science and that's very interesting because those are large scale problems and new problems and new solutions. So yes there are existing frameworks but there's so much innovation to be found and making this work efficiently is another dimension of the same problem. That's also not easy and challenging problems. Make developers happy and then you can even have people think about the financial aspects. So it should also be cheap Big data and AI is usually very expensive because it requires so much hardware. So not only tried to make it fast but maybe even make it efficient. So this whole domain is very appealing. There is new technology to be invented, tough problems and I think that's really exciting to developed. >>Fabian Lang, vice president of engineering co founder and stand a great to have you on the q Great insight. Thank you for sharing that knowledge there. And the overview of installing here at dr khan observe ability very relevant for next gen next level solutions. Thanks for coming on the cube. Right, okay. I'm john Fury with the queue here. Dr khan 2021 coverage. Thanks for watching. Mm.

from the cube studios in Palo Alto in Boston connecting with thought leaders all around the world this is a cube conversation you know for years marketers marketers have been pushing for more digital especially with their big conferences I heard forward-thinking CMO say the war will be won in digital but the sales teams love the belly-to-belly interaction so every year once or even sometimes more often big corporations have hosted gatherings of thousands or even tens of thousands of attendees these events were like rock concerts they had DJs in the hallway thumping music giant screens beautiful pitches highly produced videos thing a technical breakouts Food lines private dinners etc all come on it culminating in a customer appreciation event with a big-name band physical events are expensive but they generate tons of leads for the host companies and their partner ecosystems well then BOOM coronavirus hits and the marketing teams got what they wished for right overnight virtual events became a mandate if you don't have a solution you were in big trouble because your leads from these large events just dried up hello everyone this is Dave Allen day and welcome to this week's cube insights powered by ETR ETR is entering its quiet period and I won't be able to share any new data for a couple of weeks so rather than look back at the April survey in this breaking analysis we thought we'd take a pause and really talk about the virtual event landscape and just a few of the things that we've learned in the past 120 days now this isn't meant to be an exhaustive list but we do want to call out a few important items that we see is critical in this new digital world in the isolation economy every company scrambled they took one of three paths first companies either postpone their events to buy some time think like Dell technology world Google cloud next cube convey my MIT CBO event etc or to some companies flat-out canceled their events for the year until next year like snowflake and uipath forth number three they scrambled to deploy a virtual event and they went forward IBM think did this HPE discover Susac on AWS summits docker convey Monde a peggle world Vertica big data conference octane sa P sapphire and hundreds of others pushed forward so when this braking analysis I want to share some data from the cube what we've learned not only in the last hundred and twenty days but in ten years of doing events mostly physical and we want to share the new rules of events and event marketing and beyond so let's get right into it everyone knows events events have gone virtual and there are tons of people who could give you advice on approving your digital events including us and and I will in this segment but the first thing that everyone found out is they're going to attract far more people online with a free virtual event than they do with a paid physical event so removing time timing in the expensive travel dramatically increases the participation Tam the total available market here's a tweet from docker CEO Scott Johnson he says that he's looking forward to welcoming 50,000 people to his event this is based on registration data somewhere around 30,000 people logged into the live event so docker got 60% of the pre event registrants to actually log in which is outstanding but there's a lot more to this story I'll share some other stats that are worth mentioning by the way I got permission from docker to to share these numbers not surprising because the event was it was a huge success for such a small company in the end they got nearly 83,000 registrations and they continue to come in weeks after the event which was held in late May now marketers generally will cite 2 to 3 minutes as a respect-- respectable time on site for a web property docker logged in users averaged almost four and a half minutes on site that's the average the bell curve sauce superfans like this guy who was binge watching so this brings me to rule number one it's actually really easy to get people to sign up for free online events but it's not so easy to keep them there now I could talk all day about what docker did right and I'm gonna bring some examples in during this except this segment but the one thing docker did was they did a call for papers or a call for sessions and that's a lot of work but if you look at the docket on speaker list the content is all community driven not all but mostly community driven talker had to break some eggs and reject some folks but it also had a sponsor track so it gave folks another avenue to participate so big success for docker they definitely did it right which brings us to new rule number two attention is precious you got to create high-quality content and realize that you have much less time with participants than if they were in person now unfortunately the doctor docker example is a bit of an outlier it hasn't always been this pretty remember that scene in the social network the movie when a duardo pulled the funding on the servers just to get marks attention remember how Jesse Eisenberg the actor who played Zuckerberg reacted everybody else we don't crash ever if the server's are down for even a day our entire reputation is irreversibly destroyed the whole point well some of the big tech companies crashed their servers and they say there's no such thing as bad press but look at look what happened to s AP and s AP apologized publicly and its CEO told people that they made a mistake in outsourcing their event platform so this brings us to new rule number three don't crash now I come back to Dhaka Khan for a second here's a tweet from a developer who shared the network traffic profile of his network before and during docker con you can see no glitches I mean I don't mean to pick on sa P they they owned the problem and look s AP had a huge attention attendance at its digital event more than 200,000 people and over a million views so Wow you'll kill me with that problem but it underscores the importance of scaling and s AP you have to say was not alone there have been lots of fails from much smaller events here's an example that was really frustrating you try to log in at 7:59 but the event doesn't start until 8:00 sharp really come on back in 60 seconds and in another example there was a slide failure I mean many of these virtual events are glorified webinars so if you're going to rely on slide where make sure the slides will render its scale you maybe embed them into the video you know but at least this company had a back-up plan here's another example and I've redacted the email because I'm not here to throw anyone under the bus well you know kind of but but no reason to name names you know who they are but in this case an old legacy webinar platform failed and they had to move to WebEx and again at least there was a back-up plan so you know it's been tough in a lot of these cases here's a tweet from Jason Reed it kind of summed sums it up now what does he mean by vendors are not getting the job done not enough creativity well not only were platforms failing they weren't performing adequately but the virtual experience is leaving many users unenthused they're they're just one alt-tab away from something better if the virtual event fails to engage them so new rule number four is virtual events that look like webinars actually our webinar webinars I mean in fairness you know the industry had to pivot with no notice but this is why I always tell people start with the outcome that you want and work backwards that'll inform you as to the content strategy the new roles you need to assign and make no mistakes there are new rules you know there's no site inspection virtual and then you got to figure out what you want to use your experience to be there's a whole lot to figure out and this next next one is a bit of a throwaway because yeah it's so obvious and everyone talks about it but I want to bring it up because it's important because I'm amazed at how many virtual event speakers really haven't thought through their setup you can look good you know or at least less bad get those things called books and raise up the laptop figure out some better audio your better yet get a good kit send it to their home with a nice camera and a solid mic maybe you know a clearer IFB comms for the ear spend some money to look good just as you might go and buy a nice outfit even if you're a developer put on a clean t-shirt so rule number five don't cheap out on production value get your guests a good set up and coach them up it doesn't have to be over the top no just a bit thought out okay one of the biggest mistakes I've seen is event organisers they become enamored with a platform and the features of that platform that really don't support their objectives kind of feature creep or they have so many competing objectives and masters that they're serving that they lose sight of the user experience and then the event becomes a buffet of unused features rather than a buffet of engaging content now many have told me that Dave these virtual events are too long there's too much content now I don't necessarily agree I really think if you have something to say you should say it as long as you do it right and you keep people engaged so I want to talk a little bit about a to of the meteor events that we attended one was octane twenty20 hosted by octo the identity management security player and then IBM think 2020 they called it the the think digital event experience and they both had multi day events with lots of content they both organized sessions by topic and made it pretty easy to find stuff and all assessing sessions had a reasonably consistent look and feel to them which kind of helped the production value IBM had content organized and categorized which made things easy to find and they both had good search and with IBM you could go directly from the list of topics right into the videos which I really liked very easy and intuitive and as you can see here in this octane video they had a nice and very ambitious agenda that was really quite well organized and things were pretty easy to find as you can see with this crisp filtering on the left hand side and in really nice search but one of the things that has been frustrating with most of the events that I've watched is you can't get to the sessions directly from the agenda you got to go back out for some linear path and find the content and it's somewhat confusing so I want to come back to the docker count example because I think there were two things that I found interesting and useful with docker con you know this got George nailed it when he said this is how you display a virtual conference what's relevant about this picture is you have multiple simultaneous sessions running live and concurrently and you can pop in and out of them you can easily see the sessions and this tile and there's a red line this linear clock that's running in real time to show you where you are in the event agenda versus in a time of day so I felt like with docker that as a user user you're really connected to the event you come to the site and there's a hero video very easy to find the content and in fact you can't miss it it's not a sales pitch to get to the content and then I really liked what what George change was talking about in terms of the agenda and the tile layout you can see they ran simultaneous sessions and at one point up to seven at once and they gave their sponsors a track on the agenda which is very easy to navigate but what I really like as well is when you click on a tile it takes you directly to the session video and you can see the chat which docker preserved in the PO event mode and you have this easy-to-follow agenda and again you can go directly to the session video and in the chat from the agenda so many paths to find the content I mean something so simple is navigating directly from the agenda to the session most events haven't done that they make you back out and then what I call this linear manner and then go forward and find the sessions that you want and then dive in now maybe they're trying to simulate walking to a session in a Las Vegas Convention Center because it takes about that long to figure out where most of these events in these sessions live so rule number six is make it easy to discover and consume content sounds so simple why is it not happening in most events okay I'm running out of time so I want to encapsulate a number of items in one idea that we talk about all the time at the cube I ran a little survey of the day and someone asked does it really make sense to cram educational content product content partner content customer content rally content and leadership content into the constrain confines of an arbitrary one or two-day window I thought that was an interesting comment now it doesn't necessarily mean shorten up the virtual event which a lot of people think should happen people complain that these things are too long well let me leave you with this it's actually not just about events what do I mean by that well you know how everyone says that all companies are software companies or every company is a SAS company well guess what we believe that every company is a media company in 2004 at the low point of its reputation Microsoft launched channel 9 it was named after the United Airlines channel 9 that lets you listen in to the pilots and their unfiltered conversations kind of cool Microsoft understood that having an authentic voice with which to communicate to developers and serve its community was a smart thing to do and that is the key point channel 9 is about community it's not about audience metrics or lead generation both important things but Microsoft they launched this site understanding the leverage it gets out of its community of developers and instead of treating them like leads they created a site to help developers learn so rule number seven is get your best media mojo on one of the biggest failures I see with physical events and it's clearly carrying over to digital is the failure to optimize the post-event opportunity and experience so just like physical events when the event is over I see companies and their employees they're so burnt out after a virtual event because they feel like they've just given birth and what do they do now after the event they take some time off they got to recharge and when they come back they're swamped and so they're on to the next project it might be another event it might be a webinar series or some regional summits or whatever now it's interesting it feels like all tech companies talk about these days is breaking down silos but most of these parent and child events are disconnected silos sure maybe the data around the events is consolidated into a marketing cloud maybe so that you can nurture leads okay that's fine but what about the community kovat has given us a great opportunity to reimagine how we serve communities and one thing I'm certain about is that physical events they're going to come back at some point in some form but when they do there's gonna be a stronger digital component attached to them hybrids will emerge and some will serve communities better than others and in our opinion the ones that do the best job in digital and serving their communities are gonna win the marketing Wars so ask yourself how are you serving your community are you serving the best way that you can is a lead conversion your number one metric that's okay there's nothing wrong with that but how are your content consumption metrics looking what are you measuring what does your Arc of content look like what's your content and an organic media strategy what does your media stack look like media stack you ask what do you mean Dave well you nailed physical and then you were forced to do virtual overnight eventually there's going to be a hybrid that emerges so there's physical at the bottom and then there's a virtual layer and then you get this hybrid layer at some point on top of that at the very top of the stack you got apps social media you got corporate content you got TV like channel 9 you have video library's website you have tools for agile media you got media production and distribution tooling remember customers will be entering from any one of these layers of that stack and they'll be looking to you for guidance inspiration learning vision product knowledge how to's etc and you'd be delivering that primarily through content so your media stack should be designed to serve your community events software yeah sure but it's much more than that we believe that this stack will emerge not as a monolithic beast but rather as a set of scalable cloud services and api's think of paths for media that you can skin yes of course but also one that you can control add value to integrate with other platforms and fit your business as your community demands and remember new roles are emerging as a result of this pandemic and the pivot to digital the things are different really mostly from from most physical events is that it's very important to think about these roles and one of the important roles is this designer or UX developer that can actually do some coding and API integration think of it as a DevOps for digital organizations that's emerging organizations like yours will want self-service and sometimes out-of-the-box functionality and features for sure no question but we believe that as a media producer you will want to customize your media experience for your community and this work will require new skills that you haven't really prioritized in the past what what do you think what's your vision as to how this will all play out and unfold do you buy that all companies must become media companies or at least media savvy not in the sense of Corp comms but really as an organic media producer tweet me at devonté or email me at David Galante at Silicon angle comm or comment on my LinkedIn post who would react next week with some data from et our survey sphere thanks for watching this wiki bond cube insights powered by ETR this is Dave Volante we'll see you next time [Music]

>>from around the globe. It's the queue with digital coverage of Docker Con Live 2020 brought to you by Docker and its ecosystem partners. Welcome to the Special Cube coverage of Docker Con 2020. It's a virtual digital event co produced by Docker and the Cube. Thanks for joining us. We have great segment here. Precision cancer medicine really is evolving where the personalization of the data are really going to be important to personalize those treatments based upon unique characteristics of the tumors. This is something that's been a really hot topic, talking point and focus area in the industry. And technology is here to help with two great guests who are using technology. Docker Docker containers a variety of other things to help the process go further along. And we got here spring and who's the bioinformatics research assistant and Camille took Who's a student and in turn, you guys done some compelling work. Thanks for joining this docker con virtualized. Thanks for coming on. >>Thanks for having me. >>So first tell us about yourself and what you guys doing at the Children's Cancer Institute? That's where you're located. What's going on there? Tell us what you guys are doing there? >>Sure, So I built into Cancer Institute. As it sounds, we do a lot of research when it comes to specifically the Children's cancer, though Children a unique in the sense that a lot of the typical treatment we use for adult may or may not work or will have adverse side effects. So what we do is we do all kinds of research. But what lab and I love, which we call a dry love What we do research in silica, using computers at the develop pipelines in order to improve outcomes for Children. >>And what are some of the things you get some to deal with us on the tech side, but also there's the workflow of the patients survival rates, capacity, those constraints that you guys are dealing with. And what are some of the some of the things going on there that you have to deal with and you're trying to improve the outcomes? What specific outcomes were you trying to work through? >>Well, at the moment off of the past decade and all the work you've done in the past decade, we've made a substantial impact on the supply of ability off several high risk cancers in Pediatrics on and we've Got a certain Program, which spent I'll talk about in more depth called the Zero Childhood Cancer Program and essentially that aims to reduce childhood cancer in Children uh, zero. So that, in other words, with the previous five ability 100% on hopefully, no lives will be lost. But that's >>and what do you guys doing specifically? What's your your job? What's your focus? >>Yes, so part of our lab Old computational biology. Uh, we run a processing pipeline, the whole genome and our next guest that, given the sequencing information for the kids, though, we sequence the healthy cells and we sequence there. Two missiles. We analyze them together, and what we do is we find mutations that are causing the cancel that help us determine what treatment. So what? Clinical trials might be most effective for the kids and so specifically Allah books on that pipeline where we run a whole bunch of bioinformatics tools, that area buying thematic basically biology, informatics, and we use the data generated sequel thing in order to extract those mutations that will be the cancer driving mutations that hopefully we can target in order to treat the kids. >>You know, you hear about an attack and you hear Facebook personalization recommendation engines. What the click on you guys are really doing Really? Mawr personalization around treatment recommendations. These kinds of things come into it. Can you share a little bit about what goes on there and and tell us what's happening? >>Well, as you mentioned when you first, some brought us into this, which we're looking at, the the profile of the team itself and that allows us to specialize the medication on the young treatment for that patient on. Essentially, that lets us improve the efficiency and the effectiveness off the treatment, which in turn has an impact on this probability off. >>What are some of the technical things? How did you guys get involved with Docker with Docker fit into all this? >>Yeah, I'm sure Camille will have plenty to bring up on this as well. But, um, yes, it's been quite a project to the the pipeline that we have. Um, we have built on a specific platforms and is looking great. But as with most tools in a lot of things that you develop when your engineers eyes pretty easy for them to become platform specific. And then that kind of stuck there. And you have to re engineer the whole thing kind of of a black hole. That's such a pain to there. So, um, the project that Mikhail in my field working on was actually taking it to the individual's pools we used in the pipeline and Docker rising them individually containing them with the dependencies they need so that we could hook them up anyway. We want So we can configure the pipeline, not just customized based off of the data like we're on the same pipeline and every it even being able to change the pipeline of different things to different kids. Be able to do that easily, um, to be able to run it on different platforms. You know, the fact that we have the choice not only means that we could save money, but if there's a cloud instance that will run an app costal. If there's a platform that you know wanted to collaborate with us and they say, Oh, we have this wholesome data we'd love for you to analyze. It's over hell, like a lot of you know, >>use my tool. It's really great. >>Yeah. And so having portability is a big thing as well. And so I'm sure people can go on about, uh, some of the pain point you having to do authorize all of the different, But, you know, even though they Austin challenges associated with doing it, I think the payoff is massive. >>Dig into this because this is one of the things where you've got a problem statement. You got a real world example. Cancer patients, life or death gets a serious things going on here. You're a tech. You get in here. What's going on? You're like, Okay, this is going to be easy. Just wrangle the data. I throw some compute at it. It's over, right? You know what? How did you take us through the life? They're, you know, living >>right. So a supreme I mentioned before, first and foremost well, in the scale of several 100 terabytes worth of data for every single patient. So obviously we can start to understand just how beneficial it is to move the pipeline to the data, rather the other way around. Um, so much time would be saved. The money costs as well, in terms of actually Docker rising the but the programs that analyze the data, it was quite difficult. And I think Sabrina would agree mate would agree with me on this point. The primary issue was that almost all of the apps we encountered within the pipeline we're very, very heavily dependent on very specific versions off some dependencies, but that they were just build upon so many other different APS on and they were very heavily fined tuned. So docker rising. It was quite difficult because we have to preserve every single version of every single dependency in one instance just to ensure that that was working. And these apps get updated quite Simpson my regularly. So we have to ensure that our doctors would survive. >>So what does it really take? The doc arise your pipeline. >>I mean, it was a whole project. Well, um, myself, Camille, we had a whole bunch of, um, automatic guns doing us over the summer, which was fantastic as well. And we basically have a whole team of lost words like, Okay, here's another automatic pull in the pipeline. You get enterprise, you get to go for a special you get enterprise, they each who individually and then you've been days awake on it, depending on the app. Easier than others. Um, but particularly when it comes to things a lot by a dramatic pools, some of them are very memory hungry. Some of them are very finicky. Some of the, um ah, little stable than others. And so you could spend one day characterizing a tool. And it's done, you know, in a handful of Allah's old. Sometimes it could make a week, and he's just getting this one tool done. And the idea behind the whole team working on it was eventually use. Look through this process, and then you have, um, a docker file set up. Well, anyone to run it on any system. And we know we have an identical set up, which was not sure before, because I remember when I started and I was trying to get the pipeline running on my own machine. Ah, lot of things just didn't look like Oh, you don't have the very specific version of ah that this developer has. 00 that's not working because you don't have this specific girl file that actually has a bug fixes in it. Just for us like, Well, >>he had a lot of limitations before the doctor and doctor analyzing docker container izing it. It was tough. What was it like before and after? >>And we'll probably speak more people full. It was basically, uh, yeah, days or weeks trying to set up on in. Stole everything needed around the whole pipeline. Yeah, it took a long time. And even then, a lot of things, But how you got to set up this? You know, I think speculation of pipeline, all the units, these are the three of the different programs. Will you need this version of obligation? This new upgrade of the tools that work with that version of Oz The old, all kinds of issues that you run into when they schools depend on entirely different things and to install, like, four different versions of python. Three different versions of our or different versions of job on the one machine, you know, just to run it is a bit of >>what has. It's a hassle. Basically, it's a nightmare. And now, after you're >>probably familiar with that, >>Yeah. So what's it like after >>it's a zoo? It supports ridiculously efficient. Like it. It's It's incredible what Michael mentioned before, as soon as we did in stone. Those at the versions of the dependencies. Dhaka keeps them naturally, and we can specify the versions within a docker container. So we can. We can absolutely guarantee that that application will run successfully and effectively every single time. >>Share with me how complicated these pipelines are. Sounds like that's a key piece here for you guys. And you had all the hassles that you do. Your get Docker rised up and things work smoothly. Got that? But tell >>me about >>the pipelines. What's what's so complicated about them? >>Honestly, the biggest complication is all of the connection. It's not a simple as, um, run a from the sea, and then you don't That would be nice, but that know how these things work if you have a network of programs with the output of this, input for another, and you have to run this program before this little this one. But some of the output become input for multiple programs, and by the time you hook the whole thing up, it looks like a gigantic web of applications. The way all the connections, so it's a massive Well, it almost looks like a massive met when you look at it. But having each of the individual tools contained and working means that we can look them all up. And even though it looks complicated, it would be far more complicated if we had that entire pipeline. You know, in a single program like having to code, that whole thing in a single group would be an absolute nightmare. Where is being able to have each of the tools as individual doctors means we just have the link, the input on that book, which is the top. But once you've done that, it means that you know each of the individual pools will run. And if an individual fails, or whatever raised in memory or other issues run into, you can rerun that one individual school re hooks the output into whatever the next program is going without having one massive you know, program will file what it fails midway through, and there's nothing you can do. >>Yeah, you unpack. It really says, Basically, you get the goodness to the work up front, and a lot of goodness come out of it. So this lets comes to the future of health. What are the key takeaways that you guys have from this process? And how does it apply to things that might be helpful to you right around the corner? Or today, like deep learning as you get more tools out there with machine learning and deep learning? Um, we hope there's gonna be some cool things coming out. What do you guys see here? And the insights? >>Well, we have a section of how the computational biologist team that is looking into doing more predictive talks working out, um, basically the risk of people developing can't the risks of kids developing cancel. And that's something you can do when you have all of this data. But that requires a lot of analysis as well. And so one of the benefits of you know being able to have these very moveable pipelines and tools makes it easier to run them on. The cloud makes it easier to shale. You're processing with about researches to the hospitals, just making collaboration easier. Mainz that data sharing becomes a possibility or is before if you have three different organizations. But the daughter in three different places. Um, how do you share that with moving the daughter really feasible. Pascal, can you analyze it in a way that practical and so I don't want one of the benefits of Docker? Is all of these advanced tools coming out? You know, if there's some amazing predicted that comes out that uses some kind of regression little deep learning, whatever. If we wanted to add that being able to dock arise a complex school into a single docker ice makes it less complicated that highlighted the pipeline in the future, if that's something we'd like to do, >>Camille, any thoughts on your end on this? >>Actually, I was Sabrina in my mind for the last point. I was just thinking about scalability definitely is very. It's a huge point because the part about the girls as a technology does any kind of technology that we've got to inspect into the pipeline. As of now, it be significantly easier with the use of Docker. You could just docker rise that technology and then implant that straight into the pipeline. Minimal stress. >>So productivity agility doesn't come home for you guys. Is that resonate? >>Yeah, definitely. >>And you got the collaboration. So there's business benefits, the outcomes. Are there any proof points you could share on some results that you guys are seeing some fruit from the tree, if you will, from all this Goodness. >>Well, one of the things we've been working on is actually a collaboration with those Bio Commons and Katica. They built a platform, specifically the development pipelines. We wanted to go out, and they have support for Docker containers built into the platform, which makes it very easy to push a lot of containers of the platform, look them up and be able to collaborate with them not only to try a new platform without that, but also help them look like a platform to be able to shoot action access data that's been uploaded there as well. But a lot of people we wouldn't have been able to do that if we hadn't. Guys, they're up. It just wouldn't have. Actually, it wouldn't be possible. And now that we have, we've been able to collaborate with them in terms of improving the platform. But also to be able to share and run our pipelines on other data will just pretty good, >>awesome. Well, It's great to have you on the Cube here on Docker Con 2020 from down under. Great Internet connections get great Internet down. They're keeping us remote were sheltering in place here. Stay safe and you guys final question. Could you eat? Share in your own words from a developer? From a tech standpoint, as you're in this core role, super important role, the outcomes are significant and have real impact. What has the technology? What is docker ization done for you guys and for your work environment and for the business share in your own words what it means. A lot of other developers are watching What's your opinion? >>But yeah, I mean, the really practical point is we've massively increased capacity of the pipeline. One thing that been quite fantastic years. We've got a lot of increased. The Port zero child who can program, which means going into the schedule will actually be able to open a program. Every child in Australia that, uh, has cancel will be ableto add them to the program. Where is currently we're only able to enroll kids who are low survivability, right? So about 30% the lowest 30% of the viability we're able to roll over program currently, but having a pipeline where we can just double the memory like that double the amount of battle. Uh, and the fact that we can change the instance is really to just double the capacity trip. The capacity means that now that we have the support to be able to enroll potentially every kid, Mr Leo, um, once we've upgraded the whole pipeline, it means will actually be a code with the amount of Children being enrolled, whereas on the existing pipeline, we're currently that capacity. So doing the upgrade in a really practical way means that we're actually going to be a triple the number of kids in Australia. We can add onto the program which wouldn't have been possible otherwise >>unleashing the limitations and making it totally scalable. Your thoughts as developers watching you're in there, Your hand in your hands, dirty. You built it. It's showing some traction. What's what's your what's your take? What's your view? >>Well, I mean first and foremost locks events. It just feels fantastic knowing that what we're doing is as a substantial and quantify who impact on the on a subset of the population and we're literally saving lives. Analyze with the work that we're doing in terms off developing with With that technology, such a breeze especially compared Teoh I've had minimal contact with what it was like without docker and from the horror stories I've heard, it's It's It's a godsend. It's It's it's really improved The quality of developing. >>Well, you guys have a great mission. And congratulations on the success. Really impact right there. You guys are doing great work and it must feel great. I'm happy for you and great to connect with you guys and continue, you know, using technology to get the outcomes, not just using technology. So Fantastic story. Thank you for sharing. Appreciate >>you having me. >>Thank you. >>Okay, I'm John for we here for Docker Con 2020 Docker con virtual docker con digital. It's a digital event This year we were all shale three in place that we're in the Palo Alto studios for Docker con 2020. I'm John furrier. Stay with us for more coverage digitally go to docker con dot com from or check out all these different sessions And of course, stay with us for this feat. Thank you very much. Yeah, yeah, yeah, yeah, yeah, yeah

>> From Gillette Stadium in Foxboro, Massachusetts, if the queue covering Vita Winter warmer, twenty nineteen brought to you by Silicon Angle media. >> Hi. I'm stupid women. And this is the cubes coverage of V tug. Winter warmer twenty nineteen, where we see the emergency connections between virtual ization and cloud computing happened have on the program A user at the event Con Rebates. Who is a senior integration engineer with P s lifestyle. Thanks so much for joining us. >> Nice to be here. >> All right, So, PS lifestyle, let's start there. Tell us a little bit about that in your role as a senior integration engineer and what that means. >> Okay, So, PS lifestyle, we're national Hair Salon were in thirty seven states, and we have, Ah, super niche angle. All of our salons are in senior assisted living communities as we focus exclusively on seniors and, you know, well, twenty mics in your life more enjoyable. >> Okay, well, that's that's excellent. We always talk about, you know, jobs of the future and where there is growth. Ueno the boo birds generation is, you know, creating lots of people, you know, in health care. And, you know, part of health is making sure you're feeling happy about how you look. So I don't need to worry too much about my hair. These days, but we do, other than just head say, the older generation >> way do some of that, like massage services. Just just Yeah, well, being >> very, very cool is, you know, definitely not something we've talked about on our program. And after nine years and thousands of interviews, it's nice to have some interesting angles talk about. So you're a senior integration engineer? My understanding from some of the prep is you're really working on cloud related activity primarily. >> Yeah. So I came on board about a year ago. I switched out of our operations, roll into a development role and P s lifestyle are looking too, uh, bring the internal systems forward. I've been doing a lot of work, a lot of writing the stylist in the field when I end up writing out their services that they perform everyday, which doesn't really scale. So yeah, they're trying. Teo, bring the services into the present. Um, get get away from having to write everything down. So we're building out like a It's not quite a point of sale. System is somewhere between point of sail on, like, an Internet s so that everyone in the field automate what they're doing? Our accounting team doesn't have tio re input everything that comes in. Andi, just make things flow smoother. >> Okay? So frigates inside a little bit, You know what cloud services are using, and there's there's coating that you're doing is is part of that also. >> So right now we're developing in a PHP framework called Larry Gill. And we're playing to both elastic being stalking a w s and s, um, and we're building. So we have off front ends our old Larry Gill in Elastic Beanstalk. Not back in. We're building a P. I's in Lumen and the micro services are in T. C s. So we could have been scaling. >> Yeah, and, you know, Cloud seems an obvious solution for, you know, a a highly distributed in environment, like as retail too often is. And you know your locations are Is that How long could you bring us? A little bit, as you've been on for a year. But how long has that car journey been going on? >> Actually, a year. Okay. Came in just as just a CZ. The company started developing. Thiss has been on the on the horizon for about two years. And as the study of ramping up. They brought on additional people such myself. Just a stuff up so that we could actually walk through it. >> Okay. And I was there, you know, eight of us, Obviously the leader in the spaces. It was there some consideration as Teo, which cloud they'd be using. There's >> no things they were already using a ws to some capacity for Like what? Press hosting. It was just a natural continuation of that with me coming on board I've been looking at Well, what if we do want redundancy? Do we do we try Multi cloud, You know that's now on option. You know, maybe we start exploring technologies like Tara forms so that we can actually duplicate environments just in case. On the very rare instance that eight of us does go down. Yeah, well, so >> is that a concern? When you know, people say, you know, a ws going down, does an availability zone sometimes have issues shore, But can't you architect around this, or, you know, >> you know, I mean, we've had issues where a w s has been unavailable to us for, like, non technical reasons. In that case is like we were we were trapped. Unfortunately, we were not in production at the time, But it's, you know, that's a little look, a lesson you learn once, and then you think, Well, all right, I need a backup, just in case something does happen. And I know it's, like, very unlikely to happen, so that that then informs, you know, what is my back up? You know how much how much dough I invest in the back of >> great? Yeah, because, you know, multi cloud is one of those things that people talk about when you dig down, It's like, Okay, we understand. Why is that something you're doing? Because, you know, I want tohave price leverage of one against the other. Is it? Is there a service that I wanted one that, you know that might not be available other? Or is it it's kind of insurance. And in your case that saying, you know, in the case that you are, Are you saying I think from an architectural standpoint, I'm not looking to run in both clouds all the time. But if I have an outage, I should be able to kind of fail over almost on spin, something up relatively fast. And another environment. >> Eggs. Exactly. So it's like way we're talking about, you know, possibly looking in Asia. Maybe that's a little overkill. Maybe we could just do with, like, a droplet on on digital Ocean Does our entire environment we develop in Dhaka. That's pretty easy just to pick up and leave, pick up and move somewhere else on DH. You know, maybe far standby environment is nowhere near as powerful, at least still running. >> Yeah, and so, so great. You know, you've got that containers is kind of the base level for free. How are you developing? You know what one of the challenges out there is, you know, digital ocean, great for developers. Work for the containers, but, uh, you know, please correct me if I'm not getting this right, you know, You know, Cloud today isn't a utility, so I can't just say, Oh, I'm running on a day of us and let me just take everything and throw it in azure throat. Indio, You know, we're like, there's usually, you know, some work and prepped to make sure that I've got what I need. >> There is there is so it's like, so right now, it's like we're focused on us so we can work with the tooling. And then, as as we start getting more comfortable, we can start looking at extending that tolling toe, be a little flexible toe with multiple providers >> and cloudy. And if some people you know, concern is Tio, you know, how do how do I make sure that my costs just don't kind of spiral out of control is you know, how does kind of the internal control, you know, is there budgeting process in place? Do you have? Do you have a good understanding around what you have today? You know, is there much growth going on and what you have? And you know what? I'll be down. >> We've been actually very surprising. That resource is that we get on our tier of VWs. It's like we're not even scratching the surface. So we keep looking at, you know, we need toe. Everyone says, Oh, you need to worry about scaling. You need to worry about this and that way Haven't even touched what we have s so we were right. Now our focus is more on just making sure things run and then start scaling us as we run into that issue. >> All right, Candy. Last thing. What will What brings you to this event? So obviously it's it's been doing more than virtual ization and canoeing cloud for about five years now. You know what? What? What? What brings you to this show? >> The community is fantastic. So I have been working with in a previous life I worked with somewhere, which is how I got it in tow. Vey tug. And the community around Socialization is just incredible, Very supportive. So it's like I try and give back, so come back. And >> so so just going to follow up on that. I know virtualization community, you know, very welcoming. And the like do you find in the cloud world similar types of communities? >> Yeah, so it's I've actually just started up, eh? Of'em will use a group and then a WS user group on both of those communities have been fantastic so far. I walk in also with PHP, as I said, and that's an entirely different community. I'm not saying it's not friendly, but it's a different style. >> Yeah, absolutely. You find different cultures and these various ecosystems. And yeah, it's very different. You know, the early VV number one, you've had people. It's like, Oh, I'm used to being about have to do a little bit of, you know, building on top of it. A Ws is definitely builders, you know, and what they're doing. And you know on that. So can we really appreciate you joining? Sharing your experiences on what's happened the cloud and the community's involved in? Yeah. Thanks for running user groups. Those air always super helpful, and it's usually done out of the passion and doing it. It's It's not like that. That's your day job, you know? All right. Candy Bates. Thanks so much for joining. Uh, I'm still Minutemen, and thanks so much >> for watching the cue.