>Companies can't be supporting ten generations of gadgets.
Yes they can. Car companies support ten model years and more just fine, and keeping servers alive is a lot easier than constantly replacing mechanical parts.
Yes they can. Car companies support ten model years and more just fine, and keeping servers alive is a lot easier than constantly replacing mechanical parts.
This sort of logic is enshrined in consumer law as well - the courts idea of a reasonable lifetime for a product is tied to the amount you pay.
If you buy a $50,000 car new, sure, a reasonable person could expect it to last 5-10 years.
You buy a $200 webcam? I somehow doubt you'll be able to argue that it must work 3 years later - if it does, great. If it doesn't, well, what's a reasonable lifetime?
And a lot of armchair commentators seems to underplay the amount of sheer engineering effort or cost involved in these sorts of things - it's not a case of spinning up some AWS instances, and hacking together some PHP on your weekend and deploying.
To get a reliable service, with some decent SLA, which handles changing load and tolerates failures probably takes significant infrastructure (cloud or bare-metal), as well as a team of software engineers and site reliability engineers. Not to mention support teams.
I see this all the time with people that know zilch about technology, but it really disappoints me when I even see my fellow technologists underestimate the amount of engineering effort it takes to get something simple like a server up and running reliably.
Computers don't exist in a vacuum - the environment is constantly changing.
Let me put a real-life example.
Say there's a new SSL vulnerability or zero-day discovered - you go and check to make sure all your servers and packages are patched. Or maybe there's no patch yet, and you need to run a mitigation.
You better go check all your logs, to make sure nobody got in already though. Hmm, maybe you should contact your NOC as well, just in case.
Load just increased - you better spin up some new servers. Whilst AWS might like you to believe this is all one-button and it works with no human intervention - it probably isn't.
Oh, drat, one of the uptream endpoints you rely on just broke their API. You better whip up a patch. Then you need to test it, and make sure your CI server passes all the tests for it. Oh, and then hire some testers.
The point is - things are more complex in the real world, particularly running at any kind of scale.
I just had to pick this one. Five years for a car? I expect clothes and computers to last 5 years, for $50k car I'd expect 20-30 years with proper maintenance and repairs. Not that I'd likely use it myself that long, but the expectation would still be within that timeframe.
Or if you buy a shirt and wear it for 5 years - you'd go back to Kmart after 5 years and say, your shirt wore out, give me a refund?
The sense of entitlement in that statement is...pretty high. I'm just going to leave it at that.
If I expect shoes to last 10 years, I'm also prepared for some basic maintenance such as regular polishing and the odd sole replacement. The same obviously applies to car repairs.
If they sold it to me with the claim that the drivetrain had a lifetime warranty, and the fault was there?
Yes.
Not exactly; in the UK it's tied to "reasonable expectations" for that kind of product. Certainly non-smart heating controllers would have an expected life time of 10-20 years, so why do the more expensive smart ones get away with a lifetime of less than 3?
Heck, even 5 years?
All of this for some cheap widget? (I assume from your description it's cheap).
If you can find a single case (or similar case) where this happened, I will stand corrected.
If this was a $2000 laptop, I can absolutely see that - e.g. Apple Macbooks in Australia have a statutory warranty longer than the manufacturer's 1 year warranty. But I think you'd be hard pressed trying to claim after 3-4 years that it should still apply there. And this is for a $2000 laptop.
Here's an example of how it often works in practice, although on a shorter timescale: http://forums.pepipoo.com/index.php?showtopic=52242
Laptop power socket fails within 6 months. Is repaired, fails again. Demands refund, is refused. Takes company to small claims court; they fail to mount an effective defence and are in any case in the wrong, so he wins £400+costs.
Almost a million ford F-150 trucks were sold in 2006 and most haven't been 'rewritten' in the intervening years. Also, each repair event comes with new money. Neither of these conditions is true for server software.
Server and package vulnerabilities get discovered all the time.
And load is never constantly - it's not like you have 1000 users, and they do the same thing every day, 365 days a year.
And there are an army of script kiddies out there trying to break into your servers. Or maybe somebody more skilful, trying to break in and steal some PII (personally identifiable information).
Point is - the environment and your users are constantly changing. If you don't take that into account, it can blow up pretty bad.
Load isn't constant, but if you're not selling the device any more it's doubtful you'll have significant load increases after the first year.
Shutting down a tiny fraction of your servers isn't going to protect you against hacking.
Worst case scenario: Remove all PII from the server, and have a single employee spend a few hours a week checking on the server and updating anything necessary. It might go down occasionally, but it's infinitely better than no server at all, and it costs basically nothing compared to the original development effort.
There's much more to running a product than 'running a server'.
Eventually, the software is going to stop working on my SOE. Which means more and more boxes are going to be running non-standard deployments in my environment (or it costs me to update). Every maintenance window, infrastructure upgrade, disaster recovery exercise (and event), has to take those servers into account.
Perhaps I pay licenses for those servers to run - OS, support, databases, backup, whatever. Maybe I have a contract with an SI to run all this as a managed service and this costs. There's opportunity cost in terms of resources for keeping all these legacy products on as well - both infrastructure and resource related.
And that's just the technology related part of it. There's business and accounting impacts as well.
If you're fussy about nonstandard servers on your infrastructure, go get a handful of basic servers from hetzner or amazon. Completely silo them. No access from them to your 'real' servers, and don't include them in maintenance windows or disaster recovery. The person who is paid to spend a few hours per week keeping the server mostly-up will use part of their time on basic updates and backups, and nobody needs to worry if something occasionally breaks.
> Perhaps I pay licenses for those servers to run - OS, support, databases, backup, whatever. Maybe I have a contract with an SI to run all this as a managed service and this costs.
If you have license/contracting costs, you should have pre-allocated money for that when you released the product. If it sold to expectations, a later decision to discontinue the line shouldn't be a problem.
> There's opportunity cost in terms of resources for keeping all these legacy products on as well - both infrastructure and resource related.
There should be no infrastructure impact, and the equipment/employee cost should have been part of the initial product scope, not treated as an externality that can be trimmed at will.
> And that's just the technology related part of it. There's business and accounting impacts as well.
Like what, having to process a quarterly bill for the servers?
Let me put it this way: While the costs are real, they were expected, and can be made pretty low. They should be able to run or outsource a basic legacy server without any hurting. I bet if there was a contract saying they had to refund $2 to every customer for every month the servers were down, they could get plenty of offers to take over hosting for half that price.