Okay, are we good to go? All right, welcome. Thanks for coming over. This is Chris, I'm Dirk. We're going to talk about the next step of OpenStack evolution for NFV deployments. So what we want you to take away from this talk is not so much like a detailed list of NFV tackle requirements to OpenStack, but a bit more of like an understanding, say how the development process is changing. So in the NFV tackle environment, so how we are currently moving on, like transitioning our systems to like a fully cloud-based approach, so leveraging all the different open source components. So I'm a chief researcher at NEC Labs in Germany. So mainly working on like networking in general, in particular on SDN. And what interests me at the moment is so how can we transform the current systems, so leveraging NFV and SDN, so how we can design better mobile networks in particular. So doing some work in the IRTF and also involved in OP NFV. I'm Chris Wright. I'm the chief technologist at Red Hat and I've been working in open source for quite some time. My background is coming from Linux, being a Linux kernel developer and the hypervisors virtualization, the networking side of the IO path for hypervisors is what sort of brought me to where we are now, which is talking about how do we transform the industry? How do we move the telcos networks from the traditional model that we see today to a cloud-based model that we're building together right now? Okay. So just a quick overview of what NEC is doing in that space. So NEC is an IT and communications company in Japan obviously. So we are doing cloud infrastructure and telecom networks and services. So we have been involved in like UMTS where we had the first UMTS deployment, the first LTE deployment. Had an early VPC system and in general we have been working with Linux-based and open source-based platforms for quite some time. So you see on that diagram basically our VEPC system. So I'll tell you a bit more on that in a second. We were founding members of ONF, Open Daylight, OpenFV and one of our in a range of open source projects and relevant standards activities in this space. And so our platform today is like, yeah, we've chosen Red Hat Enterprise Linux for our NFVI systems that we run on code servers like using different network interfaces today using OpenV switch and DPDK. We also have chosen Red Hat Enterprise Linux OpenStack platform for our WIM. And so NEC has had a product like for orchestration management and of course our different NFV applications. So the system with different third party vendors like for building say complete systems for customers. And so I'm not sure how much you are aware of so how like the telco industries has been involved in recent years. So for NEC, so like our say previous product range as for like many other vendors in that space was like based on the so-called advanced telecommunications architecture systems. So like these were the like five nines highly reliable redundant systems. So big boxes with all the monitoring management features. So we have chosen Linux quite early time so we're building those systems. And from those we derived like the first generation of virtualized systems. So it was at that time our in-house developed resource management for orchestration. And so now as I told you earlier we are moving this to like an open source platform say generalizing the system, try to figure out so what of the specific proprietary developments we had done actually make sense in like upstream projects and then how we can be like successfully contribute them. And perhaps I'm sorry I was one too far. So we are currently working in NOPNFV which was like the whole industry basically to figure out what are requirements that cover the whole range of the open source projects and systems and so how we can as an industry at large like do a useful contribution to those. Did I want to talk with this? Probably not. So I have to ask you a question. ATCA, the A, the first day is advanced and I imagine that's because it was Linux based. Well for the NEC case yes. And the interesting thing to note there is open source already has a history in this environment so we're just expanding the footprint of the work we've been building on for many, many years. It's probably over this point a decade ago when the Linux industry was focused on bringing Linux into the telco environment so we're just expanding on that and if you look at this, you know, Dirk mentioned the OPNFE project. You probably had a chance to hear about that. Is anybody here not familiar with OPNFE? All right, well, I guess we're ready for beers then. The OPNFE project, I think the purpose of this project is across a number of dimensions but one of the things that's important to notice here, we're at the OpenStack Summit. We spend a lot of time talking about OpenStack and telco but the OpenStack portion or orchestration component of this overall software stack is just one piece. If you look at all of the projects up here that build up the NFDI or the virtualization infrastructure, the VIM layer, the management layer is one piece but there's critical components underneath. So what happens when you wanna make a change to the platform that spans all of these projects? OPNFE is there to help bring together all these different building blocks, organize the development efforts across these different building blocks and potentially bring them together due integration testing show that we're actually building something that works for the telco environment and sort of iterate and continue on that process.  Most of them you already know from an OpenStack context but again, there's a significant amount of work that happens below the OpenStack layer. See if I can get this to go the right direction. All right, this is just an obligatory slide about Red Hat and what we're doing and why we care about open source and upstream and the leadership that we bring there. We have a long history of being an open source company. What's important for us is working together with both the development community and the user community to bring features into the software projects that we take from an upstream and then deliver as productized versions of those upstream projects. What that means is we're developing relationships on both sides and it's really important to understand that if you are only in the developer community or you're only on the user side, you're not getting the full picture and our goal is to help the whole industry move forward and build these platforms in a way that they're reusable across the industry because one of the dangers that we see is as you build from an upstream project point of view, as you build features on top of that and don't contribute them back to the upstream project, you've created something that's both a fork and a long-term maintenance burden for you as a vendor and it's a piece of technology that's tying your customer to you in a way that that customer isn't necessarily looking for. Part of that is working together with our partners so this is why we're here today. So NEC and Red Hat saying these are all the cool things that we're doing together to make any NFV real and so you'll see some of the specific work activities that we've done in the upstream to enable NFV as a platform. The last piece there is talking about the robustness, stability, quality of the software that comes out of these open source projects and delivered as products. You're talking about platforms that are already running significant infrastructure, trading platforms, air control traffic platforms, well, I was gonna say train systems but it's kind of awkward timing but train systems as well so there's a lot of interesting effort going into building these as enterprise quality platforms that are critical to the telco environment as well. So this is just a simple view of how we take those individual projects and turn those into product components. You see Neutron and Nova on the left side from the OPNFE picture translate that over to what we call RELL OSP so that's Red Hat Enterprise Linux OpenStack platform in that upper box you see compute network storage. Those are the obvious key components of a cloud and the management piece really is what allows you to deploy and continue to monitor, maintain and upgrade your infrastructure. Underneath that are these other key components. We're all familiar with KVM and its user space component QMU, the application library on top of that that allows you to program, gives it a programming interface as Libvert and we've had to make a lot of modifications in the KVM and Libvert layers as we're trying to expose features out through OpenStack. At the bottom you see an SDN controller and Ceph or potentially Gluster as a storage technology and there at the bottom in the sense that these cross all of the compute nodes in a data center. For us the SDN controller is either something available through partners, through a third party or we're working heavily on the Open Daylight project and hope to bring that into part of our product portfolio in the near future. On the right hand side you see something called CloudForms. There's an upstream project called ManageIQ and this is an orchestration framework really. It's a tool that allows you to manage your infrastructure. It has a history that starts with doing kind of taking events from your infrastructure and then responding to those events and changing how you're doing resource allocation and giving you kind of a catalog of resources. That type of activity is similar to what you see in a management orchestration layer in the Etsy NFV reference architecture. So if you look at what we're doing in OP NFV, we talked about some of those specific pieces. We talked about OP NFV being a mechanism for tying those pieces together. On the left hand side, that's just the platform and in OP NFV one of the things that we're trying to build is testing infrastructure. So we wanna take all these pieces, we're modifying them upstream, we're bringing them back into OP NFV. What do we do with those? We have a project called Feros which is geared towards building actual physical lab infrastructure so that we can run this environment and actually run, like use a traffic generator and run telco type workloads on top of this platform to validate that it's actually doing that we've set out to enable it to do. Some of the components that build up the OP NFV project that help us get to that point. On the left, you know, the right hand side, the green stuff, the far left box is the continuous building integration. So we need a CI system. We need to be able to bring these pieces together, assemble them and then launch them into a testing phase. And so you see code names internally to the OP NFV project of projects that we have focused on deployment, the integration step and the testing step. And finally, what's really gonna be important going forward. So this is just foundational building blocks. How do we make this whole system work, validate, test, iterate, like we wanna make sure we have a stable platform that we're starting from. What we're really trying to do is bring it forward. And on the right hand side, you see the requirements projects. And we'll talk a little bit about some of those requirements projects later. But in those requirements, we're looking at what are the functional gaps in the open stack, Linux, KVM combination that we're using to build a network virtualization infrastructure layer. And then how do we take those functional gaps and turn those into development efforts and actually solve the problems that we're trying to solve for the telco use case. Okay. So looking a bit, so what is actually the motivation for like the industry to really invest so much money into NFV. So for me, it's really three things. So automation really being the most important one. So being able to deploy systems at large scale in a fully automated fashion, have the full lifecycle management automated elasticity of systems. And then as a result, we have all these benefits from flexibility. So if you wanna like roll out new services, that's all what's going to happen in 5G networks, right? So like reducing the deployment times from like days as today and two seconds. So adding new services, removing new services without having to actually change anything with the physical infrastructure. That's a key benefit. And then maybe actually maybe less important is the whole cost efficiency through consolidation benefits. Also important, also important to have good performance and so on. But the first two are really the key drivers for NFV at this point. But specifically, so when like we talked to our customers, for example, so we get a list of actually concrete requirements. So like availability in the virtualized networks, fault management for that. So remember like five nine's ATCA systems. So in the cloud, these things are all a bit different. So our mission is to provide the same level of availability with a more flexible approach. So faults can happen. It kind of have to be able to detect them and react accordingly. Performance, so you want to virtualize, but you also really want to like take advantage of like the hardware capabilities. And like especially in like certain Teco functions, it's really important to squeeze the last bit of performance out of the functions. And then so like building larger systems like requires new forms of orchestration that like across data center, across domains. That's also an important requirement we are getting. And so for the rest of this talk, so we're going through like two selected work items that the industry at large, whatever NNAC in particular, have been working on. So this is our like complete list. So detecting and notifying about hardware failures. That's what I just mentioned. So you need to be able to really know what's going on in the infrastructure to be able to react correctly. Collecting information and configuring BM allocation was all like CPU pending Yuma topic. I mentioned orchestration already. So open stack availability. So the availability of the WIM itself is important. Like physical server scale out, live system upgrade without like minimizing the overall system availability. Like more advanced VM connectivity also has been discussed today in some talks and then better ways to control machine machines. So today we are focusing on the first two. So it's a little bit. So what's the motivation behind? So what's our approaches and what's happening in the open source community? So as I mentioned before, so of course we know failures can always happen. So everything kind of has a limited lifestyle and always has kind of problems. So the question is more how to really avoid impact on like critical service availability. So like, of course that's a general requirement for all kinds of networks, enterprise, and telco. But the telco environment, well this not being able to achieve this can really have dramatic consequences. So that's a real important thing. ATCA solved that by like, investing heavily in standby systems, intensive monitoring of all the functions, all the blades in the rack, like specific monitoring blades per box, and also a tight integration of the ATCA system into a network operators management system. So there was always a very like detailed and deep view from the management system into what's going on those boxes. And well, obviously in the cloud, this has to done differently. So we have to think about how to, what is the right weight and the right level of telemetry and a reaction approach. So without really losing all the benefits of virtual relations, without losing the ability to move systems around to scale out and so on. And so like in the ATCA world, I mean there were like whole taxonomies of what can go wrong and so how this information can be used to also predict, say more dramatic failures at some point. So like physical machine failure, the chassis can have problems, storage can have all kinds of problems, the network can have different problems. So there was quite some effort in really analyzing this very, very deeply. And telecom operators today, I mean still have like the desire to be very well informed what's going on the system, maybe not to that very detailed level, but still that's an important requirement to at least be able to know that for certain functions. So in the NFV world, so in anything we're seeing three different approaches at the moment, so there's like first approach basically, is like reporting like hardware failures through the hypervisor to VVM and from there to the say element management system and then some higher layer orchestration system. So this would basically mean like the VVM and potentially the NF application itself that would be aware of what's going on. So you can see this a little bit as a mechanism that systems that were ported directly from like previous platforms would use where you kind of want to integrate or still want to maintain the integration in the management system. So that's still something you have to be able to do today. Option two, that would be say the more cloud ready approach. So basically try to escalate problems through the VVM and then have ways to like for like automated reaction and then some escalation decision and at what point you need to like inform higher layers to react accordingly. And okay, so there are also of course like existing like systems that can also do certain monitoring functions in these cases. But it's interesting to like compare the first two. So for the like option one, say one question is how to actually report like problems from the hypervisor to VVM. So you had to think about how to like relay error notifications, so how to emulate this essentially. And so what function you would have to add to the guest OS to be able to deal with this information. For option two, so if you are like working with OpenStack, you probably know that it's like there's Xenometer for example for monitoring and storing events. And what would be like the cloud approach to use a general orchestration system to react to failures. So looking at what has been done in this space, especially for like option two, which is like I think the desirable midterm, the long-term approach. Actually quite some work by the community has been done so for addressing like Xenometer performance topics. So say how to deal better like with like high amounts of like measurement data. So like time to live extensions to Xenometer. There's has been like new work started on Gnocchi to the time series database that's currently going on. So that's good. So that's of course, that's the whole industry working on that. So companies like operators when providing requirements, developers right ahead, but also other companies like addressing those issues. That's hanging a very good step. It's also good to see that OP NFE and it's a doctor project, like identifying further requirements and are working on further implementation plans. So more on that later. If you're interested in the topic in general, so Russell, Brian had a nice blog post on availability topics for OpenStack. So I recommend you to check this out. So this is a nice example so how the industry is trying to address these really strict requirements from like operator customers and to arrive at a reliable but still flexible cloud-based solution. So the next topic, so we call that collecting information and configuring VM allocation. So if you think about, let's take this example here from our VEPC system running in a virtualized environment. So we have different functions, so in different VNFs. Some of them are like dealing with signalling communication, others are really forwarding as a user plane traffic. For some of them it makes sense to collocate them onto one box and to really optimize the intercommunication between them. And so you can see if you were like dealing with a user plane gateway, you really don't want to lose any performance by having to move like the application from one processor to the other. You really want to be sure that you have an optimal memory allocation in these cases. So all these numers, CPU pinning topics, there's a real justification behind this. So of course that's not only integral networks, we also know that other kinds of networks have similar requirements. But so having these really hard performance requirements, so vendors, so before we had all the open source solutions started to develop their own approaches how to really implement that, so also including us. And the way to do it is basically you have to actually be aware of what your infrastructure provides or how the architecture of your compute node looks like and so on to be able to make good decisions on how to allocate compute platforms and so on. You have to be able to express certain requirements for VNFs, for VMs and then do the allocation and do things like CPU pinning and RAM allocation. And yeah, so what our previous range of products did was to have a concept of expressing requirements for VMs. So basically some kind of flavor approach as we call it today so being able to set like the resource control level for different types of VMs. So for example, for some VMs it's really important to do CPU pinning, disabling, crossing newer nodes and disabling sharing of the physical core. And so here you see this example here. So assume you have like this, say, critical VM two, which is like initially configured so it was like level one or three, so that basically means we don't turn, or we don't disable a new node crossing. And if you turn this on, of course, you make sure that, well, the whole VM like stays on one new node and like similar here, you would turn on, or you would disable sharing physical course and then by that making sure that this critical function really does not share the course with any other application. So that's, I mean, state of the art in visualization today. So what we are doing is basically trying to transfer the way that our orchestrator used to work, like to open stack and trying to generalize the approach a little bit that makes sense, not only for the tech environment, but also for other types of deployments. And so also there, I mean, there has quite some work has been going on or has already partially completed. So the word driver guest VCPU topology configuration was part of Juno. The new one node placement is part of Kilo and word driver pinning guest VCPUs to host PCPUs. The large page allocation for guest memory and also the PCI based new mass scheduling. So this is all work where like companies like Red Hat have invested significant development resources where the whole industry provided requirements and contributed development resources. So quite a lot has been going on and that's quite an achievement, I have to say. Just want to add one thing to that. Yeah. You mentioned something that's important, which is the initial attempt to do this that NEC had worked on and a number of other folks in the industry was often unique to their view of the world. And so when these requirements were surfacing from the telco world to the open stack world, it looked really foreign to open stack people. One of the concerns was you're proposing an interface that says let me take this virtual machine and stick it on that machine right there on those CPUs with those banks of memory and the cloud side of the house saying you're out of your mind. That's absolutely crazy. It breaks the abstraction that we're trying to build with the cloud. And through this sort of back and forth, what is the real problem statement that you're trying to solve, not the solution that you're coming with. We converged on this set of blueprints and code merge that allows us to get the same level of packet processing efficiency without breaking the cloud model. And in fact, to a certain degree, as Dirk mentioned, this is useful for other use cases and you see in Amazon, for example, you can get an HPC instance. You could probably guess what's under the hood of that HPC instance. Right. And so looking a bit into the future, so we mentioned the OP NFV doctor project before. So this is like one of the projects in OP NFV that is like initially developing requirements. So what do we still need for fault management? What is not yet there? And then thinking about, okay, how can we implement this or design this, so in the right way and contribute this to upstream projects? So I'm not sure how much you had heard about OP NFV doctor so far, but so we have just released our first public document. So describing the whole idea and the concrete requirements and also some implementation ideas. So check it out on the OP NFV website. So there are two use cases that we have described. So one is like the fault management use case. So if assuming we have a hardware failure on a physical machine in our infrastructure, so what would be the best way to analyze this in the room and how do we decide, say, how to escalate this to higher layer orchestration systems? So for example, figuring out so what VMs were actually running on that box and so who kind of owned them and so what is the right way of informing higher layers? For example, enabling and active standby reaction. So standby reaction. So that's one thing. The other thing is like the kind of a maintenance use case. So I mean, even in the cloud we kind of have to change disks or upgrade systems at some point. And so there are the ideas that, so like cloud data center operator at some point, he signs, okay, I want to do this maintenance on this box and then also again figure out, so in the same way like a map this physical machine to like affected virtual machines and then notify higher layer orchestration. So the document I mentioned describes this in more detail and then also derives a kind of concrete list of requirements for that. And so there have been two blueprints coming out of that work so far. So one on Cilometer and one on Nova. So like notification alarm evaluator for Cilometer and so extensions to a new Nova API. So I think they have been discussed this week and so far we have gotten quite positive feedback. So that's I think for opening NFE quite good result. So in like this startup phase of the project it kind of shows how the industry is currently working on making fault management even better and trying to work with those absolute projects. So there's the link to the website for you there. And do you want to look at that too? So that's what we wanted to talk to you about today. First and foremost the telecom world, the telecommunications service providers are reinventing their networks and moving all of this infrastructure from function specific hardware, proprietary hardware, functions that are trapped in hardware and expensive and difficult to roll out ways to an open source infrastructure. And we believe that we can use these components to build the right level of performance and availability needed to address the market segment. Also important, just by being at the OpenStack summit this NFE platform is again more than just OpenStack. It's a broad set of projects and we're really looking to impact the entire stack so that we build this combination into a service provider capable infrastructure so that the service providers can bring the same web scale and web agility to their data centers that we're seeing in the modern web scale applications in the internet. And then as I mentioned earlier, it's really important both from a Red Hat and NEC perspective and we believe in general for the industry to focus on upstream. All the development that we do is pushed directly upstream all the conversations that we have. We try to engage in the community rather than doing it behind the scenes and creating solutions that are either locked into a particular vendors platform or sort of bolted on to the side in a way that when it gets to the community it's really not an acceptable solution. So upstream first is a critical part of the development process here. In OpenStack, we have a telco working group so for those of you who are here, who are interested in NFV and telco features and are not in the telco working group, who is that by the way? You're all part of it. I don't believe you because I don't recognize all the faces. Please come to that working group as a way to organize our efforts and what we're doing in OPNFV is directly related to this. So in OPNFV what I like to say is if the OPNFV community in the OpenStack telco working group community aren't the same people we're fundamentally doing something wrong. So our goal is not to have this external group OPNFV to do stuff off by itself but it's to be really a part of each of the respective communities that are important. So we're kind of blurring the lines and merging together with this working group and ultimately as we gain sort of awareness in the community and credibility in the community we don't necessarily need a focused working group we just have people that are a part of the broader community. And then OPNFV is there to help take that industry defined reference architecture turn that into an open source built reference implementation and OpenStack and the relevant projects that we talked about today are really critical to that. So thank you for your time and we're really excited about this part. Questions? Yes. I think you have to use the mic because we are being recorded. Sorry. So you talked about this hardware fault detection and notification to the guests. Shouldn't the guests normally not make any assumption about whether the underlying server has that capability or some other server may not have it and just do some application level keep lives so that it runs regardless of the server has some acceleration or not. I mean, shouldn't that recite a good VNF should do its own fault detection? Any comments? Well, first of all, my point of view, totally agree. And what Dirk was saying is there are applications right now that are trying to run on this platforms that don't have that capability built in. So there is a mechanism and a method for injecting faults into those guests where they were running on bare metal, they used to be able to detect faults locally and sort of preserving that kind of behavior. But long term, the right solution is faults can happen. You build your applications in a cloud aware way. So you're prepared to deal with faults at the application level. Absolutely, and they're one of the great things about the NFV sort of transformation of the network is just creating opportunities for new people to come in and build new services for the telcos that are from the beginning designed in that fault aware kind of cloud application style. So absolutely. So what we are seeing is there's of course existing investments, that's one thing. I mean, it's also mindsets that need to change. So how to develop VNS in a cloud aware way. And this is happening very early until it has fully happened. There's still a demand for this other way. Yeah. Yeah, on your slides, you had a couple of projects on innovation that had to do with tuning the performance of compute like CPU pin-in and such. I didn't see anything that had to do with improving the performance of the actual network. Like positionally where the compute nodes are in a network or how to increase the performance of the network. So my question is that of any, is there any work being done there? Or is that of any importance to OP NFV or is it low? Do you know of any projects that are trying from within OP NFV working group that are looking at that? Right, so OP NFV has a data plane performance project. So that is basically looking into say, compute infrastructure performance improvements. So where I see this become important is if you look into like service chaining, where today we are trying to figure out how to implement service chaining at all. So how to do encapsulation right and how to attach metadata. But I think in the future it will also be important to do this efficiently. So like to avoid having too many hops in convenient locations and so on. So co-locate functions and so on. So OP NFV has two projects on service chaining. And so it's possible that, so these aspects would be addressed there. We also have two projects on the data plane. Accelerations, one is really kind of broadly how do you do performance measuring of a forwarding device and then one more specific to essentially the integration of DPDK and OVS. So that's host level packet acceleration. And then work that we've done together and you see in Red Hat to enable, first you wanna do quick packet processing in the host and then you need to deliver it efficiently to the guest and the traditional IO stack that delivers packets through KVM is Verdi O. There's been a specific project using shared memory between the host and the guest and presenting that shared memory to the guest as a network interface card and then a specific DPDK pole mode driver to pull packets out of that shared memory segment. So from the host Nick, you have something that's essentially allowing you to DMA almost directly into the guest, not quite but almost. So there's absolutely a lot of focus on that but the CPU pinning, the IO awareness, the NUMA awareness, that's actually part of packet processing acceleration because you can't efficiently do, some of this is CPU bound work and you can't do that efficiently if you're not confined to a NUMA node. So they're all kind of complementary. Oh, I think we're being thrown out. Thanks for the questions. If you have more questions, come on.


theCUBE presents UiPath Forward 5, brought to you by UiPath. Hi everybody, we're back in Las Vegas. We're live with theCUBE's coverage of Forward 5, 2022. Dave Vellante with Dave Nicholson, Ted Kumer in the series. The executive vice president, product and engineering at UiPath brought on to do a lot of the integration and bring on new capabilities for the platform and we've seen that over the last several years. And he's joined by Dr. Edward Chalice who's the co-founder of the recent acquisition that UiPath made, company called Re-Infer. We're going to learn about those guys. Gents, welcome to theCUBE. Ted, good to see you again. Ted, welcome first time. Thank you. Great to be here with you. Yeah, so we have seen, as I said, this platform expanding. I think you can use the term business automation platform. It's kind of a new term. You guys introduced the conference. Where'd that come from? What is that? What are the characteristics that are salient to the platform? Well, I see the evolution of our platform in three chapters. You understand the first chapter, we call that the RPA chapter. And that's where we saw the power of Ui Automation applied to the old problems of how do I integrate apps? How do I automate processes? That was chapter one. Chapter two gets us to forward three in 2019 and the definition of this end-to-end automation platform. The capabilities from discover to measure and building out that core platform. And as the platforms progressed, what we've seen happen with our customers is the use of it goes from being very heavy in automating the repetitive and routine to being more balanced to now where they're implementing new business process, new capability for their organization. So that's where the name business automation platform came from, reflecting now that it's got this central role as a strategic tool sitting between their application landscape, their processes, their people helping that move forward at the rate that it needs to. And process mining and task mining, that was sort of the enabler of chapter two, is that right? Well, I'd say chapter two was, first the robots got bigger in terms of what they could cover into API integration, long-running workflows, AI and ML skills, integrated document processing, citizen development and professional development, engaging end users with things like user interfaces built with UiPath apps. And then the discovery, just an expansion of the whole surface area, which opened up a lot of things for our customers to do that went much broader than where core RPA started. And the other thing about this progression to the business automation platform is we see customers now talking more about outcomes. Early on, they talk a lot about our safety, and that's great. But then what about the business outcomes that's enabling the transformations in their business? And the other thing we're doing in the platform is thinking about, well, where can we land with solutions capabilities that more directly land on business measurable business outcomes? And so we had started, for example, offering an email automation solution, big business problem for a lot of our customers last year. And we'd started encountering this company re-infer as we were working with customers. And we encountered re-infer being used with our platform together. And we saw why we can accelerate this. And what that is giving us now is a solution now that elands with a very defined business outcome. And this way, we can help you process communications and do it efficiently and provide better service for your customers. And that's beginning of another important progression for us in our platform. So that's a nice segue. So tell us about re-infer. Why did you start the company? Right, yeah. So my whole career has been in machine learning and AI. And I finished my PhD around 2013. It was a very exciting time in AI. And me and my co-founders come from UCL, this university in London, and DeepMind, this company, which Google acquired a few years later, came from our same university. So very exciting time amongst the people that really knew about machine learning and AI. And everyone was thinking, you know, how do we, this is just a really big breakthroughs. And you could just see that there was going to be a whole bunch of subsequent breakthroughs. And we thought NLP would be the next breakthrough. So we were really focused on machine reading problems. But we also knew as people that had like built machine learning production systems, because I'd also worked in industry that journey from having a hypothesis that machine learning can solve a problem to getting machine learning into production, that journey is a painful, painful journey. And that, you know, you could see that you've got these advances, but getting into prod is just way too hard. So where do you fit in the platform? Yeah, so I think when you look in the enterprise, just so many processes start with a message, start with a note, start with a case ticket, or you know, some other kind of request from a colleague or a customer. And so it's super exciting to be able to, you know, take automation one step higher in that process chain. So you could automatically read that request, interpret it, get all the structured data you need to drive that process forward. So it's about bringing automation into these human channels. So I want to give the audience a sense here. So we do a lot of events at the Venetian Conference Center and it's usually very booth heavy, you know, brands and big, giant booths. And here, the booths are all very small. They're like kiosks and all pretty much the same size. So it's not like one vendor trying to compete with the other. And there are all these elements, you know, that feel like there's clouds and there's, you know, of course orange is the color here. And one of the spots is it has this really kind of cool sitting area around customer stories. And I was in there last night reading about Deutsche Bank. Deutsche Bank was also up on stage. Deutsche Bank, you guys were talking about a re-infer. So share with our audience what Deutsche Bank are doing with UiPath and re-infer. Yeah, so I mean, you know, beyond like before we automate something, we often like to do what we call communications mining, which is really understanding what all of these messages you're about that might be hitting a part of the business. And at Deutsche Bank and in many, you know, like many large financial services businesses, huge volumes of messages coming in from the clients, we analyze those, interpret the high volume query types, and then it's about automating against those to free up capacity, which ultimately means you can provide faster, higher quality service because you've got more time to do it. And you're not dealing with all of those mandate. So it's that whole journey of mining to automation of the comms that come into the corporate. So how do I invoke the service? So is it as a mother module, or what's the customer onboarding experience like? Well, so I think the first thing that we do is we generate some understanding of actually the communications data they want to observe, right? And we call it mining, but you know, what we're trying to understand is like, what are these communications about? What's the intent? What are they trying to accomplish? Tone can be interesting, like what's the sentiment of this customer? And once you understand that, you essentially then understand categories of conversations you're having, and then you apply automations to that. And so then essentially those individual automations can be pointed to sets of emails for them to automate the processing of. And so what we've seen is customers go from things they're handling 100% manual to now 90% for 5% of them are handled basically with completely automated processing. The other thing I think is super interesting here and why communications mining and automation are so powerful together is communications about your business can be very, very dynamic. So new conversations can emerge. Something happens right in your business. You have an outage, whatever. And the automation platform being a very rapid development platform can help you adapt quickly to that in an automated way. Which is another reason why this is such a powerful thing to put the two things together. So you can build that event into the automation very quickly yourself. Yeah, that's totally cool. So add on the subject of natural language processing and machine learning versus machine teaching. If I text my wife and ask her, would you like to go to an Italian restaurant tonight? Yeah. And she replies, fine. Yeah. Yeah. Okay. How smart is your machine? And of course context usually literally denotes things within the text and a short response like that's very difficult to do this. But how do you go through this process? Let's say you're implementing this for a given customer. And we were just talking about the specific customer requirements that they might have. What does that process look like? Do you have an auditor that goes through and do you get like 20% accuracy? And then you do a pass and now you're at 80% accuracy and you do a pass. What does that look like? Yeah, so I mean, when I was talking about the pain of getting a machine learning model into production, one of the principal drivers of that is this process of training the machine learning model. Right. And so what we use as a technique called Active Learning which is effectively where the AI and ML model queries the user to say, teach me about this data point, teach me about this sentence. And that's a dynamic iterative process. And by doing it in that way, you make that training process much, much faster. But critically that means that the user has, when you train the model, the user defines how you want to encode that interpretation. So when you were training it, you would say fine from my wife is not good, right? So it might be fine. Do you have a better suggestion, right? But that's actually a very serious point because one of the things we do is track the quality of service that our customers use us to track the quality of service they deliver to their clients, right? And in many industries, people don't use flowery language, like thank you so much or I'm upset with you. What they might say is fine. And you know as the person that manages that client, that is not good, right? Well, they might say, I'd like to remind you that we've been late the last three times, you know? It's like- This is urgent. No, okay, alright. So it's important that the client, our client, the user of RIMF can encode what their notions of good and bad are. So a quick follow up on that. Differences between British English and American English. In the UK, if you're thinking about becoming an elected politician, you stand for office, right? Here in the US, you run for office. That's just the beginning of the vagaries and differences. Well, you know, I've now got a lot more American colleagues and I realize my English phrasing as often goes amiss, so I'm really aware of the problem. We have customers that have contact centers, some of them are in the UK, some of them are in America, and they see big differences in the way that the customers get treated based on where the customer is based. So we've actually done analysis in re-invert to look at how agents and customers interact and how you should route customers to the contact centers to be culturally matched, because sometimes there can be a little bit of friction just to that cultural mapping. So what's the general philosophy when you make an acquisition like this and you bring in new features? Do you just wake up one day and all of a sudden there's this new capability? Is it a separate sort of four-pay module? Does it depend? I think it depends. You know, in this case, we were really led here by customers. We saw a very high value opportunity in the beginnings of a strategy and really being able to mine all forms of communication and drive automated processing of all forms of communication. And in this case, we found a fantastic team and a fantastic piece of software that we can move very quickly to get in the hands of our customers via UiPath. We're in private preview now. We're going to be GA in the cloud right after the first of the year and it's going to continue forward from there. But it's definitely not one size fits all. Every single one of them is different and it's important to approach them that way. Right, right. So some announcements. Studio Web was one that you could try. I think it came out today. Can't remember what it was today. I talked about it yesterday on the keynote anyway, on the keynotes. Why is that important? What is it all about? Well, we talked, you know, at a very top level, you know, I think every development platform thinks about two things for developers. They think, how do I make it more expressive so you can do other things, richer scenarios? And how do I make it simpler? Because fast is always better and lower learning curves is always better and those sorts of things. And so, re-infers a great example of, look, the runtime is becoming more and more expressive and now you combine communications data as part of your automation, which is super cool. And then, you know, Studio Web is about kind of that second point and Studio X are already low-code, visual, but they're desktop. And part of our strategy here is to elevate all of that experience into the web. Now, we didn't elevate all of Studio there. It's a subset. It is API integration and web-based application automation, which is a great foundation for a lot of apps. It's a complete re-imagining of the Studio user interface. And most importantly, it's our first cross-platform developer strategy. And so that's been another piece of our strategy is to say to the customers, we want to be everywhere you need us to be. We did cross-platform deployment with the Automation Suite. We got cross-platform robots with Linux robots, serverless robots, Mac support, and now we've got a cross-platform devs story. So we're starting out with a subset of capabilities, maybe oriented toward what you would associate with citizen scenarios, but you're going to see more roadmap bringing more and more of that. But it's pretty exciting for us. We've been working on this thing for a couple of years now, and this is a huge milestone for the team to get to this point. I think my first conversation on the queue with a customer was six years ago, maybe, at one of the earlier forwards. I think forward two. And the pattern that I saw was basically people taking existing processes and making them better, taking the mundane away. I remember asking customers, are you kind of paving the cow path? Aren't there sort of new things that you can do with new processes? And they're like, yeah, that's sort of the next wave. So what are you seeing in terms of automating existing processes versus new processes? I would see re-infer is going to open up a whole new vector of new processes. How should we think about that? Yeah, I think, in some ways, RPA is this reputation because there's so much value that's been provided in the automating of the repetitive and routine. But I'd say, in my whole time, I've been at the company now for two and a half years, I've seen lots of new novel stuff stood up. I mean, just in COVID, we saw the platform being used in PPP loan processing. We saw it in new clinical workflows for COVID testing. We see it, and we've just seen more and more progression. And it's been exciting that the conference to see customers now talking about things they built with UiPath apps. So app experiences they've been delivering. I talked about one in healthcare yesterday and basically how they've improved their patient intake processing and that sort of thing. And I think this is just the front end. I truly believe that we are seeing the convergence happen and it's happening already of categories we've talked about separately, iPad, BPM, low code, RPA, it's happening. And it's good for customers because they want one thing to cover more stuff. And I think it just creates more opportunity for developers to do more things. Your background at Microsoft probably well prepared you for a company that was born on-prem and it went all in on the cloud and had multiple code bases to deal with. UiPath has gone through a similar transformation. We talked to Daniel last night about this. You're now cloud first. So how is that going just in terms of managing multiple code bases? Well, it's actually not multiple. It's the same one. It's the deployment models I should say. It's the first thing, yeah. The deployment models. Another thing we did along the way was basically re-platform at an infrastructure level so we now can deploy into a Kubernetes Docker world what you'd call the cloud native platform. And that allows us to have much more of a shared infrastructure layer as we look to deliver to the automation cloud, the same workload to the automation cloud that we now deliver in the automation suite for deployment on-prem or deploying a public cloud for a customer to manage. Interesting enough, that's how re-infer was built which is it was built also in the cloud native platform. So it's going to be pretty easy. Well, pretty easy. There's some work to do but it's going to be pretty easy for us to then bring that into the platform because they're already working on that same platform and provide those same services both on-premises and the cloud. Without having your developers have to think too much about both. Okay, I got to ask you. So I could wrap my stack in a container and put it into AWS or Azure or Google and it'll run great. As well, I could tap some of the underlying primitives of those respective clouds which are different. And I could run them just fine. Or, and, I could create an abstraction layer that I could hide those underlying primitives and then take the best of each and create an automation cloud, my own cloud. Does that resonate? Is that what you're doing architecturally? Is that a roadmap? Certainly going forward. You know, in the automation cloud, the automation cloud we announced a great partnership or a continued partnership with Microsoft just Azure and our platform. We obviously take advantage of anything we can to make that great and native capabilities. And I think you're going to see in the automation suite stewing more and more to be in a deployment model on Azure be more and more optimized to using those infrastructure services. So if you deploy automation suite on-prem, we'll use our embedded distro. Then when we deploy it, say on Azure, we'll use some of their higher level managed services instead of our embedded distro. And that will just give customers a more automation, a more, a better optimized experience. Interesting to see how that'll develop. Last question is, you know, what should we expect going forward? Can you show us a little leg on the future? Well, we've talked about a number of directions. This idea of semantic automation is a place where, you know, you're going to, I think, continue to see things, shoots, green shoots come up in our platform. And, you know, it's somewhat of an abstract idea, but the idea that the platform is just going to become semantically smarter. You know, I had to sort of re-infer as a way we're semantically smarter now about communications data and forms of communications data. We're getting semantically smarter about documents, screens, you know, so developers aren't dealing with like this low level stuff.  That is one of many areas I'm excited about, but I think that's an area you're going to see a lot from us in the next coming years. All right, guys, hey, thanks so much for coming to theCUBE. Really appreciate you taking us through this awesome platform extension. All right, keep it right there. Everybody, Dave Nicholson, I'll be back right after this short break from UiPath Forward 5 from Las Vegas.


Excellent. Let's do this. Who will welcome to Burnout, the greatest start to your organization security. If you're not scared about Burnout or you're like, Burnout's not a big deal. I'm hoping that I scare you so much that you started realizing how important Burnout is that we need to focus on. First things first, my name is Chloe Masari. I am the co-founder of Woasec, Hackiness Not a Crime, and the founder, We Are Hackers. My day job is a growth strategy consultant. If you want to learn anything about me, I am and easily can be found on standoutintech.com. All right. Now let's get to the real reason why you're here. Let's get into this talk. This thing may look familiar to you. Well, this was RSA conference last year. We were so full of hope for the new year. We hugged, we shook hands, we attended events full of people. We had drinks and food together. We leaned in to hear each other often at a busy event. We had to speak loud to be heard, and we even attend karaoke. It was a glorious time. Then eight days, 10 days later, suddenly we started hearing a different people getting sick.  But I remember that transition and that moment of knowing that I'm one of the unfortunate people that got sick. I remember how stressful it was, worried about, did I give this to someone else? The fear of losing my parents came up. Everything when it came to, do I need to revisit my will? What do I need to do? Because it was so at the beginning of it, and in the US, it wasn't prepared for it. It was a scary moment. But good news, I survived, but there were many that didn't too. I have to admit, if we were to think of 2020, this is what I think of 2020, is that in a nutshell, it was intense. Everything thought was on fire. There wasn't a moment we weren't on fire. It just seemed like the universe gave you just a little bit and then it's like, oh, you're stressed and overwhelmed. You think you're okay. You can't get any more. Guess what? I'm going to hand you another thing. It became a layer on top of a layer of more and more stuff hitting at you all at once, to a point where we're all going to be very different from this pandemic. And to be honest, we're still in it. And the reason I have this sign on here, because to be honest, we are in 2021, but it still feels like we're in 2020 a little bit. But I'm hoping things get better in many ways. Because let's be real. We are walking on a fine line of being just barely okay and terrible. And all of us have been dealing with burnout. Well, not all of us. Lucky you, New Zealand, lucky people, anywho, but even if New Zealand, in New Zealand and everywhere before 2020, in security, we've known about burnout and have been through it before all the chaos fell in 2020. This is not a new thing for us. We've been talking about this for years because with burnout, we are placing ourselves in organization at a security risk. We'll most likely click on a link because we're not 100% who we are. For example, when you wake up and you're checking your emails and you're exhausted, you haven't had your cup of coffee or your tea, chances are you may click on that link that comes from your manager because you didn't do it further looking at the details of where that email address came from, which was not from your manager. And so that's the thing is to understand is that when you're burned out, you're more likely to click on a link. You could be the most secure personnel. You could be like the leader of security or InfoSec or a leader in social engineering, but there will be a time where you will click on a link when you're burned out because you are functioning on a very low battery and you're not 100% who you are. We may not even patch right. We could be overwhelmed by what is needed to be patched immediately. So let's all be very real. The thing is that while working at InfoSec, we're kind of seen as bots, not humans, and humans cannot handle this 24-7 type of work because when we're working all hours and always expected to be on calls at all hours, like in the middle of the night, how do we even balance the personal life and work life? Because burnout occurs when we do not practice self-care and when our work demands more from us and we spend less time on personal life, the bouncing is gone, stress increases, we feel guilty, we struggle to sleep because we feel like we're trying so hard not to drown. You may even notice changes on your team, such as employees withdrawn or fast to become sad or angry or delays in email response or projects. This can all be seen when remote too. It's not just in person. And right now, working from home and remotely has increased the number of hours worked, increased expectations and has really increased the blurriness of work time and limits. And some people have quit because they cannot handle the juggling of work and personal life because their company failed them because they weren't being more flexible. And when we're not being more flexible, we're not practicing inclusion and equity in our companies. And this is one of the reasons why we saw an increase of women leaving the field because we weren't being there for them. Companies weren't listening to them they couldn't be more flexible, instead they kept putting more and more demands. Well, they unfortunately had more of also the demand for them to be nurturing. And it's one of the things that it just shows that we're so broken that we allow for this to happen. And we need to do something about it. We need to change this because let me be blunt. In security, we haven't had a job that's from nine to five PM at all. And this is the contributing factor because employers are pushing employees to work from nine to five and yet send emails, Slack messages, call them, text them at all hours. This places you and your team at a losing situation because they feel obligated to respond. And this is why the burnout cycle continues. And for those who are not aware of what burnout starts to form and look like, it could be that it used to take a few minutes to respond to an email. Now it takes an hour or so. You feel exhausted and trapped. You may even feel empty. You push yourself to a breaking point or you no longer coming up with new ideas but rather taking meds to help with the aches.  You may not even respond to friends and family when they call or text for some time. And then because you're not doing that the guilt starts entering. Now your personal life is slipping. Your life is now your work and you start to feel unappreciated for your work at work and then become resentful at work and then end up hating and dreading your job. And this is the moment you may lose your team members because what we have been doing is putting employees at a huge health risk. No matter how much sleep you get you just feel exhausted and emotionally depleted which can mimic depression and even anxiety. You may even struggle to sleep such as troubling falling asleep or staying asleep. And when we are stressed out our cursor increases and it gets harder to shut down our minds which causes us to toss and turn and reduce deep sleep or even getting enough room. And when we don't get proper sleep stress levels increase. Mental state can start shifting to anxiety and depression symptoms. And when we're overly anxious or experienced depression symptoms we start to get sick way more often such as gastrointestinal issues, headaches, infections, colds, flus, colds, rashes, irritated skin, lower immune system. Our joints and muscles are getting stiff because our body is on survival mode thinking that there's a perceived threat. It can then turn into a muscle weakness and fatigue if left untreated prolonged stress increases high blood pressure, heart attacks and strokes because there's too much adrenaline and cortisol over an extended period. Clearly burnout is not a joke. It's actually extremely serious. And we have a real problem in our industry that's leading our colleagues and ourselves into this situation. And recently this week, the who released a statement about when we're working past 40 hours a week we're putting ourselves into this situation. So let's look at the results of our industry. The reality of working in security that high demand 24 seven. 21% of CSOs said that they have taken a leave-on absence because of job related stress. 41% of CSOs took the significant step even though many reported being afraid to take sick days and 35% neglected to take all their allotted time off. 48% of CSOs said that their work stress has impacted the mental health while 35% said it impacted their physical health. 40% of CSOs said that their work stress has impacted their relationship with their families and children and 32% said it impacted their relationships with spouses or romantic partners and 32% said they've impacted their relationships and friends. 23% that stated that they've been using medication or alcohol to manage stress. I wanna just state that these statistics were released in 2020 but took data from 2019. These numbers are definitely not relevant to today in many ways. If anything, they may be much higher. The other thing to understand is that 94% of American CSOs and 95% of UK CSOs reported working more than their contracted hours. On average, 10 hours per week more. In addition, 83% of American C-suite execs and 73% of UK execs confirm they do indeed expect security teams to work longer hours. In other words, we are expected to work beyond normal work hours. You have to understand, there isn't really too many roles that are like that. Sure, sales does, but it's not like sales are gonna get phone calls in the middle of the night because of some sort of incident. But we will, we get it all the time. CSO is the manager and leader and having someone who's burned out that leads can become really dangerous to employers, security risk and increase in the possibilities of managerial issues. Coping with such issues can lead to themselves medicating on the job and walking on a very thin line of what is appropriate. But once again, this is not a CSO's fault. It is a system that is broken, an industry that isn't sufficient in the long run. It's an industry that continues to fail us and runs on people being burned out. I wanna take a moment here. I want you to understand that we have a foundation that doesn't empower us. We have a foundation that disempowers us in every single way. And there's no wonder we have a rotating door in mental health crisis in our industry. And I'm about to show you why it's like this. So why are we so burned out? You probably have ideas already. But for those that aren't aware what security team personnel are doing and what's happening on their side, I hope this gives you a good idea. By being in security, we are monitoring and operating 24 seven. And sometimes we work throughout the middle of the night. Sometimes we cannot sleep well because we're always at the edge of our seat when it comes to security because we know attackers work all hours. And we are always worried when a breach will occur because we all know if there was a breach, it would be ad hoc style to fix it. Don't believe me? According to the Pondman Institute, while security response planning is slowly improving, the vast majority of organizations surveyed, 74% are still reporting that their plans are either ad hoc, applied inconsistently, or that they have no plans at all. Additionally, more than half, 52% of those with security response plans said that they've never reviewed or have no set time period for reviewing or testing those plans. And with COVID-19 and working from home, how many of these plans have been updated? Yeah, this is one of the reasons why there was a 400% increase of successful breaches. So instead of doing better planning and having less disruption, we tend to throw tools at the problem. We always do this because it's so much easier to throw tools at something than to actually understand the situation and how human element plays a huge role here because the human element is complex. It is different from one person to another, but the reality is tools don't always solve the problem because we're actually making the situation worse by doing so, because when we add tools to it, guess what? It's not in the plan and coordination is off. And these third-party tools, we have no idea how secure they really are. Are you feeling stressed out yet? Perhaps cortisol levels rising? No? Well, I want you to imagine a situation.   Your team is scared and some are paralyzed by the fear of failing, but they're trying their best, but there's a catch here. Your entire team hasn't slept well and have sea sickness. So they're not exactly 100% state of mind. If anything, you could say that kind of are functioning the same rate and scope as someone who is burned out. Okay, now you have the backstory.  Unfortunately, that binder that was updated is not on that ship. So you're using an old procedure but have new features to the ship. Are you stressed out now? Because this is what it's like when we're dealing with bad plans and when the human element is taken out. It leaves you with a wreckage. The truth is bad actors are everywhere and attack at all hours, zero days drop often and we constantly need to be up to date of what the bad actors use. That takes time and energy. This is why we are struggling. We are part of the crew and when we don't function well or communicate well, it becomes a really, really scary situation. The reason we are in security is because we know how incredibly important it is, but we also need to come to terms that if we work around the clock and don't practice self-care or even promote employee wellness, what's the point? Because then we can be a danger to the organization as well if we're running on low battery feeling not well. And this is why burnout matters. This is why if we keep turning to tools and not finding time to plan, practice and self-care, we become the security team that sinks. We won't be able to fix a breach fast and it's really scary. And please don't turn around now and blame your employees. If they're not performing as well, because for the majority of you, that is what happens. You let the team member go without checking to see what have you done that has reduced their performance because chances are they're burned out and feeling alone. With COVID-19, we're taking care of family members on camera daily, unable to leave. We must put off important life events. We've lost people close to us. Our colleagues are struggling. We're worried about keeping our job. We're worried about afford and the life we have. We have COVID, we may not make it through COVID. We are not a machine, we're completely human. And the human element created security and run security. And we're all struggling with staying okay before COVID and even during COVID, except New Zealand. So how can we lead like the prime minister of New Zealand? Think about it, she worked with people and she planned with specialists and when you plan, there's less disruption. So let's talk about four ways how you can invest in your team. Investment number one, listen, take action together. Be strong, be kind, ask your team what they need. Don't just listen, take actions. When we listen to each other and strategize together on how to improve the team and our department, it reduces the stress because stress happens when we're not being listened to or feel uncomfortable to speak up. Your colleagues may share that certain tools aren't needed or there's a tool that does five things all in one that is better. They may share what is missing on the team and perhaps less meetings are needed. By working together on what are the issues, we can actually collaborate together on how to reduce the issues or completely resolve them. Investment number two, plan together, strategize together. With collaboration and listening, working together with the team to make strategies and revisit your security response plans, make it up to date. Revisit a plan every time a new tool is removed or added or a team member changed or an environment changed and so on. By creating and making solid plans, it helps speeds up the recovery and reduces the stress of when a breach occurs, that there's a plan to follow up that's up to date.  I mean, look at what New Zealand did. They planned. They had 25 deaths versus the US. We had over 563,000 deaths in the US because someone didn't want to plan or take actions or listen to their team. Investment number three, encourage self-care. Studies have shown that when dealing with burnout, taking one week off away from work or anything related to work provides recovery for burnout. If your employee is burned out, make sure that they feel supported to take time off and also encourage it often to the team. Majority of employees in security are afraid to take time off because they feel guilty for not being there to help their team and are giving more work to their colleagues or coming back to a dumpster fire. If you can, give everyone one day off a month for a mental health break. And lastly, make sure you have one day per week dedicated to not having any meetings. This allows your colleagues to catch up on any IMs or projects. And plus, come on, we all have Zoom fatigue a little bit here. Investment number four, be kind and respect boundaries. Please be kind to one another because from what we have learned when we work together and understand how we impact others, we start practicing empathy. And empathy is certainly missing at times in our industry. But by listening and being there for one another, it reminds us that there's people who care for each other because we cannot assume how someone is doing by how they look or their performance. We don't know how each other and what we're going through. So instead of going at someone reframe and think before you speak or act because you really don't know how that will impact the other person. So as New Zealand shares be kind because that's the element we need to stick together to protect the world from the darkness. But also know that being kind is respecting work boundaries such as that six feet of distance in a mask. So what can you do right now? This is only gonna take you maybe five minutes to do maybe 15 minutes at most. Right now you can take a screenshot of this portion of this slide and save that. It only takes five to 15 minutes to do this right now. It's called set weekly one-on-ones for 15 minutes with each employee. Basically in this one-on-one meeting is the time where you go projects that are coming up and being able to be on the same page on what to prioritize. But also it's being there for your employee. Now the one thing to keep in mind though is that when you do this, you don't micromanage. You don't follow up on anything throughout the week. That means once a week you meet with them for 15 minutes. If they need anything, they'll come to you. That's what it means. When we micromanage people, we're setting them up to fail or actually setting them up to get burned out. We're setting them up to leave. And so it's really important is that we do these one-on-ones for 15 minutes so we all are on the same page and then it's hands off. Make Monday or Friday a no meetings day. So one day per week it's set that in your department that you will have no meetings on that day. The other thing you do is set up a meeting with the team to explore ways to improve together. So just set something up. Next week or the following week, a one-hour meeting of being like, okay guys, how can we do better? What can I do to help your team out? How can we do better? And if you're not the manager that's okay, go to your manager and be like, hey, I think that we should all have a meeting and discuss how we can do better. Your manager will probably like that idea, to be honest, because they're always wondering how to do better if they're a good manager, that is. Also create an anonymous survey and really get the feedback from your colleagues on how to do better. Now I wanna say it has to be anonymous because the chances are people are still not gonna participate because they're always worried that it's actually not anonymous. So if you want real results, you're gonna have to ensure it's anonymous. And lastly, remember when we work together and listen to each other, magic happens. When we work together making sure people get personal time off without them fearing or taking time away, we are then becoming collaborative. When we collaborate, we reduce the stressful items that hold back the team from thriving. And when we focus on balancing work and personal life for everyone, that's when we no longer have that dumpster fire. Burnout as a security concern, no more. Because we know we are human and the human element rules the world we live in. And whenever in doubt, just remember if New Zealand can plan well, so can you because in all this, there's a Frodo within us who's on a journey to get rid of some malicious threat. So quick overview is that burnout places you and your team at a security risk and also a personal risk, a health risk. Collaborate to form strategies to improve the team. It's called teamwork for making a very bad environment where no one's talking to each other in a collaborative fashion. Start making plans and revisit security response plans. This is so critical. Like we have to be on top of that because you'll be helping your team members out by doing so. Promote self-care by being kind and respectful to boundaries. In this sense, don't call or text after work hours. Don't even slack after work hours, email. And make sure that you let your colleagues know when you email, it doesn't need to be responded right away. It's just to put it out there so we don't forget about that item. That is gonna be the best way forward. Anyway, I just wanna say thank you all for having me thank you in more sec. This was awesome to be part of and I hope everyone's staying safe. So thank you so much for existing. And if you wanna stay in touch with me, feel free. I'm on Twitter, Instagram and LinkedIn. Feel free to follow or add me as a friend. Totally down for that at any time.


This is an emergency alert. You must not turn off your device or look away from the screen. This alert is from the SCP Foundation, an international security organization, and it concerns your safety. The SCP Foundation speaks with the authority of the United States Department of Defense. If you are located within the area marked on this map, you should remain inside and arm yourself. A dangerous physical anomaly is in your area, named SCP 106. This anomaly is hostile to humans. SCP 106 is a humanoid, appearing similarly to a dedicated corpse of an old man. It has the ability to walk through walls and ceilings, and to transport itself within walls and ceilings. For example, if SCP 106 walked into the wall of a room, it could reappear from the ceiling. SCP 106 is also able to corrode and corrupt material, rusting metal, and rot in organic matter. SCP 106 will use these abilities to stalk and kill humans, typically children, teenagers, and young adults. As SCP 106 is resistant to damage, retreating is the best way to increase your survival chances. However, ballistic weaponry may distract it, and it is therefore recommended that you also arm yourself. The SCP Foundation is currently attempting to track, locate, and recontain SCP 106. Stay inside, and retreat from SCP 106 if it appears to attack you. Secure. Contain. Protect.


People think it's a lost skill that hey we don't pack animals anymore and you said it is still relevant especially when we deal with special operations units that come out and they tell us real-world stories of them having very little experience trying to to pack a mule or pack a horse or get on a horse because they're only means of you know actually infilling into an area you see that there is still a need for it that it is still a necessary skill set it's not being taught and I think that's what makes us one unique and still relevant trucks can only go so far vehicles Humvees but your objective may be another two or three days march from the end of that road we can maneuver around the battle space a lot faster and a lot more efficiently and then it saves our operators so when they get to the fight they're still able to fight because they haven't expended any of their own energy


Let's go, what do you got on this one? When he's talking to the jury, he turns toward the jury as they're to his right when he's being all emotional. When he's crying and stuff, he's cognizant enough in there to go, okay, I need to let the jury see me being emotional. So that's another thing that bugs me about this guy. The only time he turns toward them hard is when he's being all emotional. But when he's being angry, he fully turns toward the prosecutor. Now watch when he's being emotional and deal with the prosecutor at the same time.  And he'll track him with his eyes like that predator look we saw earlier. And he'll track him like that. Otherwise, he's wanting the jury to see his emotion and how sad he is about everything, which is I'm under the impression is fake as well.