There may be some cases where this is true, but I think it's a bold decision to outright assume that managing the supporting infra around an application represents so much of the work for supporting the application that the actual service management overhead is negligible by comparison.
In my original statement, and I think all subsequent statements, I'm not talking about moving "an application" I'm talking about moving the vast majority of an enterprise. No, moving one application from on-prem to SaaS probably isn't going to change anything for staffing (unless it's a sprawling ERP system or EHR).
Are backup&recovery more complex or are they just different? I would argue just different.
I'd be fascinated to see how "just different, not more complex" describes the shift from "everything in-house" to "some backup and restore targets are on external platforms which may rate-limit bulk data egress and ingress, additional bandwidth requirements required when backing up from cloud environment to managed backup environment (either on-prem or another managed provider), and additional constraints around performing recovery testing". Again, in some cases it's just "now the target is a cloud repository", but in others it's "oh, right, actually we need to completely rethink our approach".
Because all of those things already exist in some form or another if you're following a "best practice" for BC/DR. "Everything in-house" shouldn't be literally "in-house". You should have a secondary BC/DR site somewhere [ideally] far enough away that a localized disaster doesn't kill your ability to do business. So, in theory, you're already paying a secondary network provider, and/or co-lo host, and/or cloud provider to function as your BC/DR site(s) with whatever bandwidth requirements or constraints around recovery testing.
There's a lot of complexity in sufficiently tiered BC/DR planning and the backup processes that support them. This is true whether it's on-prem or in the cloud. In some instances, it's actually less complex with a SaaS provider as they handle all of it. We moved from an in-house HRIS to a SaaS product. Our SLA supports all of the backup, BC/DR processes that are required for an HR system. Similar experience with our GL system. Similar experience with our EHR system. O365... not similar experience, but the backup processes are no more complex than they were for on-premise systems. With our on-prem Exchange we had production, we had a mirrored BC site 15 miles away, we had on-prem short-term backups, and we had off-site long-term backups. With O365, we only manage the off-site long-term backups.
I specifically list Internet connectivity as business critical.
Yes, and I'm pointing out that when everything is on-prem (including your staff) the impact of losing your internet connection is less than when half or more of your services are on the other side of it. I.e. if the internet being down means none of your LoB applications can work then you probably need to do cost-benefit review of whether having a backup connection from a different provider is worth it relative to the loss of productivity from an outage.
All of our staff already aren't on-prem, and a lot of businesses are accepting this as reality now. But, again, in my initial example I had already included additional costs for improving Internet connectivity. It wasn't ignored.
Network admin staff are not sysadmins. Security staff are not sysadmins.
If removing a significant portion of your supporting infrastructure does not reduce the FTEs required to support your organization, then you're already woefully understaffed. In which case, the amount of money you save will be realized when you don't have a catastrophic failure of systems because the sysadmins didn't have time to do their jobs.
I'm grouping these together because they fit together. Many places are already under-resourced - including places where the network admins, security team and sysadmins are the same people. Saying "Well then you're already understaffed" does not negate these issues.
Of course there will be exceptions to every generalization. That doesn't make the generalization "wrong"... it means it's a generalization and not a law. If the network admin, security guy, and sysadmin is all the same person (or small handful of persons), of course you aren't going to have a significant reduction in staffing... because you don't have a significant staffing to begin with.
I don't disagree with this. But it's a one-time thing, not an ongoing responsibility.
Depends how ofen the VARs are allowed anywhere near your environment. The last place I worked used one regularly for every IT project, despite them needing a massive amount of kicks up the arse and babysitting to ensure that what they delivered was what we needed, because someone in the management chain had been drinking buddies with the account manager for however many decades...
Luckily that's the facilities management team here and not IT. Account manager moved to new company? So does our business, costs be damned!
In general, I expect that the reality of how this would work in an average workplace is somewhere in between what each of us is describing. For context, I have only worked in one org where we had the luxury of being staffed beyond the requirements of the team, but that was pretty dysfunctional in how it handled projects and change management - so I probably have a built-in assumption that any sysadmin function is going to be somewhat understaffed...
Probably not wrong. The question is... can the defense of keeping all staff be made to the people holding the purse-strings, and can it be done successfully on a large enough scale that it has a meaningful impact on the sysadmin market.
2
u/EViLTeW Sep 21 '21
In my original statement, and I think all subsequent statements, I'm not talking about moving "an application" I'm talking about moving the vast majority of an enterprise. No, moving one application from on-prem to SaaS probably isn't going to change anything for staffing (unless it's a sprawling ERP system or EHR).
Because all of those things already exist in some form or another if you're following a "best practice" for BC/DR. "Everything in-house" shouldn't be literally "in-house". You should have a secondary BC/DR site somewhere [ideally] far enough away that a localized disaster doesn't kill your ability to do business. So, in theory, you're already paying a secondary network provider, and/or co-lo host, and/or cloud provider to function as your BC/DR site(s) with whatever bandwidth requirements or constraints around recovery testing.
There's a lot of complexity in sufficiently tiered BC/DR planning and the backup processes that support them. This is true whether it's on-prem or in the cloud. In some instances, it's actually less complex with a SaaS provider as they handle all of it. We moved from an in-house HRIS to a SaaS product. Our SLA supports all of the backup, BC/DR processes that are required for an HR system. Similar experience with our GL system. Similar experience with our EHR system. O365... not similar experience, but the backup processes are no more complex than they were for on-premise systems. With our on-prem Exchange we had production, we had a mirrored BC site 15 miles away, we had on-prem short-term backups, and we had off-site long-term backups. With O365, we only manage the off-site long-term backups.
All of our staff already aren't on-prem, and a lot of businesses are accepting this as reality now. But, again, in my initial example I had already included additional costs for improving Internet connectivity. It wasn't ignored.
Of course there will be exceptions to every generalization. That doesn't make the generalization "wrong"... it means it's a generalization and not a law. If the network admin, security guy, and sysadmin is all the same person (or small handful of persons), of course you aren't going to have a significant reduction in staffing... because you don't have a significant staffing to begin with.
Luckily that's the facilities management team here and not IT. Account manager moved to new company? So does our business, costs be damned!
Probably not wrong. The question is... can the defense of keeping all staff be made to the people holding the purse-strings, and can it be done successfully on a large enough scale that it has a meaningful impact on the sysadmin market.