 Hello, can everybody hear me? No, no one can. Okay, I can hear me now. Hi, hi everybody. Thank you for coming out today. I'm just gonna take a few minutes today to talk about chat opsing your open stack, as also known as if this then that for DevOps. So real quick, let's go over what we're gonna talk about. I care about what is StackStorm. This is really cool. This is what powers chat ops. It's real powerful to us. And we're gonna talk about how chat ops plays into the StackStorm view of the world, view of event-driven automation. Basically, we wanna, chat ops is basically in the StackStorm view of the world. What we're doing is we're looking in for events that come in from your different tools in your environment, right? Be it your logging system, be it your monitoring system, be it your graphing system, be it your chat system. As far as we're concerned, these are all events, right? We aggregate all of these events and run them through our system. And our system has a set of rules that you can define. And based on those rules, we go ahead and kick off additional actions and or workflows, right? So it's a giant reactor loop. Ultimately, you can get as complex as you need to to accomplish very, very complex work. The idea being trying to give the tools to the computer to solve the non-value at necessary work that needs to happen within IT operations. So event-driven automation, just a couple little bit of background about who's doing this and why it matters. Specifically, F-bar is a good Facebook project. They talk about this at any chance they get. We had a really great meetup, first event-driven meetup last week where they talked about F-bar, saving them 16,000 plus hours per day, right? They're knock his man by a single person. Can't get those kinds of efficiencies unless you have something like this, right? Likewise, Borg, which is what is Kubernetes is turning into, right? The commercial version of it. Google has had something like this for many years, right? The need for event-driven automation helps them specifically scale, helps them allow to hire engineers that are using their time and energy in solving real big problems, not pushing around IT things in order for delivery purposes, right? The non-value at necessary work. And then we have some other examples like PayPal, Amazon, Microsoft. They've all got very similar tools like this. And the common theme is that the big operators, they've got these things because they're gonna go hire the people to build them. But they're one-off, they're specific to their organization and they're not portable, right? So this power is locked up within these organizations and what we're trying to do is we wanna bring it to everybody. How can we make the concept of event-driven automation easy for everybody to consume, everybody to share, everybody to leverage? And that's where Stackstorm comes in. So here's a nice little graphic that kind of illustrates at a high level what is it that we actually do. We have our sensors, again, that are listening from events and we hook into a ton of things. And this list is constantly growing. We open-sourced our first version in November of last year. We are currently at 0.9, working on our 0.10 release and since then we have increased from zero to 650 different integrations over different platforms. We expect that trend to continue very, very rapidly. We have community integrations that are coming in and one of our claim to fame is that it's very easy and very quick to write these integrations. So if you wanna get started with Stackstorm and you have an existing automation library, it's a few commands to integrate those into the event-driven automation paradigm. Likewise, Rackspace did a launch with us. We actually worked with them to create specifically chat ops interfaces for them. They are very big on trying to figure out ways to be efficient with how they do work and how they provide services to their clients and the way that they do that is directly through chat ops, empowering their users to be more powerful and allowing their customers to even take advantage of some of these self-service options via a chat interface, right? The key points here that by using something like chat ops, you significantly decrease the feedback loop necessary to accomplish work. So we'll talk about that and I'm actually gonna show some of that here in a second. We're gonna cross our fingers for a live demo here. So let's try it. What even is this thing? It is not fake, it is actually real and I will like to say while I'm getting this set up, we actually are in the process of releasing our version two of chat ops for a Stackstorm platform. You can actually go download that on our website right now, stackstorm.com slash community. Get an entire Stackstorm stack plus chat ops running in under about five minutes, right? I think that's real important is to be able to get to and accelerate these kinds of tools as fast as possible. So let's chat ops a little bit. First off, let's tweet that we're actually chat opsing. That's neat. So my Stackstorm account is now tweeted out that we're here. Hi everybody, I hope you can subscribe to us at Stackunderstorm, should see that up there. So let's run some commands. Specifically, I want to go ahead and provision an entire auto scaling group. And in that auto scaling group, I'm gonna have load balancers. I'm gonna have virtual machines. I'm gonna have DNS associated with it. I'm gonna need to set parameters about how these things are provisioned. And I'm gonna do it with one command. So what's happened now is Stackstorm is in receiving this event, right? And now we've matched it against a rule. And that rule says, okay, when you get a rule that looks like this, I want you to go ahead and kick off a provisioning cycle. So this is gonna happen. And while this is happening, let's go ahead and execute some other chat ops commands. So I have an OpenStack cluster already. Let's go ahead and inspect it and see how things are going. So I can see I've got an OpenStack cluster. I can do some information and gather some information about what's happening with my OpenStack cluster. Now why this is important is it decreases the feedback loop necessary for you to do collaboration. So imagine yourself in an incident and everybody's trying to resolve a scenario. Normally and typically you get on a phone call and you're talking over each other to try to figure out what's going on, how to resolve services. Well with things like chat ops, what you're allowed to do is you're able to go ahead and collaborate around the restoration by running simple commands. Let's go do some diagnostic information. And right now as I'm executing these commands, other people in my organization can also see these, right? And they can see what I'm trying to do in the thought processes that I'm going down and say, hey, this may spur a thought maybe I actually need to look at different pieces of the stack to figure out what's going on. So maybe I'll figure out what's going on here, show server. And so Aria is gonna come back and give us some information about what it's doing, right? What its status is, what its health is. And as I'm doing this debugging, everybody around me can see these things. And they're inspired in trying to run commands to try to figure out how to restore services. And the glory and beautiful piece about this is that there's so many things captured in here automatically by doing something like chat ops, right? By having something like a log in your chat, you suddenly and automatically have a forever history of how your operations go, right? So we're able to actually leverage communication structures that we as humans have done for hundreds of years, right? Where instead of trying to encapsulate data and encapsulate knowledge in a workbook, it's out of date as soon as you hit save. Instead, by using something like chat ops, you're allowed to actually take advantage of your dynamic communication structures and modify English and human commands mapped to the executions underneath in the event-driven automation view, right? So as long as the contract of how work is expected to get done when I request a VM, I expect a VM. When I request my alert to be acknowledged in my monitoring system, it gets acknowledged. As long as that action occurs, now suddenly I have a language that I can abstract, a set of services that I can provide to people that they can go and have and have the same amount of powers everybody else in the organization. So let's take a look some more. As a matter of fact, I'm doing some development on StackStorm. And I want to deploy some packs of StackStorm to StackStorm using StackStorm. Did they make sense? Yes, good. So let's deploy something. I want to go ahead and deploy a pack hue. So what this is doing is actually going on to our website, figuring out where the hue pack is, downloading it, cloning it to our repository, checking out the specific branch that I asked for, and then reloading it. So in chat, I can actually do rapid development of StackStorm. And everybody can see what I'm doing around that rapid development of StackStorm, testing it, seeing how well it works, and even rolling back or forward, depending on whether it's successful or not. So the key that I want to take here, right, these are very simple. It's very simple to add commands to StackStorm, right? But the power is, is that to get started with chat ops in StackStorm takes about five minutes. There's one file that you edit, and you map a set of human-based aliases that you want to map to actions or workflows. And those workflows can be super powerful doing things like provisioning entire stacks, right? But because you have the power of workflows behind you, you're able to put good safety measures around you, right? Making sure that when somebody executes something, you know how it's going to execute. You've written the bounds and guards for it. So when somebody executes it that's not you, you're okay with it. In fact, you want to encourage it because you're giving the power back to the users ultimately. And that's the key, is providing power back to them. Taking your SMEs, codifying their knowledge into chat ops, and providing them as primitives, as Lego blocks within the event-driven automation system for anybody to execute, for anybody to leverage. So suddenly, everybody on your team becomes more powerful. Our CEO goes to VCs and says, hey, look how awesome we are, and runs chat ops commands in front of them and provisions entire stacks. That's awesome. Everybody should be able to do that. So I don't know how much time I've got here. I think I'm actually coming. How am I doing? I don't even know. I have 10 whole minutes. Wow, okay. So let's see. Provide human languages, decrease feedback loop. So the other piece that's really cool about this is there's an end state that we want to ultimately get to. And that end state is the true event-driven automation. The view of the world we have and we're saving 16,000 plus hours per day, right? This is the mecca that we want to ultimately gain ourselves to. But there's so many cultural things that stand in the way of executing that strategy, right? Chat ops helps with this. Chat ops allows and provides a view of people to get comfortable with the idea of executing small commands in the context of a chat room. And they gain confidence in the automation system underlying powering this thing. So you start out very small, stuff like passive commands. Go get information. Go get data about what's happening in my systems. And suddenly, as people are using English language, what's the status of this thing? What's the status of that thing? Suddenly, instead of a human responding, the bot responds. And it starts that, oh, that's interesting. What new is happening? And then over time, you start to add smaller commands, smaller, more discovery commands. And then they become actual destructive commands or actual powerful commands, rather, right? And those commands, you can show up. And now, as you execute them, everybody gets to see them. You don't even have to train people how to use chat ops. You can just walk into a room and when somebody asks you to do task X or task Y, you can just do it in front of them. And over a period of time, they're gonna make the connection that every time they get asked to do create a new user, acknowledge an alert, create a new server, you just happen to run this command right in front of them. They get instantaneous feedback. The feedback loop is decreased. And suddenly, they say, well, hey, why can't I do that? And it's a natural progression that occurs. And that's exactly what you wanna encourage. Yes, I want you to do that. I want to give these tools to you, so you have self-service, so you have the power to go be as powerful as I am, so that I can go solve other problems. How do we increase agility? How do I make chat ops even more better for you? Even more better, I like the English language. How do I make it even more powerful for you by taking a look at, once I got to the point where I can do a single deploy a day, well now I can actually have metrics around how this is working. And I can start getting to 10 deploys a day and 50 deploys a day and 100 deploys a day. And ultimately to the goals of these big players that are saving all of this amount of time with systems like this in the thousands of deploys a day. And this is where we set yourself apart from a market differentiator is the ability to rapidly deliver. And you only get to be able to get something like that when you have an event-driven automation system where you're equalizing the knowledge that exists in your organization and providing those tools to everyone via something like chat ops. As a matter of fact, while we're talking right here, one of my colleagues is actually performing chat ops commands for his introspection. He's looking at a board that goes and looks at temperatures within a data center. So this could be something that I'm doing some passive information about to go figure out what's going on, right? Maybe I got an alert and the event-driven automation system underneath has gotten an alert that the temperature has gone up to an unacceptable level and begun an initialization of moving VMs to safe areas not in hot zones in your data center, right? This is power that you can suddenly make available to everybody. And this is really key, really key. I probably have like five minutes left but I'm not gonna give it. I'm not gonna say anything. I would like to know if anybody has any questions. Maybe how we can get started and go ahead to our website, stackstorm.com, slash community. We have a project called the ST2 Workroom where you can download an entire copy of Stackstorm plus chat ops and have it running in under five minutes. You can use the tools in order to add any of our packs that we've got available to us. Like I said, we have something about 650 different actions controlling everything from clouds to monitoring systems to alerting systems to logging systems, right? And if you've already got existing automation, you can bake those own very easily. And you can get started with it right away. Trying it out. So let me just open the floor again. I've got about five minutes. Are there any questions I can answer for anybody? Yeah. Yeah, so the question was is when I log in tomorrow am I gonna have 5,000 things to read? Well, you know, you might, right? I don't know. It depends on the communication structure of your org, right? So I used to previously work at GitHub where this thing happened all the time every day. They basically ran their entire operations via chat ops, right? And sometimes I would wake up and there would be a lot going on because we had an incident or an outage. But you know what? I wanna know the details around those, right? And likewise with chat ops having something like that, suddenly now I can have an entire incident stream of the event as it happened, as it replayed the conversations we were having, the things we did to try to remediate and whether they worked or not, all in line in a linear form, right? That's hard to put together today in our disparate communication channels that we have where there's email communication happening or phone conversations happening, right? And so the idea is that there may be extra, but now you've got a log of it and you're able to go query it and parse it at your own leisure, right? And if you don't need to get it, then that's fine. But the power is it's there and if you need to go look at it in the future, it's there. What are the questions? Yes, sir? Yeah, so the question is, what does the architecture look like? How do we do this stuff? I'm gonna just bring up the architecture of StackStorm real quick. Certainly like I would love to have this conversation in depth with anybody who wants to do it. We are at booth T17. We've got a demo of chat ops going on over there. I'm happy to dive into it. But as a general rule, let me just kind of show you, let's see if I can get this going real quick. Nope. So I'm gonna log into the box that we've been using for this demo here real quick. And I'm gonna run into my StackStorm, Pax, Twitter. And we're really big on YAML as a concept. So in our event-driven automation view of the world, we can actually go ahead and execute anything, right? Any language in any view, if it can return zero, that's a positive, it returns anything else that's a negative. As a matter of fact, even if it outputs JSON, we'll automatically parse that, make it available to you, right? So from an alias here, from this perspective, this is something that we want named and how it's gonna be executed in the context of chat ops, right? So the tweet ST2, right? And then I have my format about the English human language that I actually map those commands and how they're requested to the parameters that are executed in our workflow here, which is go execute this thing, right? So making a new tweet, making a new alias for a chat ops command is literally download repo, add alias three lines or four lines, depending on how you wanna go do it, commit to repo and then run the deploy command that we saw in this demo. That will automatically reload and get it going and it's ready and available for you. So the minute you wanna open up something, it's about two minutes worth of work. From an architecture perspective, what we do is we have an underlying event-driven system that relies on different bots. So we have a bots, right now we support Hubot and we're working on support for Lita and Ur, which are other different bots. And those bots sit in your different rooms and they connect to things like Slack, HipChat, IRC, pick your favorite client. And those will send messages to our API endpoints and then receive information back in this in the same way that our entire event-driven loop does. And I'd love to go over it some more in our booth. What else can I answer? Awesome. Well, thank you very much for your time. Again, if you have any other questions, we are at T17, Stackstorm and ChatOps. I love talking about this. You can also reach us at Stack underscore storm or me specifically at at JFryman on Twitter. So thanks so much for your time, I appreciate it.