It is late in the year 2014, and for the past several years the various vendors have been preparing their cloud solutions. Amazon lead the charge and pretty much set the industry standard with EC2 and now all the vendors are following suit, and the CIOs and CTOs have to figure out how best to integrate cloud into their IT strategy. Those that have built careers by building out huge data centers, strategically placed across the globe with thousands of purchased servers, are finding it difficult to transform.
The idea of cloud is simple… its infrastructure as a service (IaaS). You need a server, you go up to the cloud and provision one, and a few minutes later you receive the details and credentials to connect, and you are logged in and installing the packages needed to support the application stack. You need ten servers? A hundred? No problem! The cloud provides all you need, and the supporting services, like virtual networks, storage, directory services, etc.
Gone are the days of old, where you had to wait months for hardware procurement, followed by weeks for the various infrastructure silos to rack/stack/blast/config your server and hand it off to your AppDev team. Let’s not forget about the weeks that get tagged onto that provisioning cycle for the various approvals and sign-offs.
No, we don’t do that anymore. Now you can chop months off the time-to-market for your great new business enabling technology idea… or at least that should be the case. The challenge is the infrastructure camps have resisted embracing the cloud because that would require they reinvent pretty much all that they do; and they have spent 20+ years learning how to be a server provisioning/deployment shop.
There are valid reasons to take pause and do a lot of research and deep planning on your cloud strategy. In order to successfully integrate the cloud into your IT business model, you will have a lot of issues to resolve in the regulatory/compliance/legal/hr/risk/ITsec areas. All of these corporate executives know that their best interests are served by not letting data reside on third party systems — which means a public cloud service is out of the question. Or, perhaps you can come out of those deep discussions with agreement that data can be assigned to categories, and certain data can reside in a loud, but some can’t — which is good, but you now have created another thing that needs to be policed and audited. Or, you might be able to sell the idea that an encrypted VPN to a cloud, plus the cloud vendor agreeing to ring fence your cloud components completely — which also would need to be policed and audited.
Yes, the cloud solves a lot of problems, but creates some risks and requires a lot of stuff to be thought about and ironed out. The time to do that, obviously, is before putting out the capital expense. You can’t really even decide what kind of cloud you will have until these discussions have happened. It is either going to be 100% in the public cloud (not likely for most companies), or 0% in a public cloud and 100% in an internally grown cloud, or some combination of the two.
The problem with the latter two scenarios, where some form of internal, home grown cloud is in the strategy, is that the internal cloud needs to be designed, built, deployed, and operated by the same infrastructure folks that have spent the past two decades convincing themselves that a 4 month infrastructure procurement and deployment cycle is perfectly fine… and the same infrastructure organization that at this very moment probably can’t provide transparency into the exact makeup of your allocation charges.
I don’t mean to sound critical of infrastructure organizations, but the scenario I just described exists all over the place in the largest corporations across the globe. As a result, senior managers in infrastructure now have to figure out how to build a cloud that is as mature and well-thought out as Amazon’s EC2 whilst starting a decade behind.
You are competing with Amazon’s mature, battle tested cloud solution because your AppDev teams have been playing with it at home, or they came from jobs that could leverage Amazon’s public cloud. They know that procuring a Windows or Linux box should take about 8 minutes. They know that they can expect to be charged 17 cents and hour, and only be charged when the server is powered up. They know that they need to design their apps to scale out and have the app know how to create more servers in the cloud to accommodate workload peaks and scale down to reduce cost.
All of that means your cloud needs to be able to do all that. Automated provisioning and decommisioning, fully baked cost allocation models, an API, etc. You have to be able to scale the capacity of the underlying hardware infrastructure accordingly and make that transparent to the app layer — because a cloud that is “all filled up” and can’t accommodate new provisioning/growth requests for four months while more SAN shelves and/or hypervisor hosts are being procured would take the business right back to the old days of yore.
Tom C