Servers are like milk cartons: both need an expiration date printed clearly on the outside.
When a project needs a new database server, I ask the business users, “How long does this server need to last?”
Inevitably somebody gives the flip answer of, “Forever.” I laugh along with the group and then wait with a calm smile on my face, and eventually people understand that I’m serious. That’s when the uncomfortable part starts, because nobody wants to talk about old age. They want to assume they’ll live forever, their servers will always be fast, and vendors will always support today’s software.
Expiration dates can be calculated in:
- Time – how long the vendors support each component (app code, database server, operating system, hardware)
- Data size – we built this solution to support 100GB of data, and we could stretch it to 500GB, but beyond that it’s going to start busting apart at the seams
- User quantity – we’re predicting 1,000 users, but if we suddenly grew to 10,000, we’ll hit concurrency issues
And each component may have its own expiration date:
- Hardware – the server, storage, and even networking may be subject to increased support costs from the manufacturer when it’s out of warranty. Before virtualization, one of the servers I supported was a mission-critical boat anchor, and we bought a few identical ones off eBay to keep on the shelf as backups. The manufacturer just didn’t offer parts anymore.
- Operating system – Windows has its own end-of-life dates. If you’re in the cloud, Windows Azure has its own support policy. You won’t be able to roll out new VMs with old OS’s.
- Application language/framework/platform – Some of my clients have been excited to adopt SQL 2012 AlwaysOn Availability Groups, but then met with surprise when their third-party JDBC drivers weren’t being updated anymore.
- Database server – of course, us DBAs, this is the only one we think about.
In any given project, some people assume the solution will be carved in stone to last forever, and others are building a cardboard house to get us past an agile finish line. DBAs are a great example – often when we build solutions for others, we try to build an amazing, scalable solution that can handle all kinds of demand. When we implement our own maintenance scripts, though, we duct tape things together, assuming that we’ll constantly be revisiting them to hone and perfect them. In reality, maybe we’re doing it backwards. Let’s build our backup and monitoring tools so that we never have to revisit them, and instead put our ongoing work into the things the business really cares about.