A few weekends ago my team had the opportunity to stand up a server in the cloud using AT&T Cloud Architect, but not before we did our due diligence... or what I call "cloud counting."
Cloud counting entails assessing requirements and taking an inventory to determine what's needed from the cloud. You'll need to ask and find the answers to questions such as, "Will my cloud talk to another cloud or even another network and, if so, how?"
Assessing Assets
The placement of assets is really interesting to think about as part of the cloud consideration. Leading up to our weekend project, for example, we discussed how best to use the one server we were about to engage for a single application. Could we use it for other applications and problems? Should we deploy multiple servers first and then attempt to use virtualization?
We did identify security auditing, security reporting, and domain and file backup applications as good potentials for the cloud server, and one of the organization's core business operations could benefit from virtualizing its application and reporting functions. But, I didn't necessarily want to start off with a virtualized server and then add applications.
Another consideration that factored into our cloud counting is that the organization is migrating multiple locations to an MPLS network. Users at these multiple locations rely on the application hosted in the cloud.
Relying on cloud infrastructure, paid for month to month, works well for the organization because of timing with the transition to MPLS and other work to be done. In addition, we can easily upgrade, downgrade or disengage the server; we have the flexibility to turn on and off servers in minutes and hours.
Even the Weather Matters
But are these benefits enough to keep you counting clouds? They should at least get you thinking about how to use cloud resources to place your organization's assets, be they utility, application or essential to the core business.
Along those lines, for example, I asked AT&T how much it would cost to place a node from the MPLS network within its Washington, D.C., network operations center -- since that's the closest location to the physical address of the business. I knew latency would be low, but what price would we pay for locating a node in a particular data center?
I also took into account that the sites involved in this project are in a hurricane belt and all geographically located within a few hours of each other. That meant a key business application under development can reside within the cloud as well as on the private network. Housing a key asset locally, even with a backup, would keep me up at night. Centralizing it in a protected data center doesn't.
To my question, "Is it better to virtualize upfront and then avoid standing up individual servers in the cloud?," I haven't found any easy answers. But what I found with AT&T Cloud Architect is building what we wanted was quick and easy -- and that makes me want to keep on counting clouds and thinking about all the possibilities to build a better network and solution.
And in the end, by the way, I decided to let the single application reside on the server, which took but a few minutes to go online after we placed our order for it via the Web. A few hours later we had the application running successfully.
Follow Matt Brunk on Twitter and Google+!
@telecomworx
Matt Brunk on Google+
