 We'll get started in about two minutes. I have my time, the official time from AT&T, is 4.30. But our clocks in the hallway say 4.28. So I imagine most people are looking up in the hallway. So we'll wait to give people a few minutes to find us back in the deep, dark corners of the conference. So I want to thank everybody for taking some time this afternoon to spend it with me. My name's Greg, and we'll go through a little bit more of a formal introduction. Here's this is making too much noise. So I will take off my official garb that they made me wear. Hopefully people have had a chance to make it down to the booths and see what's going on down there. There are some good demonstrations, some good conversations happening I've seen. And I would like this to be interactive. So as we have discussions, feel free to ask. I will do my best. There are very bright lights, so I sort of see bodies out there. So wave your hand if you have a question, or better yet, walk up to one of the mics. The reason we ask you to walk up to one of the mics is they're streaming this. And so we want everybody around the world to be able to hear your question, because it's probably the same question they have. So if you do that, we'll be able to share that knowledge with more people. Now the clock's going backwards. It says 4.27. I'm not sure how that's working. Well, I'm going to go ahead and get started, because I really dislike people who are late. So we're 90 seconds in, and we'll start over. Thank you for coming today. My name is Greg Prisbee, and I'm here to talk to you about you must be 12 factors high to ride. Who here is a developer? There we go. That's good. Who here is operations? You have pretty much the same hands. Anybody operations and not a developer? Well, everybody here plays that wonderful DevOps title. And what's funny when I found out about DevOps, there was a talk about it, and people were like, oh, DevOps. And they described it to me, and I said, well, what is this DevOps? And I said, well, you know, you're right code that's in production that does stuff. And I said, oh, you're a developer. I mean, that's just how I grew up. That's how things work. And to that point, so that you have a little bit of understanding of where I come from, because everybody's going to have a slightly different view, a different background, different experience. So I started writing code when I was 11 years old. Yes, they had computers back then. Yes, they were available to people. They were time shares, and they were in the school. But you still had the ability to write code. Anybody remember the Star Trek game? The original Scott Adams adventure game? Oh, come on. I can't be the only person that old in the room. No? So that's how I started. And there was a book called The Big Book of Basic. And it was this giant book. And you sat there and typed in all the stuff. And that's how I learned how to program. So from there, I programmed, I did war games for the United States government for a while. And then I got tired and decided to get out and do consulting. So now I was no longer coding. I was also starting to architect. And I was starting to design. And then sometimes I would do the coding or sometimes push it off. I stayed away from QA as much as possible. Next thing I did was someone said, hey, we need a database. So I really dislike databases. But there was a person named CJ Date who wrote SQL. So he's the one who invented that language. And so I got that book. And I actually had to implement an SQL engine. So I learned a lot about that. And then when I went into production, I was a guy supporting it. So again, already doing sort of that DevOps. Moved into operations, true operations, supported over 45,000 servers in a curve roast infrastructure with a team of nine when I left. So understand that whenever you're doing something, you want to automate it. You don't want to repeat. And so that's a theme that's going to be coming back during this. To let you know I've been doing open source since 92. I was doing free software back before it was cool in the 80s. When the 90s when open source came around, I got into that and started with Linux. So I worked for VA Research, VA Linux. I worked for SUSE Linux, or Zuza if you're German. And I worked for Red Hat. Now I'm at Mirantis. So I've gone through a number of companies and seen a number of different things happening. And I want to share those experiences with you today. Pothole. This is DevOps to me. This is 12-factor right there. And how is it? Well, I'm driving to work one day, and I see this. And I say, you know what? Wouldn't it be great to have an application available to me that I could say there's a pothole at this location? So I have an idea. I have a problem that I'd like to solve because this people can blow out your tire or whatever so you get a flat, throw alignment out, cause an accident. All sorts of bad things can happen from this. So from a public safety point of view, it'd be very important to be able to solve this problem. So I have this idea. I want an app. Or I want to have a website where I can enter this information. So now I have an idea. Now in traditional, so this is one idea, in the traditional world, you're going to have two modes of IT. And what are those two modes? And if you were at the keynotes on Monday, you heard them, and you heard our CMO Boris explain his thoughts on Gartner and pieces. We'll talk about that in a little bit. But you have the traditional IT, the enterprise IT, the legacy IT. And in that environment, if I had this idea and I wanted to develop it, it would probably take a little bit of a while. Not writing the code. That's the easy part. But getting a place that I can do the development, well, maybe I could do it on my laptop or my company computer. But then I need to give it to QA. And I need to explain to QA, here's the operating system. Here's the tools that I need. Here are the libraries that I need. And let's put all those pieces together and put my code on top of it. And that can take some time, especially if I don't have a lot of servers lying around. Or the servers there are running a different version of the operating system. And they don't have the tooling I need. So that could be days, months. I have customers, it takes weeks, I'm sorry, it takes months for them to get those servers. It takes a while. And then production. So again, my idea in writing the code, I could do that in an afternoon. But to get it into production may take months. And that's what we mean when we talk about the bimodal IT, mode one, the enterprise, the legacy, some of the parts that are slowed down. That's from the infrastructure side. There's also coding pieces. And we're going to talk about different ways to code when you move into mode two or the cloud apps. And so that's what you'll hear people refer to as cattle. The idea is that I can get as many of them as I need. And when I don't need them, I get rid of them. However, I want to get rid of that cattle and only keep the ones that I need. So I just pull them, use them, and throw them away when I'm done. And that's really what mode two is there. So I have the idea of an app. And now I need to try to get it out to the market quickly. And we're going to do that with following some principles around 12-factor app. So one, I have an idea. Two, I have modes of IT. Three, I have parts. So this was actually not part of my slide deck until Monday night. To me, this was a known thing. The technology is easy. OpenStack has gotten much easier over time. That's not the problem. The problem is how do I get people to change the way that they work to be able to consume? How do I get them to fail faster? How do I make life easy for them so with the push of a button they get everything that they need to be able to do their work? Then I'm going to talk a little bit about the process. So how do I take that code? And then through process, make it available for production. And I want to automate that process. And so you'll hear terms CICD, continuous integration, continuous deployment, and possibly continuous delivery. Most people are into continuous deployment. Some actually go all the way through to continuous delivery, which is installing it into production. So what we're going to talk about is how do we get those people to change their methodology and how they like to work? What are the processes that they need to define to be able to do the work? So here are the people. The people, as I said, each one up there has a skill. They have a way that they like to work. And what we want to do is to bring them all together under a common goal and make their life easy to be able to deliver these Mode 2 type applications, these Cloudy applications, these 12-factor apps. So that's what I was talking about. One of the things I talk about is you'll hear people talk about we're going on a journey. So we'll see if through these few slides you'll understand the journey. So here's my process. How do I get from point A to point B? How do I take the code? How do I build it and deliver it into QA so that QA can do their testing? And then how do I go to production? I need to find my roadmap. I need to find the process to get there. And so this is the process part. And then finally, we have part three, which is the technology. And the technology, as I mentioned earlier, is not the hard part. We can get OpenStack. Heck, you can buy an appliance that's drop-shipped with two power cords, right? So I can plug it into different PDU so I can withstand losing a PDU into the data center. I can get a couple of drops up top so I can get routed into the proper networks. And I'm ready to go. So being able to consume OpenStack, or be able, I'm sorry, to deliver OpenStack, that part's easy. But how do I actually use this thing? And so there are a bunch of different tools, right? We'll talk about the app that you're building, the CI CD pipeline that you have in there. Maybe you have some sort of application or orchestrator that's part of it also. So putting all those tools together and understanding the process and educating the people allow us to solve that one idea of how do I build an app to identify pallet holes so they can get fixed? Any questions so far? Are you by following me? Yeah, making sense? My whole goal, so this is the beginners, is to introduce ideas and they start to get people to think a little bit differently. So what do we have here? We talked about the one idea, two modes of IT, the three parts, and now we'll talk about the four words that you need to keep in mind. Performance. So people don't think a lot about performance, right? Hardware has become cheap. Anybody who's been developing for 30 plus years remembers when hardware was very expensive to run in a timeshare or to purchase, right? So you had to write efficient code. That's no longer the case. People don't worry about memory leaks anymore, they don't worry about those things. It's like I'll slap something together, I'll just crab this piece of code, that piece of code, put it together and let it go. In a web app, right, in these 12-factor apps, performance is important because you're scaling out to what's referred to web scale. I'm not gonna have one copy of this code, or 10, or 100, I may have 10,000 copies of this little piece of code running out there. And if I'm having problems with the performance, maybe it's too slow because it's going out the disk. So hey, let's do something in memory instead, right? Maybe I'm spending too much traffic across the network. So how can I solve that problem, right? Maybe I'll write to a backing store that I can then pass a pointer to, right? An object pointer to be able to pull that data back. So you need to think about that. There are plenty of tools, there are plenty of books, there are plenty of tutorials on how to do performance. Don't underestimate it, spend some time there. Elasticity, right? That's why I just talked about this thing is gonna grow. So you really need to think about these components that you're gonna build, how are they going to scale? And there are a lot of tools out there that you can use. There's a tool, I believe, Chaos Monkey, that you can throw and to see how your app is going to behave, right? When I throw in bad data, but also you can do scale up to see what will happen. Resilience, you want to loosely couple your pieces. So what I do is I think about the UNIX model and I will come back to that. But I will simply say, if you think about UNIX, you have LS, right? You have grep, you have find, they do one thing. So think about when you're building your app, you're gonna have these different components that do one thing. And I'm gonna have a defined input and defined output. I'm gonna pass the data or pointers if I store it somewhere else on how to move around. So by giving that, it's loosely coupled, which means if one of those components dies, there's not a whole lot in there, right? It does something very small, very quick. And so if another one springs up, it can handle it, so I need to have some resilience to say, well, if I didn't get a response, and that component I was talking to is gone, go ahead and fire up a new one and resend the data. So think about how you're gonna be building these things. And there are plenty of books on how UNIX was built. They're a little dry, but they're interesting and they may give you some ideas on how to do it. And the last one's probably the hardest one, security. So who here works in security? Okay, who here has friends and works in security? So you're in security and people are friends with you still? Is that what you're saying? What I have found is security is the most maligned group outside of networking. People never like security and they don't like network engineers because they say it's always a network that's broken. So what I have found is people don't think about security up front, but if you spend just a few minutes thinking about it, you can put it into your app and have this wonderful tool. If you try to go after and you build your app and then you say, well, now I need to roll it out. And the security group looks at it and says, no, no, no, no, no, you can't because you did this, this, this wrong. So engage your security groups early, talk to them. Remember, these are loosely coupled components. So I have data moving. All that data should be encrypted, period. Everything that goes on the pipe should be encrypted whenever possible. And the important thing to know, so this has been a fact for a while. If you go and you look and see how many people have problems with hackers, 80% of the attacks are internal. So it's not that they can't get to the network, they're already on the network because they're an employee. So the thing is you're protecting against that. So be sure you encrypt. If you encrypt data at rest or not, different discussion. One of the axioms that someone used to tell me is if there's no meat, it's not secure. Has anybody heard that before? There's no meat, it's not secure. So this was when I worked for a three letter organization that was not a government agency, but was the way that most people got to the internet in the 80s and 90s. So that may give people an idea of that company. And we had our security curmudgeon. And Rob was excellent. And he would say, well, we have to have these certificates and these certificates have passwords on them. So we need to type in the password so that the certificate can be used to encrypt the data to pass along. Well, that means someone needs to type it in. Yes, when the system reboots, someone needs to type that in. Well, what if I put it on the file system? Well, then it's not secure because someone can find it on the file system because it has to be in plain text for me to be able to be read by the application to decrypt or to be able to use the key for the certificate. Well, what if I encrypt that file? Okay, what are you gonna encrypt it with? Well, something else, I'm gonna have that password in clear text over here, but you're not secure, right? If I don't have a person involved, at that point, I don't have security. So keep this in mind, right? Ask the hard questions, because it's better if you ask yourself than have the security people afterwards come and tell you this and you have to start over. Trust me, we're gonna get to the 12 factors. I'm just trying to set the mode here. So five, right? So we have one idea, two modes of IT, three parts, four words, and five design principles. So the first one should look similar. This is my Unix thing, right? So for instance, if I wanted to go to a subdirectory and find every file that I could and look for my name in that file, you know, the easy way, to me, off top of my head, my fingers know it, I don't have to think about it. It's find, space, dot, space, minus, type, space, F, space, pipe, space, X-args, pipe, grep, space, minus, I, minus, L, space, double quote, my name, double quote, right? So that will go, and if you look, I've taken X-args, I've taken grep, and I've taken find, and I've put them all together. So find, get me a list of files. X-args, take a list of files, and each file passed to the next string that's there. Search files, right, for a pattern. So again, these are components, and when you're building your web apps, your 12-factor apps, you wanna think about this. How do I break things in the components that do one thing and do one thing well? Decouple the data. The important thing here, and we're gonna talk about config files, I don't want any of the data inside my app. So this was a big deal with web stuff 20 years ago, maybe 30 years ago when the web came, trying to remember now, that you would have all your data in the HTML. And then someone said, well, there's this thing called CSS. So let me have my design guys build stuff, and then all the data that gets pumped into it somewhere else. So WordPress, perfect example, right? I can have a theme that I can load into WordPress, but all the data that's getting put up there, the pictures that's getting put up there, it's all different. I can give a different feel, even though the theme is the same. And again, that's the same thing, we wanna decouple the data, and we'll talk about why that's important. Communication we talked about in performance, right? I don't wanna be passing stuff along. If that component dies, I don't want all the data and all its knowledge to die with it, right? I need to make sure that I can get the data in and get the data out. So by using a backing store and storing that information and passing the object around makes it a lot easier to do that. And I'm also passing less data around the system. So keep your communication to a minimum, and that will help with your performance. You need to think about how it's gonna perform in scale, right, and then security. When we've talked about both of those a little bit at length. So with that, here are the 12 factors. So these are the 12 things we're gonna talk a little bit about. But before we drive into that, I just wanna ask, does anybody have a question or anything off hand that they would like to ask at this point? No, excellent. I'm also glad to see everybody's heads up, and I don't see anybody, as they say, praying at the iPhone or your device. So thank you very much for your attention. This comes from a website, 12, the number 1212factor.net. You can go out. It has wonderful text. It does a pretty good job explaining them. You type in 12 factor, space, discussion or detailed description in your favorite search engine, and it'll bring up a lot of sites. So I was able to use a lot of those sites to get information in different ways to think about it that I thought would have helped me when I started down this journey. So the very first one we'll talk about is code base. One code base is in some sort of version control, okay? So Git, RCS, CO, CVS, Subversion, Bitbucket, I'm sure there are plenty. Git being the popular one that people are using today, and sort of the de facto standard when it comes to this. What we're talking about here is, remember we separate the code and the data. So my code is in there, and I'll probably have a file for my data, because my dev data is gonna look different from my QA data, which will look different from my production data. And we'll talk about and config what that means. But I want to be able to pull out that code, not have to touch it, and when I installed it in an environment, it's gonna run in that environment, okay? Because I worked for a company in 95. They hired me in operations to help them deploy web. Excuse me. And what they were doing at that time was the developers would do this nice little website for a company that does student loans in the United States. And then they'd say, okay, we have the code, now we're gonna go to QA. I said, okay, great. So when they went to QA, they would have HTTP or colon slash slash dev.website.com slash whatever, right? And they'd have all these hard-coded URLs in it. Okay, what happens when you go to dev? Oh, we go edit every file, and we place the word dev with QA. Okay, what happens when you go to production? Oh, we changed QA to prod or a dub, dub, dub. I said, so you're testing code, and then you're editing it before you put it in production? Oh, yeah, yeah, yeah, how else would you do this? I said, well, what you're testing isn't what's going into production. How do you know what you're testing's right? People make errors. People are gonna make a fact, someone's gonna type something wrong and cause a problem. So you don't wanna do that. So that's why we have that code base that is that single code base that I'm gonna pull out and I'm gonna deploy in all the different environments that I'm not gonna edit, not gonna touch it. So important, keep that in mind when you're doing it. If you're thinking that something is different from dev than it is in QA, don't put it in the code. Dependencies. So how many times have you installed or tried to install something, only to find out it had the wrong version of G-Lib C, or it had the wrong version of Python, right? Or one of the Python libraries you needed. In the code, declare what you need. Specifically say, I need in GenX version blah, right? I need Apache web server version X. I need JVM 7.2.142, right? Say what you need and declare it. I can have as part of when we talk about how we build, release, and run, I can have files that are part of my code that make sure I check out or grab the right pieces from wherever they are to make sure that all my dependencies are set. There are things like CfEngine for anybody out there, Puppet, Ansible, Chef, Saltstack, and I'm sure there are plenty more. But all of those can be used to help build this dependency. Depending on the language, right? Perlin, Python, very easy to say use this library, right, and specify the version. So you get the right version because that's what you want to test. Again, my dev, my QA, and my prod, or prepod or staging and so on have to be identical for this thing to actually work because when I scale for web, I can't have any room for error. So config, this is how I handle separating that data. So for instance, the database that I'm gonna point to, the URI, is gonna be different in dev than QA and prod. I may actually have my own little database that I've installed and that I'm working with. And then a QA may have theirs and in prod it actually may be shared. But I can read that information from this config file at startup time. So startup time, we're gonna come back to that. So think about how you break out. Whenever I say, well, I need to hard code something in, no, put in a config file and then I have a dev config file, a QA config file, a prod config, whatever environments I need, right? I may have 12 developers and each developer can have their own config file and keep that under some sort of revision control. The other thing that I think here is when you think about logging, if I'm doing dev, I'm probably want a lot of logs and may want to actually go to console, right? When I go to QA, I may want to have less logging and when I go to prod, I may want to have the minimal amount of logging until I run into a problem, then I want to kick it up. So imagine setting a variable called log level that I could change in the config file. So again, change in the config file, all of a sudden the app can read it, get it and understand what's going on. So separate your data or your configuration information from the code base, which is important when you do that deployment. Backing service, we talked a little bit about this. The idea is treated as an attached resource. Imagine it's right there right next to you. It may be on a different server. It may actually be in a different network. It may be in a secure network because maybe that database has some sort of confidential information that security requires to be in its own zone, right? So think about how you're going to be able to get to it and in the config files where it's defined where it is, but you want to store stuff out there or be able to reach those backing services separately. Build, release, run. So this is where it gets into the Garrett Jenkins for just two tools that can be part of CI CD. You want to strictly separate the build and run stages. So I'm going to have a way, right? For anybody old enough to know what I make files were, which were replaced or they didn't last very long. It was an MIT X Windows thing, but be able to build that piece of software. And so maybe that's making sure that it has the right libraries, right? All those dependencies are met. If the code needs to be compiled, compiling the code, put it in some sort of thing that can be released then and that release is what's installed in the environment and then be able to run it. So think about it, right? As a developer, I want to be able to develop something that is a nice tightly deliverable object thing that I can give the ops. Ops then can put it in that environment and run it. And ideally, I will never hear from ops again, right? They're not going to call me in the middle of the night because, well, you're using Perl 3.6 and we have Perl 4.5 installed here and that was deprecated and so on and so forth because you've defined those dependencies. You've made it a well-defined solution. So the processes that are out there running, you want them to be stateless. So what you're trying to do here is to make sure that stuff is stored in a backing store somewhere, right? So I can have input, output, and it does some work but there's nothing in there so as I scale out and I add more resources or more components at that level, I'm able to do what I need to do, okay? So again, you need to think about, I don't want to have state that I need to pass along. Portbinding is interesting. It's, people are back and forth on how important this is. So if you think I have a web app, right, so I have some sort of web server, I'm already gonna get port 443 because remember we're doing everything secure, maybe 8443 depending on my environment so I'm gonna have that encrypted traffic but that can just redirect to my app that's listening on another port. What that allows me to do is when I go to debug, I can say, well, you know, I'm coming through the web server and my app's not behaving properly. What happens if I go to the app directly, right? So I go, the app's running on port 5000 so what if I go to that port directly and interface it with that way, right? There may also be a need during an admin process, right, or a cleanup process that you want to talk directly to the app and bypass what other tooling you have in there and that's okay and by exposing it and having that app listening on a port will allow that to happen. So concurrency, right, scaling out. We need to make sure that this thing scales out and you've noticed that there are just a couple of themes, we just have 12 ways to differently talk about those. So I want to be able to handle all sorts of crazy traffic when I do this. So if you think about that one idea that I had, in my app, I thought about it actually this morning I was trying to think, I need to have an app I can talk about and I thought about all the flooding that had been happening in Texas and I said, well, there are probably a lot of potholes from the flooding. So what if I was driving along and I had an app on my phone and on that app I clicked a button and it opened up and I maybe have a login, maybe I want to be a good Samaritan and I want to pat on the back from a Department of Transportation for letting them know about this or maybe not. But I want to be able to talk to my phone to be able to get the GPS coordinates because I want to be able to put those coordinates in or maybe I want to type in the coordinates. So I'm going to gather some information and that's going to be sent to an app somewhere or a service somewhere on the web and that's going to listen. So when it comes in, in my mind, and again, this was in the shower this morning so the design's a little shaky still, I would say, well, if I see what looks like GPS coordinates, which are well-defined so I can just do a pattern match, then I want to take that and send it to a database to convert that to an address. It's a service that's out there, maybe I need to write that service and so that'd be another component. So as people are sending this, I may need to scale out how many ways I'm looking this up depending on how fast it's responding. So being able to scale up is very important here. If I get an address, address may be good enough, but I want to verify that address against a database to make sure that they didn't type it in wrong and to add a zip code if they didn't put a zip code. So that would be the second component that would be part of it. The next component would be to figure out which agency is responsible for that road. So I need to look up that road against the database to figure out or some sort of service that may be a web service provided by the county that says, oh, that's in downtown Austin. So that goes to the downtown Austin Department of Transportation. So now I have that information. Now how do I take that and write that into a form that I can send to DOT on my behalf to open up a ticket that says, look, there's a pothole, get out there and fix it. So again, I've broken it into as many little small pieces that I can think of and look for services out there that I may need to write or that I can consume, but I need to make sure that those scale up because right after heavy rain, I'm gonna need a lot of these services to handle all those requests. A month later, the road should be fixed and no one's doing it, right? So again, there is a different scale depending on time, depending on an event. So I need to make sure my app can handle that by scaling up and down appropriately. Disposability. So remember I said I had come back to the config files and the startup. It's very important. These apps need to be startup as quickly as possible. Subsecond, ideal. In reality, maybe a second or two. I want these things to start up very fast because I'm under load and I need to respond to that load. Likewise, I want them to be able to shut down nicely. So an old timer land, I send it a sigterm. It says, oh, I got that. I have a queue of requests coming in. So I'm gonna turn off the queue. I'm not gonna take any new requests, process what's in here, gracefully shut down. So you need to think about how you handle the startup and the tear down well. The one that's hard is how do I handle a crash? But remember if this thing is stateless, then that makes it a little bit easier because I don't have to worry about that. So the best I can do so that I'm not having anything in there that I need to remember over time, let's get ran out to the store, make it so that when I restart, I don't have to go through a cleanup process. So you need to think about how I handle the crash, which is a little bit harder, but that performance and breaking out the config so I can get that sub-second start is something that's important that you should be considering and thinking about. Dev and prod should be the same, right? And this is where it gets into that continuous integration and those different config files. So we've talked about this before. The idea is my developer, he writes the code, make sure that it's all bundled together, right? So he's gonna build it, he makes a release, pops, then it's gonna release it to where it needs to go and they can then run. Making sure those environments are the same as important so that goes back to being dependencies and being declarative. This is what I want. Assume nothing, very important, okay? Now almost, I think I'm gonna be in a hostile environment. You know, I am a UNIX guy from day one. I've never run Windows or done Windows development. I do run OSX, which is UNIX under the hood, but I just think I'm going into a dot net world and they're not gonna like me or understand what I'm doing, so I'm gonna make it as declarative and explain everything step by step so that a person could push a button and get a release that they drop in place and it works, okay? So again, use that mentality when you're doing your development. Good development anyway, but again, because of the scalability, right? Because of being able to start up very quickly are all important things that you need to keep in mind. So we talked a little bit about logs. Remember, maybe you want to go to a console, maybe you want to go to a file, maybe you have a centralized logging location. So my app is only gonna write an event stream. It's just gonna stream out some way. And then based on configuration data, which is separate, I can say, oh, well, in this case, I wanted to go to a console, right, dev console, or I wanted to go to, you know, slash var slash log slash my app dot log, right? And then over a period of time, doing log rotations through another system. Or maybe I'm using Splunk, or I'm doing some sort of log stash, or HECA, or some other sort of tooling that I'm using for that. Let's figure out that, but that's handled through the configuration. It's not the app. The app just writes the logs. He may check and see what the log level is that's set in the config file, but he's just gonna write the logs out to a stream, whatever level that should be. And then finally, admin process, it's number 12. Your admin tools ship with the product, okay? Because, remember we talked about being declarative, having those dependencies? Well, if I'm not running and testing my admin tools, when I'm testing my code, maybe something changed. Maybe I deprecated something, right? So I need to include those tools when I ship. It may be a feature that's built into the app, right? But it's only accessible if a certain flag is set. Maybe it's a separate app or a separate tool that is available via the command line. But for instance, we talked about the backing store, never, ever, ever, ever, ever, ever go to that database and start mucking with the database. Use your tooling that you built with the app to be able to go and to check the database and do database cleanup and to do that maintenance, right? If you wanna do log maintenance or maybe you have some, you're writing some sort of binary string or some sort of interesting information that I need to be able to decode. I should have an app that ships, I'm sorry, a tool that ships with my app that can do that, okay? So make sure that if I'm an admin, that doesn't mean I just log in as root with all privileges and do what I want. I have to use the tools that ship with it that should have the same privileges that everybody else is using. So don't make it a special case, okay? So with that, we have run through what the 12 apps are. We've talked about the one idea and two modes of IT, the three parts, the four words and the five principles and then the 12 apps. There any questions so far about this? It's a quiet crowd. Yes, right here, thank you. Thanks for the presentation. So see this 12 factor is basically for cloud native applications, right? Yes. This can be applicable for when we write new applications, like we can consider all these 12 factors. What about the applications that are returned like 10 years before or 15 years before but still running in the on-premise data centers? How do, what is your point of view in addressing? So is refactoring is the only solution or do you have any other ideas on how we can make the legacy applications to be 12 factor complaints? Great question. So I know there's a second person so if you wanna come up to get in line, that would be awesome. So what I heard is I get it, I understand these 12 factors, but I got legacy apps and I wanna move them and run them in the cloud. Is that correct? So my Greg's answer, I wouldn't run them in the cloud, okay? You're gonna open yourself up to a world of hurt if what I wanna do is just take my legacy app and move it to the cloud. There's no value in that. You can do it, it will work, right? That's where you have that pet, right? So it's that special thing that's out there running I need to care and feed but I'm not getting that scalability that I want, right? I'm not getting a lot of the things, the flexibility that I want with my cloud app. Now, the easy thing to do is say, well just rewrite it from scratch, right? Refactor it and figure out the question become. So if I have a customer who came to me and they said, we're really interested in cloud. I said, okay, tell me what you plan on doing. Well, I wanna run SAP in the cloud, on-prem. Why do you wanna do that? Well, you know, it's an app that we use and I was thinking maybe that would be a good first step. And I said, so did the CIO fly over to Europe recently or on a very long plane ride where there was a magazine that said, you need a cloud in your organization? He said, well, there is an MBO tied to that. I said, well, there you go. It's not a good idea. You need to find the right use case for it. So you need to think about your business and what new apps. So ideally, it's Brownfield. The other thing that people will ask me is, well, can I replace VMware? You can. I wouldn't recommend it. That's not what it's here for. It's here to change the way that you think and to be able to deliver software faster. If you're delivering software faster and you need to be, you know, someone is saying to me and I will say it, the uberization of technology, right? Will you be uberized or will you be uber? And I don't like those words, but really, that's what becomes, are you going to be a disruptive force or will you be disrupted? So really, I wouldn't do it. I would take a look and figure out, is there a different way to solve the problem? And if so, I would build a 12-factor app to solve that problem, okay? You're most welcome. Next. Could you just give a practical example for number six? I didn't quite sync it. Oh, do you remember what number six was? The processes. So let me, you know what? Let me go back here. Yep. So when I think about it, right, I am going to pass, for instance, let's take the address, right? So I want to do an address lookup. So I'm going to have a process where I'm going to pass it an address and then it's going to pass an address back to me, okay? So when I pass that address, right, 123 Main Street, Anytown USA 12345-6789, I need to validate it. So I'm going to go out and I'm going to validate and then it's going to send back a correct address and that correct address could be the same or not. So there's no state inside that process, right? That process is going to talk to another service and then it's going to return something back. So it's not remembering something so that when someone else comes and hits it, that it has to say, oh yeah, this was Bob who just asked me about something else a moment ago. Does that help? It scales up faster because I don't have to be sticky, which means anybody who comes in can grab anyone off the shelf and he can do the job. He or she can do the job and return the answer. Thanks. Thank you for asking because obviously I wasn't clear enough and I'm going to update that example in here to talk about that. Yes, another question over here. So since this is an infra conference and a lot of the folks are infra people, right? As opposed to app developers. Does the 12 factor thing take into account anticipating running on two different clouds or data center regions for region level redundancy, right? Because you shouldn't be assuming that this is this ever available cloud, right? It is, it goes down for upgrades. So should app developers be thinking about multi? So if they followed those 12 things, right? So I have a URI that I need to go to. So by putting it behind a load balancer or putting it behind some server that's going to a VIP or something so they can have it in multiple locations, solves that problem. I know from my configuration when I go to my backing store, it's going to be HA1.myservice.com, whatever, right? And then how that gets handled across multi-cloud and the rest is outside the web app. The web app doesn't worry about that. My 12 factor app doesn't worry about that. My infrastructure handles how I'm going to scale across the cloud, multiple clouds. Does that help or it sounds like it looks like you're not okay with that? I think that's, I mean, it seems like there needs to be a little bit more of a collaboration between app and infra for that because if you have a VIP and you just assume that the infra will sort of take care of that across different data centers. I mean, maybe it's in the app, right? So I'm thinking easy way to do it. My app could be cloud aware, right? And with zones and the rest and there are probably some other things you could do down at that level. Not completely, but at least with the notion of having two regions, two sites at a minimum that abstraction. I don't know. No, that's a good point. I need to think a little bit about that. So it appears that I don't know if we're out of time now or not, but people are getting up. So I want to thank everybody who came. I am absolutely happy to stay and answer questions because I don't know. Keith, do you know what time we end? It's over? All right, everybody out. Anybody wants to come, ask questions, please. Come up and ask questions. I want to thank everybody for your time today.