Bricks and mortar

In my first Industry Insight, I covered the strategise phase of 'building the cloud', and then moved on to the design phase in my second Industry Insight. Here I will discuss the build phase.

One of the key benefits of cloud is cost reduction.

Gareth James is solution strategist at CA Southern Africa.

Building a cloud platform is a two-part story - firstly, constructing the underlying platform, and then adding the services that need to be delivered.

The platform itself adds no business value; the business value is derived from the services implemented on the cloud platform.

The “DevOps” set of principles are particularly important when building a cloud platform. By its very nature, the agility afforded by this means the software developers and operations can be moved closer together. Deployments and releases are streamlined, which demands a greater use of automation to reduce the risk of errors.

The design team is responsible for filtering the strategy down to technical building blocks. Where the design team typically comprises technical architects, the build phase will include product specialists, engineers and operations. Involving operations early will ease the adoption of the cloud platform.

Implementation engineers have the perspective of getting a system up and running before moving on to the next project. Operations engineers take a longer view of embedding this new stack into their existing systems, and will be involved in formalising the processes required to manage the cloud platform. At the interface between design and build, decisions around specific hardware and software will have to be made.

There are a number of considerations and questions to be asked when building a cloud platform - the first of which surrounds cost. One of the key benefits of cloud is cost reduction, and as such, the implementation cost of the platform is very important. Out-of-the-box functionality is another important aspect. Also, how much is the company prepared to pay? For example, is it prepared to buy an off-the-shelf self-service portal? What level of customisation does it require? Moreover, what would be the services cost of building the company's own platform?

Vendor lock-in is a critical factor to consider when embarking on this journey. I have heard it said that the “five-year plan” is increasingly irrelevant, and in the IT world, this window of relevance is shrinking fast. My advice would be that a company chooses hardware and software that offers the broadest possible compatibility, both to existing systems and other available standards.

Professional services costs is an area often overlooked on many projects, and cloud is no exception. Factor in not just the creation of the platform, but also the implementation costs involved in transferring the company's application services onto its cloud platform. The company doesn't want to find itself in a situation where the service implementation costs inhibit the company from provisioning services from the cloud platform.

The initial build should take a simple service; perhaps something like a small Web-based application and add that as the first cloud service. Taking on a more complex service based on its higher business value, means the company will inevitably find the complexities of the service in a new environment, rather than ironing out the wrinkles in the cloud platform.

One of the benefits of building a new system from the ground up is that a company can construct it using the most efficient methodologies available. Embracing things like the Lean IT principles will add efficiencies to the processes. Treating the cloud platform in this way means extracting high utilisation from the platform.

The process of taking a new service on board should include a process of optimising that service to run on the company's platform. If possible, simplify the service, remove unused and unnecessary components, for example, auto updating functionality is suited to distributed computing, but not for cloud.

Optimise the service to run as efficiently as possible. This means doing accurate “value stream mapping” of the process; where are the bottlenecks? Then automate as far as possible to remove the requirement for administrator intervention or user configuration. On-boarding applications should be a process - as opposed to an installation task.

Capacity management is one component that really must be included in the company's cloud platform. The capabilities should include the ability to do predictive forecasting. Capacity management should provide the company with the ability to do “just in time” provisioning of resources.

When building a cloud platform, companies should aim for a process-based, services-oriented result - one current weakness is that cloud platforms are currently being built by project-oriented resources.

Ultimately, getting this right will mean blending the two mindsets.

A modular approach to building services takes a holistic view. Software developers have been doing this for some time now, with object-oriented programming. But can infrastructure guys make the shift to object-oriented infrastructure?

Building a cloud platform takes companies to the next level of abstraction, moving up from abstracting hardware to abstracting entire services, and by service abstraction, I don't mean abstracting application components, but rather the entire service and all its dependencies.

Consider how infrastructure independent services could benefit a business, you will likely find yourself coming to the same conclusions as those outlined in the US - “Federal Cloud Computing Strategy” - Efficiency, Agility and Innovation.