4 ms·
> Moreover, the costs were predictable: for a given year and # of users, you knew exactly what you’d be spending for that level of support. No surprises. No une
by deathanatos 3y ago
> Moreover, the costs were predictable: for a given year and # of users, you knew exactly what you’d be spending for that level of support. No surprises. No unexpected weeks of having a developer doing nothing but troubleshooting a failed migration on a team-essential service.
This just doesn't hold for SaaS. That's the promise of SaaS, but again, IME, it is not how it happens.
I spend a fair portion of my time … I'd say ~1h / week, sometimes 0 but sometimes >>0 … dealing with SaaS systems not behaving the way they ought to. But unlike "owned" systems, often I'm stuck playing support ticket monkey — if the SaaS even has a function support system — and trying to get somebody else to care enough to look, often trying to get somebody else to care who you have to influence indirectly through some "customer success manager" who cares only about closing this ticket as soon as a technicality¹ will permit.
To me, SaaS & owned are nigh identical in this respect: it boils down to the quality of the actual thing at hand. Some owned systems I've used are rock solid: they do their thing, they're more or less bug free, they consume essentially none of my time. But some owned systems are just a time drain. SaaS is the same way: some are rock solid (I'd put S3 in this category) and some are simply not; I know a good number of my support tickets correlate to the same system.
¹Particularly version churn: "we have problem X" → "oh, you're not on the latest version of the SaaS ticket closed → we upgrade → we reproduce X on the new version → refile the ticket → "oh you're not on the latest version of the SaaS".
- BlueTemplar 3y agoWait, how can this version churn even happen : don't they have a range of versions they support between open beta and long term support ones ? Unless the "long" term support one has a comically short term ??
- Radim 3y agoThe OP may have – unwillingly and unwittingly – become a part of the SaaS product's testing team. This happens more often that people realize. Behind the scenes, SaaS can be a shit show: Customer files a ticket => SaaS devs cannot reproduce (or don't bother to reproduce) but fix the presumed bug maybe => a new SaaS release => notify customer to upgrade, close their ticket => wait for response from the customer to see if the fix helped. Rinse & repeat, act aloof. Pretend it's the customer's fault all along.
- deathanatos 3y ago100% I've been in that cycle.
- deathanatos 3y ago> don't they have a range of versions they support between open beta and long term support ones ? Clearly not. Azure AKS is in this category. I think the upgrade cadence is (roughly, it isn't always the same) once per every 3 months, or you'll end up on an unsupported version. The support window is longer — about a year — but that's really only how long you can put off an upgrade if you're at the top of the window, and it's not sustainable. (And if you're running on fumes like I am and at the back end of the support window, then it's effectively 3 months of support, then I have to upgrade or the support ticket gets closed.) (Further, AKS has restrictions/gotchas that can prevent you from upgrading. That won't stop support from closing tickets though! We had to abandon & recreate an AKS cluster due to that, and it was a quarter of work for me.) Azure Gateway: we have a gateway from them that is simply no longer supported. They have other "SKUs", but there is no way for us to transition from our current SKU to a still-supported SKU. (Short of outright deleting the gateway and recreating it, which would be such a colossal pain that at that point I'm self-hosting.) RDS, although this was a few years back; it seemed like that was the only response we ever got from them in support tickets. It seemed like new minor versions rolled out pretty frequently. (IIRC, on the order of monthly.) (We had several issues with servers ending up with the wrong certificate, as well as with failovers exceeding their SLA.)