3 ms·

I'm a sysadmin-turned-startup-founder, so there's my bias right there, plain for all to see. With that, this is really, really good advice. In sysadmin-land,

by donw 17y ago

I'm a sysadmin-turned-startup-founder, so there's my bias right there, plain for all to see. With that, this is really, really good advice. In sysadmin-land, all my pain comes from software that was never written with management in mind. Assumptions like 'all TCP ports are open, all the time, between all servers', 'we can put things wherever we want in the filesystem', and 'the server should be configured just like my local workstation' make upgrades and deployment a nightmare, and are nominally difficult to change in a codebase with more than a few iterations underneath it. Oh, and my other favorite pet peeves: Applications that provide no easy way to verify whether or not they are, in fact, up or down, and having debugging information dumped into the logs marked as errors, rather than as debug messages. Keep in mind that these won't bite you in the ass initially, when you're only on a single server, or on a small, tightly controlled cluster of boxes. They'll torpedo you when you need to scale up, and you'll get a second shot in the boilers if you ever need meet any number of regulatory standards for various industries (PCI, HIPAA, etc.). Fixing these early-on is easy, and you can enforce scaling-and-deployment friendly coding practices through automated unit testing and CI. Won't even really cost your coding team any extra time. Fixing them down the road, after you've got a few thousand live customers and a big pile of codebase to dig around in, is... difficult, at best.

_pius 17y ago
In sysadmin-land, all my pain comes from software that was never written with management in mind. Assumptions like 'all TCP ports are open, all the time, between all servers', 'we can put things wherever we want in the filesystem' ... One good thing about Heroku, though, is that you essentially have to do a lot of these things properly from the beginning because they enforce a shared nothing, tiered architecture. For instance, you can't write to the filesystem, you can't set up some poorly secured e-mail server, you can't have arbitrary daemons running. In general, every process that isn't core to the web stack must be executed in a completely different tier. Obviously you can still shoot yourself in the foot with poorly written SQL and other things, but a lot of the "sys-admin" type mistakes are avoided by enforcing best practices when you start with Heroku.
pmiller2 17y ago
Someone needs to expand upon this and make a blog post out of it. I, as a non-sysadmin, feel like I got an education after having read just these few points, but that's just made me feel even more ignorant than before. :/

by donw 17y ago

_pius 17y ago

In sysadmin-land, all my pain comes from software that was never written with management in mind. Assumptions like 'all TCP ports are open, all the time, between all servers', 'we can put things wherever we want in the filesystem' ... One good thing about Heroku, though, is that you essentially have to do a lot of these things properly from the beginning because they enforce a shared nothing, tiered architecture. For instance, you can't write to the filesystem, you can't set up some poorly secured e-mail server, you can't have arbitrary daemons running. In general, every process that isn't core to the web stack must be executed in a completely different tier. Obviously you can still shoot yourself in the foot with poorly written SQL and other things, but a lot of the "sys-admin" type mistakes are avoided by enforcing best practices when you start with Heroku.

pmiller2 17y ago

Someone needs to expand upon this and make a blog post out of it. I, as a non-sysadmin, feel like I got an education after having read just these few points, but that's just made me feel even more ignorant than before. :/