 All right, I think I'm gonna go ahead and get started since running a little late. So, hi everyone, my name's Grant Scofield. If you didn't guess from the big slide, I work at the 10,000 pound grill in the Ruby room right now, Engine Yard. I've worked with Engine Yard since March after moving on as the primary developer of aDrive.com. I'm a support engineer, and that's a little bit different of a role at Engine Yard than most places. Support engineer encompasses not only being able to develop and debug Ruby applications, but also understanding systems infrastructure as well. I am an oaky, I'm from Oklahoma City, and I always kinda look down upon Texas, then I went to a gas station, found some really nice beer at 10 p.m., and found out I could buy it till midnight, and that's a lot better than what we have in Oklahoma City. You can follow me on Twitter, under Scofield. So, I wanna talk a little bit about the cloud in general first, because I think that the cloud is taking on this sort of web 2.0 idea. The cloud means a lot of different things to a lot of people now. We have all these different things coming about, but they're really all old ideas. People used to timeshare on mainframes, they used to share these systems, and we've just taken that idea, applied the internet, applied all these new tricks, and now we have supposedly this OS that's gonna run completely on the cloud. So, while we're evolving, I suppose we're going back to the old ideas as well. There's a few different types of cloud computing, and software as a service is one of those, and I think that's the one that most people are familiar with. People are familiar with, of course, Google Apps, using CRM software on salesforce.com, Twitter, and the way that I look at it, really the internet's becoming the software as the service now. Everything we do is online. Everything we do is on the internet. There's also the idea of infrastructure as a service, and these are people like Rackspace Cloud, GoGrid, Sun has a system, VMware is going to one day have a system, Amazon Web Services. These are all providing the base tools you need to actually do something, and that's where we come in. We're entering the market as a platform as a service, just like Google App Engine, Windows Azure, Salesforce is actually getting into that as well, and I didn't mention Spring Source, but those are another bunch of people doing platform as a service. So, the engineered cloud. The engineered cloud is pretty much divided up into two pricing plans pretty much with the same features, and those are Solo and Flex. Flex is a beta product right now that has Solo pricing and you can get on and try it out. The difference between Solo and Flex is Solo only allows you to run one instance, whereas Flex is going to allow you to run multiple instances or a cluster. Runs on top of AWS, so it leverages all those nice things that AWS gives you, like elastic block storage, or we give you your S3 credentials, so you can even use S3 out to your clients, just not internally as well. One of the big ideas that our development team brings to the idea of the cloud is the infrastructure as code, having these repeatable things that we can click a few buttons and spin up a few servers and have that server just be like all the other servers, but tweakable as well and customizable. And then the Engine Yard stack is one of the key things, I think, that may set our cloud product apart because we've been working, you know, some of our lead guys like us have been using EngineX for years and been big proponents of EngineX, and so we bring all that knowledge and all those years of experience and we're applying it to our cloud product well. Now, don't be caught up in all of the cloud stuff right now, there's a lot of people saying the cloud is the future, it's not going to be the future for everyone, you just don't want to get on the cloud because you want to be cool. And if you're doing it wrong, the cloud can actually be a liability. If you're doing a high amount of IO, there's reasons why people like Facebook or Twitter aren't running on the cloud, something like Cassandra, which is very, very high O, is not going to necessarily fit really well in the cloud. So you need to look at your requirements and look at what you need to do. The cloud is not going to kill all your rabbits for you, it's going to solve some problems for you and can solve them very well but it's not going to solve all your problems so sometimes you may need to take a step back, look at your problems and reassess is the cloud the right solution for me or do I need to change my application to better take use of the tools that I currently have. Now, in my past I was a sysadmin in Boston I worked for a company called IT Software and managed thousands of Linux boxes and there's always something very nice about the tactical, that tactile aspect of a server or a NetApp or my Switch or my Baytech PDU. There's all these things that I can touch, I can go into the data center, I can kick it if it's being bad at night. Having that physicality is really nice and I think that being a sysadmin that's worked in large environments that's something I always liked. What I didn't like was filling out all the POs and having to wait three months for that hardware. So that's where we get into the idea of instant provisioning. Whenever I had to order 100 servers it would take me months in order to get the right people to approve, get the vendor who could be Dell, could be anyone to actually deliver those boxes, I'm gonna have to sit down, have someone configure all those boxes or you use Red Hat Kickstart or do whatever I need to do and that takes a long time. In this modern age with things like Tech Crunch and Dig, you need those 50 servers one day, you don't need those servers the next day. So what our product allows you to do is it allows you to instantly provision boxes as you need them. And one of my favorite things is how easy the deployment is. I mean, I think that whenever I started using Capistrano many years ago, we were all really taken with how easy deployment became but it's getting easier because of this idea of infrastructure as code. We also provide a lot of flexibility that I like because what you're able to do is because of this instant provisioning I can spin up a test server and I can run a long running process like a migration and see if it actually works and not have to worry about when I move this to production is my whole site gonna be down for four hours and the migration fails and I'm chasing my tail to fix things. And sadly, unfortunately, I think as time goes on, there's gonna be less and less needs for startups to have sysadmins because everyone's working in the cloud and it's making it so easy. You don't need to know all those really esoteric and Ginex configuration things to get your site running optimally. So finally, we're gonna go ahead and do some stuff now. And so what we're gonna do is we're gonna go over to our cloud environment and we could use Quickstart to get things a little, done a little faster but I'm gonna go ahead and take it the long way. The app that we're actually gonna be working with is a personal app of mine that I deploy on the nGeneric cloud which is called Twirkel. We'll go ahead and use my username with that. You have a choice of nGenex and mongrel and nGenex and passenger environment. Apache passenger is a bit legacy, it's going away. This is actually our staging environment so I guess that's why it's still sticking around there. So I've just created my environment. I'm gonna go ahead and do an application. Oops, hit enter too soon. We're gonna give it a GitHub URL where my repository sits with a, you can actually use different applications. We're not gonna go into a lot of, you know, Mirb and Rack stuff but those are available as well. I'm gonna go ahead and choose Rails two through three and their domain name. We're just gonna go ahead and throw that in there for now. We're gonna create our application. So there's a few more steps involved. We're gonna need to take anyone familiar with Git and doing Deploy is probably with Capistrano. We're gonna go ahead and go add this key to our GitHub repository so we can do our code. Oops, wrong key, I'll fail, really. Yeah, I think you're right. There we go, good call. So there we go, we have our GitHub Deploy key in place. We'll check that again. When you're setting up your instance you have the option to add gems. We'll send this out to James and we'll just add faster CSV. We can do specific versions, add those gems to the environment. You can also do that with Unix packages. If you need to call out to anything you may need and that's pretty much it. And then once we're set up our environment we can go ahead and create instances. So what we're gonna do here is we're gonna say, yeah, we're gonna want three application servers. These, you have different options of the different levels of Amazon systems you want. We're forced to use a separate database since we have multiple application servers. We'll keep everything else the default. We'll go ahead and boot this configuration. So we see here now what we have is we have our three application servers booting with our master database. Now these are automatically load balanced. If we lose one of these instances that instance is automatically going to be replaced for us. So there's lots of bells and whistles that we give you with the system as well. We give you built-in monitoring. Right now we don't do external monitoring. That'll be coming really soon. It'll monitor your applications. Monitor your memory usage. If your memory usage is, if you have less than a few percent of memory for a certain amount of time we're gonna email you that 10 times and we're not gonna spam you, we're gonna stop it. But we do give you the monitoring abilities. Usage graphs such as your IO usage, network usage, et cetera. Really painless SSL certificates. SSL certificates are a few clicks away. You can either use a self-generated or self-signed cert or you can use upload your own. And other tools we give you are the backup tools. We use Elastic Block Storage System from Amazon which gives you the ability to do incremental snapshots. So you'll take a snapshot. The next one you take is gonna be incremental so you can recover any state of your system if you need to. We also have built-in MySQL dumps and all of these things are configurable. So we do support Capstrano for deploys. You can go into our application and go ahead and grab your DeployRB and Deploy just like you're used to. But what we've tried to do with the system is bring a few other tools to the table and what we're using is we're using Chef for deploys now and that gives you post-deploy hooks just like Capstrano would give you but you actually check those into your code base. You can do one click deploys and I'll show that right now. And then you can also use GitHub's ability to do post-commit hooks or actually any Git repository you could implement that yourself. So we see our system still coming up. The servers are gonna wait on each other, wait for the database to boot but they're all in different states but eventually they'll come up. So we're gonna go ahead and pull the cooking show thing where I have a little cluster already started up for so we can go ahead and look at it. So we have pretty much an exact mirror of the environment that we had before when database three application servers. So what we're gonna do is we're gonna go ahead and go over to my application, my Torcal application and we'll just edit some code here and save that, we'll go, let's do it again. Push that up to GitHub. Then before we deploy what we'll go ahead and do is we'll look at the current version of the website. Since I have multiple versions running we're just gonna go ahead and use the IP and not worry about host names or anything like that. So the Torcal application here, we're gonna go ahead and go over to the cloud and we're gonna deploy. Now I don't have any, of course, I don't have any migrations in here so we're just gonna go ahead and deploy our code. And you can choose different things, you can choose different get branches if you want to. And so when you click deploy, any configuration changes that need to be made like if you add an SSL cert, if you have a new SSH key, things like that, those are gonna be deployed as well. And as we can see, we're deploying across everything but the database server. We're deploying the application now, there we go. We actually use HA proxy to load balance in between all the individual servers. Amazon does offer a load balancing system as well. We find the configurability and the control that you have with the HA proxy is really great. So we've deployed our code so hopefully if I did things right, when I refresh Torcal what we're gonna see is we're gonna see the little change I made there. Now going to the website and hitting deploy and one click your code is a lot of fun. But we can also do a few other tricks with that as well using get post commit hooks specifically with GitHub. So we'll go ahead and save that. Now before we do that, what we actually need to do is we're gonna need to go to our application here. And as you saw, we'll have the deployer B is over there. But what I can do is I can click here and I can get a specific URL that we can go over here into GitHub. We'll go find my repository here for Torcal. We'll add a post commit hook in and then I'll show you in a different way that we can deploy this. We'll just add a simple service again here. We'll update the settings. Now anyway, I don't know if many of you use the deploy hooks. We'll go ahead and just do a lame check-in right there. Oop, can't do that. Messed up because I didn't actually add in the stuff so we'll just do, we'll just add a simple file. And what we're gonna do is we're gonna add these brackets in here with specific commands to deploy Torcal. And then we're gonna go ahead and push that. And once we push that, GitHub is going to recognize that we had that specific deploy message in there and then if we rush over to our cloud again, we're gonna see that get deployed across the instances. So I actually didn't need to click, I didn't need to go to the website and click deploy. And this gives you a lot of power and a lot of flexibility if you wanna do really fast iterations on your staging so ever you can just always keep pushing out deploys and not even have to worry about the website and going to the cloud infrastructure to do your deploys. So another feature that I really like, personal question, go ahead. Sure, yeah, yeah. So if there's actually a whole, there's a whole system that GitHub's using that lots of people are buying into this standard of message passing via the web. And so that's just the specific message that you put in that GitHub then posts into our environment which then deploys your system. So one of the really neat features that I like is the idea of cloning. And what cloning gives you the ability to do is take your entire environment, clone it to another environment. And like I mentioned earlier, you can do a long migration or you can test a specific version of Rails if you like. You can make changes to that environment. You just cloned off your production and make sure when you deploy, everything is gonna go okay. And the clone system is very easy. I can clone an entire system with one click. We'll just call this staging. We'll go ahead and make it production for now. We'll just let it do anything it wants with the IP address. It'll clone the environment. I think this is a really powerful tool because a lot of people will spend a lot of money to keep up an entire staging environment that they mainly use or a pre-production environment or a QA environment that they mainly use for a few hours but they're dedicating an entire system or a few systems for database and things to it. And so this allows you really easily to clone your environment, test anything you need to test, and make sure everything works with one click. And Amazon's gonna take a little bit to bring those things up. So with this idea of cloning, because we're using the EBS system, we have the ability to scale both ways. You can scale your application vertically and horizontally. When I talk about scaling an application vertically, what I'm talking about is increasing your CPU or increasing your RAM because that's your database box or that's your heavy lifting background box that's running RabbitMQ for you. So I have a single environment here. You can't actually do this live. It's not something that, because you actually want a snapshot of the system, before let's say we wanna increase the disk space, we're gonna go ahead and shut that application down. We're gonna give it a few seconds to hopefully create its snapshot, finish creating the snapshots and upload them. And as we see, we can't create our environment here now. But I do have a few old storage volumes that I could pick. This is an older snapshot that I ran. So I could just pick that, if I can wait about 30 seconds or a minute for that snapshot to finish getting in place, which it is now. And I can select my latest snapshots. I can increase the disk space. I'm not, I could actually even grow my environment if I wanted to move from a single instance to five instances, I could do that as well. I'm gonna save us a little money and not do that. And I'm gonna boot the configuration. So with a few clicks, what I've done is I've just taken my environment and increased the disk space. I'm bringing my environment up. There's a little bit of downtime involved in that. But if you handle it an interesting way, you can prevent that downtime. Question, go ahead. Well, it's technically it's not an engineer creating your snapshot. But yeah, I understand, sure. Yeah, I think that it's, I haven't seen too many problems with that. Although, I have seen a few problems step up. But if you terminate the instance, the instance is going to come down in a certain way. So your web server is going to stop, your database is going to stop, and then the snapshot is going to get taken. So you're not gonna lose any data. Things shouldn't come crashing down around you. Yeah, actually, yeah, that's, I was gonna talk about that a little bit, yeah. But there's also a snapshot feature that you can actually take a snapshot right then and use that as well. So we're gonna talk a little bit about scaling, that was scaling horizontally. Let's go ahead and talk a little bit about what happens when you get famous on the internet. So you get on TechCrunch, you get on Dig, someone starts talking about Twitter, or you get on the New York Times. You're gonna need add capacity. And add capacity, adding capacity is quite simple. It's, oh, that's interesting. I'll have to wait for the environment to come back up. We have a cluster that we can work with there. Adding capacity is quite simple. All you need to do is add an instance to the cluster. We have the ability to do utility servers as well, so those utility servers aren't going to run your web servers. They're gonna run tools like Solar or anything that you can configure with Chef. So once I click add an instance, we're just gonna go ahead and add an instance. You can add up to 20 instances. If you need more than that, you can talk to us. That's just where we limit it right now. But really, if your application scales really well, horizontally, that prevents the Dig effect and the TechCrunch effect. And then whenever, a week from now when your traffic goes down or dies down, we can go ahead and terminate any of these instances that we need to to get back to the capacity we need. So we're only having the capacity, or actually, we're only putting out the capacity that we actually need. We're not investing a lot in overscaling it. The way that you customize the environment is with a tool called Chef. And Chef is a really interesting way to configuration manager systems. And so we wrap around all of that and it gives you the ability to do a lot of really nice, custom things with your system because most of the Rails applications I see every day are not one-offs. It's not a simple website. Someone's gonna want to run Tokyo cabinet. Someone's gonna want to play with Redis. And so we'll hop over to some code here. And we'll look at a very basic Chef recipe. And this one, I just opened this one up. This is specifically for CouchDB. Chef is written in Ruby, all looks like Ruby, codes like Ruby. And this statement right here simply tells the system to add the package on the system for CouchDB so that I'll install CouchDB, setting up the permissions on the log directory. We're using a template. We're templating out the Couchini file. We're adding a remote file, which we're using from a template over here, which is actually right here. We have templates. And then we're telling it to go ahead and execute so when the server starts. So we're going to add CouchDB to the default startup of the server in case it's not. So when the instance comes up, it'll go ahead and run that for us. So this is a really easy way to add CouchDB to your environment. And there's lots of other Chef recipes that we don't offer publicly currently, but as time goes on, we hope to put those Chef recipes out in the public for things like Sphinx, more custom memcache setups, you can even do in Bari Ruby with a Chef recipe if you like. So this is a little bit about how the environment works. As I mentioned before, we have HAProxy sitting on all of the boxes. And when something goes bad, what we're going to do is we're going to move that IP address over to another instance. The method uses the stoneth method, if you're familiar with that, shoot the other node in the head. So the two other nodes are gonna race to get the IP, one of them's going to get it, one of them's going to, one of the application server that's still up out of the three is gonna promote itself to master. System's going to realize that, oh, we lost a node. And so it's gonna go ahead and bring up another node to replace that. So we still have our thing going right here. Let's just go ahead and connect to this box. And the little man in the middle attack, because I bring up and down an environment so fast, my SSH keys are always changing. So there's no worries about that. We're just gonna do a sudo. Our system's gonna go down. And there's a little bit of delay in this. We check every minute. If we look right now, we see that we're getting, these CPU graphs are actually brought in from the server. And so we see that this server is no longer reporting CPU information. And if we actually click and try to go to the website, we'd see that it's down. So our system is always polling and looking to see what's happening with your instances. And so when an instance fails, it's going to recognize that in one or two minutes and it's going to bring up a replacement for that. And we can sit and watch that happen, but it's a little bit dull. So we'll come back and we'll see that our instance has moved around. So some of the things that I really haven't covered is that this just isn't a Rails product. I mean, everyone's going to talk about Rails and Rails hosting, but we also support MIRB. In fact, our application's built on MIRB. We run the, you know, and we eat our own dog food. Our application runs on the Amazon system as well, on our cloud product. You also get crontab management. You can run multiple applications. You also have the ability and your S3 access so you can actually have your clients connect to your S3 as well. You know, you can store the files on the S3 and use your credentials to provide them access as well. And one of the new features that I talked a little bit about is the utility slices for when you don't need to run a web server. Some of the things that are coming, we're adding features every week. These utility slices just came on last week. Yes, I think this is the biggest complaint, I think that I hear from customers that we don't support Postgres. That's something that we're hoping to get out very, very soon. We don't support the slave DBs and automatic failover of DBs. That's something that's coming very soon. And as you all might have known, the JRuby guys came to work at NGINYARD and we definitely hope to provide the ability to run JRuby on the cloud as well. So any other questions? Sure. No. No, the EBS technically runs on S3 but it's a separate environment, it's a separate system. So when we talk about, there are parts of our system that use S3 so when you have a backup, that's gonna be stored on S3 for you. So we do store things on that and we give you essentially the secret keys that we use to store your things so you can use your S3 accounts. You don't have to have multiple S3 accounts and two bills, you're only gonna have one bill with that encompasses all of your S3 usage for your application. So, sure. I think mainly because the Elastic Load Balancer is really new and we were developing this before. Amazon's pretty cryptic about when they do things. I mean, we just all learned about their new virtual private cluster, the VPN system that you can bring in, so they're pretty quiet. It's something that I know that we're experimenting and playing with and seeing, are we gonna work that into the infrastructure? We've had really good luck with AJ Proxy and a lot of the people that I know running fairly large applications on AWS are using AJ Proxy. Now there's a little bit of CPU load involved with that on your main instance but maybe you're, you may need to use larger instance for that but in general it works for us, it's very configurable and we have it today but I know that we're definitely gonna maybe explore that in the future. All right, thanks everyone.