The Rogues talk to Wesley Beary about cloud computing.

Special Guest: Wesley Beary.

 

Dear monkeys!

Hey everybody and welcome to Episode 85 of the Ruby Rogues podcast! This week on our panel, we have Avdi Grimm.

Hello from Pennsylvania!

David Brady.

I will not make jokes during the intro. I will not make jokes during the intro.

James Edward Gray.

I always make jokes during the intro.

Katrina Owen.

Hello from Oslo!

I'm Charles Max Wood from devchat.tv. I really quickly want to announce that I'm going to be teaching a Ruby on Rails Course this spring, and you can sign up at railsrampup.com. We also have special guest and that's Wesley. Is it Berry or Beery?

Berry like the animal. Or the fruit, I guess.

Do you want to introduce yourself real quick? I don't think you've been on the show before.

Sure, yeah. My name's Wesley Beary, I go by @geemus online and do a lot of open-source stuff and work at Heroku on the API.

Were you at Engine Yard before? Working on Fog? Or was that somebody else?

Yeah. I was there. I worked on their cloud product for about a year, and then worked on Fog there for another a year-and-a-half about, but I've done that currently just over a year now.

Oh cool! So you and Matz are co-workers… Kind of.

In the manner of speaking at least, yeah.

[laughs] Awesome.

Matz comes to Wesley for advice [laughter]

So, are we doing the Best of Parley?

I think that's a good idea.

I've got the Best of Parley.

Awesome.

My favorite thread from our Ruby Rogues Parley mailing list this week was a thread that started with a topic of method chaining, and why is there a good reason to method chain apart from readability? Particularly, are there any performance benefits? When you say, dot, you know, something dot, some method, dot, some other method dot, some other method? Is there a performance benefit to doing that over just to doing 'em all set or call separately? And I thought that, clearly this was three separate calls. So why would that be a performance benefit in any way, shape or form? And then, James busted out the disassembler and demonstrated that Ruby does in fact optimize that case slightly. And I was dumbfounded! But the the thread didn't stop there. It proceeded into a fascinating discussion of the coming lazy - lazy enumerators in Ruby 2.0 and whether that was a good idea or a bad idea. And Michael Feathers popped in and talked about rich installment and assumptions about optimization that are always wrong and generally one of those sprawling threads that I've learned a lot from. So, if you wanna read sprawling and enlightening threads like this, go to the Ruby Rogues website and sign up for Ruby Parley.

Great! Thanks. I love the Parley list; there's so many awesome people on there. Great discussions. Alright, let's get in and start talking about the cloud. Now, pun totally intended, when people talk about the cloud, it seems a little bit nebulous to me.

So, if that was a question, are you calling for a definition?

I am. But Josh isn't here so I feel a little remiss in doing so.

I actually went and looked it up. And so I went to a dictionary and I found cloud and it says “a visible mass of condensed water vapor floating in the atmosphere, typically high above the ground." I figured that this is not exactly what we're looking for so I went to Wikipedia for a second shot and Wikipedia says “Cloud computing is the use of computing resources, hardware and software, that are delivered as a service over a network, typically the internet. The name comes from the use of a cloud-shaped symbol as an abstraction for the complex infrastructure it contains in system diagrams."

I always love the cloud diagrams because whenever somebody draws a cloud on the white board, I just automatically mentally label it as 'NFI' which is “no freakin' idea.” ... and you know... the cloud is where magic comes from. It's like rainbows and unicorns can fall out of there and, yeah, it's useful.

Yeah the cloud is webscale.

Yeah.

Alright. So, Wesley you've got a lot of experience here. What did you do when you worked on the cloud stuff at Engine Yard?

I worked a lot on the lower-level stuff of it, like you actually interacting with in -- in that case mostly Amazon, but also [inaudible]. So, time the pieces together, it's actually make that into something that's a bit more useable.

So what kind of services does versus, take Amazon for examplebecause it's ridiculously popular, what kind of services do they offer in their cloud?

Amazon has, one of the sort of forefathers of this whole thing I guess, has a pretty huge set of different offerings. So, the most commonly used ones probably would be EC2 which is their computing line and S3 which is their storage service. But there's a lot more for a free services to that is like CloudFront which adds a CDN layer to S3 and there's all kinds of additional ones around-- EC2 on a compute, plus there's sort of databases of service stuff. And now with Dynamo DB, which came out just pretty recently, they have a sort of No SQL store also that you can use. So, really just kind of across the board. If there's something you need, they have something that at least kind of does it.

So one thing that I've been wondering, because you brought up Terremark and EC2, but what about services like Linode or some of the other VPS providers? Rackspace Cloud is another one that comes to mind. Are those cloud, too?

I think so. I mean, obviously it is. Even within a context of our computing side of what cloud means, it's still pretty nebulous.

But, yeah. Most of the VPS providers have moved from being as clearly VPS-like to being something much more of cloud-like, it seems like. You know how they realize that that seems to be the winning model. So, there are many many competing providers here which does make everything even more nebulous because all of them are doing slightly different things; they try to differentiate frequently on features despite sort of trying to sell the commodity.

Right. So you kind of talked about -- I'm sorry I don't mean to hijack the conversation, but I'm a little curious. You're talking about kind of a spectrum between sort of the VPS provider and the cloudlike, is somethng you said? So what's the difference between the two?

Wouldn't it be elasticity?

That's part of it, certainly. And with a lot of the VPS's, you'd kind of end up signing up for plan that gave you a certain amount of capacity on a monthly basis and that was kind of it. And now, with most cloud resources, you get things on a minute or hourly basis kind of and not so much a month at a time. So there's some extent with a lot of VPS providers that changes come in the form of billing changes more than really infrastructure changes, most likely.

So, to kind of give a concrete example for that, last time I went and got a Linode box it was -- You agreed to pay x number of month and I'll give you a VPS that has these characteristics so you're on the hook for at least a month. Whereas -- where something like Amazon, you can fire up their API, enter a few things, and a server starts up for you. You start being billed based on what that server is processing, and then use it for the day or whatever to do what you need to do. And then make the API called to sub the SERP again and you stop being built at that point, right?

Exactly, yeah.

Which is pretty amazing, really. Because you can use something like S3 to store gigabytes of data and pay a tiny bill each month. It's cool!

Yeah.

As far as costs go, it seems like if you leave a server running on EC2 versus, just having a Linode that's up all the time...EC2, last time I looked anyway, was little more expensive. Is that still the case? I mean, what are the trade offs between the different models?

It's a little bit hard to say explicitly, just because there's a lot of different like -- well, partly because the way that Amazon lists their available sizes of things, it's hard to directly compare that to other things. But partly also, with reserved instances and other things like there are ways to mitigate that costs. But I think in general it is going to tend to be a little bit more expensive. So, you pay for that flexibility I guess.

Right. But if your spinning up a whole bunch of servers, doing a bunch of crunching, data crunching, and then spinning 'em back down, then EC2 is probably the way to go.

Yeah, I think so.

I guess it all kind of depends -- it depends on everything, really. [laughter]

I mean, the last shop that I worked at full-time had dedicated hardware, and they were paying -- I mean they had a dedicated box in a co-lo at, I wanna say Rack Space, and it was like a hundred and fifty bucks a month. And that was more expensive than spending seventy bucks a month for an Amazon EC2 instance, but they were locked into that box. There was no scaling. Although interestingly enough, 90% of the people that I have worked with that used Amazon EC2, they walk in -- they're still thinking about buying a big box somewhere, because they will get one instance, get a static IP for it, they never scale out beyond it, and so they're implicitly less WebScale because now they've only got one machine, they can't scale past that machine and that machine is virtual instead of having access to the iron directly. That's kind of what I meant by the elasticity was -elastic doesn't mean you click a button and you get your new server. It's this ability to fluctuate in your usability and your usage.

At the moment, Amazon gives you a Micro Instance for free the first year. So if you're just kind of experimenting with something, or if you just want a box where two people can SSH in and pair program over Tmux and whatever, that's a really a lot cheaper for -- at least for the first year than going with the Linode instance for instance.

Yeah.

Yeah that costs, I kind of looked into those a little bit and Wesley is right when he says it's just ridiculously complicated because there was like so many variables involved and the pricing in something like EC2, you can reserve an instance which gives you a cheaper price, but over a longer period of time. So if you know you're gonna use it that long, you're great. If you can do things like do Amazon's bid pricing basically, where you can offer at a certain price and as long as it's under that price you get to keep your instance, but the second it goes over that, your instance just gets shut down. So if your site can handle that, that may be an option! So anyways, the pricing's complex but you can definitely get it close-ish like maybe $20 on the Linode side with around $35 on the EC2 side [inaudible]. But, I think David really nailed it as far as like it's the flexibility. And obviously, yeah, it only matters if you take advantage of it. But being able to bring up another instance in that cloud, and use your same AMI or Amazon image to boot up the same environment or whatever, and then play with that image a little and see if the change you made is looking good, and then if it is, just click over to your elastic load balancer that Amazon also provides and point it back at instance instead of the other instance or those instances instead of the other instances, and then boom. It's an extremely flexible environment and you can script all of this. Because it's all just API's.

So, I was a systems administrator back when this kind of started to take off with the VMware and things like that, and I remember my job was actually provisioning a server. So I remember when I first started the job, we had a pack of discs we would take down to the data center and you would put the windows installed discs, or the redhat installed discs into the server and install it. And we had a standard procedure for setting it up, and then redhat got some scripts so you could basically put it in and say "I want to run these scripts". And then, on the window site, they came up with the provisioning server that you could just put -- you could put the server that you wanted to provision basically in the same rack, and then you would just say "provision it this way". And, redhat went kind of the same way except theirs was a little more complicated. And then eventually, we wound up getting these. We had a sun, and then we had these plate servers which were -- it's just kind of this mini-rack that you slide these, they call 'em blades, but they're just -- they're servers that are kind of like large cards that you slide in and out of 'em. And we would run several virtual servers on each blade, and those were nice because then you could just provision them from your desk because you just get into the VMware software and just do it. And so it has been really interesting to see it kind of move ahead from basically no automation all the way up to clone that server and put it over there, and then it's done. And see, you don't have to think about it anymore.

Like one of the cloud hostings that we didn't mention was RightScale, which -- I haven't heard anything from them, but they were really big like two, three years ago. And, they are the most elastic thing that I've seen out there because they make it really easy to put triggers on whether or not the server's being overloaded. So you go in and you sign up for an account and you basically say "go ahead and give me up to a hundred servers if I need them, but just give me two for now," and it will -- you've set up all the puppet scripts and all that and all the trigger scripts. And we went out and did that at one company and we came in the next morning and there were a hundred servers running. And like the CEO's freakin' out, he said, "Why do have a hundred servers running? Do you know how much money does this costing us?" And, what matter I looked at the servers, and they were all getting real-life organic traffic, and I said "they are being used". And the CEO went "Oh, wait hang on", and he pulled out his phone and called somebody downstairs and he said "Is today the day we got on Oprah? Oh.." [laughter]

So, actually the question was "do you know how much money does this making us?"

Exactly! This is the sound of us not getting slashed-taunted. Or wanged, or oprah-ed, or whatever it is -- whatever the kids are calling it these days.

I maybe wrong, but was RightsScale not just affirming to Amazon?

Yeah. They write scripts; they had this write scripts thing and -- a lot of, like in the same way that the Heroku backs on to the Amazon Backplane, except that Heroku now is kind of like a real thing that backs on to the Amazon Backplane where RightScale, I'm probably talking out the wrong side of my mouth here because it's been three years since I even looked at 'em but, but back then, it was transparent. I mean you had to tell RightScale which EC2 Instance size you wanted it to back on to? And so the other way is just a set of thin scripts and monitoring utilities on top of a EC2 and AWS, etc.

Isn't that more or lesswhat Engine Yardists do, though? They just kind of sit on top of EC2 and manage your Instance for you?

Yeah. All I know is that when Amazon, when their Backplane goes down every year for its annual crash, it seems like everybody else goes down with them. So, who knows?

The end.

So we've talked a lot about provisioning servers and we've talked a bit 'bout storage, or using the cloud for storing media. What other used cases are there for cloud services or what other types or categories of cloud services are there?

There's a pretty broad group of different things. But in terms of what is like widely available, in so much smaller set, so the things that, like numerous cloud provider seem to be re-implementing, is a much smaller set than the total number of different things available. And the ones that seem to be most common are obviously compute and storage, but then DNS Management is also very common. And it seems like Block Storage related stuff is starting to become very common. Block Storage being things like EBS on EC2, I thought Stimulator 21, and beyond that there's a number of database related services and load balancing related services. I'd say those are the most common. After that it gets into more EC2-ric thing so Amazon something kind of like RightScale that they themselves run.

The only one that may I add to that is Email. You think that's getting kinda popular?

There are certainly are a number of providers that do that, but mostly the cloud providers aren't doing it themselves, with the exception of Amazon. My house is using RackSpace or OpenStack to file and something for email.

Is Sengrid out there on the Amazon or they're doing it with that?

I'm not sure. I think they existed prior to Amazon's SMS, I think it is or whatever..

So I have to wonder then. Where,because it seems like some of this things you're kind of getting over toward SAS as opposed to Cloud, or is SAS just Cloud provided services?

It's a very interesting question. I think that SAS, in a lot of ways, is just Cloud + Usability, at least to me, that's what it feels like. Like yeah you could just get some raw Uct Boxes and set up everything so that WS and TP servers can have your own email service. But it's kind of a pain and it's difficult to maintain, and it's not what you want to focus on.

Yeah it seems like the Cloud sits one level below that, right? And it's more like pause, its platform master service scrippy?

Yeah. The thing that made me wonder where the difference was was that, it seems like there are a lot of services out there that provide like MongoDB hosting and RedHost hosting. So basically you set up your account and then you have access to a RedHost Instance running somewhere out there. And I'm wondering if that's a Cloud service or Software service? Or, does it kind of live in both worlds?

I don't know that it even really -- is valuable to make those distinctions to some extent. But, I think most people tend to refer about them as Software as a service rather than Cloud or whatever. I don't know. Coz it's much easier to make the distinction between Software as a service and Platform as a service, or Infrastructure as a service. But, I think you could easily make the argument that all of those AAS things are within the Cloud per view.

Yeah, makes sense.

If we go back to what Wikipedia said, Cloud computing is the use of resources delivered as a service. So, it could -- it really doesn't encompass all of those things.

If you wanna buy a big chunk and just sit on it, you can. If you wanna buy a little junk in scale easily, you can.

Yeah, there's kind of an interesting point of this whole thing, right? That we really haven't touched on is like, Amazon does this because in order to be Amazon, you have to have this instane infrastructure, right? So, what they do is they open that infrastructure up to the outside world, like "Here's all the ridiculous computing power we need to run, Amazon, plus some more because we have to be able on scale. So, why not you rent some time on our ridiculous computing structure or why not you rent some storage space in our ridiculous storage space cluster". So, yeah, it's about the resources that they're gonna -- but that's why everybody wins, right? Because Amazon's better at scaling those things than your real company, that's just getting off the ground at its [inaudible].

Then I get more boxes with smiley faces on them.

I think it's interesting that the cloud really is just arbitrary resources in this little unicorn, rainbow, fairly land -- this is an epiphany that's just hitting me now because I drank the elasticity cool aide. I was working in a podcasting company in 2006, and EC2 was still in data. You could only get 10 servers and you had to be on the waiting list. And we literally called Jeff Barr who was their technology evangelistic at Amazon and flew him out and showed him what we were doing. And he said "Oh! I'll have a hundred servers available for you tomorrow morning". And, what we were doing is we were putting audio, we were stitching audio ads on the MP3s. So, we would literally take your MP3, take your podcasters; so we would take, you know like the intro music that we use for Ruby Rogues. If we didn't have the intro joke laid into it, we would take the song that sounds like cryptonite, but isn't cryptonite because it's free, it's royalty free. We would take that, save that in the database, then you would record a podcast and push it to us. And we would take your intro music, and then we would stitch an audio commercial, and then we would stitch your podcast, and then we would stitch another audio commercial at the end. And we did that for every podcast in our system every single day. And so, what we liked about the elasticity at that particular shop was that for two hours every night, we could have infinite resources available to us. We could have infinity computers and infinity queue size and storage and all the stuff. And then as soon as everything was processed, we could then go "Okay, let's go back to one tiny little web server at one little database, okay, and a really big disc to store all these podcast on". But yeah, I'm just realizing that I've been frustrated with Cloud Computing for the past six years because that's the last shop I ever worked at that really did, with the exception of that Oprah accident, that's the last shop I worked at that really used the elasticity the way I thought it should be used. But if you look at it, it's just its service if you can get it, then cool. I guess that that's -- you guys have polluted the definition! I can't say that and still be angry. There we go. Preservation of anger, that's important.

[chuckles] Unlike what you said there that about how you effectively infinite storage, that's like basically S3, right? S3 is effectively and infinite hard drive. If you keep piling on data and paying Amazon more money, they'll add more hard drives before they run out, right? So

Well it is momentary. That's the magic. It's momentary; is that you can get infinite resources for an hour and then walk away.

Right. And that, as Jack was saying when he was talking about like old hardware where you know, re-drop these servers in some kind of rack or something, the other option is you're running out of some server somewhere and you want that to scale up, you give a call to these people and you feel really lucky they can drop some new hardware, and maybe today, maybe tomorrow, and hopefully you may have an hour down time or so, or something like that which is...

Right. Do you start troubling or finding other ways to handle the traffic instead of just being able to handle the traffic, just put more hardware behind it?

We were checking and working our contract with a fantastic company and we love 'em -- we love them more than we like cooked food. Well no, more than! Because we buy cooked food and we buy other things, so we do literally love them more than cooked food.

And I joke, though using SQL server, and I -- not a huge fan -- and I joked about that we're doing normalization on the database, and I joke that we have to normalize SQL server because we paid so much for SQL server that we can't afford disc space.

And they laugh and the DBA gave me an annoyed laugh. And this morning, the SQL ran out of disc space and I've been very careful not to mock them because they have to buy custom special hard drives for it, because I guess you need special microsoft hard drives or something like that or so.

Yeah. SQL server is not WebScale.

Yeah. And we're really needed to talking about the cloud rather me just ranting about SQL server. But, well no! Actually this time she's on it really well which was SQL server is big iron. And it's not a Cloud, it's not a service that you can just pick up. You have to go get it. You can have, just as like James said, you can have as just much storage space on SQL server as you want, but you have to pay for it and you've got it forever afterwards whether you need it or not.

So Wes, when you're provisioning like an EC2 instance, do you have preferred tools for doing that? Chef or Puppet or something like that?

So, the majority of my experience having worked on this, but the engine you heard on Heroku is been that, mostly other people don't look that hard and I'm mostly just focused on the actual provisioning part. At Engine Yard we did mostly is Chef to manage that...

So is that technically a different stuff from provisioning? I'm not super clear on which part provisioning is.

So for me anyway, I usually would say that, for me my goals with Fog, or basically just to encompass what I see is the provisioning stuff which is getting, at least on the compute case, getting a box up and running. And once that's running like actually turning it into whatever configuration you want or whatever it is, is a separate concern.

So you don't have any particular preferences. Next is, I have another question on related to that. So, the topic recently came up on the Parley mailing list: what would I use if I'm just starting out? I wanna throw my first app up there, my first Rails App up there somewhere on the server, what would I use to host it? And the answer that came back from everyone was obviously Heroku. And, that seems to be -- for good reason -- the community to fault. But I'm thinking, let's say I am a novice Rails programmer, and I am inundated by all the different software as a service things out there, you can get anything as a service these days except possibly your actual app domain logic, or they can probably get that as a service, too, I don't know. [chuckles]

Like do I follow up on all those different -- for the email sending and for the, I don't know -- there are so many different things that I could -- the logs and logging, and everything. There are so many different things that I can sort of push out to this service. When I'm getting started as a novice Rails programmer, do I pursue all those and try to understand all those services or do you think it's better to try to do those things with -- get a Heroku instance, but then do those things the sort of traditional way and then add in those cloud services later? Do I write my app to assume that practically everything that isn't pure app logic will be handled by other software as a service -cloud services? Or, do I write my app and originally to do things internally and then factor those things out later?

That's a really good question.

Yeah. I would, like for me personally, I would just as soon do as little on my own from scratch as I can possibly manage. Like I would much rather focus on what my app is, kind of like you said I

think. You wrapped it up really well by saying "you can get pretty much everything but your app logic as a service". So for me, like why not just get it as a service, right?

So you'd say for a novice to go ahead and invest the time and understanding the different services that are out there?

Yeah. I think that the amount of time that you have to invest in like understanding what are particular software as a service version of email sending provides to you and how to use it, like the amount of investment that you need to make to get to that point is much less than figuring out how to spin up an EC2 box and set it up to be an SNTP server and so on and so forth.

Okay.

I think that's actually pretty accurate what was just said. I mean, I don't know if you have saw, but Instagrams been doing a really good job of releasing lots of detail about their technical set up and it's been written up pretty heavily. And they basically claim that they never could have got where they got had it not been for the ability and the leverage of the Cloud. And some of these articles are linked to one of my favorites in the share-a-notes, but they also have a Instagram engineering blog. By the way, that's pretty good and often adds new details, but if you'll just look through here...

I'd love to push back a little bit...

Oh okay go ahead..

If you're a Rails novice, I think it's really useful to just do Rails sort of blindly for a little while. Just follow all the conventions, make your little mailer, don't worry about MailChimp or MailGun or don't worry about figuring out those types of queues and all these other services. I think it's really useful to just see what Rails actually does and learn some of the idioms. And then if you find that your app has really complicated needs that are better served through another service, that's a great time to start figuring out those other services. But as a novice, it's really overwhelming to try to get your head wrapped around everything all at once.

It's Leaver's Law, right? I mean, everything the system does for you, the system also does to you. And so, it's like 3 years ago in Rails, all we talked about was "should I roll my own authentication or should I use a plugin?". And, it was almost a holy war. And so, yeah, the short answer is you should know how to do it yourself and you shouldn't have to do it yourself. But to get to that point, you have to do it yourself and you have to try pulling in a service to do it. Does that make sense?

Yeah.

It does. But I think that you don't always have to experience pain in order to realize the value of something or to find a better way do something. But I do think that with, in particular with rails, there are a lot of things to understand - a lot of things to understand. And as a novice, I think it's really helpful to just go with, sort of just follow the steps and not worry about the extras until you just kind of see how will everything is sewn together and then expound on that.

One other thing I wanna throw in here and it's much more along the lines of what Katrina is saying is that, with the cloud and everything else, again if you don't have to be the expert, why should you? I think eventually you wanna get there, but yeah, being able to focus on just one thing, it really makes a lot of sense. So you go with Heroku and then once Heroku is pain, meaning that your one Dyno that you get for free isn't enough, or your service isn't working the way that it should and you know somebody else has solved the problem, yeah that's when you spend the time to go and solve that pain. Unless you're just interested coz there is that, too.

I think I really agree with what Katrina just said, but I guess where I was trying to go with the Instagram thing is that -- what happened is, in Instagram's early days they had like 3 engineers who are scaling up the site and they were doing it on Amazon's Cloud. And because of that, that brought them a lot of advantages like "sure, you're first to write the app, you put it out there, you do everything as been now as possible". But then at some point, you're going to need road back [inaudible], right? So you can put up 3 used servers instead of 1 and bounce traffic between them. And at that point, you've got several ranges of options from custom setting up your own server and stuff which point you can probably tweak it to be the best load bounds or for your set up, if you really want to get in and do it that much. But, the Amazon makes it where -- with a few purchase of a button, you can get a load bounds or in friend of your instance says that it's real reasonable, right. Maybe not the best set up you could have, but definitely good! And, I think that maybe eases the scaling up of these things, right? Of how do I worry about DNS now, they were gonna need to do some DNS tricks, so Amazon has servers for that, too. And, it seem like the engineering team at Instagram was saying "it was because we were on at EC2, that we weren't able to ease the end to this things," right?

Yeah.

So I wanna change the direction just a little bit, and I wanna ask specifically about Fog. Now, I'm not gonna ask about the API or anything, except that I'm wondering was Fog written to solve certain pain points with Cloud Computing? Or was it written more to provide a comment interface for provisioning across several different Cloud providers?

It has changed in its purpose from when I first started, I think. But, it's encompassed both to those at different times. When I first got started with it, a lot of it came down to they're just not being a good library support yet and review for a certain things that were just coming out, like starting day zero I wanted to be able to play with certain things and I just couldn't. So, one of the very first things I'm employing on it was actually simple DB for Amazon which is a No SQL store. And then, having done that, I wanted to have S3 support. And I found that some of the, at the time, existing Ruby S3 libraries were, I felt lacking. They were not really very well supported so a lot of them have been updated in 6 or 8 months since some of the code I felt was a questionable quality. So I wanted to have a better foundation for doing those things and then I did EC2. And so for a while I was actually all Amazon services that I just wanted out better tools to use. So that was when I was dealing with the pain point which is not, in my opinion, always haven't good library store with Amazon. But then from there, I built enough curiosity and knowledge around Cloud stuff that when RackSpace started, many of their offerings I was curious to see what the differences were and how they compared, and so then I added them. But at that point everything was still very raw, very close to the metals, or very similar to their APIs. And after working on both them and parallel for a while, I quickly realized that it was incredibly difficult for me to keep track of all the discrepancies between the two, by the lone somebody that hadn't spent all that time with them that I had. And so from that, I'd created a new pain point for myself and so then I started undertaking also fixing that pain point.

So, now that things have kind of evolved and matured a little bit, what are the pain points that people are seeing now with putting stuff on the cloud or moving to the cloud from just having a server in a co lo?

It's really a good question. One of the big things I think that comes quickly to mind and I think it's kind of a corollary to the scaling thing but maybe one that people don't realize until they worked on the space for a while is the idea of transience because in the Cloud, that's much more the case. Like it isn't really that you have a particular server that you will have indefinitely, it's that you have a

particular amount of compute power that you will have indefinitely. But there's a lot of power and thinking that that compute power might change into a different server like the actual materialization of it might be different because there's a lot of cases where I would argue that you're a lot better off just killing your old server that's misbehaving, and spinning up a new one to replace that than necessarily taking the time to debugging, somehow fix that old server. And that also if you really can do that, it aids on actually doing like big scaling quite a bit because the servers themselves become much more interchangeable and a lot easier to work with. With there's a big mind such change to get to that phase that is a lot different from just "oh we'll do this in a way that it's more elastic."

I was actually gonna ask you about that. Do you see more of a move towards fault tolerance? I mean it goes right hand in hand with the transient, right? I mean if the server just goes away, you can't lose that server's work.

Right. I think that the Cloud stuff definitely facilitates fault tolerance, but it doesn't, in many cases, take care of it for you. Which is why, like it's one of the reasons why I ended up moving and just start working at Heroku is because a lot of the things that Heroku does actually take care of that stuff for you. Like Dynos were actually very transient. It's pretty transparent, tend users that they're very transient most the time, but Dynos can't come and go because maybe we wanna do a security patch or whatever else we can just sort of you know transparently swap out your Dyno and not really have any impact to end users.

So, I guess my next question is: are there instances where you would recommend to somebody to move off the Cloud and into a colo?

It's hard. Most the cases that I hear that are related to that usually have regulatory reasons more likely than necessarily typing core reasons.

That makes sense. We secure few things like that.

Yeah. Like we have to own the entire box like we have to know that nobody else can physically beyond this box. But outside of that, I haven't heard too many cases that are like that. The other big one has cost, but that's a really hard argument because like, as we discussed earlier with EC2, it's so hard to have a sense of what you're actually getting for that money versus what you're getting in in colo place. Because with EC2, they can spin up a different server that you could put your stuff on to, whereas in that colo, it might take quite sometime to do that. And though transparently replace hard drives that fail underneath the covers for you in most cases stuff like that, colo is just aren't going to offer. And the hidden implication there being that they have all of these experts around that know about this stuff that are basically working on your servers on your behalf, that you aren't explicitly paying for.

Right.

I think there can be some pretty heavy differences and scenarios like GitHub's needs for example. You know GitHub is really sewing a kind of infrastructure, right? And they have very specific needs as far as like being able to get information from gitrepositories which implies certain things like you know how fast they can talk to something stored on a hard disc somewhere, etcetera, right? And I think in those scenarios, they eventually moved away from the cloud to a very server-oriented facility because that's one of those million-dollar cases where the fine tuning probably is way worth it.

Yeah. And it depends, too. Like I don't know everything about that situation by any means, but it may be possible that there could have been re-architecting that would have made it work okay on the Cloud. And to some extent that's a special case also because they're big enough that it's likely that any cloud they went to had bend over backwards to accomodate them, or any colo for that matter. But, the colo's are more like that they bend over backwards in the Clouds. The Clouds are mostly kind of like "well here's what we have; you can use however you want but we'll add things as we add them.

Yeah one other thing that came to mind when we're talking about colo's versus clouds is that in general, the colo, you're putting all of your stuff in one data center. I mean, I've worked for companies that spread their stuff out of cross-multiple colo's, but it's seems like that's much easier with the Cloud. So you can set up servers across different locations with an Amazon's cloud for example. You can go East Coast, West Coast, and you have a few others -- a lot of these other ones is like "pick which data center you wanna put stuff at in". I mean even Linode, when I spun up a new instance the other day, there were like, "where do you want this hosted?" And my one server was in Dallas I think and so I said "well, put this one in Atlanta". And you know, they for the most part, can talk to each other seemlessly, I mean it might get a little more late and see if it's East Coast to West Coast talking, but you can distribute more easily. With the cloud, it seems the new can and colo's because you got the provision space in each location if you're in a colo.

Yeah.

It doesn't seem like a lot of people do that, though. Like when Amazon's data center in Ireland got hit by lightning or whatever it was, a lot of sites just went down.

Yeah it's true.

But if you have a backup system in another location than in a lot of cases, all you have to do is change your DNS. And sometimes you can even setup systems do that seamlessly and...

You'd think that! You'd think that wouldn't you? [laughter]

How come everytime Amazon East Coast's down, half the internet disappears got it?

It is true; it's very true.

Well, it depends. I mean, it's easy to relocate your computing power but it's very difficult to relocate data.

Yeah, that's -- you've gotta have those databases perfectly in sync and yeah, it'sa none trivial power I think.

I worked at one shop that had everything in RackSpace and everything also on rights Right Scale whice is a nightmare bacause we kept wanting to write RS on things and that gave you no information. [laughter]

So we basically have asked and risked on everything for RackSpace and RightScale. And the data, yeah, I came down to the problems -- the two problems we had were the front and the back end of the chain. We at one point very briefly, had my SQL replication working between two servers in RackSpace and then over the colo boundary into RightScale and then Bucko, it was a master master ring replication. And it stayed up for about a day before the databases got corrupted. So yeah, the data became a problem. But the other thing that we had was the -- all of the balancing in DNS stuff was in RackSpace. And this was 2009; was when Rackspace had their Dallas colo blowup. In order to transform its blew up and then litteraly took out a floor in their building. Like litteraly punch a hole in the floor that was like 20ft across...

See I have that happen to my home office all the time.

Well yeah. So me, too. But that's more of a mad scientist makers of such kind of thing. But the problem was it's that all of the stuff that we needed to switch away went down with the data and the processing power. And so, eventually you have to put some eggs in a basket and then you have to watch that basket. You eventually reach your point where you cannnot perfectly distribute all these extra cross-multiple app baskets. At least as my theory. Boy! We probe Wes on here! We're telling him a lot about his job, aren't we? [laughter]

So, let's go to Wes now for rebuttal. Am I full of crap?

There are parts of it that are much harder to deal with another parts. And it all depends to you because there are technologies that make some of this easier like during the kind of distribution you're talking about with some No SQL store such as Dynamo. Well, I guess dynamo isn't immediately available to us but something like Riak can do that distribution in a much sort of more straight forward way. But actually using it on a day to day basis is much less straight forward, like it's not a way that we think about things. We usually think about things in a more SQL-like modalities, though. So I mean, I think part of it is that problem kind of like the transience thing like there is certain minds that changes that we could work with her data anyways that would allow us to distribute it more, but like that's a big minds of change and a big shift so --

Yeah.

Alright. Well, we're getting close to our time limit. Are there any other aspects of the Cloud or Fog that we wanna go over?

What's the coolest part of your job, Wes?

So, as of recently I've become in-charge of the API for Heroku, which I'm working on polishing up and trying to make into a more publicly accessible more consistent things so that people can do awesome stuff on top of it.

Is this the thing that I talk to when I type Heroku and then some staff at the command line?

Exactly, yeah.

Cool! Okay!

Previously I worked on the CLI which was sending a lot of this commands on most people's behalf. And now I'm working on the API itself to try to get it to a point where you can, feasibly just say "Hey everybody! Here is some API plans and here's some good documentation" unlike "Go do things with Heroku that we never even imagined".

Cool!

And so I'm pretty excited about that. We have some more to do still there. But I think there's some amazing potential for, kind of like I said, like all these things that we have old, the two line there that you can do stuff with. But that we, inside the company don't have the hours in the day o imagination or whatever to come up with. So --

Is there a new used case that you're allowed to tell us about, that's new and exciting incoming?

It's a good question...

It can be something that you've seen or not...

I mean, one of the I guess more obvious one has just to with handling-scaling automatically, which is always as fantasia. But it's very difficult to do on a way that it's universal, like because different people use cases are much different like some people are eeyore bound, some are memory bound, whatever. So it's hard to know what thing that you need to watch and once it hits a certain point that you need to add extra capacity. But with the API being open, the way that we hope that it will, it's much more feasible that you could watch you're on metrics as they came out of your app. And if you knew that a certain thing indicated that you needed to add extra capacity or that you're at a point where you can remove capacity, could just take care of it yourself, which I think is pretty powerful. And I think there's some other things like coming down the pipeline in terms of making the easier to do, seemless deployment, and possibly to do AB testing and to manager, staging, and production environment and things like that. For the most part, a technically feasible using that Heroku command line, but aren't always the easiest. And in a lot of cases, go back to the same problem where it's difficult to come up with a universal solution that would work for everyone coz everybody does these things slightly differently.

Yeah. Cool.

That's cool. So I have to ask, your API is gonna get you a little point where you're gonna be like the Twitter of hosting? And when you get that big, I mean you guys are already making money so I guess you're ahead of Twitter on that count, but --

Ouch!

I have to ask, are you gonna start limiting the number of users that people can have on their apps?

No. Because of the way that things are routed and stuff if you have minutes like Mustangs, if you have a lot and a lot of users like the weight and seed of the individual users, seed will tend to grow old on that getting queued by in each other. But if you add capacity to that, then the through of it can follow. So, we found a lot of great cases where people spun up apps bacause they were gonna have an ad on SuperBowl or something, right? And so they like just added a ton of capacity so we go through just fine and then we're able to scale it way back down afterward. And then next thing in my mind from having done a lot of this cloud subdirectly and now working at Heroku is that, there's all this stuff that Heroku just takes care of that you don't realize it's a pain in a butt unless you had to do it yourself. But, it's nice to not have to worry about a lot of that.

Yeah. Makes sense. So one last question, I've always been curious about this. But this Heroku used their own infrastructure for their management app, you know where you sign in to Heroku and you set up new apps and all that stuff. Is that all running unlike Heroku Dynos just like everything else that we put on there?

We have a lot of stuff running on for a few dynos, but not quite everything. Some things are much harder to do that with another's. We're moving more and more towards putting more things on to Dynos, so the grand tradition of sort of dogfooding, as much as possible we try to figure out what are the services that we're running internally that for reasons as for why we still can't quite put on to Dyno. And then, that's one of the things that informs us as we figure out what the new features are that we're all up.

I think there was a really good talk about -- was it Aloha Ruby Conf maybe where there's running Heroku on Heroku or something like that?

Yeah. I think Noah did that...

Yes, there was it. Aloha Ruby Conf, it was running Heroku on Heroku, and it was, bang! There were a zoosky, was that any thing?

Yeah, so internally we refer to it as the self-hosting singularity. And much like the other singularity it's something that we foresee happening at some point, but we're not quite there yet.

So this makes me really curious. What kinds of things can't you run on that Dyno?

He goes into that, in the talk about why parts of it are difficult and stuff. It's well worth watch for that video.

Okay I will refer people to the video then, and we can go ahead and into the picks unless there are some other present thing we need to talk about.

Well I can drop just one really quickly which is basically that the only thing you can't route to a Dyno is HT2D traffic. So, if you wanna do anything that's over other protocols or not just HTTP, you can't do it on a Dyno currently. So that's one of the big ones and something that we hope to address, but have not addressed publicly yet.

Cool. Alright. Well thanks for coming Wes. Let's get into the picks. Should we make James go first?

Sure, I've got a couple of easy ones this time. When I looked on mountain lanes, some of the changes and the way that a rest handles virtual spaces, which I cannot live without, were good and bad. The good was, I loved the way apps get their own virtual space when you full screen them. The bad was, I lost the 2D layout of spaces, which I'm ain't on after that, actually bothers me because I would have it set up as a 2 by 2 grid. And then no matter which space I was in, it was only able one move to get to the next space because I can go down or way toward back which would get me to the one at the end or whatever. So, I had this kind of system and I really missed the 2D aspect of spaces. Anyways, if you're like that, there's an app that takes care of that for you now. It's called "Total Spaces", and it puts the grid byte structure back in spaces. And then, for something fun, since curious mates and probably a lot of us who are doing shopping and stuff but -- just I saw this Tuesday and thought it was just a great hut. It's a tumbler about a person that built a bot that randomly goes on Amazon and written -- given certain reminds, buys things for him. And so he sketched these random Amazon shipments that show up with things that the bot decided to buy for him, And then he will talk about what was on that shipment and -- well that's weird or "Oh! Hey cool! I would have never known about this reddish bud thing". I always thought it was a super cool kind of life act of a kind of beneath with and get outside your bubbles. So, fun idea to work through and just get inspiration from.

You've seen the xkcd about that, haven't you James?

No, I haven't.

I don't know if Randall Munroe really did this, but he drove, I'll put in the Show Notes, he drove an xkcd. He rode a bot to basically -- he gave it 30 bucks and $365. And every day, it would try to find something for a buck with free shipping and send it to him. [laughter] DAVID: And it's supposedly sent him an empty gas can, a ski mask, a shovel, and like on the fourth day he turned it off because he said "I turned it off before I ended up on every FBI watch list ever. [laughter]

Hey, and that's how Randall started his life of crime.

Yes.

Awesome. David what are your picks?

I just got one today. For somebody who doesn't have a lot of time for reading, I sure seem to be doing a lot of reading lately. And if you followed my picks at My Book Picks in the past, you know that I'm really interested in books about happiness and about psychology. And I finally cracked open "The Happiness Project" by Gretchen Rubin, and I can't recommend this book highly enough. It's fantastic. It's just her documenting a year of resolutions that she made that would try to make her happy. And one of the surprising things that she found early on was that, things that made other people specifically happy were more likely to make her happy than general principles that are known to make everybody a little bit more happy. And that's why she ended up writing the book which she decided "I'm gonna tell you exactly what I did and how it worked and what didn't work for me because my experiences that this is more likely to make you happy or to give you ideas for what will and won't work for your own happiness project". And, I'm about halfway through it. It's very obvious that she comes from a legal background and that she did a ton of research into this book because I'm listening to it on audible right now, and I'm gonna have to buy the hard copy so that I can mark it up because she would just dump lists of information. I don't recommend it for audiobook, unfortunately, but something that you can read with a highlighter and stick post its all the way through it. Just fantastic! The Happiness Project, Gretchen Rubin, highly highly highly recommended.

Terrific. Katrina what are your picks?

I've got three today. The first is sort of, because we did the cloud computing thing, it's powerof60.com. It's 600 hours of Amazon compute services for free. So if you just wanna play around and kinda get a grasp around what it might be able to do for you, powerof60.com. The second pick is just kind of a general thing that I keep going back to and that's ofthesource. Just have ofthesource handy. I have macro that takes me straight to thesource.com ready to tylpe in whatever the word is. This is just really good when you're trying to find a more accurate name for a very bullet per class. Just look up the word and kinda word surf until you have something that expresses it really accurately or precisely. My third pick is wordoid.com. So this is also for naming things but it's -- when you need a poetic or expressive name for a project or a gem, and you need something that kinda suggests a topic but doesn't actually mean anything. So wordoid.com will also check the dotcom and dotnet domains to see if that they're available and not showed up straight away. So as examples, the first word that came up for me today was "exceptacle" which I just thought was really really funny. I've used it for a bunch of things I have -- a project, or I'm involved in a project called "drumquick" which I just thought was the coolest word ever. I've made an app for etsy users to do their reporting, meaning a friend, and we call it "metricore" which is also came off of wordoid. Other things that made the gem called lamedo later which just munges IETN files. And I made norwidgets which is a gem that takes English and generates reasonable looking Norwegian, of course with a command line binary. So yeah, wordoid.com for fun, poetic, expressive names that mean absolutely nothing.

I just wanna say "reasonable looking Norwegian" is the name of my next band. [laughter]

Alrighty. Avdi, what are your picks?

What are my picks? Let's see. I recently replaced my development machine for the first time in many years. I got a Lenovo X230 laptop and I'm very very happy with it. It's pretty awesome machine. If you're looking for for a developed at a very portable, not quite ultrabook, but very portable machine that has very high specs for its size and runs Linux really well, the X230 is pretty great. And for a less technical pick, I'll just pick one of my family's -- our family's favorite YouTube channels which is Epic Rap Battles of History. Every guest we have to disc this and they always love it. And there are actually two channels: there was the Nice Peter channel which is they started out on and then they spun off an actual channel for the rap battles which is called ERB and, I'll put links to both those in the Show Notes. But some particular ones to look up, the first Adolf Hitler vs Darth Vader, it's pretty epic. The Chuck Norris vs Abraham Lincoln is great as is Master Chief vs Leonidas.

It's nerdy but I really love the Keynes vs Milton. - [laughter]

That is not theirs, by the way.

That's not theirs? Okay..

No -- no, totally different people.

It's also very educational.

Yeah. The Keynes vs Milton was made by some economists.

Oh okay. Okay.

But, yeah the Epic Rap Battles, they're actually -- the tunes are great and it's surprising when you look through them. Just how many relatively obscure references they managed to cram into the raps!

That's funny. Alright Wes, what are your picks?

Sure. I've got a couple. The first I'd just say is actually where I live, Iowa City, which I feel like I always have to defend at some extent because people are always like "You live in Iowa? Why would you do that?" But it's a a great town. We have a small but pretty great text.scene, we have machine-learning computer vision made up, we have ruby and javascripts made ups. Like just lot of stuffs going on, a lot of great culture, and other things. So, definitely a fan. The other one which I've just been planning like recently is called iFleet. And it's a tools for using your phone to measure heart rate variability. And so, the idea with heart rate variability is, as you breath in your heart rate increases slightly, and as you breath out it decreases slightly. And that's caused by the interaction between your parasympathetic and sympathetic nervous systems. And depending on how stressed out you are basically, the sympathetic nervous system can kind of take over which would mean that it will acceletate more quickly than it will decelerate. And so, HRV is a way of measuring basically which of those whose in prominence, which is an interesting measurement of basically how stressed out and tired you are. So as someone as like super interested in quantified-self stuff, I found it really interesting to see like how rested and stressed am I today. And so in particular, they talked about using it for elite athletes so that they can figure out when they are on their way to over training so they can avoid over training. But I am not an elite athlete, and so far I have just been using it to see like "am I getting enough sleep?", "did I -- am I pushing myself too hard?", like "how am I doing today? do I need to rest?". And it's been super interesting for the week that I've had it. So --

That sounds amazing. Unfortunately, I know what it's gonna tell me.. [laughter]

There's some great studies on that kind of stuff, Wesley, showing how heart rate variability dramatically affects things like people's will power. So when it's on a whack, you have much less will power to resist temptations and stuff. You get worst on your diet or things like that. It's pretty cool stuff.

Yeah it's pretty fascinating. There's a bunch of really interesting studies and stuff around it all so and so. I was pretty pumped to see that or an investment of maybe about a hundred bucks so I could have an app on my phone that I could put on a heart belt in the morning and actually get my HRV for the day so that I can actually see how it's tracking overtime and see whether or not it's gonna get range drip or moving into a bad range and that's for a thing.

Yeah, it's awesome! I wonder how it's -- it compares to like to Fit Bit or whatever. Anyway, so I'm gonna give a couple of picks. This last Friday was my birthday and my wife bought me tickets to go see The Hobbit, and the movie was awesome. So I'm gonna pick the movie, but more than the movie, I'm going to pick the soundtrack. The soundtrack that you can get at the store is not the same as the soundtrack you can get on iTunes. You can get a special edition that has some more tracks on it from the movie and that's the one that I recommend that you go get. So I'll put a link in the Show Notes to where you can go and buy it on iTunes, and yeah, go see the movie. It was really really good. And that's all I have for this week. So, just to wrap up, go sign up for Parley. You can do that at rubyrogues.com. And, thanks for coming Wes, it was awesome.

Yeah, thank you!

Hurry up and end this episode! It's interfering with my reading of Wordoid.com! [laughter]

I bought 7 domain names already.