“We’ve got staff here that are ready and able to deal with any kind of network or server issue. But it would take us an hour or so to get out to the colo site.”

Why would a site need to send its own techs to a remote site? What if the site was across the country? What if it was a CDN network? That’s the whole purpose of including remote hands services when one positions computing resources other than locally.

Anyway, the application, whether local or remote, needs to be architected for resilience in the case of server failure. After all, servers can fail if they’re local and, presumably, the app needs to keep providing service. Similarly for network failure, one architects for network degradation or failure.

“[If we run out of capacity we would use] a combination of the colo, SaaS, PaaS. . . We’re designing our environments and our strategies to include extending our infrastructure out into the cloud, so we’re spending a lot of time not doing capacity management and not figuring out how I would build the next data center.”

What does it mean to “extend infrastructure to the cloud?” Sounds as if “cloud” just means traditional co-location in this context.

Where is the data that the applications are reading and writing? I’m surprised that data affinity isn’t one of the top factors considered when considering using remote compute services, whether classic co-lo or true IaaS, elastic, self-service “cloud” compute/store/network.