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.
19 Comments. Leave new
Unfortunately with some of our customers we have to deal with the fact that they will be driving their servers into the ground (10+ years) and spec them accordingly…
I was once told by a wise elder that any new application/system has an average life expectancy of about 7 years… Is this a fair estimate?
Eric – that’s a great question. If you look around your environment, what does the average age look like?
Well, we collect stats on every SQL Server database and we capture the date the database was created and I came to an average of about 4 years … interesting.
I’m a big believer in the limited-lifespan app…I think 7 years is a good rule of thumb. By the time an app hits 10 years old, it’s almost always well past time to replace.
Storage, too. Tease out the refresh/depreciation schedule during planning. Make sure they’ve got a strong plan for migration to the refresh system in 5 years (or other reasonable
(Happy fingers on the last incomplete version of this comment)
Storage technology should have an expiration date, too. Tease out the refresh/depreciation schedule during planning. Make sure they’ve got a strong plan for migration to the refresh system in 5 years (or other reasonable refresh timeline). Don’t do SSDs within the array unless needs within that timeframe show they’ll be valuable. If they will be valuable, use them where they’ll deliver value and don’t over-commit. Over-investment in today’s technology is one of the biggest inhibitors I see to organizations refreshing their technology appropriately.
Well written Brent. I’ve been at my current company for just over 3 years, as the primary (and 66% of the time – sole) DBA. In that time, I’ve done a lot to make it a lot easier to pop in new hardware / software. From documenting the logins and access levels, to making it “policy” to build new physical servers with HBA’s and databases on SAN disk, to using DNS CNames for use in Connection Strings rather than NetBIOS names.
Most of my focus has been combating “SQL Sprawl”, but I had enough foresight to work on increasing density while working towards limiting the pain of having a shared SQL Servers impact larger business functions than standalone and one-off database servers have.
Brent,
Thank you for the post. They are always very informative and professional. I agree with you about the importance of this issue.
In the majority of the shops I have worked, nobody knows or nobody cares about expiration dates and other important requirements. Usually there are very few requirements to start a project but nevertheless we start it.
Maybe ignorance, maybe lack of time, maybe managers don’t know how to and, as a result, they don’t ask for definitions and answers to very important questions. Expiration date definition requires a very good understanding of the business and technical environment.
Expiration dates not only for servers but for the other IT stuff is a kind of a politically incorrect question. You have to be careful if asking too many smart questions or you can end up with updating your resume.
I believe it will be very interesting if you go deep in more details on the how to calculate the expiration date of your Server and even more important how you would decommission your old servers with the least disruption to the business.
Thank you again,
I’ve written on this as well in the past. Some companies have hardware refresh cycles – the easiest form of server expiration. That could be tied to many things, not the least of which is financial.. But for those who don’t have such a policy, it’s the proverbial Wild West out there. The average production system is in play anywhere from 3 – 7 years in my experience. Then you have the offshoots – dev, testing, staging, etc. So it’s not just one set of prod servers we’re talking about.
Another big factor is security. It’s one thing to use outdated stuff. It’s another when your software is no longer supported and you don’t get security fixes. Companies don’t think about that. MS publishes their lifecycle for all products; most people have no clue it’s there or follow it.
Heretic!
The business is my patron, not my employer!
That’s like a Galileo thing to say Brent. Thanks for the orbital reference check! Sometimes we forget where the sun really is.
we still have beige compaq boxes running some applications that date back to 2000 and 2001
everyone always wants to keep on using a server but if a new app requires a newer version of the OS then they have to buy a new server. our rule is we never upgrade the OS on a HP server. NEVER.
tried it years ago and had too many problems with the HP software
oh, that’s very nice that Microsoft already prints the expiration date on the packaging (2000, 2005, 2008, 2012, 2014). I used to think is was only the product name…
Nice way to summarize it all… but wait the minute, we haven’t upgraded all sql 2005s to 2012 or even 2008R2 and 2014 is on the horizon. I’ll never have to worry about job security 😉
We lease our equipment, even workstations…that gives you a convenient, enforced 3-year upgrade cycle.
Hi Brent.
On my job half of the servers are 2000 and 2005. 🙂 Just a few 2008 and 2012. however we are planning to buy or implement PDW 2012 (Parallel Data Warehouse). Brent, what do you think about it?? and in you opinion should i focus more on sql server or pay attention to PDW device because that’s what’s new from Microsoft.?? SQL server will be replace by PDW in 5 years from now??
Thanks Brent.
Alejandro – no, SQL Server definitely won’t be replaced by Parallel Data Warehouse. PDW is a specialized database that’s very expensive and is only suited for a certain type of tasks. It’s like a screwdriver – it’s great for driving screws, but it’s not meant to replace a hammer. They’re both still useful. You should learn both tools and choose the one you’d like to work more with in the future, and specialize in that. Enjoy!
Thanks Brent.
as always, really good point.