This Industry Insight is the second in the series covering “building the cloud”. In my first Industry Insight, I covered some of the aspects of strategising exactly which services a company would like its cloud to offer. In this Industry Insight, I will examine how to take these inputs and translate them into a design.
The onramp to cloud should not be steep.
Gareth James is solution strategist at CA Southern Africa.
The “design team” would need to have more of a technology focus; their task will be to translate the strategic requirement into a practical, achievable technical solution.
The inputs to the design team would be the services the business wants to offer as a cloud service. An important aspect to include for those services currently offered using traditional architecture is the current cost to host the service. This cost provides a guideline and places the requirement in context. The first service that a company offers may well cost more to host as a cloud service, but having built a cloud platform, then the second or third service should break even and all additional services should see the business realise savings.
This first step towards a cloud solution should be a services cost. An appropriate design should see the company start small and scale hardware and software resources as required.
Cloud on the brain
The key aspect the designers should consider is that the solution should be created with cloud in mind. As far as is possible, both hardware and software should be bought utilising a pay-per-use model. This means the design should scale modularly. This concept is harder for a technical audience to accept - they are usually risk averse and used to building “head room” into every project.
Remember, the onramp to cloud should not be steep. It is this up-front cost that is one of the greatest inhibitors to cloud adoption. Standardisation of services is another aspect that directly impacts the cost basis. Wherever possible, services should be accommodated in the same way, using a template-based model.
When receiving the service inputs from the strategy team, the first thing the design team would do would be to categorise the services, and the initial categorisation would be to place the service in three basic categories.
Firstly, there are those in the “not now” category - delayed due to technical or business reasons. Secondly, those in the “cloud broker” category - those where it would be simpler, cheaper or better implemented using another existing third-party cloud service. Thirdly, there are those which the business would like to host as a private cloud service.
The readiness assessment performed during the strategy phase should be high level, with a business focus. During the design phase, a more rigorous technical readiness assessment must be performed. It is a good idea to keep this separate from the strategising phase, otherwise the company runs the risk of the strategy being bogged down in technology details. A feedback loop to the strategy team will now highlight required changes and any risks. The strategy team can then make an informed decision on how to proceed.
When designing a cloud, the design team will need to first to settle the question: “What characterises cloud for the organisation?”
Cloud clarity
There will of course be those who would like to create their own definition of cloud - one which would suit the path they would like to take. So, which definition should be followed? The US NIST (National Institute of Standards and Technology) definition has become the de facto standard to which most organisations adhere.
Most technology vendors use a slightly modified version of this definition. The five essential characteristics are listed as: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Of the five, broad network access and resource pooling are those which are typically not difficult to achieve. Providing a self-service portal to users that can do automated provisioning is the one that is desirable for the business, but typically has the most push back from the technologists, who don't like to relinquish control. Measured service is essential if companies want to calculate the true cost of service; this should specifically measure usage of resources like RAM, CPU and bandwidth. Billing on a user basis is a poor compromise, as it doesn't reflect real usage. Rapid elasticity is the “essential characteristic” that is often misinterpreted. Rapid elasticity should mean the design should easily scale to accommodate more capacity. It does not mean the company should build a platform with lots of idle extra capacity.
I do realise that I have gone back to first principles in outlining the cloud characteristics, and it is because the risk here is that companies could dilute the value that cloud brings. Many have claimed to have cloud, but in fact have hosted virtualisation, which is run using the same traditional financial models, but perhaps with a greater degree of efficiency. I have seen designers want to pare back these cloud characteristics, due to higher up-front design costs. This is false economy, as they will ultimately sacrifice the long-term cost savings of cloud.
Agility is the first victim of a poorly executed cloud design. And innovation will also suffer due to the rigidity of failing to incorporate the required flexibility in the design. My final thought is this; as with many things in life, good foundations are essential, and the design should cater for all the requirements of progression to a cloud-based delivery model.
Share