 This is Robert Dempsey of Atlantic Dominion Solutions. He's going to talk about cloud computing. Thank you, Jeremy. OK, so I want to start out here real quick with a little video. See if I can make a play. Oh, thank you. I can't take any credit for that. I've got a friend of mine that does some video production. I'm like, dude, I need something to intro, and so that's what he gave me. Very happy. So I'm going to talk about leveraging the cloud with Ruby. So as you can see, this is how I normally dress every day, literally, when I'm working. This is my secret agent suit that I wear when I'm infiltrating the enterprise and getting Ruby and Ruby on Rails in there. So again, just some quick credentials on me. I'm the CEO of Atlantic Dominion Solutions. We are a web development firm in Orlando, Florida. We specialize in Ruby on Rails, and we're also getting heavily into Flex. I'm the founder of Rails for All, which is not for profit. And through that, we do things like Axis Conference, which is a little two-day Ruby on Rails conference down in Orlando. It's going to be the second one. It'll be in February. I'm also the co-chair of Daderati, which is a local tech thing. I got a BA in computer science from Rollins. I'm doing an MBA right now. And CSM stands for Certified Scrum Master. We do agile, and specifically, scrum is what we use as our development methodology. And so next week, I'm going through certified scrum master training. So I'm angry. I'm like mad cow angry. Because if I hear this one more time, there's going to be some major trouble. And Jason knows all about that. He actually angered me very much this morning by saying that. So Ruby on Rails can scale. If you understand how to scale it, in my opinion, so what do we have to understand in order to get there? Well, there's all this. Or there's a much more simplified version of really how the NBC architecture of Rails works. So already, you're probably wondering what the hell that has to do with Ruby in cloud computing when I'm talking about Rails. Well, as we all know, if you really want to build some serious Rails apps, you have to know what you're doing with Ruby. Hence Ruby on Rails. And where cloud computing can come in with web-based applications is two parts. It's at the web server level. And it's also at the database as well. So when I think of cloud computing, I think that I don't want to have to buy anything. I don't want to have to think about resources when I'm setting up servers or storage. And I want to be able to easily scale my application. What exactly is scalability? And people like to define it as the ability to either handle growing amounts of work in a graceful manner or be really enlarged in the sense of an application. Or it can refer to the capability of a system to basically handle a lot more traffic as needed. And I can see I'm working a tough crowd this morning. So really, I'd like to add to that, though, to that definition of scalability. And basically, it's an application and the resources it uses grow as demand increases. And this is where cloud computing really comes in. So to get something up on the cloud and basically be all cloud-enabled and all that good stuff, what I need is I need servers. I need storage. I need access to other utilities. I need to do it all without buying anything upfront. In other words, I don't have to provision servers and all that kind of thing. I want to do it all with Ruby, obviously. And that in a nutshell, really, is the cloud. So before we get to what the cloud exactly is, because there's a lot of definitions out there, too, I want to talk about what we had before we got to the cloud itself. So in the beginning, there were clusters and there were a couple of kinds of clusters, high availability and load balancing clusters. And there was also grid computing. So a high availability cluster looks like this. Basically, you have the internet up there at the top. You have a router. You got some web servers that basically talk to each other via a heartbeat. So if one fails, then the other one just picks up. Then behind that, you have some data. Now a load balancing cluster is a little bit different because you have a firewall up front and then you have actually load balancers that send the traffic back to the web server. So the load balancers know what's behind it. So if a web server dies, then the load balancers will know that. And then they'll just route the traffic appropriately. And the grid was the next level up and even closer to today's cloud computing where basically you're out there somewhere and you can access all of these resources that are literally all over the place. So you could have a cluster of servers that you have access to, some amorphous stuff over here, some data somewhere else, documents, applications, they're basically very loosely coupled and all over the place. So what's not a cloud? It's not a cloud if you can't buy it on your personal credit card, if they're trying to sell you hardware, if there's no API. If you need to re-architect your systems for it, definitely not a cloud. But it takes more than 10 minutes to provision, i.e. if I can't launch a server in less than 10 minutes on demand, then that's not really cloud computing. And if you have to specify the number of machines you want up front, again, mention that, and if you own all the hardware. So the next kind of thing though, before the cloud even that's out there is something called utility computing, which a lot of people will confuse utility computing with cloud computing. And what utility computing is is basically compute resources packaged as a utility. It can use clusters and grids. It pays you go model. And some examples of actual utility computing are like Amazon's web services, EC2, S3, which y'all might be familiar with. HP has some stuff, Sun Microsystems has network.com and you can do stuff with that too. So ultimately though, what cloud computing really is is basically a way to increase capacity and capability on the fly without having to invest up front or licensing anything also. So the cloud is really all-encompassing. The cloud is, I mean, it's utility computing. It's software as a service. So even like Google Docs could be considered cloud computing in a sense, because again, you don't own anything. With that, they store everything. God knows where they store it. I'm assuming, you know, in some data center. But really I don't have to worry about any of the resources that go into actually making Google Docs happen. Hence, software as a service itself is even defined under the umbrella that cloud computing is. Web services in a cloud, platform as a service, managed service providers, I was kind of interested to see. Service, commerce platforms and even internet integration, which are basically, there's only a few big guys out there that are trying to make it so you can easily attach to all of these kind of resources that are out there. So why is cloud computing in general important? Obviously it's a big buzzword that's going around these days. But Forster, or sorry, Gardner rather, projects that by 2011, IT departments are really gonna start basically outsourcing a lot of their infrastructure. And so they're gonna look to services like cloud type services to do that. Already people are doing that with things like Amazon's EC2 and S3. So for instance I could launch a ginormous compute cluster on EC2 without having to invest anything up front. I can do my jobs up there and then after it's done, kill it off. So the advantages of cloud computing are there's no hardware to buy, which is great especially for startups when you have to keep costs down. There's no infrastructure to support, which is great. I'm a Microsoft certified systems engineer. I did IT administration for years and there's a reason I got out of it and I'm programming and that's to not have to do that. And you can add capability also with minimal coding, which we'll see. It's actually almost ridiculously easy to take advantage of a lot of services out there with Ruby. So what we're gonna get into next, we're gonna talk about options and pricing. I put out on our blog and said, hey, what do y'all wanna hear about? And I think Greg from Rails Army there said, I'd like to see some options and pricing, what's out there? So I'm gonna talk about that. I'm gonna show a standard EC2 deployment because another person commented on the blog that they said, so I hear EC2 is so inexpensive, but then I hear it's, in reality, it's not really all that inexpensive and the reality is it's not cheap because of how you have to architect an app that's running on EC2, so we'll show what a standard EC2 deployment looks like. I'll give some recommendations. We're gonna look at some code and then just wrap it up. So what do we have to work with with cloud computing? Obviously, probably a lot of y'all already know about Amazon web services. There's another provider called Morph, which is into the realm of platform as a service, RightScale, which Greg had mentioned, and we'll all get into exactly what RightScale does. There's Heroku, which y'all might be familiar with. Joiant has their accelerator products and EngineYard is working on Vertibra, which is our Vertibra error, why not? But either way, it's coming soon and I don't know about that, so we won't talk about that one. But then do-it-yourself-clouds, as Greg had mentioned, PoolParty. There's another service called Scaler, which is really cool. There's ElasticRails, and then there's probably a lesser-known one called WeoCEO. So with Amazon, you have Amazon EC2, which is their compute on-demand. It can run anywhere from 10 cents to 80 cents per compute hour for an instance, depending on the size of the server that you want. So the smaller instances, which have like 1.7 gigs of RAM and a processor go for 10 cents, but if you want some mammoth, ginormous server, it's gonna cost you about 80 cents per hour, plus transfer costs, which they measure in gigabytes. So you pay for the instance and you pay for transfer in and out, unless you're working with Amazon's S3. So if you have data stored on S3 and you're serving it up via EC2, there's no transfer costs there. S3 is 15 cents per gigabyte, plus again, transfer costs. So if you use S3 purely for storage, then they're gonna hit you up for some transfer costs there as well. Then there's Amazon SQS, which is basically a penny for 10,000 requests, again, plus transfer costs. So Greg had mentioned Starling. We have one of our sites, What's Up in Ruby, that uses Starling to basically tear through blogs, and we use SQS for the part of the messaging backend. And then there's Amazon SimpleDB, which is 14 cents per machine hour, plus $1.50 per gigabyte per month of persistent storage, plus transfer costs. So the pros of Amazon Web Services, obviously, you can pay as you go, you can use one or many, i.e. I can launch one instance, or I can launch up to 20. I think if you actually need more than 20, you have to call them and ask for permission so that they know you're not trying to like denial of service anybody all of a sudden, because you could easily do it with Amazon. Not that I would know anything, but yeah, anyway. So there's no infrastructure purchases, which is great. So basically I have, at my fingertips, practically unlimited compute capability without having to buy anything. And then there's also a lot of third party service providers that actually have services on top of Amazon services. So the biggest con to Amazon is that you have to build reliability yourself. So if y'all have read any about how Google does some of their operations, they basically have like three copies of everything. And it's almost the same kind of thing with Amazon Web Services, where we have had instances on EC2 vaporized when we try and reboot them. So if that is your only server, then you're gonna be screwed. So you have to build reliability on top of something that is somewhat unreliable. Also there is a, excuse me, configuration overhead with EC2. Now the third party service providers come in to giving you a lot of management tools for EC2. Otherwise you can do it all via command line, but I like a nice little GUI that allows me to manage everything myself. So the next one is Morph, and they're somewhat newer on the scene. And also I gotta give a little disclaimer, we're actually a partner with Morph, and we're a partner with RightScale. But that's not necessarily why they were included in the presentation, but so they're here. So anyway, so Morph starts at, they have a developer version, which is really cool. So basically I can, within about five, 10 minutes, I can get a database set up, I can pull down a custom Capistrano file that they give you, then I can basically deploy my app onto Morph. So we have three sites up and running on Morph. They used to support only Postgres as a backend database, and they now support MySQL as well. And one of the cool things with Morph is that I don't have to deal with the management, really, of anything. I deploy it up there. If I start with my developer version, I can check to make sure that everything's working great. I say okay, let me go to a paid version, which then will put my app across two servers. And so there's a lot of reliability built in, and then it goes up from there. Now, one of the things though that I was trying to make sure that I understood with Morph was when they say, okay, you have this duo, and you have these two cubes, I'm like, okay, great, well, what's that mean? How many, and one of the things that we obviously deal with a lot, at least with Rails apps, is mongrel. Okay, well, how many mongrels do I get? So how much traffic do I know I can handle? So basically they said the duo is one mongrel on two machines, and then it goes up from there, but they never put more than 12 mongrels running on a single instance of EC2. So the pros are, you pay as you go, takes about 10 minutes to sign up and launch, and there's basically like zero configuration, it's automated migration running and all that good stuff. One clicks scaling, so literally I can click a dropdown and say, okay, I wanna go from duo to whatever the next level is, and in about five minutes, my app will then be deployed instead of on the two machines onto four, and so on and so forth, takes about five minutes. They fully manage everything, and they actually have hardware load balancers that everything runs through, and they back up all of it for you, and you can restore backups, and we actually had to do that once, and their support is really good. And then again, migrations run on deploy, so you don't have to worry about making sure that your migration's ran. The cons though is that there's no SSH, or file level access. So if you don't care about that, then Morph is great. If you do care about that, then you don't wanna go with Morph. So the next people again are Ritescale, which is really one of the more premium offerings for EC2, and they, I'd say they are almost like the Cadillac of EC2 management tools. There are so many options that you can use with Ritescale, it's not even funny, and it takes a little bit, it took us about a week to really get a full grasp of what you can do with it, they have a couple different offerings, their Ritesite edition is 2,500 set up, and then $500 a month, and then plus EC2 costs, and S3 or anything that Amazon would charge you was on top of those numbers. So for instance, with Morph, where you're paying 30 bucks a month, you're just paying 30 bucks a month. You don't have to pay for EC2 and all this, unless you use S3. They have Rite Grid, which is more of their product that offers scaling on demand. So this is where actually starting to get into the realm of actual true scaling on demand, you can set limits and say, okay, if my CPU goes up to like 80 or 90, or it gets pegged, then start scaling out my app. Of course, that can be dangerous too, because if you have no limitations on it, for instance, like when we're chewing through blogs with WhatsApp and Ruby, it pegs the processor. So if you had, if you said, okay, if you have no limitation, and you say if my processor gets to 100, fire up another instance, well, every instance we fire up and start doing work on, the processor gets pegged. So basically we'd have an instance launch for every blog, so you gotta watch out for that kind of stuff. Then there's the premium edition, where you get like everything. And it's a $2,500 set up again, and $750 a month. And then of course, like I said, there's AWS fees on top of all of that. So they're more of the premium people. So the pros, there's a multitude of configuration options. Literally, we have clients deployed on RightScale where we can launch a multi-server deployment with a click of a button. Because once you have it set up, we can launch a full deployment, which a standard deployment for RightScale used to be two front ends and two back ends. So we can launch all of that at one time. It'll install any software that you need and whatnot. So it's really also platform agnostic. Scale on demand capability with their RightGrid product or their premium offering. One click again, multi-server deployments. And you can manage everything AWS from a single interface. Now the cool thing is, they also have a free developer version. So if you just wanna be able to manage stuff on the EC2 without or S3 or SQS, you wanna see all that in a graphical manner without actually having to pay anything, then you can use that now that's on video. So they've seen that, I probably said that. So that's great. Cons is it is a bit expensive. So it is more of a premium offering. And there's a lot of upfront configuration that is required, but once you have it up and going, then you're good to go. And it is dead easy to support, easy to deployments. So the next people are Heroku, which from what I gathered from their website and from their interview on the Ruby on Rails podcast, right now it's free for now. Later they're gonna charge somehow based on work or something like that and I've asked them because I had seen that they said they would be here but then I heard they might not be here but if they are here, then track them down and ask them what they're gonna be charging people later because they definitely have intentions for it. So the pros of Heroku are you can do everything in a browser like literally they have the code editor, the whole nine yards in a browser, they have automatic scaling. Now I couldn't find really any documentation on how exactly that works, but they say that they have thresholds and everything already set in their software that says if it gets to a certain level of traffic, then start scaling out that application. Also one of the cooler new things that they have is that you can work locally, then deploy. I have never actually, I mean I tried using a code editor in a browser but I'm not a big fan of that. So what's cool is though is that you can do all your work locally, send it up to Heroku and then it'll do auto running of migrations in the whole nine yard and deploy your app for you and all of it. So that's a really cool new feature that they have. The cons right now are you have to use like a Heroku.com domain as far as I know. If anyone knows different I couldn't find anything else on their website saying anything different. So basically I'd have like robdempsi.heroku.com which for a business face is I want my own domain name and I want to say like robdempsi.com because that looks a lot better. And also choices are made for you. So much like in Rails where it's opinionated and it says okay we're gonna do this. They do the same kind of thing. They've made choices for you so that it's easy to deploy but you don't have as much flexibility. So the next one is Joint Accelerator which is more of a traditional hosting company if you're familiar with Joint. Their offerings basically started 75 a month and go up to 250 and on. Now the pros are is that you pay as you go obviously so you start out with like a VPS that's great and then if you want another VPS, okay that's great. They have solid hardware. They use a lot of sun stuff which is notoriously good and from what I was told by some of their internal guys they use ZFS which is a function of open Solaris where if you need more storage they can give you more storage. Now the cons are that you have to call in to scale your application. So in my opinion that goes kind of down to the bottom where that's not really cloud computing because if I have to call somebody and say hey scale my app up then from the definitions that we have before that's not cloud computing. And also open Solaris is fun to try and configure and get running and work with in general but I won't go off on that at all. So into the do it yourself ones pool party as Greg had mentioned is free. It's a Ruby gem so you obviously don't have to pay for that but you do have to pay for AWS costs. Pros are easily our easy configuration and deployment from seeing their screencasts that look pretty easy and you can highly configure your EC2 instances so it gives you all the flexibility of installing software and all that good stuff. The cons are I found it really lacking in documentation and when I went into their IRC and actually posted a comment on their Google group and said hey does anybody have experience working with Rails apps on pool party? I got zero answer and I couldn't find really any documentation so if anyone knows where it is please let me know. Right now it supports only Ubuntu EC2 AMIs which are Amazon machine instances which for me really isn't a problem because I love Ubuntu as a server but I know like right scale uses for their standard they'll use Centos or some people want to use actually like Red Hat Enterprise if you're paying for it. So with this you only get Ubuntu and from what they said in their like on their site it's not production ready and that's just to qualify that they said that around June 20th. So if it is now they haven't said. So next up is Scalar which was created by Intridia which is another web development firm. Scalar itself you can get for free from Google code you can download all the code and host it yourself and then of course you're just paying for Amazon web services again the cost or they have a paid version which is $50 a month plus Amazon web services which is really cool you can go in they have a screencast of how it works you can set like min and max threshold so you can say okay you know if I start you know my app starts getting a huge amount of traffic scale it but only use like only fire up two more instances tops. So they put a threshold on it so you don't get this like multi thousand dollar bill from Amazon at the end of the month you know what is that? So pretty cool pros obviously is free for the code base always nice you can configure auto scaling of literally everything and I had a lot of talks with Dave Naffas from Intridia and what he told me is it'll also scale the back end databases and they have just a few like lines of code change to be able to deal with that also in your Rails app when you all of a sudden you have one database and all of a sudden you have multiple ones they can handle that and it's configurable to do automatic database backups to S3 which is nice because one of the things I sometimes forget in the very beginning is okay great I've got my app up and going oh yeah I gotta back it up you know just in case God forbid anything happens or my EC2 instances vaporize when I have to reboot them which they do. So the cons are you have to use their base AMI so you're in it really not too many options there but that was really the only con I could find of that one. The next one is this thing called elastic Rails and there's a free community edition which you can use again plus the Amazon web services charges no one really is gonna foot the bill for that one then they have a $10 month personal edition which allows you to manage ones you build which kinda gets into the pros of basically you go and they have this tool online where you can literally build your image so they have they say okay I wanna build an AMI that has Rails okay great and I you know I have this version of Rails and this version of Ruby and I wanna use either Nginx or they now support Apache with passenger which is really cool so they'll support that one also and so you build up basically you say okay I want these Ruby gems and whatnot it'll build it all up for you and then you can spin it out as either a VM for like VMware or I think they also support parallels or you can launch that sucker on the EC2 when you're done which is pretty cool so you build this custom bundle and deploy it and there's this GUI management console that lets you manage like all of the servers that you built now the cons are really the elastic server equals application stack it's not actually again cloud computing you can launch it over there but then you still have to deal with everything really after that Community Edition is for non-commercial use so they actually license it and they say okay if you're using the free version that's great but you can't use it for business which sucks so the next one also is that Rails 2.0.2 is the latest version of Rails that they support and I like to use the new stuff but that's just me so WIO CEO is I believe it's the last one it's free again plus the AWS costs cool things about them they have actually automatic load balancing built into the software they have automatic scaling and much like with scaler you can set minns and maxes so you say okay I need a minimum of two front ends but if I have to start scaling that sucker then don't go over four front ends so you don't get again whacked with some insane EC2 bill the cons, well this is a con for me is command line setup I work a lot in the command line but I don't want to have to manage like full deployments of servers and stuff via a command line which right now you do for them and there's no specific documentation on using Rails like at all there's no documentation so what's the standard EC2 deployment look like and why is it really so expensive to use it? well this is what one actually looks like if you want to have something where if a server vaporizes you're not SOL so again you start at the top of the firewall which will just let Amazon handle that one you need at least two load balancers like actual machines running only as load balancers then behind that you have at least two web servers so if one goes down you're not you know you didn't screw the pooch with that one and for database you have a master and slave database so if your master database goes down promote the slave fire up another one get replication going again and keep going so you need a minimum of six servers running on EC2 for full reliability so how much does that cost? well if you have two load balancers and say the small instance which is again it's 10 cents per compute hour so two dollars and 40 cents a day if we figure that an average month has 30 days then your two load balancers are gonna cost you 144 bucks your web servers are gonna cost you 144 bucks and your database servers are gonna cost you 144 bucks so a standard EC2 deployment will cost us $432 a month and that's only for the instances themselves that's no S3, that's no SQS that's no making sure your stuff is backed up somewhere you know cause again God forbid nothing so that's like the base cost is about 432 bucks so what do I recommend? well the question is are you a developer or are you a systems administrator? again I did systems administration and I don't wanna do it anymore so I choose developer on that one so my suggestion is pay for it you know pay a little bit of money for some of these options and get full management tools of everything it makes your life so much easier and the costs for a lot of it are really low so you can start off with in this order I would say you can start off with morph we start around you know again like $30 a month next up I'd go for scaler and then after that if you have a bigger budget and you need to handle some like serious configuration of stuff then right scale is the way to go with that so finally let's look at some code of using all this stuff so first some books some books that I would recommend programming Amazon web services which I gave a copy to Jeremy which he'll be giving away restful web services is another great book cause a lot again all of these the APIs for a lot of these services are rest based and then Ben Schofield did a little one called practical rest on rails two projects which is also good I will warn you though that programming Amazon web services literally like does you do everything yourself just so you know instead of using gems also just another shameless little plug of myself eight Amazon web services articles did one on introduction to AWS Ruby developers economical use of S3 blah blah and then the full Monty which is using Amazon S3, EC2, SQS, Lucene and Ruby for web spidering in which we use stuff like H per cot to pull down pages and rip them apart and then there's another one for Amazon's flexible payment service which is called sample applications in Ruby for Amazon FPS and the reason I didn't really mention FPS in my talk was that I think there's one project out there run by a guy named Tyler Hunt that actually has anything built to tie in like in Ruby to tie in with FPS so there's no real gems or anything available to make it easy. So some gems that we can use however I suggest the right scale gems cause you have like two gems and they do everything and they are awesome and we'll see how to use those in a second you can deal with EC2, S3, SQS and simple DB all from one Ruby gem which is awesome and then it depends on this thing called write HTTP connection remit is the project again for dealing with Amazon's flexible payment service and then pool party is available as a gem as well. Some plugins if you're in the rails that you can use for S3 paperclip is a great one for attachments there's also attachment foo which was kind of like the standard and then there's also backup foo which makes backups of MySQL to S3 dead easy for simple DB you can use this one called AWS SDP proxy and then for SQS there's active messaging which is a plugin as well. So if you want to use paperclip with S3 then basically use these two gems right here write AWS and write HTTP connection oh and by the way these slides I've already actually posted them online and I will post that everyone can see all the slides so don't worry about typing up code real quick and the documentation for all this stuff is also really good. So to use paperclip is really easy say you have this product model here all you have to do is say okay has attached file and you basically say what you want okay so I'm gonna call it a photo I need some styles for it I wanna store it in S3 here my S3 credentials kept in another file secret here's the path where I wanna store it and there's my bucket on S3 in which it'll go. So very easy and literally that's it and so then once you put your file upload and make your form handle uploads then you're good to go and then it's dead easy. For SQS you can use a gem called SQS and it's using that one in your config environment.rb if you're using Rails then you just require Ruby gems require SQS put in your credentials for Amazon and then say you have a job model and then to get a queue basically it's queue equals SQS.getqueue and give me the name of the queue itself you can send a message really easy just dot send message and then the whatever the messages that you wanna send you can easily receive messages dot receive message again easy and then you can delete a job from a queue again just as easy and this stuff really is awesome. So using the right AWS gem is almost even easier so if you use the right AWS and the right HTTP connection gems then to create a queue then you just do that first line of code I'm not gonna read all this cause that'd be really boring. Basically just gen a new SQS queue give it your Amazon credentials and then you say okay you know my queue is now named my awesome queue done and then you have a queue up on SQS to sit in there waiting for your good stuff. So if you wanna create another one you do the same kind of thing and that true there on the end is for actually something you can set a flag for visible so you can actually have stuff in the queue that's visible or invisible which is really interesting and then basically to use the gem if you wanna see how many items are in it you just do queue two dot size and it'll tell you how big your queue is at the time. So to pull a message from the queue and make it invisible for some reason if you want an invisible message basically you just say okay create an object message one say I receive from my queue set the visibility is zero and then that's pretty much it you're done. So if you wanna clear it add a message delete the first accessible message in there three lines of code again Ruby makes it extremely easy. So if you wanna use simple DB which is is anybody using simple DB for anything? Anyone know? Okay yeah. It's kind of weird for storing like unstructured data so much like I guess like Google's big table I think it is where basically they determine what is like what are my rows or what it's basically like key value pairs is what is storing on simple DB. So if you wanna use simple DB for anything like some intermediary say again very easy fire up create the interface give it some credentials protocol HTTPS if you wanna keep it hidden or you don't mind someone hacking your data when you're pulling it down that's fine and then you can say if you wanna log it as well. So with simple DB you have these things called domains which is where everything stored so to create one again once you have your SDB object create domain give it a name done if you wanna delete it same kind of thing one line done. If you wanna create and save attributes for say John and Sylvia like okay you know create this thing for John I'm gonna give him car and beer I'm gonna do the same kind of thing for Sylvia you put your attributes you get and again then you're done very easy to deal with simple DB. Now if you actually wanna pull something out of there once you put it there get attributes again very easy if you wanna get attributes only for one thing that's in there then you can specify that there at the end where it says cat you're saying for this cat object that's out there give me only the attributes for that one you can query a simple DB and you can also query it and say okay give me a limit of actually the first 10 items that you find so you can query it almost like a relational database but you're not quite not as cool all the stuff. Okay so that took a lot less time than I thought it would which is good I guess since we're going to lunch pretty soon anyway. So ultimately you know the cloud computing for scaling apps of any sort is really the missing piece of the puzzle and again Ruby makes it like dead, dead simple to use. So thank you very much for your time and coming to the hoedown thank you Jeremy for inviting me here to talk till you find people this morning. So thank you and here's me everywhere online. So are there any questions? Yes sir. So the biggest problem we've run into with cloud computing especially EC2 is mail because the EC2 instances are a known dynamic IP range. So pretty much everything that gets sent from an EC2 instance proper gets sent right to jump mail. So it's a problem for basically all these so it's a, you know, it's not dynamic, it's dynamic. Curious if you have a problem solution for your app to host on EC2 instances. Yeah, so the thing is is that sending out email from EC2 instances goes to spam and yes we've had that problem a hell of a lot and it's annoying. So one of the things that we've done is have you guys used the elastic IPs or basically you give it the IP and then you create an SPF record and it still goes to spam because I know like things like Yahoo and MSN there's been nothing that we can do. We just have to tell people like when they sign up on the sign up page and say hey add this email address to your contact so it won't go to spam. Otherwise we've actually used like Gmail for an SMTP server if you will and so that's how we get around that a lot of times. So it's just like, yeah send it through Google. Insight, under-originally, no. We're spam dealing with that it's like a never ending battle. Yeah, I mean we're using Google after your domain and there's a couple of, I think SMTP auth or a couple of different auth SMTP. Okay. Auth SMTP? Yeah, so it's an outsourced SMTP server so you can delegate to them and they're really good at getting them. Right on. So auth SMTP? Yeah, it's gonna add to the cost a little bit but it will get your mail delivered. Is that, how expensive is that, do you know? Depends on how many emails you're sending. Okay. One of the biggest clients is like 150 or so. 100 bucks a year, maybe. Okay, not too bad. Any other questions? Where are the slides? The slides will be posted on my blog or our blog as soon as I get out of here so they're on slidechair.net. If you type like cloud computing, ruby, stuff like that, they're up there. So you have them. All right, well thank you very much and have a good lunch and I'll see y'all later.