 Yeah, so I did this two years ago and I guess that means I'm experienced, but I've been so nervous for some reason. So I'm trying to just remember like there's so many people here I know from the meetups that I've made friends with, so I'm trying to just chill out, but here we go. So leading an enterprise to the public cloud, what does that even, what does that mean? I work for a company called I-Lone. It's a kind of a division of Springly Financial, which is a huge company. So in Chicago, we're hiring, everything is kind of I-Lone branded, and it's a super fun place to work, but this talk is about the enterprise. So to go with that, just a little background with me, I've been doing kind of technical work for, I don't know, 18 years, something like that. I was traditional IT, I've done, I was like the help desk guy before we even called it the help desk to high performance computing. And then what I would basically call like high traffic websites or admission critical websites for the last six, seven years in the DevOps space. And all the automation of Puppet, Chef, Ansible, Docker, all of those kinds of things. But the last, like my talk two years ago was very kind of compliance and auditing driven, this is, this talk is very enterprise driven too. So, but it's about the cloud. So what is the cloud? Google, Google knows, it's bullshit, right? And I wanted to give this talk, I was tempted to like, every time you're gonna say cloud, like say cloud, but instead if you've seen that like browser plug-in that turns the word cloud into but everywhere. So I'm not gonna define it, DevOps is not really defined, we all know what it is. We're here, maybe you're learning, but it's not, it's not like something you can go and definitively say what it is. I think the cloud is similar. But what we know is that people are using the cloud, people are moving to cloud more and more and more. And just some factual stuff, I mean, Amazon Web Services, it's approaching $10 billion year in revenue, it's pretty amazing. Microsoft with Azure is kind of newer to the game, but doubled year on year, $800 million. Is that like the end of Q2 or the whole year? I don't know, it's just ridiculous amounts of money. But what's happening is, like Amazon is not an equal distribution of who's using Amazon or the cloud. So the old man yells at the cloud, and millennials are to blame for everything. So an enterprise, what does an enterprise mean to you? And I can be a bit flippant about things and I should probably be more polished. But the first word that comes to my mind is terrible. So if you want enterprise software, that means I want some terrible software. And we've got enterprise practices, what does that mean? It's change control with multiple layers of approval and just weeks gone by. So I'm thinking terrible and trying to. So on the right side, I try to think, there's some other things. As an engineer, I'm excited about problems like hard problems to solve. You get those at scale, you don't get scale if you're not making any money. And once you are, you sort of become an enterprise. And then you have that money, so then maybe you can do some green field work. And you've got deep pockets to do fun and interesting things. I'm getting so excited by security kind of problems because it's like, all right, I've been doing infrastructure automation for quite a while. I can run in another Rails app is not that exciting to me. But suddenly we've got millions of customers, their data from their credit reports and their bank accounts and all of this kind of stuff. Nobody, I want to protect that, I want to do as good a job as that as possible. So that's kind of exciting to me and you get to at scale, like that's a bigger problem to solve. So I mentioned I loan, we're tiny, we launched our business a year ago, September and it is owned by Springleaf. Springleaf is 90 years old and they acquired one main financial which was their bigger competitor a year ago. So just like scale 2000 something branches where you want to, what we do is essentially we lend money, you want to borrow money, you go to a branch and like this is who I am, this is my driver's license. And they, just for kind of a scale, like they've lend out 14, $15 billion, collecting interest on that, that's pretty good business to be in. So that's great, right? Except brick and mortar businesses aren't necessarily the future and really any business you have to innovate. So you find yourself in, you're an enterprise now, you're a victim of your own success, how do you continue to innovate? So that's kind of where I loan came in and this is before me. I joined I loan 15, 16 months ago, about four months before they launched the business. And they were, development environment was already in AWS. The decision was already made like it's going to be in AWS. That's why they hired me. I've been running production applications in AWS for six something years. So it's great. I didn't really even know about the parent company that much. A little bit of a bait and switch there, I'm not bitter. So it's like you can do everything. And so we did and it's great. But what I found out over time is like all these exceptions got made, right? There's audit really wasn't particularly involved and socks and infosec was pretty hands off because it just wasn't material. I think initially we had no business value, right? We had no customers. We weren't making any money. But over time, it's important because it's something we feel is very important for the future, but materially the number of customers, the amount of data we're protecting, it's not the same. So they make all these exceptions. And I just want to point out it's a valid business in its own right. I mean, it's super important. I would not want to take that away from the people who work on I loan at all. But for me, it was also very much a proof of concept. It allows the enterprise now to do this again. And why do I want to do that? I want more problems, hard problems, scale, all of that. So what's happening, what happened in that Chicago office is a brand new office. Brand new team of developers, new ways of doing things. You ask pretty much most companies and development teams, even when they're really, really awful or terrible, they think they're agile. Because agile is just like, of course we're agile. It's been around since 1999 or something. Yeah, but they're not particularly. And DevOps is like, I'm a DevOps now. My team, we're the DevOps team. It's resistance is futile, that's what we get called. Even though I think, hey, it's about collaboration and things like that. But this team in Chicago, they're really solid people. They get that helping each other is important. And that we're kind of like all one team and in it together. And just the DevOps way, so to speak. And along with that, how do you operate that? You kind of throw away all the rules and you say, this is how we're gonna do it. I hate the expression, but as if we're a startup. And but we are doing things like continuous delivery, release when ready. We're shipping code multiple times a day. But you hire a person like me and also just the other managers are very experienced. They've run businesses at scale, this is not the wild west. We take security and all of these kinds of things super seriously. So the kinds of things that we did with I-Lone really paved the way to do some other things. And so what we did was we brought in outside security consultation. Don't take my word for it, who am I? It's like, is there some credential that would make my opinion valid? Probably not. So the things we asked a security company to say, this is our network architecture. Does it make sense to you? Is it secure from like, you guys are the experts. That is your industry, that's your value add, tell us, how can we improve it? What kinds of security appliances should we have? This is what we have in mind, and does it make sense? And it can be very different than an enterprise because I'm going to use open source technology and I'm going to build some things myself. I'm not always just going to look at the magic quadrant and go, yes, I'll buy two of those, please. So we also had a formal risk assessment done. So we decided to, for all of our controls of how we manage risk within the company, we would adopt a NIST 853 standard for everything. And ask the security company, what should we be doing differently or better, what can we improve? And that was a good process. The output of it is, I guess the risk assessment part of it is they come in, they interview you, they talk to everything about how you release code, how you test your code, how you harden servers, things like that. And you end up with this risk register of things that you need to mitigate. And an easy example is, I've got a VPN. The only access to all my AWS infrastructure is through a VPN. But it doesn't have MFA enabled, right? So MFA is a good thing. So pretty easy, you go add, integrate MFA into your VPN connectivity. So that's a simple example. But they give you this tool that helps you manage your risk and pay it down over time. And it's complicated, I won't go into that anymore. But the output really is there's all these technical things you should do better. And then there's a whole bunch of policies that need to be written. If you don't have it written, what you do to keep a secure posture, it's almost like you don't get any credit for it at all. And so maybe that's my talk from two years ago is you should be writing these things down and make them auditable and things like that. Another thing we did really without being asked by any part of the parent company was to form a information security management group. So we took, basically me, I have a security engineer on my team, the two heads of development, we're like, we need to talk every month about new vulnerabilities or patches or just security projects, implementing web application firewall, all this and that. Just talk about what we're doing, put it in writing and share that information. And so we would do this every month and quarterly we'd invite executives from even higher up and we would share this information. So kind of the thing for me there was like, I'll go back. But the more you share, the more trust you get, right? So another one we did was, okay, like I said, we're not the Wild West. We get pentested. In fact, we did two rounds of pentesting for I loan. It was a year and a half to make enough that we could launch, right? A few months before launch, kind of do an initial pentest, where are we? Okay, now we're ready to launch another pentest, find more stuff, fix any higher critical finding before we launch. Some things we can put post-launch. And then, so everything's cool. And then I get an email one night from my boss. He's like, hey, you guys got red team pentested last night. And he worded it ambiguously to make it sound like they broke in. So I wake up to this and I start panicking, looking at logs. What do they do? Anyway, I find out they got nothing. They weren't able to have any findings at all. And the nice thing is they took my team out to dinner and spent a ridiculous amount of money at a very nice, fancy place. And it's like, you felt appreciated, which was good. So all this is kind of going on. And you've got these dev teams that are fast throughput. And somewhere along the line, I found this thing, I've started reading way too much Gartner stuff, mostly to be able to speak to executives. And this term bimodal IT came out. And if you've never heard of it, it's kind of worth reading. But I found it and it just resonated with what was happening. You've got this fast moving department able to iterate and measure and observe what's happening on our websites, what are our customers seeing or doing, and respond to it. You see something that needs to be fixed and you can fix it really, really fast and the rest of the company is more, it's gonna take time. There's a lot more effort, there's huge teams of manual QA. And I'm not saying that's bad, there has to be because those systems are older, they're harder to kind of, you can't just turn them on a dime. But I took a little bit of Umbridge with the idea of bimodal IT and that it's kind of a recommended good thing to have a slow moving part of your company and the fast moving part of the company. That's actually not bad, but the idea that if you're moving fast, that you're also now insecure or unsecure, whatever that word would be. And then essentially you're like cowboys, right? And I'm like, we can move fast and be safe and stable and secure and all of those kinds of things. So if you're familiar with Jez Humble, he kind of put everything I had been feeling into writing and articulated it way better than I ever could. And it's like here's the flaw at the heart of that. So moving along, like I said, I loan was kind of our entrance into this. And I think because we were doing a good job, the guy who heads up the springleaf.com web development team, who's in Chicago. This is again like a kind of modern dev shop, fast moving, continuous delivery. They deploy even more frequently than the I loan team does. And he's like, but I want to be in AWS. And can you help me get there? So I said, sure. I've only been at the company at this point like four or five months. I didn't really know 100% what I was signing up for. And I also, I kind of thought like, hey, I'm going to do the technical work. But actually most of the next like eight months was convincing the business that this was a good idea. That's kind of what the rest of it is. And I guess my main caveat was I have to hire somebody else. I think the more you do, the better your automation has to be. The better your test coverage has to be for your infrastructures that you can make changes in a safe way that you've not just kind of left technical debt for the future behind. And so I'm like, I have to hire somebody. So hiring is really hard. I'm probably guilty of wanting one person that can do all of the things. Because I don't know, like the other sense, we're not out in Amazon just yet. And I loan is so small, not making money. How big should my team be? So I can't have a whole bunch of different people. I have to have a pretty small team. And they kind of have to know how to do everything or be able to learn it. So that took me six, seven months to find the right people. And this kind of like there's a report here that I would have thought the top concerns would have been security related or compliance. But actually the lack of resources like finding people. We've done this kind of thing before is really hard. And knowing exactly what that skill set is is also hard. I actually don't care if people have Amazon experience because I view that as probably the easiest thing to learn. So all right, so we're gonna do this thing. We're gonna bring springleaf.com out to the wild cloud. And I think I skipped past it, but half of all new business comes via that website. So it's critical and there's suddenly, there's no like, this is a minor part of our presence as a business in front of our customers. That we're gonna make exceptions for. Everything has to be approved and above board. I didn't even know who the stakeholders were. I had no idea how to get approval for this. And so maybe we should have had a plan. I had no plan. So I just kind of asking questions in the dark, who does this, who does that? Kind of find my way to the right people. I guess I just wanna say this, this talk is kind of a journey of what happened. It's not necessarily like, this is gonna work for you. You need to copy all this. I do think there are some things to be learned though. So what we did was I just started asking people questions and figuring things out. I eventually learned there's a bunch of stakeholders and this is my fake little org chart, can you see the whole thing? And I had to kind of appease people within IT and Infosec and internal audit and SOX and I was part of the product development so that was easy but then there's even cyber risk and legal. So I'll talk a little bit about each of those I think. Probably my first conversations with IT were probably November-ish. And we explained the network architecture, service oriented architecture, like how we do everything that we do. I kind of thought they'd be like, wow, you guys are so cool. And I thought maybe it'd be like a collaboration and they really just looked at me and were like, you're gonna be busy. Like, I got no problems but you're gonna be busy and I'm like, you're not gonna help at all, this is just us, okay. And so some of those same people were involved and but now we're talking Infosec and networking people and the network team was probably the most technical that we worked with. And they were, what does this network look like? And can you draw a picture? And I gotta say, I drew a network diagram so many times that in June, so six months later an auditor said, can you update the network diagram to show where this one firewall, and I just said, no, I'm done. I will print it out and draw it with a pen. Like I'm not going back into Vizio or ever again. So I'm, I don't know, I'm not the most, I think that's like a DevOps failure or something, but I don't know, I just, you reach a point. So kind of the things we're gonna talk about are listed there. The shared security model of Amazon, and I would think this would be the same with Azure or something else. Who's responsible for what? I don't have access to layer three down in Amazon to know what's going on in their network. I have no idea what their hypervisors look like or how they perform or how they keep me safe from some other customer. But they give you a nice diagram and we talked about this. And I'm like, they secure the cloud, I secure what's in the cloud. And I don't know, I talked about this a lot, but it's really hard to tell. I always think people understand me and then they go, I don't have any idea what you just said. Okay, I'll try again. And the network architecture was similar in that I would, so I'd say, hey, Amazon, if you look at their VPC, of course, we're gonna use a virtual private cloud. They give you a few different examples of how to configure it. This is scenario two. You've got a DMZ and you've got a private network. And there's things on that drawing that people ignore. Maybe it's not even on there, but that's how I've always built things. And people thought it was my idea, and so they didn't trust it. Because who am I? I've been there now five, six months. These people have worked there 20, 30 years. So I'm the new guy, and they don't know me. And so why would they trust me? We have an external security company saying this is good. But still, we're not really getting like, yeah, that's good. And then NIST published a standardized architecture for enterprises in AWS, and that was in January. And I was like, yes, it's not my opinion anymore. And it's a little hard to tell, small diagram. Google those words, you'll find it. But essentially, you're getting back to a three tiered architecture that enterprises love. And it's okay. All it meant really was like, I've got my EOBs and the DMZ. I've got my application servers and a kind of middle tier. And I've got my databases in a different tier, segregated at a network level. And that's a good thing. And then we have connectivity back to the data center. So this was, there's things we have to access in the data center. Like if you have an I loan loan, you cannot also have a spring leaf loan. We need to be able to talk to each other and figure out, you probably could. But depending on the state, there might be a limit on how many fees we could charge you, or as maximum we could loan to you. There's just a lot of laws. So there's APIs that we have to interact with across that wire. So a direct connection is encrypted, five minutes, whoa. All right, so I'm prepared for that. Infosec was like, I want all these tools. And I just basically said, okay, we will do all of those things, except like some of them don't make sense. You cannot, like a software defined network, you cannot snoop on it the same way that you can snoop on a corporate network router or switch. So we had to, we kind of had to evolve the stance to let's use, let's have parallels for all the tools we have, and we use the same ones if we can. And then we can always kind of iterate later if there's a better way of doing things in Amazon. Something's completely lost in translation. Security groups and network ACLs, I basically think these are, if you can't buy it, if it doesn't have a label, if it's not a next generation firewall, then it basically doesn't count. They're really, really powerful and hard to get set up correctly as well. And I could talk about that. They wanna know, okay, we're doing everything different. Are we throwing away all the rules? Are you still hardening servers, controlling access to things? Are you encrypting your data at rest in transit? Yes, yes, yes, yes, yes. We're gonna do all those things. We'll document it, we'll share it with you. Now we're gonna do it. Again, we bring back the security consultation. Get a new risk register just about the spring-leaf infrastructure. Another pen test, because it's different applications in the I loan one. So here we get to, okay, so I'm working with teams. We gotta get kind of higher level support. And this is where I'm start reading things like American Banker and Wall Street Journal trying to be like, what financial service companies are going to the cloud? This is not my comfort zone. But they very much wanna, nobody wants to be the first, right? They're like, are there banks and financial companies doing this? So start going there, skip some of that. So really, this is key. We put all of this in writing. We had a written business case, like why are we doing this? What's the scope? What are our concerns? And if you capture people's concerns in writing, it allows you to kind of argue back or suggest an alternative. That was probably the most essential part of getting this greenlit was having it in writing and just kind of continuous, just relentlessly following up and addressing concerns. I'm just gonna skip some of this. Audit, socks, cyber risk was the last one. And finally, on June 20th, we have no concerns, which is their way of saying, go for it. So now it's time to build. That meant we also required one main. They're like, that needs to launch in AWS too now. If that's how we're gonna do everything, your deadline for launching that is 10-1, cannot be changed. You've got 12 weeks, build everything, right? Okay, we got this. So this is fine. This is also fine. And anyway, that's kind of the end. There's several lessons to learn that I could talk about if people want to know more, maybe in a breakout session. But we'll say no executive cares about your technology. Chef, puppet, docker, serverless, immutable, just totally worthless to talk about. Pick your battles. I really just fought with, if this is gonna create my team more work, either now or in the long run, I will fight. If it's like, you want me to send some logs somewhere else? Okay, I'll send some logs. I'm also gonna do log analysis myself. But there's no harm. One last one maybe is confusion grenades. I never heard this term before, but I was accused often of lobbying confusion grenades. People asking me a question, I start answering, and I completely misunderstand either what they wanted to know or an effective way of telling them. So we helped each other a lot. I very rarely would talk by myself, we'd have other people and it'd be like, I would try, I'd see eyes glaze over and it'd be like, Ron or Gino or somebody like, can you guys try, like let's, so you gotta come at it from a lot of different angles and those communication styles, like some people don't respond to email. They want phone calls and voicemails. This is crazy to me. But if you understand how other people want to be communicated with and it's important to you, you gotta meet them where they're at. You can't just wait for them to come to where you're at. Keep your requests simple. Relentless following up is really the key. And we got four weeks left to launch all of this stuff. So I've been a little stressed, but anyway, I probably ran out of time. Skip to the end. Talk to me if you want to know more. Thank you, Brian.