Open source and the cloud, part II
Peter Dawes-Huish develops his thoughts on a plan for cloud migration
As I mentioned in yesterday's column for Channelweb, you need to develop a plan to enlist executive support when adopting open source. You need to invest the time and resources. The move has to make sense to the stakeholders.
So create and share your plan. Once people know that their job is safe and they may receive further training, you are likely to gain enthusiastic supporters.
Look at vendor ecosystems. Those from Red Hat and Novell are probably the most advanced Linux ecosystems, and provide a stack of compatible technology.
Select low-risk applications for your first migration projects. Your migration priorities should depend on a comprehensive review of cost, risk and value. But choosing a lower-risk target can be instrumental in building confidence in future migration.
Choose a project that has a direct match of ecosystem components. Sometimes, the first project can merely be to buy a server, build the platform (OS and components), and recompile the applications.
Do some strategic migration planning. Evaluate your requirements and design the solutions in an integrated environment, taking applications, solutions, and systems into account – that means the enterprise IT infrastructure, the system and solutions performance, and related interdependencies.
Analyse the existing hardware in detail so it can support the applications you will be migrating. For each application, include the development, testing, staging and deployment environments:
• Number of servers and processors per server
• Memory requirements
• Storage and file system requirements
• Network requirements (bandwidth and latency)
• Other I/O requirements (accelerators, management subsystems, and so on)
Create a consolidated deployment scenario and virtualisation analysis. Consider the new hardware requirements and chosen deployment scenario: cloud, consolidation, dispersion or aggregation. Today’s servers are powerful and scalable enough for all these scenarios.
Do a high-level hardware redeployment analysis. A key benefit of migration is the elimination of expensive RISC servers to reduce total costs. However, most organisations do not migrate all their applications at once.
As you migrate applications off one RISC server, consider using that server to add capacity for an existing application environment that you are not yet ready to migrate. This can save significant funds.
Then revisit and update your risk analysis, based on the more detailed information you have now gathered. If risk factors have changed significantly, you may want to reconsider or re-prioritise your application migration list.
Formulate a training plan. Determine which staff will need training and identify appropriate resources. Based on the information you have gathered, create a detailed estimate of direct costs and savings.
Peter Dawes-Huish is chief executive officer of LinuxIT
Open source and the cloud, part II
Peter Dawes-Huish develops his thoughts on a plan for cloud migration
Finally, you are ready for the master migration roadmap. Use all the information you have gathered so far to create a project plan that details when, where and how your migration will occur. The first step is to prioritise specific system and application migrations based on factors such as when you will have capital available, specific business priorities and datacentre constraints.
Create actual project timelines that include tasks and dates, and match specific capex and opex to quarterly IT budgets.
Of course, what I am really saying is that you need a plan to adopt Linux or open source properly, and drawing on the strength of the ecosystem will help maximise your advantage.
The customisability and flexibility of open source lends itself to creating defined standards, such as a Standard Operating System (SOE) – a tested standard selection of computer hardware and software and their configuration for use within an organisation.
This can reduce deployment times, standardise software deployments, simplify maintenance, boost stability and reduce management costs.
Each version of Linux has its own terminology. In Red Hat, it’s called the core build. Core build supports a defined set of target hardware and a defined set of pre-configured services and applications on top of the OS.
Applications might originate from Red Hat or from third-party vendors. An organisation often has a number of different core builds for desktops, servers, different Red Hat Enterprise Linux versions, or different hardware architectures.
A core build installation to a particular system means all required configuration is performed automatically to integrate the system into an existing IT infrastructure such as authentication services.
The configuration is also modified dynamically to suit particular hardware profiles such as the size of hard disks or RAM. Alternatively, it might be configured to use a different network or different security services depending on the networking segment where the system is located.
Core build allows systems to be deployed rapidly and in a standardised manner. SOE Management Platform (SOEMP) is a set of different technologies and products as a centralised management platform that can manage several core builds in parallel.
This centralises errors and configuration changes, and allows for integration with customer asset management. It also aims to automate QA mechanisms, provide integration with change management, incident management, and any other IT tools and processes. It can lower costs dramatically around core build QA, deployment and maintenance.
It is only at this stage that I believe that you are ready for cloud.
Open-source adoption in the cloud using SOE is widespread, and that is no surprise as it helps ensure that the return reflects the IT investment and enables real savings. Focus on the customer's needs, not on the offerings.
Peter Dawes-Huish is chief executive officer of LinuxIT