Developing Perspective

#112: Servers, Servers Everywhere.


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.