You are currently on IBM Systems Media’s archival website. Click here to view our new website.


Take Care When Building Your Own Cloud Service

If you build and run your own cloud infrastructure, you should give considerable thought to packaging it as a service. This will make it easy to order and consume by your customers. Be mindful that your internal private cloud, in a real way, is in competition with commercial public clouds and these commercial services are attractively designed for sale and use.

So what do you have to think about? Consider this:

Hardware platform: Your service will run on hardware. What platforms will you use? Will they be existing or new? Using existing hardware is appealing for a number of reasons including the low capital outlay and ability to make use of the experience you already have. Assuming your hardware has capacity, using what you already have will cost less and have a short provisioning time. Since you know this hardware—servers and other devices—you have a short learning curve. New hardware may be your only choice but it comes with a greater start-up hurdle.

Use of virtualization: What will your stance be on virtualization? Is your standard “everything virtualized” or will you support some non-virtualized devices. You might think that you have total freedom with virtualization but it is a good idea to check into the kind of workloads that are likely to be your early adopters. Look into these workloads specific requirements, if any, for dedicated hardware.

Key software: Software is a key point when developing your own services. What operating systems will you support and at what levels? You can determine this, again, from your likely cloud workloads. What about control and management software? Will your current base for non-cloud environments work in your new cloud service? This requires investigation. You will probably want to consider running at least part of your cloud management infrastructure in your cloud. This will keep your overhead costs lower than using dedicated servers or servers with basic virtualization. Cost savings can show up when your cloud service is pay-for-what-you-use in design. These ideas are summarized in Figure 1.

Service Building Blocks

Workloads running in your cloud will require certain support services. You can build these services into your cloud service catalog from multiple sources. Let’s discuss backup and restore. You may want to use your existing backup and restore enterprise service or build a cloud-specific service into your new cloud infrastructure. The main decision factor will be performance. Will an existing service that is not a physical part of your new cloud infrastructure perform well enough to be used or must it be replicated into the new cloud environment?

Will you provide patching as an automatic service or will it be on-demand? The automated service idea holds cost-saving promise but requires testing flexibility on the part of your application teams. One approach to use is first you publish your patching schedule and a list of patches and then application developers test their applications prior to the patches going live. Is this approach likely to work or will another tact be more useful?

What about a security service? Will you automatically scan devices or images to ensure security compliance? Will every application running in your service share the same security policy or will you support different policies by application? When you devise the service think in the context of policy, technology, and controls. This would be the framework of your cloud security service.

Beyond the Basics

Once you figure out how you will handle support services like backup and recovery, patching, and security you should consider service packaging, self-service and labor matters.

For service packaging, you have many factors to consider. Will you use a pay-for-what-you-use pricing model and support flexible scaling of resources like CPU and memory? Will you strive to simplify computing by making use of standardization? A combination of these decisions will result in a cloud service with a personality. The decisions that you make will result in a set of constraints that may close the door to certain kinds of workloads so you have to be careful in what you decide.

For self-service, will you support rapid provisioning of images and other resources through a self-service front end? Will the front-end be for users or administrator or both? On one hand, you will experience some pressure to open the service to non-specialized users but at the same time you may feel the need to limit access so provisioning is initiated by IT specialists. A lot depends on what technical questions need to be answered during the provisioning process.

Will you add labor-based services to your cloud-service catalog? These services could be activities like database health check, OS image recovery and application software patching and testing. The services could be offered in blocks of time that you pay for as you use them. Of course, creating open-ended labor services could result in staffing challenges, as it is expensive to employ enough skilled personnel to handle the ups and downs of dynamic resource needs. The features, services, and cloud conventions are recapped in Figure 2.

IaaS, PaaS and Workload-Specific Environments

A challenging thing to do is to place your new cloud service in the right way to meet the needs of your community. Will it be general purpose or specific? The simplest general-purpose environment is an infrastructure service often called Infrastructure as a Service (IaaS). A more challenging alternative is to create a Platform as a Service (PaaS) in a functional area like database or web serving. It is difficult to create a database or web service that anticipates the needs of your community and it layers on top of your IaaS service so in a way it is double in its complexity.

Perhaps an easier way to move forward is to create a cloud environment specific to a given workload like collaboration or analytics. Instead of dealing with a broad range of complexities your challenges are specific to the specific workload. If this particular workload has sprung up in pockets all over your enterprise, creating a cloud environment to support it offers an opportunity to consolidate and simplify that could result in a win for your company. The options to meet the needs of your community are shown in Table 1.

Risks and Rewards

It is imperative that you package your cloud infrastructure and platform as a service. Consumers of your cloud infrastructure need services whether you define them in advance or not. When you define them ahead of time and thoughtfully put them in a catalog you help sell the cloud service.

At the same time, you are setting up for challenges that need to be solved before these workloads can be put into a productive state. The decisions that you make will open some doors and close others so make them carefully. When requirement surface that you have not anticipated remember to put them in a list that can be prioritized and implemented in the near future.

Joseph Gulla is the general manager and IT leader of Alazar Press, a publisher of award-winning children’s books. Joe is a frequent contributor to IBM Destination z (the community where all things mainframe converge) and writes weekly for the IT Trendz blog where he explores a wide range of topics that interconnect with IBM Z.



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters