 Everybody doing all right? So far, so good? All right, there's been a picture taken, hold on. All right, there you go. OK, cool. All right, so welcome. Welcome to this talk. I'm glad you all are here and took some time out of your busy schedule to talk a little bit about building Cloudy Apps. So the way I like to get started is by figuring out how the clicker works. All right, I'm going old school. The way I like to get started, whiteboards are good. All right, hold on, let me bring her back to life. There we go. Thank you, thank you. The way I like to get started is at the end, all right? This presentation, I know you all have been going through presentation after presentation. It's after lunch, so we're probably in a food coma. Many of you probably enjoyed the parties last night. And one more presentation is probably just a little bit too much to ask. So I'm going to do this, I'm going to do your favor. I'm going to start at the end of my presentation and give you all my highlights. And then anybody who wants to stick around can stick around for the rest of it, all right? How's that sound? All right, so when building Cloudy Apps, two things you need to keep in mind. One, you need to enable scaling. All right, so in your application, you need to build it so it can scale. Number two, you have to expect failure. Hope you guys enjoyed the talk. Thank you for coming. All right, but those want to stick around and chat a little bit more. Couple things I like to do, but before I get into the deep content, I want to make sure I understand my audience. So I need a little bit of audience participation. Don't be shy. Just raise your hand. I just want to understand who's in the room. How many of you are here at the OpenStack Summit for the first time? Show of hands. OK, all right, very nice. Next question. How many of you have ever attended a Rack Space training for OpenStack? Oh, nice. I've got a few of you. Did I teach any of those classes? I apologize that you have to go through this again, my friends. Good to see you guys, all right? All right, good to see y'all. OK, how many of you know which track this talk is listed in? That's sweet. Tony's Track. Which track is it? What is it? Somebody said it. The Getting Started Track. This is the Getting Started Track. And since most of y'all didn't know that, you're in the right place, all right? This is the Getting Started Track. OK? How many of you are just getting started with OpenStack? How many just getting started? Cool? All right, welcome. All right, let's see. How many of you are developers? Sweet. How many of you are operators? Sweet. How many of you are both? Dev Ops in the house, all right? How many of you are neither? No Dev, no Ops. All right, a couple of y'all here. Cool, right on. Welcome, welcome. How many of you consider yourself to be technical? Cool, OK. And how many of you have access to a working OpenStack cluster? Cool. How do you define working? OK. How many of you know what OpenStack is? This is a serious question, serious question. Cool. Not everybody rolls their hands, OK? We will help there, too. OK. How many of you know which projects make up OpenStack? OK. How many of you have ever written a production application for the cloud? Cool, you all can help me with this talk, all right? OK. Last question. How many of you remember the end of my talk? All right, what were the two points? My job is done. All right, nice. All right, but if y'all want to hang out with me now that I know a little bit about you, allow me to share a little bit about myself. My name is Tony Campbell. I'm director of training and certification at Rackspace. If you want to know more information about training at Rackspace, you can hit that URL, training.rackspace.com. Like just about every other company here, we're also hiring. You can take a look at that at rackertalent.com. If you want to follow me around, you can do so on Twitter. I'm at Cloud Train Me. Or you can find me on LinkedIn at Tony Campbell. I'll pop that back up a little bit later. But a couple of other interesting things about myself. So I was a broadcast communications, English, and theater major. So it totally makes sense that I'm at a technology conference, right? OK, no doubt. So that's what I studied in school. But while in school, I landed a job at Sun Microsystems. And working at Sun, god rest their soul, working at Sun really taught me a lot about technology. And that's kind of where I got into the technology scene. Then I landed a job at a, get this, it was an office supply company. Who knew they had high tech at an office supply company? But at this office supply company, they did one of the first e-commerce systems. Back in 1997, we had an online internet ordering system that we named I-97. So yeah, we made the letter I popular before Apple did. So it was I-97, some of you got that. Some of you will get it on the way home. OK, so we made this app called I-97. And then I went on to work for Atachi Data Systems, right in Santa Clara, California. Any California residents here? Good to see y'all, good to see y'all. Now I'm in Texas, but I do miss Cali, all right? We also work for an e-benefit startup in the Baltimore, Washington DC area. Any Maryland folks? Cool, in the back. Good to see you, all right? And then I ended up at Rackspace, OK? So I moved on down to Texas. And it's amazing, sorry, this isn't in my speech. It is amazing how, like, Texas seeps into you, because I found myself saying y'all. It's a real word out there. I kid you not. Any Texans in the house? Y'all know what I'm talking about. All y'all with me, OK? So if I say y'all in my speech, I really did, I was really born in California. No kidding. All right, so I've been at Rackspace the last 10 years. While I was there for the last 10 years, I started off in web development. I took care of Rackspace.com. That's when we had less than 150 employees. So I did web development there. Then I moved on to software development, where I worked on the My Rackspace customer portal team. Some of my former team members are here. Good to see y'all. All right, but that's when we got into software development. And they know the pain that I'm going to be talking about in this talk. And feel free to cry with me when we go through how we used to do things before the cloud, OK? So we did software development at My Rackspace. And then I was a part of the original Rackspace cloud team, AKA Mosos. Any Mosoites in here? Any? No, just me. All right, so I actually worked with Jonathan Bryce. And Todd Morey, on a product called Moso, when we launched the original Rackspace cloud. And now I work with the Rackspace private cloud team. And I basically do OpenStack training for Rackspace private cloud and around OpenStack. But the sum here is, for me, life is about software development. That's what I love. That's what I like to get up in the morning and do. I like to get up and do software development. Anybody with me? Anybody looking at me like, oh, man. We're a special breed. But if you do it, you know what I'm talking about. So I love software development. So if I had to explain to you where my happy place is, you can imagine that my happy spot is not necessarily on this end of the room. I'm a little bit happier over here. Anybody with me? All right, I'm a little bit happier here doing software. I've got to make sure my slide's in the right place. I'm a little bit happier here doing software development. This is what fills my bucket. This is what makes me happy. But software development before the cloud was quite interesting. I don't know about your world, but our world looked a little bit like this. We wrote applications that our users were able to access and use. So we write this application, user hops online, and they get to use it. That is one of the most gratifying things when people actually get to use our code. Because sometimes as software developers, we write a lot of code that never sees the light of day. Maybe it's just me. But every once in a while, you get some code out, somebody actually gets to use it. So as we began to write these applications, we got a little more sophisticated. At first, we would write these applications, and we put them in this big monolithic app. So we write all of our code and just kind of slam it together. It was spaghetti code, if you will. Probably this is just me. You guys are looking at me like I never wrote code like that. I would make spaghetti code. And then I learned, and I grew up as a developer, and I learned to start slicing it up. So now we got tiers. You may have a presentation tier. Where all my UI logic is at. Then I could have a service tier. And then I might have a data access tier. So I got this app. I start to tier it whichever way you want to slice your app. So far, so good? All right. Just so you guys don't fall asleep, I'm going to ask a quick question. Every once in a while, I'm just going to ask you get it. If you guys get what I'm talking about, just say got it. But if you don't get it, just look at me strange, and I'll try to drive it home. Everybody get it? Good. All right. So we got these three tiers across our application. And of course, every application needs a database, right? So we would take these tiers. We would take our database. And if you're anything like me, we would take that and slam it on one box. This is genius, right? So famous last words from any developer when they get done writing some code, and they hand it over to the QA department. And the QA department finds a bug in the code. The developer always looks at the QA engineer and says, work for my box. I got some developers in there, awesome, all right? So that's what we would do. We would write this code. We'd slam it on a box. If it worked on our box, push it to production. We're good to go, all right? Nathan Anderson is not in the room, is he? All right. Nathan, somebody used to work with a Rackspace. We used to actually make code changes in production on the production server. But that was a long time ago, right, before we had the cloud, right? But this is what we would do. We soon, I'm going to get in trouble for that later, we soon found out that this was dangerous, right? If all my code, my database, all my code is running on the same box, what happens when that box decides to take a nosedive? Bye-bye application, right? So we got a little bit smarter. Say, hey, look, here's what we're going to do. We're going to take the database. We're going to pull it off. We're going to put the database on its own box and the application on a whole different box. So now I got two different boxes. I'm good to go, right? North and South, you guys are smarter than that East to West, right? No good, right? What happens if I lose either of those boxes? My application is gone, all right? You guys remember where my happy place is? Software development. What am I talking about right now? Hardware, right? I'm not happy right now, but this is stuff I have to do to get my application into the hands of the user, right? So here's what we did. We said, OK, we're going to introduce this load balancer, all right? I'm going to fill up this load balancer and I'm going to have two application servers sitting behind the load balancer. So users are going to come into the load balancer and where does the load balancer do? Man, I can't get nothing past y'all, man. The load balancer balances the load, right? So a user comes in and I take one user and I send the user over here to this awesome cluster of nodes. Then I send some users over here to this awesome cluster of nodes and I just carefully balance the load between those nodes. Everything is harmonious. We're all living in peace, right? There's one database server supporting them all. Everything's good, right? Anybody from South Africa? Anyone? Aish. Here we go, right? What is going on here? All right? So we lose this database server and then I'm still in trouble. So what did we end up doing? We have this replicated database now, all right? So now I got a load balancer, two application servers, a database server, and I'm replicating that database to another server just in case something falls over. Now I'm good. My app is humming. People like it. Then the cost of success. More users. We used to have this joke at Rackspace. When you win the pie eating contest, you know what your prize is? More pie, all right? So with success we got more users. That was more stress to our system. So what did we do? We work at Rackspace. We threw hardware at it, all right? So we got more physical machines that we thought our application. We even took some machines and just sent them off to the side just in case something went wrong. And then I still got my database server and my replication. Data, data, data, and then all this hardware. And then of course we got to get firewalls and load balancers that are redundant, right? They got to have fell over between those puppies. Physical machines, database servers. Where's my happy place? Where is it? What are we talking about here? Hardware, right? I love hardware for you hardware geeks. I love you guys. If I didn't have you in the world, I'd have to deal with it, right? But in this world I'm dealing with this hardware. Then it even got funnier because our company came to us and said you got this great infrastructure running in a data center. But what if something goes wrong in that data center? Then what are you gonna do? So guess what we ended up doing? We got the same setup in data center one. We duplicated the exact same setup in data center two. And then we replicated the databases between the two. Just in case something went bad in data center one, we could quickly fail over to data center two. Now I know you all are a lot more sophisticated than us, but I will confess and tell you what happened. When we had failure scenarios, it was quite a manual process. Okay, some of my old teammates here don't lie. Are you still on the Web 911 mailing list? You are blessed. We had a Web 911 mailing list. So when that server went down, guess what happened? My phone would wake me up at two in the morning to deal with software in my happy place? No, to deal with hardware, right? So I'd get up in the middle of the night and have to fix a box. Actually, I didn't fix it. I watched somebody else as they would fix it, right? But if I lost two, we were really in trouble, right? If we went ahead and lost the database, we had to fell over to the replicated database. This was the old world that we were living in. This was our pain. Has anyone seen this movie? Anyone? All right, then came the cloud. All right, so my friends who are new to OpenStack, I'm gonna give you a quick overview of OpenStack in 60 seconds, just so you're caught up, okay? Remember my happy place? Here's OpenStack, everybody seen this before? All right, I want you to see this diagram with new eyes. See this diagram with the eyes that I see it with. You can see this diagram on opensack.org. There's a couple of things I wanna point out to you. At the top of this diagram, it says your application. That's software, makes me smile. Gets even better, APIs, right? Software, at the top of this OpenStack stack, you see software. This is my application. This is what we write and we're using APIs. And to a developer, that's a beautiful thing. It's the application programming interface. It is the language of love, if you will, right? This is how we communicate with our systems. If I can talk to something through an API, I'm very, very happy, right? I already feel peaceful just talking about it. And the bottom of the stack, notice what it says, standard hardware. All right, so what does OpenStack do for me? I've got hardware, I've got software, and I got this beautiful cloud in the middle that allows me to treat that hardware as if it was software. Man, that's the best thing since Kool-Aid, all right? I mean, that is a beautiful thing. I'm able to treat this hardware, the stuff that kept me up in the middle of the night. I'm able to treat it as software now. All right, so that allows me, you guys notice my disclaimer, I reserve the right to take more than 60 seconds. I may already be over. All right, so quick review for those who are new to OpenStack in the room. This is a community. We learn as a community. So the community is gonna teach you about OpenStack in 60 seconds. Here we go. All right, everybody ready? We're gonna crack the code and all the code names. What is Nova? What is it? Compute, nice. What is Swift? What kind of storage? Ah, good. And somebody else said something about... Oh, that was my guy. I shouldn't have known that was you talking, all right. Getting all detailed on me, all right. Glance. All right, image. Keystone. Identity, good. Horizon. Cinder. Block storage and Nova volumes powered by it, yep. Quantum. So those of you new to OpenStack, you know all the lingo now, all right? It's not quite that easy but that gives you a quick rundown of what we're dealing with. Compute, object storage, images, identity, dashboard, block storage and then networking. Oh, and I shouldn't use Quantum anymore. We can't use that anymore. Do you guys hear that? Yeah, sorry, sorry, my bad. We don't use Quantum, it's networking. That's not there, I'll fix that slide. All right, so here's what we're here for. How do we make an app cloudy? How do we make it cloudy? How many of you are here for the end of my speech? Who is here for the end of my speech? All right, all right, cool, awesome. How do we make an application cloudy? Enable scaling, expect failure. Enable scaling, expect failure. I'm a simple guy. I don't know if you guys came for something more complex than this but I'm a simple guy, all right? Enable scaling, expect failure. When I write applications, there's two things that keep me up at night. Anytime I write a piece of software, two questions keep me up at night. First one is this. How is my application gonna handle success? What happens when I end up on TechCrunch? I get slash dotted. Oh, this happens at Rackspace all the time. What happens when I end up on Oprah, right? I kid you not. People end up on Oprah, child visits is back there. They end up on Oprah and they call us and say I'm gonna be on Oprah. I need to up my infrastructure, right? Because they're worried about the hit they're gonna get when Oprah comes on. So how is my application gonna handle success? This keeps me up at night. Second thing that keeps me up at night? How's my application gonna handle failure? What is my application gonna do when something goes wrong? When a hard drive fails, when a process stops, when I run out of memory, how is my application gonna react? The benefits to cloud are twofold. Cloud can provide options for scaling your application. So when success comes my way, cloud gives me the capability to scale it. Cloud also gives me an option for handling failure elegantly. But beware, just because you take your application, slapping on the cloud, does not make it scale nor fault tolerant. Is that a surprise to anyone here in this room? Just checking. All right, good deal. All right, so what I have to do is I have to take my application and I have to cloud enable it. Have to cloud enable my application. How do I do that? Cloud you asked. I'm gonna give you a couple of tips on how to create an app and make it cloudy. First thing is this. In the cloud, we use horizontal scaling. You can scale vertically too, but we tend to use horizontal scaling. Don't buy a bigger box, just get more boxes. All right, so here's how we used to do it in our application. When our app was humming along and the box started to heat up and turn red and give us trouble, what did we do? We bought a bigger box. And then when that one got to be pressed out, bought a biggest box, right? And then when we really had a successful app, we bought this super big honking box, right? The thing about it is during lunchtime pre-lunch, the application we worked on at Rackspace, it was under load between 11 and like two in the afternoon. I don't know what it is about that time, but a lot of people were hitting our application. But guess what happened at seven o'clock at night? Those loads started to fall off. So did my box go back down to small? I still had that honking box with excess capacity. This is the cloud story, right my friends? What do we do in the cloud? We scale horizontally. So when I have a box like this that's being pressed and it doesn't have enough resources, do I buy a bigger box? I get more boxes and more boxes and more boxes. So we scale horizontally. This is an important fact, everybody get it? Good, anybody not get it, don't be shy. We are a community. Wait, everybody close your eyes, close your eyes please. Close your eyes, come on, do it, do it, do it, do it. Close your eyes, anybody not get the horizontal vertical scale thing. I'm the only one watching. All right, okay, right on. All right, so once we get our app to a point where we're able to scale horizontally, it opens a lot of opportunities for us. So how do I make my app horizontally scalable? Here's a couple of suggestions I would give you. First thing is to componentize your app. Break your app up into components. When I first started writing software, I threw everything into one big application and there's just one big honking coupled app that ran on this box. But I grew up and learned a little bit more about components. So there's many ways you can slice your application, okay? There's a lot of different ways you can break it up into components. I'm gonna give you a couple of ideas, but it's really up to you to decide how that workload best gets split up. First one is you could break it up by roles, right? I could take a web tier and I could have this web node that was responsible for serving web requests, all right? And I might run on that web node. What might I be running on that node? Apache? What else? Speak up, can't hear you? Nginx? All right, what else? Tomcat? Sorry, I didn't mean to laugh at you. Yes, Tomcat. I'm a Java developer learning Python, I admit it, all right? So that's why he said Tomcat, he's messing with me. All right, yes, I would run Tomcat in that box and I run Groovy and Grails too, so now. All right, anyway, sorry. So you're gonna run all your web-based stuff on that box, right? It's gonna service your web requests. And then the next one you might break up to is what I call a service node, okay? This service node is where you might put your business logic. All your worker processes might break out into this different node. And then you may have a data node. It could be serving a database, NoSQL, relational, or maybe it's serving some other form of persistent storage, okay? But this is just one way you might be able to break your nodes up. There's a ton of different ways and I might go so far as to take that service node and break it up even further. So I might take that service node instead of having all my services run together on one box. I might take it and break it up where I have a registration service for my application. Where people come and register. I might put that on its own node. I might take the billing node. I might take an admin node. And I might split these nodes up. How you split them up is totally up to you. The granularity you use is up to you. But the point I want you to see is that the cloud utilizes, I almost call this old technology, old thinking, but it's not. It's just a generation before cloud. It utilizes service oriented architecture. We've heard about this for years, right? It's the same sort of idea. The takeaway is how you componentize your application will determine how you can scale your application. All right? So if each of these are broken out into different nodes, I'm able to scale them individually. Get it? Good. All right. Second thing I tell you to do is as much as you can, make those components loosely coupled and autonomous. Make them where they're on a need to know basis. They don't have to know a whole lot about each other, but they're able to operate independently. Here's how we used to build applications. For those of you who are just catching up, lines in this diagram are not good. All right? All right, we used to have these applications where everybody had to know about everybody, right? Everybody was in the Kool-Aid. They had to know what was happening. What are you doing over here? How are you working over here? This is how we used to kind of look at applications, right? You really want to take a picture of that? Oh, okay, I'll let you. All right, okay, good deal. Now what we do is we want to try to make those loosely coupled and autonomous. One way we might pull that off is by leveraging a queuing system, okay? So we take this queuing system and we put it in between all of our nodes and everybody talks to the queue and the queue manages all the interaction between the different nodes. Doesn't even sound so much more peaceful, right? Everybody communicates through the queue, right? Now, there's challenges with the queue too. It's not nirvana, right? So I can solve everything, right? But this allows me to basically draw less lines, all right? Okay? So all the communication here is done through the queue. What this means is if for some reason when that web service node needs to get a message to the registration node, if the registration node is taking a nap, if it fell off a cliff, if it's not listening, my web service node, my web node can still operate because it's just dropping the messages on the queue. When this registration node wakes back up, it'll pull those messages off the queue and do the work, okay? This allows me to scale those two independently. Get it? Good, all right. Next thing, stateless nodes. Not necessarily a stateless application, all right? Stateless nodes. Here's what I want to do with a stateless node. When I have a node here, like I used to do back in the day, I would use a model view controller, for example, and I might have a services tier in a database. I got this all running on a machine and then I have some state data, right? Think of it this way, if I have a shopping cart, when somebody purchases something and drops it in the shopping cart, I need to save that state somewhere, all right? Back in the day, when we were doing old school software development, I just saved that state right on the box, right next to my application, all right? My application's there, my database's there, my state, yeah, why not? Throw it there too, right? That's all good until that box does what? When that box goes away, and boxes never go away in the cloud, right? All right, you see where I'm going. When that box goes away, I lose my state, right? So I can't play that game anymore. So now I can take a node where I bust out my presentation logic, my application logic, my data services, my database, where am I gonna put my state? I'm gonna put it down here in the database because this doesn't go away if it does, so does my job, all right? This is gonna be persistent, right? So I'm gonna put that state there and then up in the controller, I might use some sort of a pointer, maybe in a cookie or something to point back to the main ID from my state down here, all right? The idea is you wanna try to keep your web nodes and your service nodes as stateless as possible. Try not to store state on those nodes because they will, they'll fail, they'll go away, they'll disappear, they'll break, they'll fall over because we build this stuff on standard hardware, commodity hardware. Everybody get it? Good, you guys are awesome, all right? Persistent storage, all right? If everything's gonna go away, something's gotta stay the same, right? You can't tell me that everything's gonna disappear. Something has to stay and be persistent, all right? This is where persistent storage can help us and there's a ton of options out there for persistent storage. A lot of cool things that we're doing in OpenStack and then a lot of the other ecosystem communities as well. So how many of you write applications that use relational databases? How many are using no-SQL databases? How many are using both? Who is not using a relational database at all? One! You're awesome, dude. I wanna be your friend, man. That is awesome. All right, so relational databases in the cloud, okay? So say I got MySQL and I wanna run MySQL in the cloud. What do I do? Say what? That is an awesome answer to a master, master replication in the cloud. So if you guys haven't looked at Galera, take a look at it, it's an awesome way to go about doing this. Another thing you might do is a lot of the public cloud vendors have Database as a Service and we're working on Database as a Service in our community as well. Code name, that one is Red Dwarf. I almost said Atlas, that's a little bouncer one. That's Red Dwarf, all right? So we're working through a couple of Database as a Service options. The nice thing is with the Database as a Service I can just throw my data at it and the replication and the protection is built into the system. When we get there, it'll be awesome. There's also other options that you can use out there but try to leverage a platform provider if you can on that. Otherwise, Galera, build it up yourself, master, master replication, master slay, whatever you need to do, make sure there's just not one copy because that box can do what? You guys are getting it, all right? No SQL Databases. No SQL Databases were born in the cloud, right? So they're built for the cloud, right? So they just work up the box. That's a joke, nobody laughed. Okay, so there's a ton of no SQL Databases out there that we can use. You got Cassandra, you got Couch, you got Mongo, all sorts of options out there. We got Block Storage in Cinder. We call it Cinder here in OpenStack. You can use block storage, persistent block storage. Remember those Nova Volumes though? They're like a USB key. You plug them into one virtual machine. That virtual machine gets to use it. Then you gotta plug it out and plug into another one, right? Unless you're using some sort of shared back end and some crazy cluster and all sorts of stuff you can do, right? But general, that's how we're working. Object Storage. Object Storage, how many of y'all use Object Storage? Sweet. I'm a little biased here, but because we teach Swift all the time and some of you've been through my class, I literally light up when I teach Swift. It is the most elegant application I have seen in a long time. I'm not saying it's perfect, but the guys who thought that thing out are pretty awesome, all right? So, we got Swift and then there's caching. You can use caches in order to speed this stuff up. You can run a caching tier so everybody doesn't have to hit the persistent storage all the time, okay? Everybody get it? Good. I'm looking at my clock, man. Time flies when you're having fun. I'm having fun. I don't know if you guys are having fun. All right, okay, kinda. All right, you guys can fake it for me. Just smile. I was like, yeah, that's crazy. All right, images. The key to being cloud-ready or scale-ready is your images, right? So, if I have a box that's running a web server and users are hitting that web server and all of a sudden I need more web servers because Oprah just announced my new application, right? And I gotta pop up more web servers. I'm gonna have to go to what OpenStack system in order to get an image? Glance. I'm gonna go to Glance and then when I run the Nova Boot command, if I'm doing this from the command line or the API, I'm gonna have to point it to the image that I wanna use and if I'm using Q-Cal 2, what's it gonna do? Stream that image down to the host? Some of you guys are looking at me like, man, you gotta come to our class, training.rackspace.com. Come check out our class. All right, I'm gonna stream that image down to the compute host and then use that image to spin up the virtual machine, right? What happens if I need to quickly spin up brand new nodes? If I have an image that's pre-baked, I'm able to quickly spin up those additional nodes. So as I need more web nodes, I just go to Glance, pull an image, pop up a new virtual machine, off and running. In the old school days, I kid you not, we work at Rackspace. We have a ton of servers. I still have to get on the phone. I have to call somebody, say I need a server. They have to run out to the data center, pick up all the hardware, rack all the hardware, plug in all my memory, put it in a rack, wire it all up, make sure everything worked correctly, and then bring it back to me in a couple of days. Not so in the cloud world. Now I just go out, I grab my image, I create my virtual machine, I pop it up and up and running. That is pretty sexy if you ask me. Okay, it's just me. All right, okay, a couple of things. Once you have all this stuff in place, once I'm prepared for horizontal scaling, once I componentize my application, once I try to make it as stateless as possible, once I get my persistent storage figured out, that allows me to do some really cool, smart scaling. In essence, my application becomes alive. It becomes infrastructure aware. It knows about the infrastructure that it's running on. So I can do some interesting things, such as auto scaling, okay? Any right scale peeps in the house? Right scale in the house? Any right scale users? All right, love right scale for this stuff, right? So if you don't wanna build this stuff on your own, take a look at right scale. But I'm gonna give you a high level of sort of things that we can look at doing. All right, so I've got my cool application over here. It's got a cloud load balancer at the top, a cloud load balancer at the top. If you guys read the Grizzly release notes, you know that we've got, oh, I got, wait, LB representation from RaxFace, I saw you represent. All right, we've got cloud load balancers coming with Quantum. The first edition is out through Grizzly, is that right? And the Grizzly release notes? HAProxy is what it uses, very cool. With a cloud load balancer, I'm able to go to my happy place because I can use an API to throw nodes behind a load balancer or remove nodes from a load balancer, right? So I've got this cloud load balancer sitting across the top, and then there's a bunch of web nodes that I got sitting there, right? Those web nodes are on top of a service node, serious service nodes. What brokers the communication between my web nodes and my service nodes? My queue system, right? So I got my queue system sitting in the middle, and then I got this nice database cluster at the bottom, right? Where I have all my data clustered. And then this monitoring system sitting off to the side. So that monitoring system may be listening to the queue. And the monitoring may be looking at the queue and taking a look at the different queues to see which ones are really busy. So say, for example, it's time to pay all my invoices and I have this billing service and the billing service is listening to the billing queue and there's a whole bunch of billing requests stacking up in the billing queue. And this billing machine, I got one box for example, is just churning, trying to answer all those questions, right? What can I do when this monitoring system realizes that? I can walk over to my API and my API can auto-magically spin up more business or more invoice nodes to pick up off that queue. So I'm able to scale out these nodes independently. Pops another service node in, starts working the queue. All because the monitoring system was able to do it. Not because my dev ops guy had to get up at three o'clock in the morning or my DC ops guy had to get up and rack a new server. It's all done programmatically through the system, right? Then we may be listening to the cloud load balancer. The cloud load balancer is being monitored. We notice that there's a ton more requests coming into the cloud load balancer. Maybe once again we've been on Oprah so a lot more people are hitting this thing. What can I do? It's not a trick question. I add another web server node. It's awesome, right? I start building this stuff in and off I go, all right? Here's another cool one. How about cost scaling? How many are concerned about cost? Who doesn't care about cost? Man, I got a cool project for you, all right? If you don't care, all right? Cost scaling. Back in the day when we did vertical scaling, like I said, we bought the biggest boxes we could. We put our application on those boxes and they withstood the thunderstorm of activity. But then when that storm quieted down, I still had that big old box, right? Even though I was only using this much, right? Sometimes we spend our virtual machines and never spend them down. Here's what we can do now. Oh, nine o'clock in the morning. Add a few nodes because it's getting busier. 11 o'clock, it gets even busier. Oh, what happens around two o'clock? And then things die back down, all right? The ability to actually have my application react to different things in the environment is now available to us through OpenStack and through the cloud. Failure recovery, what happens when I lose that node? I make an API call, I bring up another one. This is awesome. I may have my application even do this while I'm not watching, right? It can do all this auto-magically, right? So that brings me to the beginning or the end. If I'm gonna build a cloud-enabled application, there's a lot of stuff I can do. But for me, it really falls into two buckets. Those buckets are one, enable scaling, man. If I had a prize, I'd give it to you. Two, expect failure. Enable scaling, expect failure. Use all the tools at your disposal. But realize it's a brand new world. We don't have to write software the way we used to write it. We can write it in such a way that it's infrastructure aware allows us to stay in our happy place and makes the world better for developers and operators alike. Preguntas. That's questions in Spanish, all right? Yes. Yeah, and I'm gonna give you the answer to every single question you guys are gonna ask me right now, I'm gonna give you the answer. It depends, all right? What are you using for your bus? Check group CSB? Yeah, I think it depends a lot on the enterprise service bus that you decide to use. In the Java community, we tend to do a lot of bloated things that may not necessarily lend themselves well to the cloud. So I often recommend looking for something that you can integrate with outside of the normal Java community. What we found that we use a lot to, not just on the bus side, is we found Groovy and Grails is a great combination between the two. I said Grails, not Rails. It is Java's jealous brother of Rails. We call it Grails. But that is a great tool that has a lot of functionality that allows you to do a lot of things cloudy and more groovy. Sorry, that wasn't a direct question, but it depends, yeah. I think I got time for a few more I'm getting. I got one more, I'm getting the one more sign. All right. I do wanna fill this slide up. Once again, we're hiring and we're training, all right? So if you need either one of those, reach out to us. Thank you guys, you guys have been a blast. Hope you enjoy the rest of the conference. Take care.