To some, the idea of enterprise data centres still being around in ten years’ time is anathema. By then, they assert, all enterprise IT will be running in public clouds. The only people who can’t see this are insecure box-huggers frightened for their jobs and IT dinosaurs with no imagination. We, however, are going to assume …
"To some, the idea of enterprise data centres still being around in ten years’ time is anathema. By then, they assert, all enterprise IT will be running in public clouds."
It appears from the tone of the first paragraph that you think such people are as silly as the box-huggers that they themselves are deriding. If so, I agree.
There is absolutely no way that the enterprise data centre as we know it is going to vanish entirely; far too many industries have either regulatory or self-imposed rules in place that mean cloud storage or applications simply would not be appropriate.
I don't get it (at least not all of it)
I do not understand why companies will be prepared to put their data - which to many companies define them, onto a public infrastructure where you have no control about who can access the data, and in many cases, cannot even tell which geographical location their data resides in (which can be important if they don't want the FBI and DHS trawling your data).
It's all very well saying that the cloud providers will ensure that your data is secure, but that is about as trustworthy as a bank saying that their traders do not try to influence LIBOR. They may not even know what individual employees are doing. At least if one of YOUR employees leak data, you can take appropriate action without a commercial contract being between you and the guilty party.
I know that you could put cryptography in place to make the stored data not useful to a third party, but that may not give you the security that you expect if your data is stored in certain territories which require key escrow or disclosure.
I can see that some services may be suitable for deployment in a public cloud, but there are, and will remain, many that are only suitable for a private cloud or within controlled boundaries, requiring physical data centres.
"We need to stop thinking about the data centre as a facility in which things are housed. It should be seen as a shared corporate resource and notional hub for coordinating the safe, effective use of internal and external services."
This is not an either/or thing. You don't do the latter by ceasing to do the former. The data centre (or, "machine room" as it's still called round here) will remain the place(s) where the disk trays live, where the physical servers/blades are, where much of the core routers and switches are, etc. Similarly, those routers will need people with certain skill sets and experience, while the servers will need people with different skill sets and experience, and different again for the storage systems. And different again for the people looking after the virtual servers and whatever else running on top of it. Yes, sometimes one person can wear multiple hats and do several of these, but expertise in all of them is just not feasible.
All of which makes this article seem very much like what already happens anyway, with a liberal scattering of buzzwords.
Seems to me, there's much more mileage in working out what you need, not what people are trying to sell you, than in tinkering with who's in what team. If the people in those teams work well together, then the team boundaries end up a bit hazy anyway. If they don't work well together, putting them in the same team won't help...
Another nitpick - to me, an "application" is something like Word, AutoCAD, SPSS, etc. Software at the client, in other words. This article (and others I've seen lately) seem to talk of things like exchange (or email infrastructure generally) as "applications". I think of these as services, or back-end components. Or is that just me?
I think it might just be you, although I don't disagree with you as it happens. Mind, it starts getting clunky in that language when you're talking about Oracle or SAP implementations.