0:00:00Welcome to Under the Radar, a show about independent iOS app development.
0:00:04I'm Marco Arment.
0:00:05And I'm David Smith.
0:00:06Under the Radar is never longer than 30 minutes, so let's get started.
0:00:10So today we wanted to unpack the situation that occurred,
0:00:17I guess it was the beginning of this week, the end of last week, something like that,
0:00:21where Parse, a fairly widely used platform for app backends,
0:00:27announce that they will be shutting down. And while the actual situation and the nuances
0:00:33of that aren't particularly generally applicable or interesting, the actual sort of -- the
0:00:38fundamentals of that, of having this big general purpose platform that was used by lots of
0:00:43apps finally shutting -- or deciding it was going to shut down has a lot of knock-on effects
0:00:48that are probably worth unpacking.
0:00:49Before we dive into that, it probably makes sense to just sort of talk about what Parse
0:00:53And so Parse was this platform that made it relatively easy to make a backend for your
0:00:59application that would do object persistence, user management, things like that, like a
0:01:04very basic high-level, like, non-specific to a particular industry backend sort of system
0:01:10that a lot of apps could use.
0:01:11And it had fairly attractive pricing, and including a free tier, which is always a bit
0:01:16of a trap for these kinds of things, where you can say, "Oh, we can use it for free,
0:01:19and if our app gets really successful, then we -- only then will we have to pay."
0:01:23And eventually, a couple years ago, it was bought by Facebook, which made everyone who
0:01:26was using it kind of happy because, oh, now it's not this sort of fly-by-night thing.
0:01:30It's backed by, you know, this major corporation.
0:01:33But now it's being shut down.
0:01:36Facebook has decided that that's not something that they want to invest in and continue to
0:01:39maintain.
0:01:40And so a year from now, they are going to be turning it off.
0:01:43They're doing it pretty well.
0:01:45Like they're giving a year's notice and a bunch of migration tools.
0:01:48But at the end of the day, this thing that I've heard varying reports, but at least,
0:01:55it's fair to say quite a lot of apps make use of, at least in part, is just going to
0:01:59be turned off.
0:02:00And as a result, the apps that use it, if they haven't been updated or migrated, are
0:02:04just going to stop working.
0:02:06And that's kind of tricky.
0:02:07>>
0:02:07- Yeah, I think one of the weird things about this
0:02:09is like, you know, it kind of ties back to App Economics,
0:02:11where in order for these apps to continue working,
0:02:15it has to be worth their developers' time,
0:02:18and their developers have to have the budget
0:02:20to now do a noticeable update.
0:02:23And you know, they've made it relatively easy.
0:02:26They've released big parts of their service
0:02:28as open source that you could just install on any server.
0:02:31Microsoft Azure has started trying to attract people
0:02:33to migrate to them, and they're making it a little bit easier
0:02:36So there are migration options here that aren't going to be incredibly work heavy, but it
0:02:41is still work.
0:02:42You have to still do an update.
0:02:43There are going to be things you have to change and rewrite.
0:02:46And so it has to be worth that happening by the apps developers.
0:02:51So if you're relying on an app that uses this that hasn't been updated in a long time, that
0:02:55might never be updated for this.
0:02:57It might never be worth somebody's time to update it.
0:03:00And that's unfortunate.
0:03:01And that is going to cause a lot of problems in the app store as these apps just kind of
0:03:03slowly collect one-star reviews and stop working and they just kind of live as zombies forever.
0:03:10>> And so as developers, when I see something like this, like I said, the specifics of the
0:03:16par situation are sort of vaguely or intellectually interesting but aren't actually practically
0:03:21that interesting. But what it makes me think about is it makes me evaluate the dependencies
0:03:27that I have in my own apps and as I build apps, and increasingly, fewer and fewer of
0:03:33the things that I build have no web component whatsoever.
0:03:37Because it seems like these days, you're going to need some kind of backend for your application.
0:03:44Either something like parse or that's sort of like off the shelf or something you build
0:03:49yourself.
0:03:50And you're probably going to need these for at least one of three reasons.
0:03:53You're going to need some kind of, your app's probably going to do something backup-related,
0:03:57where people are, if people are putting any amount of data into your application, they're
0:04:02probably going to want to be able to have it backed up.
0:04:05And this is something that for a long time I used to say, "Oh, I rely on the iTunes
0:04:09iCloud backup system."
0:04:11But that is all kinds of problems and issues that you'll run into, where, like, I have
0:04:16a recipe manager, and I ran into issues where their recipes were fully backed up in the
0:04:22the latest backup that they did,
0:04:23but they accidentally deleted the app.
0:04:25And so now the only way they can get their recipes back
0:04:27is to do a full restore of an old backup onto their device,
0:04:32potentially destroying newer data
0:04:36on other apps and things.
0:04:38It's a mess.
0:04:39So you wanna be able to backup your data,
0:04:40or you wanna be able to sync your data
0:04:42between different devices,
0:04:44so you'll need some kind of backend to do that.
0:04:46Or you just have an app that has a core service.
0:04:49Obviously, I imagine in Overcast,
0:04:51you need a backend, or a lot of what you do wouldn't work
0:04:56if you didn't have some kind of backend to run for it.
0:04:59- Oh, sure, I mean, there are podcast apps
0:05:02that don't use server-side backends as intermediaries
0:05:05and just crawl feeds directly and everything,
0:05:07but that's not how I built mine,
0:05:09and it affords me a bunch of advantages
0:05:11to have done it the way I do it,
0:05:12but now I have this big dependency on my service.
0:05:15- Yeah, and I think ultimately, that's the right word.
0:05:18At the end of it, building these backends
0:05:21that are maybe, aren't always required,
0:05:23but are going to be required in a lot of cases,
0:05:26the biggest thing that I think this situation
0:05:29is instructive for is making us aware
0:05:32of the things that we're dependent on
0:05:34and that our apps are dependent on,
0:05:36because we're always gonna be dependent
0:05:38on something, it seems.
0:05:39There's no way to really say,
0:05:41okay, I'm gonna be completely independent,
0:05:42because ultimately, you're gonna be,
0:05:44I'm very reliant on Apple, for example, and iOS.
0:05:49If Apple announced tomorrow that, hey, we've decided this iOS thing isn't really working
0:05:55out, we're just going to turn it off.
0:05:58We're just going to stop making iPhones.
0:05:59I'm not saying that's likely, but if they did, my apps would stop working.
0:06:03In the same way that if Parse going away meant that apps that relied on it go away.
0:06:08Or maybe a more practical example on the Apple side of things is if they decide, you know
0:06:13what, CloudKit isn't working out, we're going to turn that off.
0:06:16Or those types of things.
0:06:18or I rely on my hosting provider.
0:06:20I host all my Linux servers on Linode,
0:06:23and if they decide they're gonna go out of business
0:06:28or they decide they're not gonna do the kind of hosting
0:06:30that I need anymore, suddenly I'm in a big bit of a bind.
0:06:34And so there's no way to avoid being dependent.
0:06:37You're always dependent on something,
0:06:38but there's a lot of dependencies
0:06:41that you kind of have some choice in.
0:06:43Do I wanna be so wed to a particular platform
0:06:47back end or system? Or do I want to be a bit more flexible and do, you know, usually it
0:06:52ends up like the more custom you make it and how much of it you control, you're going
0:06:56to have more like portability and be able to be like, you know, if this particular host
0:07:01goes away, I can just get another one. And you're going to be able to look at the trade-offs
0:07:05and make more choices than if you're just all in on one thing. That's when you start
0:07:10to get a little bit awkward.
0:07:12awkward.
0:07:13Yeah, and that's why the selection of what you depend on, this is why I'm usually very
0:07:18conservative with these. Obviously I try to minimize how many external services and companies
0:07:23and things I depend on, but you're always going to depend on something, as you said.
0:07:27This is why I always try to choose as conservatively as possible. So yeah, Apple could shut down
0:07:33the entire app store and that would really be disruptive for us, but that's very unlikely.
0:07:39The App Store's continued success is pretty important
0:07:42to Apple as well, so I've aligned my incentives
0:07:45with this now pretty old and pretty important thing
0:07:48to its parent company that it is very unlikely
0:07:51that Apple will do that and that will be a problem for me.
0:07:54Facebook shutting down Parse, this thing they bought,
0:07:58did not have that kind of luxury.
0:08:00If you were a Parse customer six months ago
0:08:01and you're evaluating this dependency,
0:08:04it isn't that important to Facebook to keep this running.
0:08:08So that this was foreseeable,
0:08:09that this was a high risk of happening,
0:08:12that this company made this service,
0:08:13it got big, it got bought,
0:08:15the parent company didn't really depend
0:08:16on its continued operation for their core strategy.
0:08:19So this was always gonna be a risk, right?
0:08:22So if Linode, Linode, however we're supposed
0:08:26to be pronouncing it, I say Linode, you say Linode,
0:08:27they say Linode, if that particular Linux VPS host
0:08:32gets shut down, well, that's unlikely
0:08:35'cause they're really big
0:08:36and they've been around a while,
0:08:38but even if that happens,
0:08:40migrating away from that is not that big of a problem
0:08:43because there are other Linux VPS hosts just like it.
0:08:48And if every Linux VPS host went away,
0:08:52you could get a Linux server somewhere
0:08:54that behaved very similarly.
0:08:55If every Linux server provider went away,
0:08:59you could, as a last ditch, run one in your house.
0:09:02You shouldn't, but you could.
0:09:04So the transition options away from something
0:09:08are also very important.
0:09:09Parse shut down, they did a decent thing here
0:09:12where they open sourced a big part of their server
0:09:15and made it installable on your own stuff.
0:09:17But what if they didn't do that?
0:09:18Lots of things shut down and never do that
0:09:20because they just either can't or won't
0:09:22or don't feel like it.
0:09:24So suppose you depend on an Amazon web service
0:09:29for your business and Amazon shuts that down.
0:09:32Most of the time, that is very hard to replace
0:09:35'cause they are so custom and proprietary,
0:09:37you can't just kinda do your own thing.
0:09:39If you depend on any kind of high-level service like this,
0:09:43then it is always a risk that the more custom
0:09:47and proprietary and high-level something is,
0:09:49the risk of it being hard to replace
0:09:52if it ever does go away increases.
0:09:54- Yeah, and I think that's ultimately probably
0:09:57like the enticement and why it's this weird tension
0:10:00that you find yourself in as you're developing a service
0:10:02as you're thinking about a feature, you're saying, "If I do it with this high-level
0:10:08construct that this company's providing, I can save myself a lot of time up front,
0:10:15because I'm not having to build that again."
0:10:19If there's this solution that they've come up with that means that user authentication
0:10:24is just a thing that I can just plug into my app, and it handles all the secure password
0:10:31storing and email resets and all that kind of stuff.
0:10:34Say there's a service that does that off the shelf.
0:10:36That's days, weeks, months of time that you weren't spending building that thing, but
0:10:42instead you're just kind of more integrating directly into your application.
0:10:46And so it's enticing.
0:10:48And you're getting this enticement at the benefit of that upfront time, but it's sort
0:10:53of at the detriment of this risk that you're increasing in your application.
0:10:58And maybe that makes sense, like if you're just kind of prototyping something and throwing
0:11:02it out there, or you aren't in a situation that's very time limited, that you have to
0:11:07get, you know, if you don't ship your app in a month, it's you're going to miss some
0:11:12kind of market window or opportunity that or like, that's the only amount of like, you
0:11:16just have that much money to make a run at it, and you just kind of have to, then great,
0:11:21like it, there's nothing bad about those types of things.
0:11:25But it's this weird tension that you're finding of because you're so locked in at that point,
0:11:30you're setting yourself up for difficulty down the road.
0:11:33Because it's not necessarily your short-term benefit and long-term pain, because developing
0:11:40it yourself, there's also long-term pain.
0:11:42It's a different kind of pain, but you have to then be the one who's maintaining it, or
0:11:46when security issues happen, you're the one going in and patching your web server or the
0:11:54the Linux distribution you're installing on your servers
0:11:56or whatever, at some point there's always
0:11:58long-term challenges with these things.
0:12:01But the difference is more one of you're totally locked in
0:12:05and at the whim of whatever that company is.
0:12:08And unless you're their biggest customer,
0:12:11which for the kind of people who I imagine
0:12:13listen to a show like this, you're unlikely to be
0:12:15a service provider's biggest customer,
0:12:19you're just gonna be kind of like,
0:12:21sort of washed back and forth based on
0:12:23make sense for them.
0:12:24And that may or may not be a position
0:12:27that you find yourself in that you'd be comfortable with.
0:12:31This episode of Under the Radar is brought to you by Hover.
0:12:34Quite simply, Hover is the best way
0:12:35to buy a managed domain names.
0:12:37And when it comes to buying a domain name,
0:12:38Hover is the first place I check.
0:12:40Now, when you have an idea for a project,
0:12:42naming it can be difficult.
0:12:43When you finally get that name, you
0:12:44want to be able to quickly and easily get the domains
0:12:46that you need.
0:12:47Hover provides a simple, fast, and hassle-free method
0:12:50of buying domains.
0:12:51I don't want to be faced with 1,000 screens
0:12:53and all these add-ons, high prices,
0:12:55all these custom weird services that seem like scams.
0:12:58I just want to get in, select what I need,
0:13:00buy it and get on with my life and building my new idea.
0:13:02Hover makes this very, very easy.
0:13:04Their search is very nice.
0:13:06It suggests things for you if nothing's available.
0:13:08They can search all the TLDs, all the crazy new ones,
0:13:11in addition to all the nice old ones.
0:13:13And they have .com domains starting at just $12.99 a year.
0:13:17Great prices on all the other ones as well.
0:13:19All of these include Whois privacy for free
0:13:22with every hover domain, because they believe
0:13:24that you shouldn't have to pay extra for something like that.
0:13:27Obviously, you want to keep your private information private.
0:13:29They also have fantastic customer support.
0:13:31If you want to call them, they have a no hold, no wait,
0:13:34no transfer telephone support policy.
0:13:36When you call them, you talk to an actual human being,
0:13:38not a robot, not a menu.
0:13:40You don't have to say like, operator,
0:13:42like those stupid speech menus.
0:13:43It's a real human being you can just talk to directly.
0:13:46They pick up the phone.
0:13:47And if you do, of course, prefer the robots,
0:13:49they also have great support documents
0:13:51and support guides on their website
0:13:52for getting everything you need,
0:13:53and you can email them as well if you'd like.
0:13:56And they also have a valid transfer service
0:13:58where they can take all the hassle out of switching
0:13:59from your current provider,
0:14:00simply because they do it all for you.
0:14:02You can just give them your login to your old provider
0:14:04and they will transfer names for you if you'd like.
0:14:06All that for free, of course.
0:14:08They have so much more great stuff.
0:14:09They have volume discounts,
0:14:11they have custom email addresses, storage and forwarding,
0:14:13and so much more stuff.
0:14:15Check it out today at hover.com.
0:14:18Use code perspective at checkout.
0:14:20That is once again, Code Perspective at checkout,
0:14:23and you will get 10% off your first purchase at hover.com,
0:14:26and you will show your support for Under the Radar
0:14:28and all of Relay FM.
0:14:29Thank you very much to Hover for sponsoring this episode.
0:14:32- So it seems like we should probably also dive now,
0:14:34dive into kind of like what we do, how we approach this,
0:14:38because I think we both have found ourselves
0:14:41at the end of the thought process
0:14:44on how we should bake back ends for our service
0:14:46with the like, well, we're gonna build them ourselves,
0:14:48and we're gonna build custom applications
0:14:51running on Linux VPSs that we use.
0:14:56And probably worth saying why we kind of do that.
0:15:00- I mean, to me, first of all,
0:15:02it's all about control for me.
0:15:03I'm a control freak, and I wanna do everything myself,
0:15:05and I want everything to be under my control,
0:15:08because I don't want to have major parts of my roadmap
0:15:12dictated by a dumb change in my host that,
0:15:16oh, all of a sudden this entire thing I depend on
0:15:18is shutting down and I gotta change that.
0:15:21Apple gives us enough of those things,
0:15:23with new device releases and everything,
0:15:25but those are kind of an unavoidable part
0:15:27of working with Apple.
0:15:28But when it comes to running your services,
0:15:30you control a lot more of that
0:15:31and you can avoid those things.
0:15:33And so I love that part of it.
0:15:35And for me, it's also a lot about capability and cost,
0:15:39low cost and just being able to do a lot.
0:15:43CloudKit is very appealing in a lot of ways.
0:15:45And if I was making a new app today,
0:15:48I would think very hard about whether I could just do it
0:15:50all on CloudKit and whether that would be
0:15:51the right move for me.
0:15:53But it is still limited in what it can do, what it can't do.
0:15:58And so for me, a website, like a regular Linux backend,
0:16:02is the default for me.
0:16:03I know how to do it.
0:16:04It really isn't that hard,
0:16:06which we'll get into in a little bit.
0:16:07It really isn't that hard.
0:16:08And it is surprisingly capable for surprisingly little cost.
0:16:13- Yeah, exactly.
0:16:14I think the reasons are fairly similar for me. I think the thing that I like most is
0:16:20being able to tailor the backend of my application to not necessarily the application, but it's
0:16:27tailored to the way that I think and the way that I solve problems and the way that I'm
0:16:31thinking about the problems that are being solved in my app. So when I'm dealing with
0:16:37something like sync, like the generic term for one of the hardest problems in computer
0:16:42science. I like that I can—I'm solving that problem in a way that makes sense to
0:16:50me, that I'm not having to kind of shoehorn my application and the way I think about it
0:16:55into the model that a service provider provides. And they say, "Well, we handle conflict
0:17:01resolution using last updated wins," or something like that. And maybe that works,
0:17:07maybe it doesn't. And so when you build it yourself, I actually understand it. I have
0:17:12to go—I've gone through and I've made the decisions at the various levels of like,
0:17:18"Well, I want this to work this way, I want this to work that way." And so then down
0:17:22the road, when I'm debugging something, I have a better understanding of how I expect
0:17:28it to work, and when things go wrong, I have a sense of where they might be going wrong.
0:17:32Like, is this an app problem, or is this a web service problem? And ultimately, it probably
0:17:38also just makes my apps better and makes me a better programmer. Like, having this breadth
0:17:42of experience that at this point, I can build something all the way from the UI in the application,
0:17:50the business logic inside of the application, and then all the way through to the web service
0:17:57that's managing that information and a database at the back that's storing that information.
0:18:03Having been able to do all those things is just good for me from a career and personal
0:18:09development perspective. Like, I've learned to solve more problems doing it this way that
0:18:15ultimately I think makes me a better developer. Like, I write less. My apps are probably better
0:18:20because they're the kind of calls they're making. Like, I know what the server is trying to do with
0:18:25those calls. And so you don't end up just like, "Well, this is like the naive, obvious solution.
0:18:30I'll just kind of throw all this data at the server." Or I'll, "Hey, let me just ask for
0:18:35for all of it, all the time, and because if the servers are overwhelmed, that's not my
0:18:41problem. Those are things that ultimately probably make my apps better. And like you
0:18:45were saying, it is kind of crazy how inexpensive it is to do a lot of these things now. A lot
0:18:52of my things are just backed by two or three VPSs that cost—at a basic one, it's like
0:19:00$20 a month or something like that, $20, $40 a month. For a lot of my applications, I end
0:19:04up spending maybe $100 a month in servers, and that's really not too bad for the kind
0:19:13of capability and the throughput and the number of users that you can support even just at
0:19:18that level.
0:19:19Oh yeah, I mean, even the $20 a month server level on a modern host like LineOut or Digital
0:19:25you can get so much for this money now.
0:19:28And when you're using boring old fast tools
0:19:31like MySQL or Postgres and you have like
0:19:35a modern web language in front of it,
0:19:37you know you have, even in the old ones,
0:19:38PHP, Ruby, you know like Python,
0:19:41or more recently you might have like Go,
0:19:44these are so fast, you can do so much,
0:19:47you can support so much usage,
0:19:48it's way more than you think.
0:19:50'Cause now you have these modern processors
0:19:52doing the virtualization,
0:19:53You have SSDs on almost all these hosts now.
0:19:56It is incredibly fast to do.
0:19:58And so you really can support a lot on very little hardware.
0:20:02- Yeah, and I think ultimately that makes it a lot easier.
0:20:04It's, they're the hardest problems I've ever had to solve.
0:20:08The only time I kind of regretted doing backends myself
0:20:11is they were the early days of Feed Wrangler,
0:20:14my RSS syncing system, which I was doing stuff
0:20:18that in retrospect was really foolish
0:20:21and was just crushing my database.
0:20:24My Postgres database was just constantly dying
0:20:28and falling over.
0:20:29And in retrospect, it was because I was being,
0:20:34I'd made a few really bad assumptions upfront,
0:20:36but even there, that's the only time I've ever really
0:20:41had to do any low-level performance tuning
0:20:44of any of my applications.
0:20:46Otherwise, just out of the box,
0:20:48things are just fast and work and it's fine in a way that,
0:20:53it would be problematic if I really needed to be
0:20:56a database administrator, a serious DBA,
0:21:00whatever they call them these days,
0:21:02doing that kind of work, but most of the times
0:21:04I just install Postgres with the defaults,
0:21:07tweak a few things the way I like it, and then it's fine.
0:21:10And it just runs quickly enough for,
0:21:13that my users don't even really notice
0:21:15any kind of performance issues or problems.
0:21:17- Yeah, I mean, you might think,
0:21:19if you haven't done this before,
0:21:21or the last time you did this was like 10 years ago,
0:21:23you might think that running servers requires
0:21:25lots of low-level tweaking and performance tuning
0:21:28and getting these right config variables
0:21:29to exactly the right buffer size and everything,
0:21:31and you don't really need to do that anymore.
0:21:33It's very rare for most people to need to get
0:21:37that down into the nitty-gritty stuff.
0:21:38It really is, as you said,
0:21:40you can just install these things with the defaults,
0:21:43and usually you're fine.
0:21:45That's usually all you need to do,
0:21:46because everything is just so good now.
0:21:48There's so much headroom.
0:21:49The software is very mature in a lot of these things,
0:21:53and the hardware is very mature too.
0:21:54So you really get a lot with just the defaults now.
0:21:58- And I think one thing that I was kind of looking forward to
0:22:01when we got into this topic is you said
0:22:03you had a few little pro tips
0:22:05for getting into this kind of administration,
0:22:07because I think it can be a little bit intimidating
0:22:11to go and install Linux.
0:22:15Then you start to like, well, what version of Linux?
0:22:17What should I do?
0:22:18How to get started?
0:22:19And I remember it being a little intimidating,
0:22:21but at least the fun thing is once you get going,
0:22:24there's tremendous resources,
0:22:26and you can just kind of get going.
0:22:27And once you know it, you know it,
0:22:28because this stuff doesn't really change.
0:22:31- Yeah, basically, Google is your friend,
0:22:34not the corporate structure, but the search engine,
0:22:37Stack Overflow, all these things.
0:22:39These are your friend, because lots of people
0:22:42have been running Linux servers for years.
0:22:44And as you said, the tools and the commands
0:22:47and what you need to do doesn't change very often.
0:22:50Typically, you learn this stuff like once
0:22:52and you have to learn something new maybe every two years.
0:22:55It's pretty stable, it doesn't change much.
0:22:58So number one tip I can give is to pick a very popular
0:23:03but somewhat conservative Linux distribution
0:23:06to do this with.
0:23:07For years, I recommended CentOS,
0:23:09which was based on Red Hat Enterprise Linux.
0:23:11I think today, I think Ubuntu might have more momentum behind it. So I actually just managed
0:23:17my first Ubuntu server recently and things are a little bit different but I was able
0:23:23to figure it out. So between CentOS and Ubuntu, you can't really go wrong. Turn on auto updates
0:23:31for as much of the system software as it makes sense to do that for. Usually every major
0:23:35distro has a way to do this. It's very straightforward. That will take care of most security problems
0:23:40for you. If you basically are not an idiot, which you're not, trust me, if you're not
0:23:46an idiot and if you leave things mostly at their defaults with the distro and what it
0:23:50comes with, modern Linux distros are very secure by default because they know that that
0:23:54matters, like the defaults matter, so they've all adopted pretty conservative and pretty
0:23:59secure defaults for the most part. Keeping things updated automatically is very easy
0:24:03and things like that. On other high level stuff, only run the software that you need
0:24:08to be running. And they're all very good at letting you manage this. So like, if you have
0:24:12a server that you have your website on, don't also install like, "Oh, let me install FTP
0:24:16so I can like trade files with my friends." No, just leave that off. That's just a liability.
0:24:20Just don't do that, you know. Install what you need to install. And if you want to play
0:24:24around with different things, you can create a second VPS for like five or 10 bucks a month
0:24:27and play around on that. Don't play around on your main servers. Run only what you need
0:24:31to be running on them. Take advantage of the built-in isolation in Linux machines, especially
0:24:38with regard to networking. Almost every service that you'll be running will have some kind
0:24:44of like listening port where you can say, "All right, this database should listen on
0:24:47this interface, on this port." If you only have one server, make the internal stuff listen
0:24:52on local host so that you can't log in to MySQL from outside. Like, you shouldn't need
0:24:58to do that anyway. You should be doing things on the server if you need, you know, management
0:25:01stuff. Lock that down. If you have multiple servers, use private networking. Every host
0:25:05that's worth their salt supports private networking between your own machines. So if you have
0:25:10multiple servers and you need to talk to each other, have them talk to each other only over
0:25:14private interfaces. Have things like MySQL or Memcache listen only on private or local
0:25:19interfaces. That helps a lot. Just make it, don't rely on like keeping your passwords
0:25:25secure. Make it so that passwords don't even work from the outside. So that also applies
0:25:29with things like SSH when you're doing login, remote login.
0:25:32So disable root logins once you have a user set up,
0:25:35have that user have pseudo access with the password,
0:25:38and then that user account that you're logging in as,
0:25:40say you're logging in as David,
0:25:41make that the only user that can log in via SSH
0:25:43and make that key authentication only,
0:25:46disable password authentication in SSH.
0:25:49This is very simple stuff to do.
0:25:50You can Google how to do it.
0:25:52So that, right there, you have no way
0:25:54to log in with a password.
0:25:56You have to have the encryption key to log in.
0:25:59That knocks out massive brute force possibilities
0:26:03and everything.
0:26:04That helps so, so much.
0:26:06Between that and private networking for private services,
0:26:09you really eliminate a lot of problems.
0:26:11Now, moving on slightly to user data.
0:26:14Collect as little user data as possible to get your job done.
0:26:19Because worst case scenario, somebody hacks into your server.
0:26:22Worst case scenario, they take your database.
0:26:25What do they have?
0:26:26Think about it.
0:26:27When you're designing your database,
0:26:29you're designing your service,
0:26:30what information do you really need from people
0:26:32and what can you get away with not having?
0:26:34If you don't need to get people's email addresses,
0:26:36don't get their email addresses.
0:26:38If you're taking passwords from people, hash those
0:26:41so that people aren't getting just the MD5,
0:26:44for God's sake don't do that.
0:26:45Use secure password hashing like Bcrypt on strong settings.
0:26:49There's lots of good practices for this,
0:26:50lots of things to tell you how to do this.
0:26:52I've considered even for overcast,
0:26:54I do have the email addresses for people
0:26:56because I figure I have email addresses
0:26:58and I have hashed passwords with strong bcrypt,
0:27:01but I'm like, I've been thinking recently,
0:27:02do I even need the email address?
0:27:04Could I hash that too?
0:27:06'Cause then you have, if you steal my database,
0:27:08you just have no email addresses.
0:27:10That would be amazing.
0:27:11And I was thinking, if you hash the email address
0:27:14so it works just like the password basically,
0:27:16then you could still have logins,
0:27:18you could still have password resets.
0:27:20The only thing you really can't do is,
0:27:22I can't email people randomly out of my database,
0:27:26but I've never done that.
0:27:27I don't send a newsletter, I don't do any of that stuff.
0:27:31So, you know, stuff like that.
0:27:32Think about just like what data you have,
0:27:34what you're collecting, and what you can afford
0:27:36not to collect.
0:27:37Simple security measures beyond that, you know.
0:27:41You should have database backups.
0:27:42You should also be encrypting those backups.
0:27:44There's built-in stuff, there's a crypt command
0:27:45you can pipe tar through and everything like this.
0:27:48Really simple stuff on Unix to do all this very securely.
0:27:51Make sure, though, that you are testing these backups.
0:27:54Make sure you can decrypt them.
0:27:55So that's very important.
0:27:57Don't store the encryption key only on the server
0:28:00because then if that server gets wiped
0:28:02or gets lost or whatever, you've lost your data
0:28:05and your backup decryption key, that's no good.
0:28:07One strategy I employ there is I write my database backups,
0:28:13I copy them onto a write only S3 account.
0:28:17So the credentials that are on the machines
0:28:20can only write to the bucket,
0:28:21they can't read or delete from it.
0:28:23So that way if somebody hacks into the machine,
0:28:25they can't also go and delete all my backups.
0:28:27So I have separate credentials that I can pull the backups
0:28:32off of there and restore that never live on my servers.
0:28:34Those stay with me and my personal documents.
0:28:36Those never live on the servers.
0:28:38So keep things as secure and separate as you can
0:28:41just by design like this.
0:28:43And that's really about it for basic security stuff.
0:28:46It really is not as hard as you think.
0:28:49And you don't have to do very much.
0:28:51You don't have to constantly keep on top of your servers
0:28:54and be constantly babysitting, for the most part,
0:28:56you set it up and it basically runs itself.
0:28:58And if you set it up with sensible default
0:29:00using conservative software and some basic security settings
0:29:03like what I've said here, you can be pretty much fine.
0:29:06- Yeah, exactly, and I think that it's the kind of thing
0:29:08that if you can't do this kind of thing,
0:29:12and if everything that Marco just ran through
0:29:15is complete gibberish to you,
0:29:17you should probably do something about that.
0:29:19It's an important skill to be a developer,
0:29:21to understand some of these basics,
0:29:23sort of like the fundamentals that run the internet.
0:29:26Like, you should understand what this is
0:29:28and to sort of take control of that.
0:29:30And like you said, just get a $5 like,
0:29:35VPS somewhere and start messing around
0:29:36and start seeing, you know, learning.
0:29:38'Cause that's how most people learn this stuff.
0:29:40You just start doing it and you get better at it.
0:29:43- All right, we're out of time this week.
0:29:45Thanks for listening everybody.
0:29:46And next week we're gonna go into a little more detail
0:29:48about our server setups, lessons we've learned,
0:29:51and how to minimize the workload.
0:29:52We'll see you next week.
0:29:54- Bye.