What an interesting question and resulting dialog!!! Thanks for getting this kicked off Carl and for all those participating.
I see a few different threads going on here and I'll see if I can sort them out a bit.
I'll first note that I assume that there is still software being developed by said company. If a company has stopped building software and instead is using only SaaS services, then sure, they'll probably need very few "IT" people. I will say, though, that in the era where software is a differentiator, sometime THE differentiator, I see it going the other direction - companies are building MORE software themselves rather than less.
Okay, so with that assumption established, here are a few scenarios:
1. Company moving out of their own data centers into cloud data centers.
Now, this does not mean they are going “cloud-native.” I make the distinction in the book between “cloud” which is more about the where
of computing and “cloud-native” which is how
1a. A company moving to the cloud can take all of what they have today and simply run it in someone else’s data center. Here I totally agree with Tim that your IT load is not likely to decrease very much. Sure, you’re not racking and stacking hardware anymore, but you are still provisioning and managing the compute, storage and network needed for your software.
1b. If, as a part of the move, the company begins to change their software, leveraging some SaaS services for things like databases and messaging systems, then it is possible that they can move some of the responsibility from their own IT to that of the SaaS (cloud) provider. Take a database, for example, the database provider is going to take care of things like upgrading the DB servers, patching vulnerabilities, etc. but your apps that are leveraging that DB, well, all of the lifecycle events around that won’t be managed by the SaaS provider - that’s still on the company building the software itself. Now, without getting into all of the details, I would point out that:
it might be the “application team” (some might call them the DevOps team) rather than some traditional ops team that is doing that management. And 2) that the trickiest thing is that with responsibility for management distributed across the SaaS provider and the company building software that depends on that service (i.e. the database), there is a non-technical problem to solve here; have to figure out what these new operational practices are. How coordinated must the folks managing the DB be with those managing the software that uses it?
2. Company is going “cloud-native.”
That is, they are building software that is far more tolerant to change (I almost like the subtitle of my book better than the title “Designing change-tolerant software”). Now, whether that lands in the public cloud or some private cloud, there are implications on the staffing in IT. If private cloud then you still need folks to manage things like the compute capacity (served up by something like Kubernetes, Cloud Foundry, Google App Engine, etc.) and services (like databases, messaging, etc.). If you are in the cloud, you could use some of the same services I talked about in 1b above. What is most interesting in this case, though, is that when your software is more tolerant to change, then that allows you to more loosely couple the management of the services from the management of the compute. It get’s back to the question I posed above:
How coordinated must the folks managing the DB be with those managing the software that uses it?
Really, only once they are more loosely coupled can IT resources be shifted.
So in broad summary:
* If you are going to the cloud but not cloud-native: probably little reduction in IT staff
* If you are going cloud-native in a private cloud: probably little reduction in IT staff, but roles change and efficiencies can be achieved.
* If you are going cloud-native and to a public cloud: you could offload some of the IT responsibilities to the cloud provider. (Even here it’s not a given - need to be deliberate to achieve such things).
Thanks again for the question and dialog. Super fun!