Ask HN: How many servers do you manage? | Hacker News Reader

Ask HN: How many servers do you manage?

I personally only run about 5 for my various websites/services. If I had finished about half of the projects I've started, that number might be closer to 50.

Although I don't spend much time managing the servers themselves, I can see how it would eat up a lot more time with more users and less organization.

A few things I'm curious about: Are you counting servers you run at a company, or ones you use for your own side projects? How do you manage them? Manually, scripts, enterprise apps, or something else? What's the primary function of your servers? Front-end web, databases, back-end, etc?

I'm asking b/c I have a couple side projects almost ready to be launched, so I'm wondering if there is a better way I should be managing all these servers. Thanks!

View on HN

I would go one of two routes.

1) Learn ansible. Then you can manage a fleet of servers with 1 set of scripts. Have a single ansible stack for all of stuff, and you can do simple tasks easily. Consistency is key, try to minimize the number of special flowers. i.e. pick ubuntu 16.04, then use it everywhere. Not much benefit from half ubuntu half debian.

2) Pay for someone else to do the server stuff. Could be Google Container Engine or elastic beanstalk or Heroku.. You will pay more money, but need to learn less stuff.

The better choice depends on your tradeoff of learning to do things yourself vs just paying an easy tax.

I'm currently using Fabric (with nothing else) but have eyeballed Ansible. Does it completely replace Fabric for you, or do you find yourself complementing it with something else?

You can manage servers manually but it's kind of like supporting applications without tests. You're going to spend an order of magnitude more time dealing with problems especially if you ever need to add a new server. You can get away with manually managing servers until you're responsible for ~50 servers. At that point you're going to need to invest in automation.

For automation it's best to use either configuration management like Puppet, Chef, Salt or to invest time in orchestration tools like Ansible. Ansible is probably the easiest to get started with as it's just yaml configuration files. In general, while you can use code-based tools like Fabric, you'll spend a lot of time rewriting functionality that already exists in ansible. Please note that most orchestration tools let you write OS-specific code whereas configuration management is great if you're managing 2 or more different OS'. If you do need to manage Red Hat and Ubuntu consider standardizing on one platform or using a configuration management tool

Honestly, PAAS like Heroku are great if you just want to work on building applications. They take care of the complex stuff, including making sure that your infrastructure is secure. And if/when you're ready to manage servers yourself you can move from them pretty easily.

I support 100 < n < 150 servers for 6 hours of a chase-the-sun rotation.

I'm personally responsible for around 40 servers, across 5 cloud locations, providing a backend to ~5 products.

These are all configured with the same software stack: a DB, an LDAP running on top of that, and a web service or two for interacting with the data.

We have deployment, configuration and monitoring systems (avoiding naming specific products as it'd be easy to figure out my name, etc...) and avoid touching the live systems directly wherever possible. Chances are, if something needs to be done for one system, it needs to be done for all (can schedule individually), and it keeps things consistent. In case of failure, we know we can consistently redeploy our systems (assuming data backups are available).

At my day job, running >100 servers.

Those include

Web facing servers (Nginx+Rails) SOLR clusters MySQL clusters Memcached Redis

Most of the instances now include Docker images running on them, those host microservices that the main application is communicating with.

Everything is managed by Chef (including Docker orchestration), CircleCI for testing and deployment (Docker push and provision to the servers as well).

For side projects, I always choose Heroku for the simplicity of things, nothing really beats it for what I need.

I also have Digital Ocean with nginx on it, that's where my blog is hosted, proxying to S3 files.

I have been using AWS Elastic Beanstalk for deployments. After the inital config, tt has taken all the work off my plate. Closest to the Heroku 'git push heroku master' experience I have got on AWS.

I have got a few small projects each with 2-3 servers running at a time. Elastic Beanstalk manages load balancers with auto-scaling.

last job 90 servers in different environments. Everything was managed via ansible. Once you have everything automated it it is a breeze to support and environment.

Run your own projects (if they aren't important) on shared hosting like webfaction(supports python etc).

Manage 4 using fabric scripts.

A few hundred. Automation, FOR THE WIN.

We use Chef, at this customer.

For another customer ~30 machines. Ansible there.

Reply on news.ycombinator.com