Developing Perspective

00:00:00 ◼   ► Hello and welcome to Developing Perspective.

00:00:02 ◼   ► Developing Perspective is a podcast discussing news of note in iOS development, Apple, and

00:00:06 ◼   ► the like.

00:00:07 ◼   ► I'm your host, David Smith.

00:00:08 ◼   ► I'm an independent iOS and Mac developer based in Herne, Virginia.

00:00:11 ◼   ► This is show number 112, and today is Friday, March 8th, 2013.

00:00:16 ◼   ► Developing Perspective is never longer than 15 minutes, so let's get started.

00:00:19 ◼   ► All right, so today I'm going to be talking about servers.

00:00:23 ◼   ► I'm going to be talking about the server infrastructure that I use, why I use it, and some of the

00:00:28 ◼   ► lessons and things I've learned there. But before I get into my actual setup, I just

00:00:32 ◼   ► want to respond to yesterday I mentioned online that I was, you know, going through this process

00:00:37 ◼   ► of, you know, building up and establishing my server infrastructure for the my recipe

00:00:43 ◼   ► book sync is infrastructure that I'm about getting ready to roll out in the next couple

00:00:48 ◼   ► of weeks. I had a couple of questions like, Oh, how do you do that? Oh, what does that

00:00:51 ◼   ► look like? And you know, make your blog post. And I just wanted to say, and sort of explain

00:00:57 ◼   ► why I never blog about that kind of thing, or why I never put out the exact details of

00:01:01 ◼   ► exactly how I do it. And the simplest version of that is that anytime you do anything that

00:01:07 ◼   ► is a specific prescriptive sort of how to, something technologically based, the moment

00:01:12 ◼   ► you hit publish, it's already out of date. It's already got all kinds, you know, things

00:01:17 ◼   ► are just always changing. There's, you know, there's lots of components, there's lots of

00:01:19 ◼   ► things going into it. And then every time you publish it, it's just going to keep getting

00:01:23 ◼   ► more and more out of date. And that's the first part. And then the second part is that

00:01:30 ◼   ► everybody's needs are slightly different. And as a result, there's always these little

00:01:34 ◼   ► nuances and tweaks and changes and things that people will do that then cause problems

00:01:38 ◼   ► or incompatibilities or questions that, you know, the logical thing is if I'm putting

00:01:42 ◼   ► out a guide and saying, Hey, this is a way to do something, that there's a certain implied

00:01:47 ◼   ► warranty that I'm doing with that and a certain obligation, not strictly, but an implied obligation

00:01:53 ◼   ► that I would help people who sort of navigate that process.

00:01:56 ◼   ► And that's just a tremendous amount of load and complication

00:01:58 ◼   ► that just isn't something that I can take on.

00:02:01 ◼   ► So that's why I never kind of really get into the weeds of how I do things

00:02:03 ◼   ► technically.

00:02:05 ◼   ► Similarly to why I don't publish a lot of coding how-tos or things,

00:02:08 ◼   ► because the problem is if you put that out there and you say,

00:02:11 ◼   ► hey, this is a cool thing that I did to learn whatever, now all of a sudden

00:02:16 ◼   ► there's a lot of weight that gets carried along with that.

00:02:20 ◼   ► Rather than talking at a high level-- and this

00:02:21 ◼   ► is what I love about doing a podcast, is I can talk at a high level about something,

00:02:25 ◼   ► give you pointers, give you direction, and hopefully that's helpful. And then, you

00:02:30 ◼   ► can go in your own direction and sort of be more self-sufficient in that way.

00:02:33 ◼   ► I don't know if there's an exception for something like an open source project or something

00:02:37 ◼   ► where there's a bit more stability about it, but just for something like lightweight,

00:02:41 ◼   ► this is how I do it, it doesn't work quite as well. The line of things, I did want to

00:02:47 ◼   ► mention something that I've had a lot of people talk, "Oh, I'm a bit nervous getting

00:02:50 ◼   ► into the server side, I don't know exactly what to do, you know, can make and rec making

00:02:54 ◼   ► recommendations. And a timely one is RailsCasts, which is by Ryan Bates. And it is a amazing

00:03:02 ◼   ► resource. It's basically a series of screencast tutorials about rails. And obviously, if you're

00:03:07 ◼   ► not interested in Ruby and rails kind of thing, it may not be your quite your cup of tea.

00:03:10 ◼   ► But if you've ever wanted to get into that kind of thing, it is he is very clear, he's

00:03:14 ◼   ► very straightforward. And he's just a legend. Like I mean, he is very good at explaining

00:03:19 ◼   ► something in a way that makes a lot of sense. There's a lot of kind of how to's in there,

00:03:24 ◼   ► that he has the benefit of I being that's what his profession is. So he has the ability

00:03:27 ◼   ► to go back and revise and update them. And there's also a comment section attached to

00:03:32 ◼   ► each of his tutorials, which often has a lot of great feedback where if someone has a problem

00:03:36 ◼   ► and then finds a solution, they'll often post it into the comments. And so often, you know,

00:03:40 ◼   ► I'm working on a particular infrastructure or something. If I go into the comments about

00:03:44 ◼   ► the place that sort of sourced the idea, there's almost always a solution to the problem that

00:03:48 ◼   ► I'm running into, which is great. And I highly recommend that they'll be only in the show notes,

00:03:52 ◼   ► but it's just real rails cast calm. And that's actually where I got the idea for what I'm going

00:03:57 ◼   ► to talk about for the rest of the show, which is kind of how, where I've been heading in terms of

00:04:02 ◼   ► setting up for server infrastructure and how I manage that. So right now, and this is just sort

00:04:08 ◼   ► of the way what I feel comfortable with, it doesn't work for everybody. There's a lot of different

00:04:12 ◼   ► options and a lot of choices. But right now I do almost all my hosting on Linode, which is a

00:04:16 ◼   ► virtual private server provider, they do basically your leasing

00:04:20 ◼   ► virtual Linux boxes by the, I don't even know, they price

00:04:25 ◼   ► monthly, but you can come in and out of however you want.

00:04:27 ◼   ► Basically, you know, means that I have virtual servers that are,

00:04:32 ◼   ► in my experience, very, very reliable and very performant, or

00:04:35 ◼   ► is performing enough for what I want. And are just kind of work

00:04:39 ◼   ► work really well, they've actually been doing some recent

00:04:41 ◼   ► updates and making even better and make their pricing even more

00:04:44 ◼   ► competitive.

00:04:45 ◼   ► That's kind of how I do it.

00:04:46 ◼   ► And a typical sort of setup that I have for them

00:04:49 ◼   ► is that I have an application load balancer in the front,

00:04:53 ◼   ► which Linode provides a service called Node Balancer, which

00:04:55 ◼   ► is just a $20 a month add-on that you can put in front

00:04:59 ◼   ► of your boxes that will do load balancing for you, which

00:05:03 ◼   ► is nice and convenient.

00:05:04 ◼   ► And in my experience, it's been working really well.

00:05:07 ◼   ► Behind that, I put a series of web servers running.

00:05:11 ◼   ► Right now, I'm running Nginx and Unicorn,

00:05:14 ◼   ► which is kind of my front end and Rails processor, whatever

00:05:18 ◼   ► you call it.

00:05:19 ◼   ► And then in the back, I have a database,

00:05:22 ◼   ► which is right now Postgres or whatever you want to call it,

00:05:26 ◼   ► running in the back.

00:05:27 ◼   ► And so that's very straightforward, classic web

00:05:31 ◼   ► hierarchy.

00:05:32 ◼   ► A load balancer in the front, you kind of have that diamond.

00:05:34 ◼   ► The load balancer in the front stands out

00:05:36 ◼   ► to end web services based on the load,

00:05:40 ◼   ► and then come down again into the database in the back.

00:05:43 ◼   ► And the reason I use that infrastructure on Linode is it's very, very cost effective.

00:05:50 ◼   ► And for the kind of load that I'm trying to manage, it works out to be very, very, very

00:05:54 ◼   ► cost effective in that something like Heroku or one of the other kind of more elastic providers

00:06:01 ◼   ► where there's an expectation of that you can sort of go easily and to some degree you can

00:06:05 ◼   ► kind of turn up the scale yourself, that works well if that's something that you're really

00:06:10 ◼   ► worried about. If you're really worried about sort of whatever the hockey stick turn on

00:06:15 ◼   ► your app or your service, where all of a sudden you're going to need to be handling 100,000

00:06:20 ◼   ► times more users than you did the day before, that potentially is useful. The nature of

00:06:25 ◼   ► what I do, all the people who use my web sources for the most part have already given me some

00:06:29 ◼   ► amount of money. And so that limits dramatically the growth that I can have. In kind of a weird

00:06:36 ◼   ► way, that's a good thing, that there's a limit to the number of people in the world who are

00:06:39 ◼   ► willing to give me a dollar every day. And so I don't have

00:06:42 ◼   ► to worry too much about these kind of crazy spikes in growth.

00:06:46 ◼   ► That being said, you want to have an infrastructure and a

00:06:49 ◼   ► setup in place that allows you to scale as you need to. And

00:06:53 ◼   ► this infrastructure is fairly flexible for that. And this is

00:06:56 ◼   ► something that I'm going to be talking for the last latter part

00:06:59 ◼   ► of the thing is you need to get very good at the provisioning

00:07:02 ◼   ► process for new servers and to be able to grow and collapse

00:07:05 ◼   ► your your needs as you as they as they sort of change. And it's something that you get

00:07:10 ◼   ► very good at. And that's kind of the process that I've been working on. And this is all

00:07:14 ◼   ► actually got started from there's a rails cast called Capistrano recipes, which I'll

00:07:19 ◼   ► have links from the show notes, where Ryan talked about how he does does this and it

00:07:23 ◼   ► was something that once I saw was just, you know, an answer to exactly what I've been

00:07:27 ◼   ► looking for. And basically, all you do is you have a series of scripts for provisioning

00:07:32 ◼   ► a fresh Linux installation to exactly what you want.

00:07:35 ◼   ► You can do this with Chef, Puppet,

00:07:37 ◼   ► there's all kinds of other variations on that

00:07:40 ◼   ► that people use.

00:07:41 ◼   ► But for someone like me who's not a system administrator, who

00:07:43 ◼   ► doesn't do a lot of this, most of what I do

00:07:46 ◼   ► is I set up a basic infrastructure.

00:07:48 ◼   ► I put it out there and just kind of run

00:07:50 ◼   ► Linux on for a while.

00:07:52 ◼   ► That works fine.

00:07:53 ◼   ► And I'm talking about systems with not crazy numbers of users

00:07:58 ◼   ► because then you have numbers of users that are measured

00:08:00 ◼   ► you know, for some of the apps it's hundreds of thousands, for some of the others it's

00:08:03 ◼   ► tens of thousands, but you're, you know, that kind of load, I'm not going to go crazy in

00:08:09 ◼   ► terms of building these super scalable infrastructures. I want something very pragmatic, very simple,

00:08:14 ◼   ► and very repeatable for myself. And so this is what I've been doing for the last couple

00:08:18 ◼   ► of days is I've gotten, I've been sitting there actually just consciously practicing

00:08:23 ◼   ► tearing down and rebuilding servers over and over again. And this is, this is sort of the

00:08:27 ◼   ► The lesson, the takeaway for today that I wanted to mention, is that you want to be

00:08:31 ◼   ► able, before you ever launch something, you want to practice the worst case.

00:08:36 ◼   ► You want to practice and get good at what the bad case for that could be.

00:08:41 ◼   ► And so in this case, it's what happens if something goes bad with one of my machines?

00:08:45 ◼   ► One of my things gets hacked.

00:08:46 ◼   ► One of my, the machines that I'm physically running on has a problem.

00:08:50 ◼   ► I need to spin something up new.

00:08:52 ◼   ► don't want to learn the process of how to deal with that at that time. You want to be

00:08:59 ◼   ► practiced and skilled in doing that ahead of time. And so what I spent all of basically

00:09:03 ◼   ► yesterday doing is I just went into Linode and I'd say like, you know, rebuild this machine,

00:09:07 ◼   ► fresh install, go through and run the, you know, work through my workflow for setting

00:09:12 ◼   ► it up and getting it provisioned. And I got to a point where it's basically, you know,

00:09:17 ◼   ► from start to finish, from an absolute, from an empty machine to a running web server,

00:09:21 ◼   ► which is the one that I focus on mostly, is about 10 minutes for me. And most of that

00:09:25 ◼   ► time is just watching, you know, scripts fly by and doing things. But that process and

00:09:30 ◼   ► being very, you know, confident in that is something that gives me allows me to use something

00:09:34 ◼   ► like Linode. If that's something that's scary to you, you may need to use something that's

00:09:38 ◼   ► more managed, something that's more like a Heroku where they're doing most of that for

00:09:42 ◼   ► you. And understanding that you're at a as a result, you're paying for that you're paying

00:09:47 ◼   ► for that extra hand-holding and abilities

00:09:51 ◼   ► that they're kind of laying on top of your infrastructure.

00:09:55 ◼   ► So that's kind of what I do.

00:09:57 ◼   ► And you can apply it to a lot of things.

00:09:58 ◼   ► You also want to play around with load testing.

00:10:01 ◼   ► A great tool for that is something

00:10:03 ◼   ► called Apache Benchmark, or AB, you'll

00:10:05 ◼   ► see it often called, which you can just get for any platform

00:10:09 ◼   ► you can imagine.

00:10:09 ◼   ► And it's just a really simple tool.

00:10:11 ◼   ► All it does is you say, I want you

00:10:12 ◼   ► to make 1,000 web requests, or I want

00:10:14 ◼   ► to make you 10,000 web requests with a certain amount

00:10:17 ◼   ► of concurrency. So I want you to make a thousand web requests, ten at a time. It lets you kind

00:10:23 ◼   ► of see how your web service responds to that. And lets you kind of ramp up the volume in

00:10:28 ◼   ► a way that is often a bit tricky to do otherwise. And it works really well. It's something that

00:10:32 ◼   ► helps me kind of identify little bottlenecks or little issues in my web servers in a way

00:10:37 ◼   ► that would be trickier to do without actual load. Obviously, once you have real users,

00:10:41 ◼   ► using a tool like that is a little funny because you don't necessarily, you can only do it

00:10:44 ◼   ► for a new infrastructure, you wouldn't want to put undo load on your, you know, your production

00:10:49 ◼   ► environment when users are actually using it. But that's, it's kind of a strange topic

00:10:54 ◼   ► for today. But I thought I wanted to kind of just work through kind of I get a lot of

00:10:57 ◼   ► questions about how, how and why I want to use servers. And a lot of people get too wrapped

00:11:02 ◼   ► up into all the, I don't even know, it's like a religious debate, but it's like a, there's

00:11:06 ◼   ► a lot of different choices you can make. And at the end of the day, it doesn't really matter

00:11:11 ◼   ► which infrastructure you use, if you're a PHP guy, if you're

00:11:14 ◼   ► a Python guy, if you're a Ruby guy, if you're doing JSP or ASP

00:11:18 ◼   ► or any of these infrastructures, at this point,

00:11:21 ◼   ► and this point in kind of the maturity of web stacks,

00:11:26 ◼   ► functionally, they're not going to make much difference.

00:11:28 ◼   ► And I mean that mostly from like, your end user

00:11:31 ◼   ► isn't going to notice a difference, really,

00:11:32 ◼   ► if you're using one or the other.

00:11:34 ◼   ► What's important to the user is reliability and stability

00:11:38 ◼   ► and performance.

00:11:39 ◼   ► And those things are something that is more on you for developing the skills that you

00:11:44 ◼   ► need to manage whatever stack you're using and to understand the intricacies of it.

00:11:49 ◼   ► I always find the thing that's dangerous with a tool like Heroku, which is great in that

00:11:55 ◼   ► it's super easy and flexible, is that you can—it's a very leaky abstraction, maybe

00:12:01 ◼   ► is the best way to say it, where it hides so much from you that you can start ignoring

00:12:08 ◼   ► some of the complexity of what you're doing. And then at some point, the that complexity

00:12:13 ◼   ► can sort of jump out and bite you in a way that you may not understand what's going on

00:12:18 ◼   ► or may not know how to fix it, you'll have some strange conflict, or you'll have some

00:12:22 ◼   ► weird caching thing that's going on that sort of at levels deeper than you can access levels

00:12:28 ◼   ► that you're not really aware of. And that can be caused really weird problems. And that's

00:12:32 ◼   ► something that may not happen every time it may not happen often, maybe won't happen at

00:12:36 ◼   ► at all. But it's a danger that I love. For me, I like to have an infrastructure that

00:12:40 ◼   ► I really understand that I know what's going on all the way from the, you know, from when

00:12:45 ◼   ► the request is made all the way down to what OS that machine's running, all those kinds

00:12:49 ◼   ► of things. That's why I use the infrastructure that I do. Learning Linux and learning to

00:12:55 ◼   ► administer Linux, I think it's one of those skills. If you're, if you don't know how to

00:12:59 ◼   ► do that, if you're not comfortable in a terminal SSHing into a machine, you really need to

00:13:04 ◼   ► And I say that not necessarily as if you're a developer, you may never actually have a

00:13:10 ◼   ► practical need to, but it's something that if you are uncomfortable with, you're probably

00:13:16 ◼   ► missing out in terms of your ability to respond in a variety of circumstances.

00:13:22 ◼   ► And it's not that hard at the end of the day.

00:13:24 ◼   ► You know, it's like getting comfortable with all the various tools and what that looks

00:13:28 ◼   ► like in a Linux machine.

00:13:29 ◼   ► You can spin up one on Linode for $20 a month and play with it.

00:13:33 ◼   ► Or there's even like Vagrant or Virtual PC or Parallels,

00:13:38 ◼   ► I think can even just run a Linux server locally

00:13:40 ◼   ► and you can just play with it.

00:13:42 ◼   ► And I think it's just something that I would encourage

00:13:43 ◼   ► a lot of you to do,

00:13:45 ◼   ► 'cause I think you're a better developer

00:13:46 ◼   ► the deeper into the stack you have knowledge,

00:13:49 ◼   ► whether or not you end up needing to use that knowledge.

00:13:52 ◼   ► And basically, yeah, so that's how I do it.

00:13:54 ◼   ► That's something that I'm looking forward to rolling out

00:13:56 ◼   ► and I think it's a good exercise to go through

00:14:00 ◼   ► and it's something that you,

00:14:02 ◼   ► Even if you only are focused on the front end, understanding how back ends work is useful.

00:14:06 ◼   ► All right, that's it for today's show.

00:14:08 ◼   ► As always, if you have questions, comments, concerns, or complaints, I'm on Twitter @_davidsmith.

00:14:12 ◼   ► I'm on AppNet @davidsmith.

00:14:16 ◼   ► And if you're going to email me, if you have a question about the show, something like

00:14:19 ◼   ► that, I'm david@developingperspective.com.

00:14:20 ◼   ► All right, hope you have a great weekend.

00:14:23 ◼   ► Happy coding, and I'll talk to you next week.