All right, I think we can go ahead and get started. Okay, so I'd like to thank everyone who's joining us today. Welcome to today's CNCF webinar on Lean DevOps, Building a Culture of Delivery. My name is Terry Lee. I'm the Lead DevOps Consultants at Media Consulting and CNCF Ambassador, based in Johannesburg, South Africa. So I'll be moderating today's webinar and we would like to welcome our presenter today, Carl Campbell, CEO and founder at CTO.ai. So before we get started, just a few housekeeping items. During the webinar, you are not able to talk as an attendee. There is a Q&A box at the bottom of your screen. So please feel free to drop your questions in there and we'll get to as many as we can at the end. And please note that this is an official webinar of the CNCF and as such, it is subjected to CNCF's code of conduct. So please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF webinar page. With that, I'll hand it over to Carl to kick off today's presentation. All right, thanks, Harry. Thanks for everybody who's joined the call, the webinar here. So just as we get started, I wanna make sure that I set some expectations about what you can get out of this talk. This is not necessarily a technical talk. So if you were looking for more technical details, we're not gonna be diving into any command line today, but I do have a follow-up talk that I'm working on to try to communicate some of these concepts in a more technical way. The focus of this talk is obviously building a culture of delivery using Lean DevOps. And I'm gonna walk you through a lot of my experiences and my thoughts as I try to advocate for accessibility of intuitive DevOps tools that help us all to build better software. So just getting started here, a little bit about me before we get started. So as Harry mentioned, I'm the CEO and founder of CTO.AI. What's good to know about my background and my experience which shapes my worldview is I have a very, I'd say, non-linear path where I have gotten in my career. I'm self-taught as a software engineer and an entrepreneur. I dropped out of high school to pursue tech. I started my career in the very early shared hosting days working for companies like Hostopia, which is white-label shared hosting back in 2002, 2003 for telcos. And so I've watched DevOps evolve from this early days of sort of FTP into where we are now. I've also spent an equal amount of time in my career on the front end and the back end. I spent a lot of times in the early days of Mootools and Node.js, but I also was very involved in early Linux open source work as well. And over sort of like the last five years, I've helped maybe 25 different startups implement some form of DevOps. And that's a big part of what is shaping the presentation that I'm gonna offer today. I've also worked at larger organizations. So for example, a company like Zillow who acquired my last startup. And so I've had a pretty decent amount of experience across different sizes of businesses. But what I focus on a lot in my work and in my practice, obviously as an entrepreneur is advocating for the interests of much smaller organizations. And with that comes a level of efficiency that's required, shall we say. And DevOps is a great platform for that. So a little bit about CTO today, just so that you understand what we do and why this is such an important thing to us. We provide a platform that enables developers to create and share workflow automations leading the command line. The idea is you build this workflow and it's using a container. The container then works in anybody's CLI, but also in Slack sort of an isomorphic workflow is how we think about it. You can publish it to our platform. It's instantly available to your whole team, which means that senior engineers can now help junior engineers who are joining the team be more effective. This helps the business because you're able to get access to a broader base of talent and aren't competing for talent as much. And at the end of the day, what we advocate a lot is for DevOps engineers and senior engineers to be a bit of a, what we call a 10X multiplier or 10X engineer. It's not one person who's 10 times better than anyone else. It's an engineer who helps five people be two times more productive using technology. So what is DevOps? I'm going to just frame this out of the gate so that my views are understood. I subscribe quite directly to some of the things that AWS says, DevOps is philosophy's best practices and tools. I like to think of it in that order. My belief is that the tools exist to immortalize the philosophies and best practices of your team. And I think often a lot of times we read that book backwards. We start with the tools and then we try to work towards the philosophies and best practices. But I like to clarify that out of the gate because it really informs why I start with the idea of building a culture of delivery and then work towards tools in how I think about this. And obviously we all know the impact, 200 times more frequent software deployments, 255 faster lead times or 2,555 faster lead times. One of the reports that I often will point to also at the same time when quoting these things that I think we mostly all know is a report called The Developer Coefficient by Stripe which goes on to touch on maybe the less glamorous side of DevOps. It says things about like, there's $300 billion lost every year in developer productivity in large part due to legacy software but also complex tools. But more importantly, it really highlights the interests and the needs of DevOps in organizations. And I think this quote's really great. It's not just how many Devs a company has. It's also how they're being leveraged. And so that goes back to that multiplier that we can see when we use DevOps. So setting the frame as I advocate for early stage and early stage with DevOps, the early stage of a business, the early stage of a team has lots of challenges and let's just go through them real quick. I've been through all of these many times. I mean, hiring is always a challenge. It's a challenge everywhere but it's certainly a challenging organization and an early stage organization. But in early stage organization almost everything is a first. You're learning everything for the first time together and success is often implemented bottom up but it's measured top down. And this requires a lot of accountability but also initiative from the engineers to go out and explore tools, best practices. And it can be really hard if you start with tools and then work towards best practices, especially when everything is a first because there's an a shared set of philosophies and best practices that emerge in an early stage business. Most of the innovative tech that these early stage businesses are implementing is quite time consuming and complex for them to wrap their head around. And ultimately in early stage business you just never have enough money especially if you're on the venture track because you're always working against some runway. And so it's hard to just spend more money to get more efficiency because you really and so when you think about DevOps it really can act as a differentiator in how companies implement their success. So the current state of DevOps is that it is fragmented across many different tools and technologies developers have been tasked with workflow automation and it burns valuable time that can be used for shipping features that customers love. And I've got my little guy with me here guys so we're just gonna try and work through this right now. You just jumped into my office. And this is kind of what it looks like. I mean, this doesn't even dig into the huge amount of open source tools that are now coming out of the CNCF and the Kubernetes ecosystem. But when you think about this it can be quite overwhelming for a developer to think about how to be efficient across this many tools, right? So what are the DevOps challenges that we're really tackling? Yeah, it's a dinosaur. Many companies struggle to adopt DevOps best practices and DevOps tools are more complex than ever before. And as a result, what I think is that most startups it can feel like a snake swallowing an elephant. So how do we tackle this? How do we make it easier for these very powerful tools to be available in earlier stage businesses and actually realize their full potential? DevOps evolves over time. And what's really clear to me from being at different stages of businesses is there's sort of this adoption curve that's really important to understand when you're thinking about implementing a DevOps culture. In the early days, you start off with a smaller team and the number of developers is quite low but the DevOps efficiency or the inefficiency is also low. So your efficiency is high. You have things like source control, server management, cloud management and as you adopt more tools, ultimately you add more complexity to the process. And that can create inefficiency. So what do we need to do in the beginning as we're considering the process by which we implement DevOps over time? Early on, you're flat, you got a Kanban based organization. You evolve into more of a matrix or agile driven organization. And what I think a lot about when I'm adopting DevOps in organization is how do I realize that this is the journey that I'm going on and how do I adopt things in time based on the organization's needs? When I frame it like this for people, I think one of the things that I've seen with engineers is it really puts the whole journey in context and it helps people to not, to obviously like be mindful of things like security and compliance or governance and policy but obviously like front loading that in your journey to adopting an end to end DevOps tool set can be quite challenging because in a flat and Kanban organization information flows very differently than in a matrix or agile oriented organization. So if I were to state the problem that I see out there within DevOps, especially for the early stages, 300 billion loss in developer productivity every year and access to developers is now classified as a bigger threat than access to capital by most businesses according to the strike coefficient. The technical leaders who are building tools and supporting engineering teams know that it's critical to invest into the workflow that their team requires for work and by workflow I also just mean generally tools but it can often be too time consuming especially in the early stage to ad-licate critical resources to doing it right. So how do you survive in that situation? For us the way we've tried to do it is make it really easy to automate automation and intelligence into a workflow. We do this with something that we call ops which are essentially an end to end operation that allows anybody to automate a thing very quickly and that sort of creates an experience across the developer lifecycle that's quite consistent. We've also tried to make it very accessible across the command line Slack but also CI CD. So these things that we offer on our platform called ops are essentially these developer workflows, developer experiences that can bridge the interfaces that developers use and someone who's more technical can adopt tools at the CLI level. Someone who's less technical might adopt it at the Slack level. But ultimately what we try to do and the key thing here that's a win is we try to abstract a lot of that complexity behind the scenes so that the developer can just stay focused on the task at hand and they don't end up going down a deeper rabbit hole trying to work with the tools than they do with solving the actual key feature that they're trying to deliver. So the idea here is trying to expand that idea beyond CI CD Slack and CLI to really embrace the model of what are the best practices and the philosophies that we want to immortalize into our tooling layer and how do we make it as cheap as possible for our teams to do so. I think when you approach your tooling in that perspective, when you start philosophies you start with best practice and then you immortalize them into your tools and you deliver them in a very accessible format to your team whether it's CI CD, whether it's GitOps or ChatOps whether it's your CLI ultimately you now have that leverage point that we were talking about earlier and that's what enables you to sort of 10x your team and that one developer can make three or five developers two times more efficient because they've solved the harder problem and then delivered those philosophies and best practices into the tools. So this brings us to this idea of like building this culture of delivery and there's a number of things that I've tried to really embrace as I've learned these lessons over time. I think as an organization grows it's really easy to add more process add more tools, add more complexity but in doing that you ultimately are taking what I think is the easier road what's harder is to try to stick with simplicity longer try to stay leaner longer try to add less complexity longer I think that really takes a level of intention and really thoughtfulness to do that and I think that's often the harder path and I really try to encourage people to do that there's been thought leadership on this for a long time people like Dan McKinley who've talked about choosing boring technology the idea being that you have three innovation tokens spend them wisely. If you spend it on your database or on how you deploy an application you don't have that innovation token to spend in other places like a customer facing or a business facing item. So in my mind a lot of things in DevOps should be relatively boring that doesn't mean they should not be enjoyable to use but they should be easy enough to use that they feel like a commodity. The other thing that I think a lot about is how do you set expectations for people who are joining your team whether it's at the early stage the later stage. The more complexity you add the longer it takes for somebody to deploy code the experience that they have setting up your tools really dictates to them what are the philosophies and best practices or therefore the expectations in this company. So in most startups that I've worked in or started we try to have this rule early on where everybody deploys on day one and the reason that we would prioritize that even over things like some of the administrative work is that I want you to know that when you join this development team you're gonna be very successful at contributing to value that customers are gonna see and if I can set that expectation on your first day it really does a huge amount of good for the holistic culture as the company grows. It's often obviously a very hard thing to maintain in the long run but it is sort of like the intention or the goal of every good DevOps practice. I think it creates a platform for the success of people who joined your team and that's ultimately how I think about DevOps. And one of the things that I think is often missed in organizations which is maybe not so much DevOps but falls a little bit more in a product management is that as engineers we often don't have a great ability to estimate things accurately and this is because most of the systems we work with are complicated. We also have a hard time sometimes clearly articulating what the impact of a contribution might be. So like what would the impact be if I go and automate this GitOps pipeline? So what I really try to encourage engineering teams to do is not just estimate things but actually communicate a more complex model for how they communicate priority. And I think of this as prioritizing your best work. What I like to try to get people to do is communicate impact plus confidence divided by effort. It's because if you can communicate the impact that something has and the confidence that you have that it will reach that point of impact and you divide it by your effort, you get something that's much more valuable than a story point. What you get is the ability to prioritize the things that are gonna have the highest yield in your team. And the other thing that I talk a lot about with early stage businesses is when they move into this idea of DevOps, there's a lot of knowledge out there already around the traditional DevOps lifecycle. And at the end of the day, it also includes quite a bit of information about how product management works in this graphic that I think we're probably all familiar with. For early engineering teams, even though I try to get them to talk in the form of like ice impact confidence divided by effort, I do try to get them to focus a little bit more on just the technical things that they need to adopt and adopt those in time based on where they are at in their go to market cycles. So pre-product market fit, you have a very different level of needing to operate and monitor obviously post-market fit or in a mature organization, that maybe is a higher priority. But I think when I visualize DevOps and lean DevOps in this format on the right, it sort of helps you to create the cyclical journey where you're first trying to get a full loop and then you're reinvesting. So you start with committing, then you're reviewing code provisioning servers, delivering servers, you need to build managed incidents once you have them in users and then you need to build a measure things, whether it's in the product or it's in the system. Now you need to reinvest in that curve. How do we make commit and then review and then provision delivery? And I think one of the fallacies about DevOps is people kind of think like you set it up, it's done, but it's a continuous investment. And the more that we can communicate that, I think the easier it is for businesses to justify the cost and improving the efficiency of their engineering teams by further investing into DevOps. So I think part of what we need to work on as a dev community is just how we communicate our priorities, whether it's ICE, or how do we communicate the investments that we're making and the impact that it has in the business. Another thing that factors into this is how an organization structure is set up. And sometimes we may or may not have control over how this is organized. Maybe something that we can organize within an engineering team or a DevOps organization, but it also may be something that's set more broadly in the business. But it's just important to understand that evolution as I talked about earlier, so you have your eyes wide open. Early on you have a flat organization. Communication is very easy to have cross-functionally. People work very independently. Then you move to a more matrix or agile organization. And obviously you start to have domain expertise, even some information silos, if we will, where I maybe don't know what that team's doing over there or that team specializes in security or they specialize in DevOps. This team over here is focusing more on this part of the system. And I think figuring out how to maintain a level of cross-functional consistency across these different groups is a really hard challenge when it comes to building a culture of delivery. Because as an organization grows, it's usually not the tools that break down. To be honest with you, it is the philosophy and the best practices. It's how we communicate about our expectations and how we understand that this organization, this team over here is doing this, this team over here is doing this, those two things are different. Well, now we have a massive context switch between those two things and a fragmentation of how we think about doing software development. That doesn't mean to me that we need everything to run in exactly the same way and we need to control the highest common denominator. But I do think it's about making sure that if there are new ideas emerging in the organization, those things can flow, especially if they're a net order improvement on investing into these workflows that we use to deliver software. A good example of this that's rooted in data is ultimately security. And so the 2019 State of DevOps report, we pulled some data from that and we looked through this to try to really find data that suggests that there's big changes happening. And still 50% of organizations have a centralized security function. That makes sense to me, like security, especially in large organization is a deep specialization. I think what we do see as, and we see this with other specializations is there is a movement to more generalized and distributed models for this specialization, which means that we're lowering the barrier to entry to for other developers to think about security. And this is sort of the rise of DevSecOps. 31% of organizations said that they centralized security function but had delivery designated delivery expert on each team. And then 14% literally were distributing and decentralized as security function. And I think that this is sort of more of a, like everybody is involved in security. And when you think about that extreme, there's definitely a need to like pollinate information, like what are your security best practices? How do this get implemented? In a centralized model, if you just go, hey, all of our security function happens within the pipeline and the pipeline is what analyzes our security. And you basically create kind of a black box for the rest of the organization. But if you have a more distributed model that where information can flow, it helps people to understand like what's happening and why we're implementing these security procedures. And this brings us to sort of the lattice organization structure. So a way to think about this in the public domain would be some of the things that Spotify has put out there about how they organize their company and their engineering teams. More recently there's been feedback on this that talks about its compromises and drawbacks as well. I think that's really good because there's obviously no one size fits all way to build a successful company. But I think the benefit of this approach that especially in the early and mid stage is you can ultimately have sort of this verticalization as we highlight in green, which is aligned with sort of business units that might have strategic goals that are relevant to let's say product or relevant to a section of the business. Horizontally you can layer in these specializations, things like security, DevOps or generally it depends on how you wanna break it down. But if you can have a designated point person on each of these areas, whether it's the business unit or the cross-functional disciplines that are more specialized, you can start to build this model for permeating knowledge and cross-functional training, which helps people move across different business units and have similar expectations. And this is really easy to do in the earlier stage because usually just have one DevOps engineer, but as you grow, this is a harder thing to implement. But I really encourage people to think this through because it's really important how we communicate philosophy and best practices. I think tools are a big part of how we immortalize them and translate our expectations, but there's a lot that can't be translated in a tool obviously. And this is why we have so many Zoom meetings. So the technology and process tactics really matter. And there's a lot of different ways to approach it. I went through a few that I see out there, but I think there's some like really core things that you need to just focus on. So there is no silver bullet that'll offer you on this, but there are some things that I really value when I'm building a team and scaling a team. For me, tooling enables less technical team members, maybe junior team members, to be given more responsibility, which creates less burden on senior members. So the more you can like start there and figure out how do you translate the philosophy and best practices, so it's accessible by others, I think you're really hitting an important point if that's your primary goal. Secondarily, I think you have to be mindful of what the long-term looks like. And I think you need to start with strategies and focus that focus on high velocity because high velocity is much harder to get as if you start with low velocity, it's much easier to get to, much easier to start with a higher velocity and then slowly lose some velocity over time. But that's a really hard thing to focus on early because you have to adopt certain tools along the way. You're inevitably gonna slow down as you add people in process. So just recognize that there's a negative correlation between the work we do sometimes and the productivity of an organization. Our goal is trying to maintain a focus on this velocity as we leverage more DevOps tools. And this is why I advocate for Lean DevOps because I think it's one of the most important correlating factors in the end result of the work that we do in DevOps because it kind of looks like this if I were to just summarize. So what we have is velocity on the left and the amount of process complexity on the right. As you adopt more process and ultimately people, you have velocity in green, which is diminishing over time. The point of, we say CTO today, but just DevOps and Lean DevOps in general is to try to sustain that velocity longer. And I think if you factor in that model into how you think through your DevOps strategies, you really have a robust framework that can scale, it's what worked well early and scale into a growth model. It's very adaptable. And I guess that's the whole point I'm trying to communicate is it should be adaptable, but it also should be very accessible because the number one thing is how do I get access to the tool I need to achieve the thing I need? And the tool is just the means to the end. So this is where I don't offer like a concrete conclusion, unfortunately, because there is no perfect process. I'm not going to tell you exactly how to do DevOps and that's why I didn't start with a technical talk here because what I'm trying to communicate and what I'm trying to advocate for are a lot of things that actually don't start with tools, but I do think tools are important part of the process, the important part of the tactics. So when you think about tools, they enable bottom-up adoption and they can create top-down transparency. I mean, that is a big important thing, but they also have to immortalize, as I've said, the philosophy and the best practices. As you start breaking out your organization into different specializations, it can be an advantage to maintain a flat organization longer. So think through really hard when you start breaking up teams. Is this what we need? And or is that going to create an amount of overhead or a level of fragmentation and communication, philosophy, best practices and tools that adds an exponential overhead to that business? When's the right time to do this? Most times I've seen organizations start to do this as sort of 25 engineers, and then again at maybe 40 or 50. And then from there, it's kind of really different based on how people work. But the most important thing is, because every organization is different, is you have to be adaptable and so should your tools. You're gonna have to evolve best practices along the way. You gotta be kind to your future self, being think through one of the things that you're gonna have to tackle later, but try not to front load all of the solutions. And what I think is really important is to be able to throw away code. And as engineers, we often don't wanna do that because it might communicate that that code failed. But if we can normalize that idea with an organization that right is building for right now and sometimes right now is not the thing we need in a year or two years from now, what it does is it gives us permission to evolve as we go and not carry forward our assumptions. So I try to communicate, always retest those assumptions about what's working and what's not, and give yourself as much permission as you can to throw away code. And then as you're growing, like one of the key things here that's really, really hard to do is to manage and be mindful of the dichotomy between velocity and stability. Stability is very important as a business gets to scale as it's robust and it's predictable because you need to have that predictability to evolve from the premise. But early on, adaptability and velocity to get to that level of stability is also very important. And I can't count how many teams I've seen fail in the early stage because they think the goal is to build for stability before they actually really understand what they're building for stability. And they don't leverage the leaner side of DevOps as an advantage early on. So the more you can do that, I think the better you're able to grow with your DevOps strategy. So my takeaway, the thing that I'm advocating a call to action for all DevOps engineers in the CNCF is this idea of accessibility and intuitive developer tools. I like to frame this around the idea of like who are you 10xing? What I'm trying to really bring to the table with this talk is almost an obligation that I think we all have to consider who are the constituents who are using our tools? What philosophies and best practices do those encompass? How are those adaptable and how do those actually remove friction from the process? And I think we have some really powerful tools in the DevOps world, but we need to spend more time on making them intuitive and easier to use for the next 40 million developers. And that is the presentation. So I'm happy to open it up for Q&A, but I will just note that if anybody's interested in what we're doing, please, we have a free Slack community where we talk about these things a lot. Please come check us out. And we'd love to continue the discussion there, but I'm also happy to answer any questions now that may be out there. Cool, awesome. Thanks, Carl, for the fantastic presentation. So we do have some time now for questions. You have a question that you would like to ask, please drop it in the Q&A section at the bottom of your screen and then we'll get to them. So I see that there are two questions currently. So the first one's from David. And David is very interested in hearing more about your experiences and tips with regards to maintaining a cross-functional consistency across teams and avoid information silos. So we'll come into that. Great question. Probably the hardest thing. I think it's the hardest challenge.  I don't have a clear answer for how to solve this in a situation where there exists a lot of what I think of as communication debt or expectation debt or process debt. I mean, there's all these other forms of debt that we carry forward. It's why I think we need to retest our assumptions. And so this is why I try to advocate for the idea of starting this conversation in the early stage because earlier you can start thinking about that as inevitably the outcome. And there's a bit of a physics mindset here, right? And I think Elon Musk talks about this little bit like you should start assuming you're gonna be wrong and work towards being right. So I always start with just assuming that that's gonna exist and like it's unavoidable. I think if you start with that assumption and you try to make different changes like on your journey there or take different approaches on your journey there, that is the number one thing that I've seen reduce the friction that you can feel at a later stage. I think when you get to that point and you suddenly see the forest through the trees and you're like, oh man, we have all of these information silos. There's a lot of approaches you can take that I think are helpful but don't necessarily like are hard to implement, hard to influence change. And this is why we have things like digital transformation that happen. I think some of the things that are really important is like try to have a single source of truth with obviously your code base, right? So try not to have multiple source control systems but also documentation. Certainly I think CICD is good. I think the thing that's the most important there is just generally accessibility and observability and transparency. So this is one of the things that we think things like chat ops is just really good for under the gate and obviously chat is not a silver bullet like it does certain things better and get ops does certain things better but the more you can make your workflows observable by default the more you can make them inclusive by default. The more that on that first day that engineer can look and see here's how somebody did that the less they have to then go dig and find the information. It's just a more organic way to surface this context. And I think these are strategies that tend to work really well but they're hard to implement and I think we need to make them easier to implement. I think by default what we tend to do is lean towards security and control and mitigation of potential human error. And I think we lock things down sometimes so that they're less accessible and I think what we could be thinking about is okay if that's we're putting all this effort into governance and compliance and security and like these things at the end of the cycle that give you that stability. Well, could we approach those things earlier by just making them more intuitive? So there's less room for human error but you still get the benefits of like transparency and accessibility where that junior engineer can deploy a thing and the system is good enough at falling back because you have this really clear and easy way to roll back that you're mitigating certain risks just out of the box. And so I think a lot about that and unfortunately I don't know that I have like one strategy but I'd say definitely like centralize your documentation. I think engineering office hours are really important just a place for people to get and like share ideas especially like team leads coming and be like hey, my team tried this, my team tried that. You know, it's always a balance because the time invested in is a big factor to how much ROI you get in the later stage. So try to start it earlier as early as possible and that doesn't mean give up if you're at the later stage and you're already at this point it just means you need to be probably more thoughtful and ready to achieve more buy-in to make change. And so executive stakeholders are super key in that kind of piece. And that's why I talk about trying to surface how we communicate about our KPIs and our goals in a slightly different format because I think they translate a little bit better to the business world and then they're easy to get stakeholder buy-in on. Cool, thanks Kyle for that. So the second question is from Barton who asks what role does ops play in this process? And I guess is the question about ops is in an ops team or ops is in our platform. Maybe I'll address both. I don't want to be too presumptive there. So I think the ops side of DevOps is this idea that we used to have sys admins and people who are sort of more on the IT and operation side. And what we were trying to do is like make systems more accessible so devs could access ops and be in there for DevOps. And I think what role that the ops team plays in this is really that call to action and that obligation that I was describing about how do we make the system as intuitive as possible whether it's a CI CD system or it's some other method for like getting access to logs. How do we make it as easy to access that as possible? I think that's the obligation of the ops team as they think about the devs as their customers their internal customers. And I think prioritizing the needs of the developer and understanding like what is their end game? What do they want to get to? And how do I get them there as quickly as possible without them having to take on all of the knowledge that I spent the last 10 years doing. I think that's the role ultimately of dev ops especially if you think about it implemented from the ops side of the equation. What we've tried to do with our platform the workflows which we call ops is try to start from that constraint and say look if the goal is to make this accessible to people what are the ways that we can really leverage the simple enough ways for these developers to get access to that while not assuming we know what the ops team knows. And so we think of as the ops platform is generally just a set of tools that you can use to build a developer experience that's easily distributed to your team and has 12 factor principles. The idea is you build this command line and you write it with our SDK the command line is just a Docker file so you can kind of think Haroku for developer workflows. Once you build it and you publish it it doesn't just run in everyone's command line without them having to think about environment variables and all these other things, it also runs in Slack. So you get chat ops for pretty much for free when you're building your command lines. And what we think this does is it both drives down the cost of automating things and taking the knowledge out of your brain as the ops person. And it makes it very easy to make it accessible and intuitive because now it doesn't just run through Slack or through the CLI it also runs through Slack which means you can automate away a lot of those things that were your dependencies on you. It doesn't replace your traditional CI-CD system necessarily it's a container though so you can run anything you want in it. You can put your Terraform scripts in there your Bash scripts, like whatever tools you use you're the expert, I'm not here to tell you how to implement your technology. What we're trying to do is like bring down the cost of distributing this knowledge out of the specialist brain into the form that the generalist can access them and reduce the burden on the DevOps heroes that we are helping us all ship software, right? Awesome, thanks, Carl. So the third question is, do you see your company competing with established players such as Jenkins X and GitLab as well as SaaS products, CI-CD vendors like Codefresh and harness.io or are you focused on spreading a message of efficient CI-CD only? Great question. I think we often get confused with CI-CD maybe because like an op is a container and you can like execute it in many different ways. We don't really see ourselves as a CI-CD solution. We see ourselves as a framework for building a developer experience that's accessible and measurable. So one of the things I didn't talk about is when you write these workflows we also have not just a set of frameworks in SDKs for the 12 factor principles, secrets, configurations. You can also store events and metrics. So we try to layer on top of existing tools in a lightweight way so that you can automate across your tool chain with some level of consistency. As a result, I guess there's overlap with some of the things that the CI-CD companies are doing, there's overlap with some of this what I think of as like the rise of the workflow and I think the intention behind that is here's a set of tools that you can use to implement your ideas bottom up and drive transparency top down. But I think we're unique in how we think about it because we're really focused on the idea that you can build the CLI which is typically how we automate all the other things and CLI and then from there the CLI also works in Slack. I suppose when you start triggering these workflows based on commits or other types of system events, I mean, it's really hard to figure out how it's different from CI-CD. It has a lot of the same kind of like fundamental principles in that way but we very much start from the idea of a more distributed and loosely coupled workflow for developers and as a result, we're not as much of what I would think of as like a centralized CI-CD system. It's accessible through Slack but each Slack channel can have its own set of workflows and to be honest with you people automate things that have nothing to do with CI-CD quite often and I think there's a lot of things that developers do which doesn't just fall into the existing CI-CD paradigm things like getting access to logs, running that report for a product manager against like who logged in and some of the migration stuff that we do is not great inside of CI-CD to be honest with you. I think CI-CD tends to be in some cases, it is a single point of commanding control which is great but I think in this remote world more and more of that control plane and how we think about where we jump off to start our day, where we jump off to do our work and where we communicate and collaborate more and more I think it's moving to Slack. So we're really trying to take this like Slack first mindset of how developers do work and we don't think of ourselves as like a chat bot but we're more chat first or chat free I guess in how we think about enabling you to build out your developer workflow. So I know that isn't like a direct answer but I hope that gives some context. Yeah, so DevOps isn't just like automation in CI-CD there's more to it than that. Yeah, and I see Barton clarify that he's talking about the ops team so hopefully Barton like that answered that question as well it's an obligation on the ops team to make tooling accessible and we're just trying to make that available to lower burden on the ops team. Yeah, awesome, thank you. Next question, while we take cognizance of the velocity versus stability graph can we not look at DevOps security which is DevOps sec to improve the stability? So such as including security tools to get more stability? Yeah, I think that's great. And that's actually why I sort of like point to security in that other slide about where like we're trying to measure the shift in this mindset of like centralized versus decentralized approaches in how we permeate knowledge but also practices and philosophy through tools. So I do think that like the rise of that sec ops is like great because it reduces the burden on the generalists to have to observe all of the deep knowledge of the security specialists and we're using tools to distribute that knowledge in a process-driven way to embrace best practices. So I think it's one of the new trends certainly that is finding that balance between stability and velocity because it's unintrusive and it's typically quite intuitive. You check your code in it runs some sort of security scan and then you get a note put and then if like you're blocked you need to now go contact switch and figure out why to block that. But I think there's still more that can be emerging from this field to make it even more intuitive because I don't think it's quite enough just yet to say, all right, well, you failed the security policy, right? And like now you have to go figure that out. I think there's now like that's the beginning of the feedback loop. And so the question is how do you continue to guide that developer down the set of things that they need to make complying with those policies more intuitive? And that's where I think we have a lot to still explore as practitioners because I think we do a really great job now of distributing the policy and the best practices and the tools in a lot of ways. DevSecOps is a perfect example, but how we do that and then how we leave the developer still back to the proper outcome is something that I often see that still needs a lot of work from a usability perspective. Cool, thanks Kyle. Another question, what have you observed are some great catalysts in large organizations that help the transition to a DevOps mindset, which in your experience, brought quick wins that clearly demonstrated the benefits of adopting a DevOps culture and practices to improve delivery. I need to think about this one for a minute. A long question. Yeah, well, digital transformation is definitely not it. I saw a great slide about what prompted and catalyzed digital transformation in my organization. The CTO, the CIO, or COVID and COVID had a checkbox in it. I think while I don't wanna make light of any of the suffering that's happened here with as a result of this, I do think unfortunately the catalyst, and maybe I'll just, is it okay if I just stop my screen share here, Harry? Yeah, Susan Lee? Yeah, cool. One of the things that I think is like, unfortunately, one of the things that is that catalyst is often, it's often some unfortunate situation. And more often than not, it's like there was a security incident, there was some downtime, a third party vendor didn't meet SLA or something like this. And there's a lot of other things that sort of like permeate up to this sort of like challenge where then like management leadership is now in this mindset of like, okay, this bad thing happened, we need to mitigate that. And I think that's often, it's just too late, right? And so this is where I try to like tell the story from the earlier stage because I recognize as we get to the later stage those catalysts are actually really hard to create. It's not clear to me what is a consistent set of catalyzms. I think that the mainstream adoption of DevOps is definitely one of those things that's helping organizations that move to cloud but these things are really slow. So they happen over a long period of time. I think the things that we have more control over is how we tell the story, how we advocate for the interests of our teams, how we create that like shared set of conversations across an engineering group to advocate that, how we start speaking the language of business and how we advocate it. So like if you go to a Chief Revenue Officer they don't understand what it means to say like I need to like scale the Kubernetes cluster or something like that. They're just like, okay, you're gonna add more servers like that should be just done, right? But if you frame it like, hey, here's our what's a door metrics and here's the result of how things are getting slowed down. And if you want things delivered on time we need to move this number. I think that's you're getting closer to speaking that language because I mean a sales team is very data driven a marketing team very data driven and we don't often try to create that same kind of data and use that data to justify some of our investments the same way that other teams do as engineers. And I think like it's expensive to do that. And I think it's something that gets thought about way too late in the cycle and this is why door metrics are usually something that like large organizations are thinking about. But if we can find ways to make these tools easier to adopt then it's less of a conversation of time and energy investment where you need someone to sign off you can kind of just do it it's a commodity at that point. But if it isn't that easy then you need to have some form of like information that you can really tell the story and meet people with where they're at and just recognizing that like other parts of the organization maybe don't understand what's going on in the engineering team it's a bit of a black box and that you need to translate that to them and say here is a set of metrics that you can understand which kind of like thin slices the situation and here's why and here's how it'll be good for you. I think we tend to lean with like if you don't do this, it'll go down and that's like a fear-based approach but if you talk about it as a profit center here's how we can make more money like now the sales teams are your price up like oh, we like to make more money, right? So I think it's both storytelling a bit and I use analogies a lot which sometimes miss the point but that's what I've tried to get across sometimes when I say like a snake's clawing an elephant or these kinds of things. Okay, cool, thanks Kyle. I don't see there's any questions. So lost chance guys, you guys have any questions? Please put them in the Q&A panel. So I have a question actually. So one of the questions mentioned DevSecOps or DevOpsSec, right? So this is like a term that has been recently coined and in your slides you mentioned a lot about DevOps and security and compliance, right? What is your sort of feeling about this term DevSecOps? Would you consider your practices DevSecOps? I mean, I think any term like this anytime we're branding something like this in our community it's often like us trying to translate something we've been doing into something that we're trying to more commoditize and lower the cost of so it's more accessible and like more mainstream, right? And I think that generally is what I'm preaching on from my soapbox, right? Like that's the thing I'm trying to get across. So I align with that very well. I'm certainly not as deep into the security space or the DevSecOps space myself, but I do look at when I zoom out and look at the macro effect that is a great example of a more a slightly more niche area within DevSecOps. I think now you have things like we were talking earlier before the call about AIOps area and like that's kind of the same idea. It's like we're trying to make this segment of technology more accessible. And that's where I really love the whole like DevSecOps AIOps like whatever ops you wanna come up with. I think to the extent that that DevSecOps movement continues and it continues down that path. And you see AIOps follow and you see other emerging, I would expect there's gonna be something related to front end at some point that kind of gets coined. I think that's generally good because overall what it's doing is it's lowering the barrier to entry for the developers who don't wanna struggle with the technology and need to meet their deliverables. And then they can say, hey, look, I can do DevSecOps. They can even put that on their resume. Like I've been working in a company that does DevSecOps, right? That's good for everybody. I think what we have to recognize is like what is the pathway there? What are we trying to achieve? And how do we then like look for other areas where we can bring down that? And if the way we do that is by like coining a term so that people can like organize around it and bring their knowledge and expertise. I think that is incredibly aligned with what I believe we need to do to build cultures of delivery, that especially in security. Because security is often something that gets adopted way late in the curve.  The cost to use it is much lower. And the more we can bring things down the curve so they're easier to adopt, right? The better we do at maintaining that velocity versus stability paradigm as the group grows and the best practices and such evolve. Oh, thanks Carl. So I see there's no more questions. I think we can end of the session. So again, thank you Carl for this fantastic presentation. And thanks everyone for joining us today. The webinar recording and slides will be online later today. And we're looking forward to seeing you at a future CNCF webinar. Have a great day everyone. Thanks everybody.


Maybe you've been wondering recently what is going on with Into the Radius 2, and let me just start out by saying that the original Into the Radius, even though it turned out to be an extremely complete, well thought out and detailed VR game, it actually still strayed from the original path that the developers had when they first came up with Into the Radius. There was a lot left unrealized, and the developers aren't completely specific about what exactly was overly ambitious that they didn't achieve in the original Into the Radius, but I'm assuming since I did play Into the Radius 1.0, it just mirrors this possibly the most fantastic part of Into the Radius 1.0, that at least one of those overly ambitious ideas was to have the map be one gigantic map that doesn't have any loading times for different areas, it's just all clumped into one massive map. Back in a lie that was one of my favorite things about Into the Radius 1.0, but for very obvious reasons that wasn't really going to work, because that is a lot of shit to render on one map dude. So in Into the Radius 2, I think the developers are going to be spending a lot more time and energy trying to realize that original vision that they had for Into the Radius 1, but just couldn't quite achieve. But it seems like the overall goal for Into the Radius 2 is to preserve a lot of what made Into the Radius 1.0 so special and then just upgrade it. So that means all of those same gameplay mechanics that we love like weapon cleaning, eating food, customizing our bases, and even customizing weapons are going to be getting upgraded for Into the Radius 2. And better yet, we are also going to be getting multiplayer for this game. Into the Radius is no longer an isolated, lonely experience, you can experience it with your friends if you want to. I'm just going to come over here and chill on this rock dude.  Yeah, yeah. Sorry, okay. When we get back to talking about Into the Radius 2, as for the bigger changes that are coming into the Radius 2, one of them is that Into the Radius 2 story is completely different from the original Into the Radius, happening sometime after the Pachorst event, aka the Radius. And unfortunately, the man that we all know and love, alright, Explorer 61, isn't going to be returning into the Radius 2, to my knowledge. But we are going to be getting a brand new explorer, someone who travels a very similar path to Explorer 61, but in this new area, we're going to be able to travel to different locations that we've never seen before, encounter dangerous situations and entities that we've never even thought of. And apparently, our adventure has much more dire consequences than before. I don't know what the hell that means, but for the most part, I feel like in Into the Radius 1, Explorer 61, pretty much just, it's our job to research stuff, man. We basically go out, we're guinea pigs, we get killed, we come back, alright, and talk about what we saw. Now from a surface level, that is exactly what this game is. But if you haven't seen the ending, I really don't want to spoil that for you. You may have noticed that nothing we really do in this game has any severe consequence to the UNPSC or the world for that matter. This is pretty much, we're in the thick of it out here.  The most exciting thing to do in the Radius is get killed in an absolutely insane number of ways. But it sounds like in Into the Radius 2, we might have a little bit more weight to carry. There are going to be some consequences. Maybe you don't finish a mission in Into the Radius 2, the world explodes. I'm freaking excited to see what they mean dude, oh my gosh. One thing for sure, I really hope that they don't take cigarettes out of the game. Maybe even throw in some blunts dude. There are guys that tried to mod blunts into this game, and I'm not going to say that they did a bad job, but looking at this Into the Radius developer made cigarette, it's like, come on, we could get a bong in this game, I'm not saying do any of that stuff. This thing would be hilarious to have in a VR game. The developers really made it clear that these new locations and the overall look of Into the Radius 2 is going to be a level up from Into the Radius 1. The overall visual style is going to be basically a Baltic city, but and this is where it gets pretty damn exciting, this new location is basically taking place prior to the events of the Pachorist Anomaly, aka the Radius, it's that big beautiful thing in the sky. So we're going to be able to see how things were prior to the Pachorist Anomaly.  Now in general, the developers said that the gameplay is going to essentially be the same and feel the same in these new locations, but gameplay is apparently going to be affected by these so-called new factors. I was doing air quotes, that's why the lighter one of new factors. And I mean honestly, that's kind of cryptic. New factors doesn't give us very much information, but they said that they're going to release what those new factors are just later on down the line in development. So I'm pretty damn excited to see what these new factors are going to be and how drastically they're going to impact gameplay. Into the Radius is awesome. I love this game so much, you guys don't even know. This game helped me get my mind out of a really dark place during COVID.  But one thing that I am actually really worried about is I want Into the Radius 2 to have these next level graphics and next level locations. I also really really want this game to run like smoothly. Into the Radius, I'm not going to lie, it's a little bit of a labor of love when it comes to graphics and getting this baby to perform well. You really got to mess around with the graphics settings to get this just perfect, but when you really dial in those settings, it does play almost perfectly, dude. And I guess that's one of my big worries, alright? I don't want the devs to be overly ambitious when it comes to making the graphics this so-called next level up from Into the Radius because I mean dude, this game as is looks insane, especially on PCVR so it's like what is this next level that we're going to, huh? And how exactly are you gonna get there while still maintaining a game that performs well? Because dude, as good as the graphics are, if I have to be changing my graphics settings every 5 to 10 minutes because I play the game for a few minutes and it just looks beautiful, it just looks effortless and smooth.  You just want a game that looks good and performs really good and preferably doesn't have a BTR. I absolutely hate this thing. In fact, a tank can't shoot through. Hey, I'm assuming that's hey. I think these are giant stacks of hay. Believe it or not, equipment is getting an upgrade too. We're getting new tactical vests and backpacks so you have a little bit more customization when it comes to your play style and we're getting new options for upgrading your equipment, storing your equipment and we're also going to be getting upgrades to one of the most satisfying things you can do in this game, cleaning your weapons. And if you're wondering where I got this absolutely menacing looking gun, you're probably gonna want to go watch this video.   This changes the way the game feels so much. Is there any rule against smoking in the shooting range? I think in real life, yes, there definitely is. Oh my God, we can smoke in here. All right, dope. Apologies if my voice is sounding a little raspy, kind of stuffed up. I currently have a cold. Into the Radius 2 is going to be a full-fledged, single-player game, but you are going to be able to play co-op too, with up to four different players. So if you want to play with your friends, Into the Radius 2 is going to let you do that. The only thing though is the co-op save file is going to be different from the single-player save file, and there's no cross progression. So that kind of sucks, but then again, I'm just happy that we're gonna be able to play this game in co-op mode, period, because if you're new here, you might not know, but this has been quite the long ride for multiplayer. We've been asking the devs for multiplayer as long as we've been asking them to provide mod support, dude. I bet they're so tired of hearing this shit, but we need it. There also isn't going to be really any unique content that is exclusive to the single-player game mode. The developers even supposedly have already had like a little play test where they tried out multiplayer and Into the Radius 2. I'm assuming the early alpha version, but they said that Into the Radius, the entire gameplay loop and everything that you usually do in Into the Radius actually feels super different when you introduce other players into the mix. And I don't even know if they mean it in a good way, but I don't doubt that it's going to be good, and I'm super excited to see how Into the Radius 2 plays differently with the introduction of multiplayer.  Anyways guys, that is the end of this little Into the Radius 2 update. I am absolutely pumped to play this game when it releases. I hope you guys enjoyed this video. Leave a comment if there's any Into the Radius related content you want to see in the future. Have an awesome rest of your weekend guys, and I will see you on the next one. Bye!


Well, the door is closed. So I guess it's time. Yeah, fantastic. So thank you all for being here. I'm Lorenzo Mangani from QXIP The company behind Homer sub-captured, I have protocol and a few other things actually Parts of good part of the team is here with me today. So Foslem is always the only occasion where we actually meet over the year, Andre Hey, I see a lot of friends in the audience. So thank you for being here Again Really quickly because we don't have a lot of time today. We're gonna present some news about our project specifically Homer 7 and how it finally rejoins with the RTC community. So Little big picture of our stack which has been evolving over time for those of you who are not familiar with Homer. Homer is a collector Which is purpose for you know tracking and generating metric statistics time series indexing out of data Originally, we are we were CIP centric or you know very CIP focused platform. This is not scrolling, right? Well, okay So the platform has been initially created to track CIP then it evolved to also track RTP RTCP statistics Logs and so on so forth until you know RTC became popular and we had to rethink everything all over again Which is what really happened in Homer 7. So Homer 7 is really an Evolution of the project which tries to get rid of some of our design limitations and open the doors to whatever is coming next So we don't want to make the same mistakes again So we dropped the CIP centric. We dropped being Tied to a specific databases. We dropped our internal way of doing statistics. We dropped the way we're doing correlation We basically threw it all away. So we kept the concept of Homer and we tried to rethink Oops how it works internally. So instead of having you know static map protocols now We have custom ones so anybody can take our platform define a new protocol Of course CIP is going to be already there, but we you know did this to prepare for really events So events coming from Janus media soups and now also Jitsi Can be indexed can be correlated with other protocols. It's it becomes a generic platform for collecting Data flows and events so totally right.  So we threw it all away and we did it in the modern Technology so we picked no JS just because there's a lot of people that are good with it So we can get help and we can get contributions Again designed to support any protocol. So this is going to be a generic collector. Of course, it's Tailor to voice and real-time communication. So it comes already with you know some concepts that maybe other platforms don't have In terms of tying things together and correlating It's integration ready. So we no longer Forced people into our little island come and see the statistics that are made for you But we rather do the opposite so we open it up so that we can send and stream whatever the platform is Processing and generating to pretty much anything that's out there and I'll show you some of this We went standalone so the previous versions of Homer could only be Assembled using open sips and come I do as shells for the capture functions. This is no longer the case So we have our independent capture servers and agents We have two branches one is in go and it's you know Tailored for performance and stability the other one is in no JS and it's Taylor for hacking I'm working on the second one, of course And then we try to turn the project into a building block for other people to do the same thing we did in their platform So Homer until the previous version was something that you had to install and use and that was it Now we want to allow people just to use Let's say a headless version of Homer where they provide the API they provide the UI Sorry, they provide the visualization or the integration Maybe they want to capture some stuff and using in a customer portal. They don't need our entire stack They only need specific elements of it. So we broke it all down And this is how more or less Correct. Yeah, this is more or less how it looks today. So in Center out Left to right. So on the left you see you know starting from the classic We have all of the void platforms that we support natively and of course This doesn't include anything that you can port mirror or just pan to the platform It doesn't matter but asterisk freeze, which I made the open sips RTP engine on tp proxy They all come with native HEP support. So you flip a switch and they're sending data to our platform We now have also a harder set of agent that we use for Just normal sniffing statistics lawful interception a bunch of purposes Which is a darning partnership with Kubro and then we have all of the newcomer So we have Janus media super and jitsimi now our finally first-class citizens into the platform All of these splits between two main sockets One is the HEP one that you probably already familiar with so that's our encapsulation protocol Which is native in those platforms that we mentioned the other one is just a generic JSON socket that we used to receive whatever you send to it and Inside of this socket. We have Processors or pipelines that are modular where we can decide. Hey, here's a new type of report that you know Jitsi meet is gonna send from the browser and from those reports. We can go and tap out any data So this is completely dynamic. It's not something that's hard-coded because those events are not, you know Based on specs that might change maybe next week does a new metric being shipped out But one of these products that you want to make a use for so we try to make it easy for this to to be possible Once data makes it into Homer it gets of course processed index prepared for correlation And then it splits into these three main groups that you see on the right So TS is for time series Data is for whatever we index and we make searchable and logs are logs So the lowest let's say for in based on complexity there, you know different use cases different types of data that we want to handle And now they're all separate. So we have those three nice pipelines with the same event We can choose a let's pick those, you know two Properties and store them in the database for search Let's take those three metrics and send them to Prometheus or influx to be or whatever we want And you can mix all of the above. So what we really wanted is to just give people finally the choice the option to do what they want Why because we find that a lot of our users and customers already have some of those systems. They already use them They're already tracking, you know system load or some other applications status and events somewhere and we just want to make it easy to plug into those Platforms be it metrics logs and whatever else. So you see here on the list the influx to be for me to send elastic are mainly the three most popular targets that we have for statistics, but you know Elastic for instance can take all documents. So you could build a homer You just sense everything to elastic search and that's all you have you don't have a UI You don't have any of our databases just trim it all there and hopefully mix it with other data That you have same for time series and so on so forth. We'll get into more detail internally It's all simplified. So we have those sockets. We come with those two initial ones But you know, hopefully people will contribute more or extend them We have the API which is mostly used for you know, connecting to the user interface and the clients and so on And the two main features that I mentioned before and you know, this is just fresh out of the oven So, you know, I decided not to go into a lot of technical detail, but where explain how they work Protomapping is the stage where we define what comes into the platform from either of the sockets so Of course once we parse everything it becomes a JSON object from these JSON object We can start and deciding what we're gonna use for what so maybe that's a specific header that we're gonna elect for correlation Maybe that specific headers that we want to be indexed in a certain way that we want to be wildcard searchable or I don't know The integrator will decide for the majority of cases and on top of these proto mapping rules We have correlation rules. So For those of you that use the old homer correlation was sort of a static concept So you were going for instance from a call ID and trying and adding suffixes post fixes or maybe extracting an XC ID To find what was the next step On in number seven. This is a cascading concept. So a C-plag could find another C-plag These other C-plag could find a log this log could find Media statistics and so on so forth. Of course, it can be a circular concept if that's the case But you get the gist. So we just want each method to be able to find more information and bring it all together There's a new of course user interface to leverage all of the above it's based on HEPIC, which is the commercial version. Hey, Tari of our stack So this brings a whole lot of you know new features into the experience the old Homer 5 interface. I think is the main reason why we don't get a lot of contributions. It was homemade It was a mess. It was something only we could understand and not always, you know There's parts that me Alexander were going back to and you know, we also couldn't read it so we decided to take it all throw it in the bin and Have somebody redesign this properly. So this is now a Proper UI where you know a web developer can come in and within hopefully 10 15 minutes Make the extension that they want without getting into our mind. I mean telling is you know, I mean our cultures I think are probably the issue here. So this is no longer the limitation as other people working on this and it makes a lot of sense It's pretty much the same thing. So, you know, we run a time-based or time-range application We have widgets which are mainly useful for displaying charts or looking for data The latest addition that you see here is lucky support. So Homer is now a full Fledged lucky client so we can search using the tags and stuff the same way that Grafana does in the latest release Homer is already able of doing so you can send Seep or logs or whatever it is that you want to store as a simple log with labels to lucky as opposed to the main database So we can now even create different storage types for the data that we send and the beauty of it is that hockey lucky Of course is providing labels. So the search is dynamic as you type You get all of the options and it's really easy to get data together Of course logs correlated to seep seep related to log. So it doesn't matter where you start You're always gonna end up with the full cycle information Time range selection just like the previous version everything that you have on a dashboard Everything that you're doing is based on a range that you have selected or that you're you know changing as you go Typical case, you know what's happening in the last 24 hours who does a spike? Let me zoom into that What is the spike from going back to the logs message it all statistics that are behind it? We mentioned custom protocols and statistics so this is a zoom into how those widgets are configured We currently support influx dbm from it you so the Homer UI can display data straight off those two platforms without mirroring without doing Anything so we write to them and we read from them in terms of displaying it multi-select I mean this works pretty much just like you know, it's It's based on the original. So for the influx dbm widget It's loosely based on our chronograph works for the Prometheus one. Of course our Prometheus works Widgets for search specifically can be fully customized. So if we're talking about seep, we're gonna have you know All of the standard seep headers. But what if we're talking about? GC events what do they have what what are the headers that we care about and do we really care about the same ones? So users here can or integrators here can choose what they index as we said and of course everything that they index becomes available Into this dynamic form. So if you have 10 fields any of your users can choose whatever fields they want to Have on their desk every day. So to make it comfortable Inside of those widgets Don't see the time I'm gonna check it good inside those widgets Everything is again dynamic. So you can see here an example for some protocols that we have in our test stack So we have seep. We have logs. We have RTP reports, which now can be indexed as searchable data If you have that need in your you know support case We have the Janus protocol. I didn't make it in time to add GC But that's what we implemented just over the last few days. So Search results are dynamic tables depending on what they are they display different columns when you select one of those rows the system starts the Starts fetching all of those correlated legs and correlated information. So you start from a CIP session You end up with maybe three CIP sessions because they're correlated some logs so on so forth I don't want to get into more detail about this because I guess everybody is pretty much familiar with the scope of this application We display everything as flows. This now includes anything that's captured. So previous versions This was only valid for CIP or let's say network Type of events now it's everything that we capture. So in the in the flow, you will see logs You will see RTP statistics. You will see whatever you send to the platform that belongs there So the juicy part RTC time series and for this I'm going to zoom in to that previous image How do we do this? So Janus has its own type of events and they're you know Completely different from those of media soup and sure enough completely different from those of GC What we didn't want here is to create an adapter for each So the JSON socket that we have is simply able to recognize types by the properties that they're carrying. So yes Let's say for the GC events the way we collect them right now is not from the server, but rather from the browser So we use the analytics. I don't remember what it's called function where you can inject the library into your GC client just like they do for Google Analytics or call stats We can take all of those events instead of sending man to you know, somebody else's storage We send it to our own we index them the way we want and we can make sense of that Mostly as time series because you know, it doesn't really make sense to keep any of those events as originals But when you start extracting, you know the round three time the jitter or whatever else You can create really really nice pictures such as this one So, you know, you can instantly start tapping into what your platforms are measuring You can decide how you take those platforms. So is it gonna be by IP?  Maybe comes from signaling Maybe you have any specific field within the events that tells you who's the customer all of this is now programmable So any of you hopefully can go in can use it for you know the Standard stuff so whatever is common within those platforms But if you're developing one of those platforms the best part is that you can exactly start Offloading, you know some of the the tasks directly into Homer This is an example of the same in Elasticsearch as we said now you're free to store whatever data you want whatever you want By default we use Postgres for index data five. Yeah Postgres for index data, but again, you want to send it to Elastic do it you want to make statistics in another platform great Freedom is the is really the key here. So This said last few minutes. Why should you use Homer and Homer 7 specifically? The first reason is that it's now full-featured. So the previous platform by our own admission, you know I had several limitations that were kind of you know a restricted in the use cases. This is now longer the case So we should be ready for anything.  So by now it's been Many many many years and I think we work with everything and anything out there Some of our customers are incredibly large. So we also follow, you know tier one Networks fortune hundreds out there. It's incredible. You know when I'll you know large enterprises how many phones they have and I'll Finally they realize who I have to monitor this stuff. So we've seen it all and we decided to stay agnostic So we don't care about anything specific compatibility is a global HEP native, of course, this is a booster, you know all of the platforms that already support HEP You don't have to do anything to use and finally That's a model behind this so more five again was a little bit of an original concept This one is standardized so we can support it More efficiently the use cases of course packet capture Which was the previous one RTC analytics, which is the new chapter that we're really focusing on So talking to anything troubleshooting doing alerting and alarms based on all of these new data That we now collect intersect and correlate big data Because we can stream whatever we're extracting to anything and finally machine learning, which is the new This data it's really easy to use it for something and we have a different presentation for that that doesn't fit today Lessons learned with Homer and using Homer There's a team line between love and hate your customer get pissed really easy, especially the big one So if you cannot offer them a good model if you cannot understand what their problem is They're gonna leave for somebody who does Early bearers get to find the best bugs if you start monitoring when you start designing you don't have a problem to solve later You already know, you know the initial issues you don't force your customer going through the bugs that you don't even have visibility over Complexity is the hardest thing to capture the later you do it the worst is gonna be when you go and try to capture already You know a complex system that spends over 12 data centers and already has 12 protocols Going in ways that not even the engineers understand go and explain it to the monitoring guy. Good luck You know, we're gonna take weeks just to understand what the problem is So doing it early pays off and then of course the higher you fly the higher you fall when you have a lot of traffic and you start You know having issues Those cost money. So working on this early is really paying off to many of the customers that we're working with Installing the easy way Docker so we have Docker containers for everything that's already recipes that mix all of the features So hopefully you can go in there and find something that falls close to your use case and use it as a starting point If you don't find it open initial will do it How to support Homer by using it by talking about it by letting us know why you even don't use it sometimes Or what's preventing you from you know taking it where you need we need community input. So We've been working really really hard to keep, you know, everything open source To keep it useful now also other platforms are able to use the app protocol to the same thing that we're doing and we're super excited about it But we really, you know the community feedback to understand what we're doing right and wrong Are there any questions? I don't think I have any time We got two minutes two minutes for questions. Does anybody have a question and keep in mind you get a shirt if you do Yes What's your specific usage for a hat this important protocol that Seems that is going for the most Or transport for that analysis well have what we were hoping for have was it to be a generic that? Anybody could use to make a platform to make the same thing that we're doing or to make it easy for Somebody to monitor, you know a new product that we're making so what we're hoping for it is that it you know It continues or it becomes a standard that more and more platforms and doors And we hope not to be the only ones using it and I think in the next presentation will find out that we're not I hope I make it there What's the relationship between HEPIC and The the HOMA product the HEP protocol really HEPIC is something that we Designed because some really large companies apparently they really don't want any open source into the platform So we kind of have two tracks HEPIC is something that's more designed for the very large And complex network for you know people that need to spend money to do it Homer does really the same but you know it's a fully community. So they don't have any code in common They're just using the very same encapsulation protocol and they go for the same goal There you go. Thank you. So my question is what's the compatibility between Homer 5 and Homer 7? In terms of capture agent 100% so they still use the HEP protocol nothing changes everybody that was Yeah, HEP 3 let's say from HEP 3 up. It's all the same. So open seeps remains the Leading cities in terms of variety, but anybody that sends HEP it's able to continue cool The difference is in the JSON socket. So now we're able to get also those non-structured events and whatnot Those shirts are nice come on guys One more There you go. Sorry short. I'll bring you on Is it packaged in Some distribution not yet. No mostly because it's very modular So the way that you assemble it makes it into many pieces. Hopefully you don't need all of them So no, we don't have that yet. Actually, you know, we never been huge fans of making static packages Also because it's different technologies, but we'll get there hopefully as a contribution Thank you. Well you get it anyway Thank you so much


This is the propeller blades. I've been using on my boat. Yeah, I took it apart First I made these blades a little bigger than I thought they should be and then trim them down to the point where I thought they were a little bit too small so I could figure the size should be just a little bit bigger than that and I was hammering them a lot getting them into the right kind of shape and Once I was satisfied with them I decided to make some really good copies because you know with all the hammering and bending on this they don't come out Super smooth, you know, they're smooth-ish, but definitely not super smooth. So then I took the blades off And pulled out a piece of curvy pipe I've been saving Because the propeller blades it's kind of nice to have a curve one way this way But then the opposite way this way, you know like a saddle curve and an inside curve of a pipe does that so I Layed this on here figured out where it matched the closest Drew my blade a little bit bigger or actually a little longer in the same same width Cut it out and then I got three blades That I didn't have to curve so because I didn't curve them the curve is really even and there's no dense or anything so this should be Pretty much an optimized propeller for the boat Hoping pretty close. Anyway. Oh before I made this one. I also did some calculations. See that calculations to You know check that my propeller blades are at least theoretically about right and they they seem pretty good based on the Calculations I did increase the pitch just a little bit based on the calculations Because according to my calculations my old propeller was limiting my speed at about nine miles per hour And I got up to maybe a little bit more than that and I got up to eight point nine miles per hour So that's pretty good. So I made this one so it'll hopefully go more like tennis I've used up all my internal curves pipes So hopefully I got it. Oh look at that So smooth I did have to buff the inside because that pipe was an exhaust pipe So the outer curve Was a very shiny and polished, but the inside was pretty rough If you want to see all the details of how this is fit together just go back a few videos to where I made one What's a good looking propeller hope it works as good as it looks Well that way sounds like it's balanced a lot better than the last one kind of want to take the boat out I don't know about the weather though.  I just put one foot there and one foot here Ah should be no problem. I could put half my weight on that Or I could stand right on the front pee off the side. Oh, maybe I'll do that. That sounds kind of fun You know, I will need to be able to get up to the roof To deploy my solar covers and undo them when I'm out in the water. So I should test this Now I'm gonna go. Okay. Bye. I think before I go in I'm gonna get some exercise all right 10 laps around the bay pedals only alternating between legs and arms all right Looks like a good spot to start. All right. Jamie. What are you doing here? So this gear here fits in here and it presses against this gear And it's pushed against the gear with this rubber wheel Now the rubber wheel was pushing against You know this round pipe And there wasn't that much surface area for it to really push on And once in a while if I was pedaling hard it would skip a gear Make a terrible sound didn't get damaged because the material is really strong I would like to fix that though. So I'm putting this flat plate along the back I'm not sure if it's thick enough. It might end up just getting bent over time. Still It'll give a better surface for the wheel to press against this wheel to press against then Just that pipe I cut this out of an old toaster oven I put a bit of oil on there too That should help I didn't put oil on it at the beginning because I wanted the teeth to wear into each other And these are way smoother than when I made it It looks like that worked There's a pipe inside that gets smashed in there And it presses against the tabs at the bottom of these that are folded up And it holds it locks it all together. So when I smashed that pipe in It bent these propeller blades back further than I wanted them to be I was hoping it wouldn't really matter So I just tried it Now I'm thinking maybe that mattered more than I was hoping so I took my vise grapes and cranked them forward bent them I didn't want to do that because I don't want to loosen them but they still seem Like they're in there tight. So I think it'll be all right Let's see if that makes any difference here All right, let's give that stuff a try All right pedals don't skip All right, let's see if that propeller made any difference does feel better. Oh, that feels a lot better Can you tell me if this is any faster or slower or what than yesterday?


What is up everybody branding adult here senior managing editor at numberfire.com and I've got three picks I like for the Valero, Texas open at Fandalsports book this week First up is Corey Connors Sometimes you're interested in a bet because of good current form. Sometimes it's course history. Sometimes it's course fit statistically But with Corey Connors, it's all three this week Connors is a former winner at TPC San Antonio's course back in 2019 He's also finished 26th and 14th at this course while putting pretty well on these screens And if you follow Corey Connors closely, you know to monitor those putting stats more importantly The irons are what's carrying Connors at this track But also long-term Connors over the past year ranks in the 97th percentile among this field and adjusted stroke Skeen to approach which is my stat that accounts for recency and field strength So plenty to like with Corey Connors this week Next up is Gary Woodland former U.S. Open winner Gary Woodland returning to form in time for a return to TPC San Antonio Where he finished T6 a year ago Woodland ranks in the 91st percentile and driving distance over the past 50 rounds According to fantasy national while sitting in the 15th percentile in fairways gained That's a fine mix though because according to data golf TPC San Antonio's O's course boasts the least penalizing fairway misses on the PGA tour Woodland is strong across the board right now He has used that for two top fives and a top 25 in his past four starts Notably Woodland is a really strong putter from within 15 feet That is a great sign for his long-term putting stats. Lastly. I like Mito Pereira His odds have shot down the board, which is not what you want to see But there's still some value on him at plus 5500 to me this week He's going to be a course debutant Sure, but he's a long hitter with a lot in his profile to like among the field Pereira ranks in the 92nd percentile and adjusted at t-degree in play over the past year He is in the 95th percentile and adjusted approach in that same time frame He's been dominant on par fours one of the best close range putters And he's actually expected for a lot of putting regression in his favor So I think that we can still buy low on Pereira who's got some really good results in his past four starts Including a t-15 at the Genesis, which is a strong field t-30 at the Honda classic Miss the cut at the volatile players, which I'm fine with t-27 at the valis bar And if you don't think he has the wind juice, that's fine A top 10 is very much in play as well. That'll do it for my Valera Texas Open picks. Best of luck this weekend