There is a lot of talk about technical debt – that thing where systems have been allowed to run because, well, they work. Why poke a sleeping troll, or whatever that saying is. Don’t fix it if it ain’t broke.
But this leads to technical decay that can be hard to quantify and hard to pull into any kind of plan. If you think about it, how do you plan for “we need to update this thing because it’s getting old, but I realize it works right now…”
It’s a tough budget item to sell, to say the least.
The cloud, and particularly SaaS and managed services. The reason this can become an issue is that these services are managed, out of sight, out of mind, and just work. You don’t even necessarily have to keep doing maintenance patches; they may be done for you, or you may find that you miss those updates just because it’s running just fine, thanks.
This is quite dangerous. It’s a risk because patches can indeed get missed. Technology updates can be missed. If you look at hosted servers, you may quickly find that you have a server (or more than one) that’s 2008 r2, another running other versions, everything from the earliest you have up to the most recent Windows Server… all because when you turn it on, set it up and let it do its job, it just works. It’s not sitting in your facility, it’s “out there.”
The same is true for SQL Server. Updates in SQL Server that are minor releases often can be automated and dropped into place on maintenance windows. But more major updates (full version releases, for example) can be more tricky to update. Downtime may be involved, and certainly testing should be done to make sure your systems are going to be ok with the update (or do changes to make them be ok with it).
Of course the same is true of your application development. Continuous development is a nice thought, but of course, budgets and ROI play into the continuous updates. And at some point, someone is going to bring up “change for change’s sake isn’t necessarily good, why not let it just run?” – and you’ll be in a tougher spot.
Leaving applications and systems in an older state is a critical mistake though. Security issues are in custom software, in older OS versions, in SQL Server, all of it. They’ve been addressed by patches whenever possible, but it’s more than patches. It’s security protocols (TLS for example and how SSL is managed/handled) and other approaches that mature. It’s updates to functionality. Mobile support. Dropping flash support.
All of these things and 100’s if not 1000’s more, are in play at any time. Having a continuous look and process for updates on your systems is a critical business requirement.
What’s more, if you are using a cloud provider, you may find that they have added new capabilities, new features, new solutions that you really should be considering for your systems. Not because it grows your bill (although…) but because they’re best of breed. Do you have a web application firewall in place? How is your security set up? What about access to your systems?
All of this is simply to say that “set it and forget it” is both a tendency and a curse. It’s just too easy to let things run and let them do their job. And no, not saying you should break things, just that what was good enough recently, may soon be a debt that can bite you at a time when you’re not expecting it if gone unmanaged.
