4 ms·
I'm going to comment solely on the adoption of Dev Ops, which I personally consider to include change management, incident management, deployment, monitoring, m
by pedoh 15y ago
I'm going to comment solely on the adoption of Dev Ops, which I personally consider to include change management, incident management, deployment, monitoring, metrics, and file distribution.
I believe that the barrier to adopting solid Dev Ops practices is so low that for most startups, adopting them early is a smart move. Sure, today, your startup doesn't need to use Puppet or Chef to ensure that all of your servers (whether they're VMs or baremetal) are running the same pieces of software with the same configuration files, because manually installing those is easy. Once those same VMs have had features X, Y, and Z added to them, and files have been changed over and over, and then all of a sudden, you need more servers because your startup has been featured on Hacker News, you're probably going to need to re-invent the wheel and figure out all of those steps that you've done to your initial servers. Puppet and Chef make consistency across your entire environment possible, and getting them up and running is not difficult. Puppet (and probably Chef, although I'm not Chef fluent) can be run in serverless mode, if desired, too, which makes the installation and use even easier.
If you manually manipulate your servers now, you're going to need to automate later. You might as well spend a little time creating your "Dev Ops way" now, so that when tomorrow comes, you'll be spooling up identical servers that are monitored and have metrics coming out of them, you won't break a sweat, and you won't be awake at night wondering if you'll be able to recover fast enough when the Hacker News crowd comes and plays Mozart on your servers.
Here's a simple Puppet conf file that makes sure /etc/hosts is identical to /tmp/files/etc/hosts (untarred from a tarball):
file "/etc/hosts": {
source => "puppet:///tmp/files/etc/hosts"
}
That's it. Now of course Puppet gets more complicated. I'm using Puppet to do our code deployments backed by a MySQL database for the puppet node classifier. I can take a stock installation of an OS and bring it up to spec with the proper users, packages, our applications, config files, et cetera with a click of a button. But you can start small and simple, and as your business grows, so can your Dev Ops infrastructure. And it may very well be that your Dev Ops infrastructure doesn't need to grow very quickly. The barrier to entry, though, is so low, that for many if not most it is worth the minimal amount of time spent to get a simple and scalable method of deployment up and running.
The open source components of my Dev Ops stack consist of:
Puppet (http://puppetlabs.com http://puppetlabs.com) - Create and maintain files, packages, services, mounts, et cetera. Same on every server, every time.
Nagios (http://www.nagios.org http://www.nagios.org) - Sets our email inbox and cell phones on fire when there are problems.
Graphite (http://graphite.wikidot.com http://graphite.wikidot.com) - Fantastic metrics collection and display software.