In the space of a little over 20 years, Linux has grown from an open source ideal into an enterprise class OS used in every domain. Adoption has not been linear: growth rates in the past five years having far outstripped the preceding 15 or so. The appeal of open source among developers came first, but it took commercialization to build trust and to push Linux into the mainstream.
Technology adoption curves vary on a case-by-case basis. Virtualization, for instance, has a longer history than you’d think, though its recent rise to prominence in the enterprise has been rapid, and the adoption of open source virtualization has been faster still. Now we find ourselves at the start of an adoption curve for cloud. The benefits of cloud ICT solutions and services are well documented, but examples of enterprise class cloud-based service adoption tends to be isolated into silo solutions such as storage. Furthermore, cloud providers are proprietary services, unable to ‘talk’ to one another. Open source is required to break down proprietary walls in cloud.
Enter OpenStack, an open source cloud computing project led by the OpenStack Foundation to provide the delivery of infrastructure as a service (IaaS). The adoption of cloud in the enterprise, like Linux and virtualization, is a matter of “when” not “if.” With 150 technology firms actively taking part you would think the odds are stacked in favor of OpenStack. But with so many stakeholders, measuring success and the true state of the project may be difficult for some time, posing challenges for Enterprises wanting to embark on the OpenStack journey.
OpenStack offers organizations the possibility to get to an IaaS implementation in a much more cost-effective way. In this one of the key value propositions is that Compute, Network and Storage Services can all be provisioned in software rather than hardware. But while OpenStack is maturing fast, traditional applications aren't quite suited for this fabric of the future (yet). In this situation, it has been interesting to watch different business models emerge around OpenStack and tying their brands to the open source cloud project.
Image via Shutterstock
Before a business even considers adopting OpenStack, the project management needs to have a full view of its IT landscape – a detailed matrix that classifies all of the organization’s workloads needs to exist. This matrix should consider basics like Cloud Security (Data and Privacy Rules and Regulations), Locality Rules (Where is the consumer and where can this data be placed by regulation), Interconnections and Dependencies to other Applications and Application-Specifics like Scaling and High-Availability Architectures (Can an application be horizontally scaled, does it work highly available with stateless nodes on all tiers?).
These are the questions that any IT project manager will need to know before moving towards Open Stack. There will be more, of course, and these will be dependent on the type of business, the existing IT infrastructure, the budgets and the IT culture of the firm. There is a saying in business that if you fail to plan you plan to fail and that is 100 percent applicable when it comes to Open Stack adoption.
Many firms already have organizational technology matrices in place as a matter of course since it is good practice. However, plenty of companies fail to do it properly or simple lose track – basic book keeping or reporting can often take a backseat as the need to deliver a project or series of projects takes priority. Only once the full landscape is known will a business be in a position to see what can be migrated, what needs to stay on traditional data center infrastructure, and how to orchestrate the coexistence and migration that needs to take place.
To make management of multiple virtualization/IaaS solutions run more smoothly, a “manager of managers” software solution such as Red Hat’s (News - Alert) CloudForms should be considered in order to implement the organization’s business processes seamlessly. This all ties in with the creation of an architectural matrix of building blocks. With a view of the applications to be migrated, the appropriate level of resourcing can be more accurately estimated. From a pragmatic standpoint, project managers have to face up to the fact that despite the decision to embrace OpenStack, legacy systems cannot be forgotten.
Once decisions have been made about what can and can’t be migrated, and a business is in a position to start moving over to OpenStack, an evaluation of the business models proposed by vendors should be the next step. Decision makers will face a bewildering array of choices from vendors. Some vendors will look to OpenStack as an open source solution that comes complete with the benefits of open source. Others will be selling “OpenStack” that is modified to connect to proprietary solutions: it would be OpenStack in name only, but not in spirit, effectively locking you further into legacy solutions.
Related to selecting a business model is the selection of a partner who understands your business and technology requirements. For certain projects, the technology should be thoroughly understood, expectations regarding the what, when and how much should be set in advance. With other technologies the future is less certain, since there has been less past experience upon which to call. In short, trusted partners can help you with this and will enable firms to on-ramp quickly.
In general, it won’t be appropriate or possible to attempt to migrate the entire IT estate of a business to OpenStack. Therefore managing legacy will be an on-going challenge, particularly as those legacy systems are still likely to evolve over time and require additional management. Twenty years ago, many predicted the death of the mainframe, but the mainframe is still with us. The same will be true of whatever systems that are not moved into the cloud with OpenStack.
It is important to remember that OpenStack can be consumed as a supported service, and is not necessarily a one-off installation. Rather than investing in a bespoke roll out, which in itself would be costly, the business would then be faced with on-going management and maintenance fees. Using an OpenStack with a completely Open Subscription model will effectively avoid vendor lock-in, if it is not dependent on closed-source tools coming with the package. Especially tasks like patching, security fixes and version upgrades can be addressed by choosing a supported package.
If you’ve read this far, then there’s a good chance you’re already strongly considering OpenStack, and I am willing to bet that your favorable disposition to open source means you will have already adopted Linux across the enterprise. Rather than attempting to reinvent the wheel and make things hard for yourself, configuration and lifecycle management for OpenStack can and should be done similar to your enterprise Linux distribution.