 All right, welcome everybody. I've been reminded several times that I am the guy standing in between you and the welcome reception afterwards, so I will try to keep this pretty even keeled, but I do hope, as part of this process, that this is more of an interactive session. This is supposed to be a Birds of a Feather session. Really hope to have a lot of audience engagement and a lot of conversation around the topics. So that's what this is intended to be. Speak up. I've got a few slides up front to kind of help guide the conversation, but really it's more of a conversation than anything else. So a little bit about me. I've been doing computers and softwares for a long time, more than I care to admit, but really if you were in a previous session, I came to learn about light bends, learn about Aaka and Scala as I was working on a machine learning startup some years back about eight, nine years ago, and the way that that happened is I was starting to look at Spark. We were trying to understand how they were processing data. We had similar needs, and so as we looked under the covers, we discovered a lot of Scala. We discovered Aaka, and so we began learning about it and decided to use that as our implementation stack. Fast forward a few years, I was working with another company where we had a large e-commerce platform. On that platform, we were processing 10 digits of revenue annually across about 25 markets worldwide, so it was a very busy e-commerce platform, but we were running into problems of scale. So I thought back to days where we were learning about Scala and Aaka and thought, wow, how can we leverage those lessons into what we're trying to do to scale this e-commerce system? So I ended up calling LightBend actually and asking them for some help on some training of my staff. That's how I got to know reactive architecture, and here I am, so it's like coming home. Being amongst all my people, this is wonderful, so grateful to be able to be here and to visit with you all. So what I wanna talk about is, we've heard a lot today about how reactive systems are super powerful, how they can accomplish so many good things. We've also heard how they're very challenging, how they're very hard, and some of the difficulties that we faced. I want to flip that a little bit. I want to talk less about the technology, and I want to talk about the other side of this equation. So how do we introduce reactive architectures to your executives and your technical leadership? It's a really, really important conversation point as you're trying to move forward a reactive agenda to be able to get that buy-off. But equally important, how do you inspire your technical teams to change the way that they've been doing things for many, many, many years? This is so ingrained into how they behave and think, but the ways that we talk about reactive systems and the things that you need to do are very counter-intuitive to how they've been doing things for a long time, right? So how do you get them to make that switch? How do you package those ideas so that they're easily consumable and exciting? So how do you get people fired up to be able to start working on these kinds of things? How do you convert the fear, uncertainty, and doubt into the fear of missing out? How do you get them to the place of, this is really scary, I don't want to bet my business on this, I don't want to make this giant leap into, I need to do this because this is how I'm going to ensure the survivability of my business as we scale, right? Really, really important to help them make that switch but this is a really hard thing to do. That of course inspires forward momentum. What I want to do, this is the conversation part of this presentation. I want to learn from you, I want to know what has worked for you and what hasn't. What are the things that you have found as that you've encountered? What are the things that trip people up as you start talking about reactive architectures? Make sense? Wow, we really need that next session. So I want to understand more about you guys really quickly. I know this is something you've seen several times today. Quick show of hands, how many people have implemented their reactive systems and architectures? You're here to really kind of sharpen the saw, learn a little bit more but you feel like you're really on the way, okay? How many of you are just starting that journey? You have some systems in play or you're in development with the system, you're committed to the architectures but really not something that you're moving forward with? Zero, okay. And how many are here just curious about reactive architectures and you're trying to learn more to see if this is something that you want to move forward with and adopt? Again, oh, so a couple, great. I really want to hear these voices as we go through this conversation. So as I've tried to have these conversations with various teams that I've interacted with, these are some of the key areas that, key topics when we talk about what goes into implementing a reactive architecture. These are the things that people usually trip over. These are the things that cause them great concern and like, man, that James guy, he's talking crazy talk and I'm not sure that we want to do this. So some of the things don't need to read the whole slide but I'm going to monolith versus microservices. They're comfortable with the monolith. This is the model they've been working in for 20 years. They really, it scares them to think about what happens when they break that monolith into a bunch of little pieces. I have a hard time managing the teams that I have in place today and you want to break that apart into more teams. You want to change the whole architecture. That's crazy. Synchronous versus asynchronous. We've lived in a very synchronous world in terms of computing for a long, long time. To move that to an asynchronous architecture is something that frightens them as well. This is something that's really, really difficult for people to move toward. Eventual consistency, when you're talking eventual consistency, are you talking about milliseconds, minutes, hours, days, weeks? We don't know, it's eventual, right? That scares them when you start talking about the possibility of eventual consistency. Data in general, the way that you model data inside of a reactive architecture is quite different than you would in traditional relational database. So when people start thinking about this operationally, there is a production problem happening. How do I get my hands on what exactly is happening in my system so that I can report to customers? I can report to executives and I can tell them what's going on. They're used to being able to get their hands on a keyboard, but that world shifts dramatically when you start rearranging things for them. Consistency versus availability? We know we have to have the conversation, but a lot of times executives don't want to talk about, why can't we have both? I need both. It's not an either or decision and certainly there's shades in between those two extremes, but having that conversation is sometimes hard. And then finally, when we start talking about how you organize teams for success, it means a shift in their organization and why is that important? How can't I do this without doing that? I like to say often that the technical problems that you encounter are very interesting and challenging, but the people problems are that much more interesting and challenging. So making the technical leap to a different architecture, to a different way of thinking, is hard, it's doable, but there are people problems, the organizational problems on top of that are something that's even that much more difficult. So really what we're talking about is education. How do we educate people into, like I said earlier, converting the FUD to FOMO? You're really talking about an educational process. I want to quote a famous philosopher, the cowboy philosopher, Will Rogers. He said at one point, there are three kinds of people, the one that learns by reading, the few who learn by observation, and the rest of them have to pee on the electric fence for themselves. You need to recognize as you're having these conversations with everybody in your organization that everybody has a different way of learning, and you need to provide as many opportunities as you can to help them in this journey. So when you do that, you want to involve as many senses as possible. Don't miss an opportunity to engage somebody in a conversation. Think about different ways that you might be able to present an idea or a concept so that they have an opportunity so that it resonates with them. Make learning an experience rather than a lesson. So you want to be able to provide opportunities for them to rather than a PowerPoint presentation, like I'm doing here, you want to make things more experiential. So how can you engage them? How can you pull them into the conversation? And then of course, repetition. This is a patient process. You need to take some time with this. Don't get frustrated as you keep moving this forward. Be patient, be confident in what you're trying to do, and you will eventually get to the end. So the way that I want to shape this conversation, we're getting to the point where I want all of you to get involved, is one way that I like to provide these experiences is through games. The opportunity for someone to get involved in something that's a little bit less connected to the things that are immediately in front of them, that still have powerful lessons that can be applied to the individual environment. So I want to talk through those challenges that we've seen. I want to pause actually for a minute. I had this list right there. Does anybody else, any big stumbling blocks that you've run into, as you've tried to move things forward, read? Maybe that'll drive Kalex adoption in the marketplace. I don't know, but this whole notion of, yeah, you may sell widgets, but you're a software company. We're in the 21st century here now. Yeah, so to rephrase the comment, people, so going back to previous conversations, you're going to have to develop a lot more software than what you're comfortable with. You've got to become that software company, a technology company, to be able to advance what it is that you do in the marketplace better. We are in a digital economy where it matters, and this is how you differentiate yourself. Other key ideas, things, struggles that you've run into? There's got to be more than this. I didn't hit them all. All right, so we will step into it. I like to provide experiences, and one of the ways that I like to do that is through games. It's a very easy way to capture someone's attention, give them an experience, and then you can leverage what you learn as part of that into what you're trying to do with your reactive architecture. So, a few rules. Games need to be easy to transport. I can't have this big, bulky setup that I have to lug around as I go to different places or different meeting room stakes. 20 minutes to set up has to be easy to understand, has to be inexpensive to run, must be memorable. So again, involving as many senses as possible, get people engaged, and then the games can either be analog or digital. So with those key things in mind, I'm going to present some ideas for games that you might try and talk about some things that we have in the works. We don't have time for all of us to play games together, so we're just gonna talk about ideas here, right? The first is a game that I like to call Monolith Jenga. So back to this idea of monolith versus microservices. In a previous talk today, we talked about monoliths of monoliths where individual components come together to form a large architecture for an enterprise. So I literally did this with a company that I was working for. I took, I made a Jenga game, and I labeled on the sides the different parts of the system that we were trying to work with. So they were by name, whether it was by process or as a physical system name. And I invited a couple people up from the audience to play monolith Jenga with me, but what I didn't tell them is that I drilled holes in the end of some of the pieces and I ran fishing wire between them. So that when you tried to pull on one piece, it necessarily was connected to someplace else in the tower. So we could have conversations then about what happens in a monolith and why things take so long and why people are so worried about touching anything inside of this. Why does delivery velocity suffer? Because we have to be so careful about all the part pieces in the carefully constructed tower that we're trying to operate with. An enhancement I thought about for monolith Jenga is to include a deck of cards. So the deck of cards literally would be you need to move this piece. So it comes at us a little bit like a new feature or a new capability that business is trying to imagine. It's sometimes it feels random. I know it's not random. Sometimes it feels random, but you draw the card and you realize, oh, I need to move the LDAP piece. That might be a critical piece in the infrastructure and it suddenly becomes really difficult, very precarious task. I'm looking for suggestions. How can you enhance an idea or something else to talk about monolith versus microservices with your executive team? I'm hoping that this is going to help all of you as you have conversations, by the way. Ideas doesn't have to be monolith Jenga. Yes. Can I have you hold that for a second? We got a microphone coming to you. Right there. Yep. More like a thought than an idea, but like strangler pattern. How would you represent that? How would you represent a strangler pattern in this? So in a strangler pattern, literally what you're trying to do is you're trying to take one of those blocks and you're trying to say, this is no longer LDAP and I'm going to make it something else, right? So you're replacing a block. You're not necessarily playing Jenga with it, but you're putting in something that's made out of rock or something else, right? But how would you go about doing that? It'd be worth having a conversation there. This one's kind of sticky. It needs to be, needs to move a little bit better. Thank you. Other ideas. This is a fun, fun experiment. Some other variations that I tried was while they're playing Jenga, you separate them by some distance in the front of the room with everybody watching. And you have someone that you hang a sign around their neck called DevOps and they have to carry the board from one person to the next and deliver it to them so that they can continue playing. Next game. With this game, what we're talking about is eventual consistency. This is a really hard time for people to understand but a lot of people don't understand that we live in a very eventually consistent world. So how do you communicate that idea? So here's the game idea. Go get a $15, $25 Visa card, preloaded Visa card, give it to somebody in the room, tell them they can spend it however they like. But before they spend it, they need to go put it on their Amazon account as a payment method and then tell them to go buy something worth $50. Anything they want, treat yourself. What they're going to find is they're going to find that they will place the order, they will get an order ID, they will get a confirmation email, they will get all kinds of things and they'll feel like they were able to successfully make this transaction. Couple hours down the road, they'll get an email back saying, hey, sorry, but something came up as we were trying to process your order. That's eventual consistency at work. A lot of people don't realize that they already operate in an eventually consistent world. So I'm looking for ways that you might be able to engage them and help them see that it's okay to be able to relax some of the real-time constraints as they are communicating with their customers in building applications. Other ideas, eventual consistency. You guys have all run into it. Read. So talking about coherency delay. So schedule a meeting with a whole bunch of people and see what happens. Takes a long time to make that happen, right? It's pretty hard to coordinate. All right. Moving on. This is a new concept that I'm working on. I'm really fond of it. People I work with are sick of hearing about it but I'm gonna keep beating this drum. So we're working on an application internally that is hopefully a showcase piece, a sales aid that we can use to help people see what reactive systems can do. But as we're demonstrating this, I want to introduce this game that I like to call the IT Wheel of Nightmares. So you imagine all of the terrible things that can happen to a production system. A database goes down. I get a denial of service attack. There's a big sales event that the business springs on me. There's a new feature that I want to release. All of these things that happen in a consistent or not a consistent but a regular production system. So first you engage them with an activity where they interact with the app and they can see it performing in real time. And then you invite them to come play the IT Wheel of Nightmares. Someone literally comes and spins the wheel. It lands on one of these catastrophes. The database goes down. You ask them questions like, what happens in your system today when the database goes down? We can have that conversation. Now in this system, let's talk about the database goes down. I can say, which one? What do you mean? And then we can talk about event stores. We can talk about projections. We can talk about all of the different ways that we handle and treat data differently in a reactive system. We can then actually enact that catastrophe. So a little bit of chaos engineering where we can pull something out of the system and then we can see resiliency at work. We can see how the system is actually going to behave. So when we get this thing in place, I hope to be able to make that more generally available so that not just us are using that but other people can use this in your conversations with your teams to be able to help them understand reactive systems. Enhancements are ideas for the IT Wheel of Nightmares. Maybe a better name. But I like the name. The Chaos Monkey. Kind of the same idea. But again, you're pulling people into the conversations, the ones that you're trying to educate and you're giving them an opportunity to play the hand of God a little bit in spinning this wheel. So it gives them a little bit more engagement. What's gonna happen? I hope it lands on the whatever square, right? I want to see what happens. All right, last one. This is really talking about organization. This is a game that gets played often inside of lean circles. So lean manufacturing in particular. The idea is you have a team of people, four to six people and their task is to build as many airplanes to specific paper airplanes to specification as possible. So part of the specification is the little writing that you see on the wings there. They have to be able to produce airplanes of a certain specification. And with this game, what you do is you introduce different concepts as you go. So I want to organize the teams differently. You introduce different rules. You introduce pull systems versus push systems. A lot of different things that you can do to change the dynamics. And through a couple simple exercises, maybe an hour of time, you can show people how you can change the productivity of your team with less people with less resources and get double if not quadruple performance in terms of things that are made. So when your team starts talking or your executives start talking about delivery velocity, how do we achieve that? Part of the message is you have to think about the way that you organize your teams differently. This is a really hard message for people to get to receive, right? But you want to show them in a real way how these little changes actually make a huge difference in their ability to move forward. Of course, then you can start talking about what are these teams going to do. You can start introducing reactive ideas and concepts. You can do that little by little, slice by slice as you have a longer term roadmap for how you would achieve your goals for a reactive system. Okay. Those are all of the games that I currently have in play. Ideas for other things. There's several topics that we haven't touched on asynchronous communication, cap theorem, Conway's Law. We talked on a little bit. Other ideas, games, things that you've seen of work, things that didn't work. Have you taken, how many want to go back and start playing some of these games with your teams internally? Couple of you? I'd hope a few of you do go and try. I would love to get your feedback back as you play these games and hear ideas, advancements, changes. Of course, we want this to be a continuing conversation. So please, as we mingle in the lobby here, please come see us. Follow us however best to get ahold of us. We would love to talk to you just to learn about you and learn about how things are going. We're always interested in improving our craft and a big way that we do that is we learn from others instead of peeing on the fence ourselves. So anyway, thank you for coming. Thank you for being part of my experience here and we look forward to talking to you later.