There's a degree of fibre path convergence due to our premises location (only one practical approach, without spending six figures to trench through a very, very long parking lot or trying to get easement under the Parnell rail switching yards), but it will be separate conduits going to separate provider end-points. In terms of sticking stuff into "the cloud", going properly into the cloud is a no-go because the data some of our clients provide has significant data sovereignty concerns associated; Banks, health insurers, etc. Keeping it in NZ is easier but if we can't get the data into our processing systems it's useless to us, and putting *those* into someone else's DC carries significant cost, as well as making it even more vital to have full link redundancy because if our staff can't connect to those systems they can't do their work. If any of you who have looked me up on LinkedIn have then gone and looked up my employer, you will have seen that we're not a "service provider" in the normal sense. We need to have public-facing systems so clients can push data and we can place data for them to retrieve, but we don't provide services to the public at large. I've certainly seen some good ideas come out of this, but if I just need to come up with a numbering plan to put all our networked systems onto public space I'm nearly at a /25 without even accounting for the WiFI DHCP pool or some additional system/head count increases. On 7/11/2013 23:23, Dobbins, Roland wrote:
But you're still single-threaded in terms of your IDC. Not to mention the possibility of converged fibre paths, et. al.
Other folks in this thread have mentioned moving your public-facing properties into a cloud-type deployment. This is by far the most sensible thing to do, IMHO.
And don't forget about any single-threaded issues in your middle and back-end tiers.
-- Matthew Poole "The difference between theory and practice is that practice is easier in theory than theory is in practice"