When a company begins architecting a private cloud, there are many decisions that need to be made about architecture, hardware and delivery model. One key decision that often gets overlooked is how to deliver the services and applications that run the business. There are two general options: continue to deliver services in the same model we’ve always done but now on a more optimized platform, or reassess service delivery and use the private cloud migration to optimize the process as a whole. Most commonly, this decision is not made consciously, and companies design private cloud application delivery to match the legacy model.
The most common service delivery model in data centers is based on the lower hardware reliability of x86 and x64 servers when compared with their big iron cousins. Because these systems have a lower mean time between failure (MTBF), we design redundancy and availability into the software stack. This is typically accomplished by placing a single application within a single operating system on its own server hardware. This limits the failure domain by decreasing the scope of affected applications when a piece of hardware fails.
Desktop and server virtualization greatly improves upon this model but does not change it. By virtualizing, we maintain the "one application, one OS, one piece of hardware" model, but place multiple virtual hardware instances on the same physical device. We then take advantage of the stateless nature of virtual machines to increase availability using the advanced features of our virtual platforms.
If we take this current model as is and move it onto a cloud architecture, we may be missing out on an opportunity to design more efficient, resilient service delivery methods. I look at this move very similarly to the way I look at server virtualization projects. Many people choose to perform physical to virtual (P2V) migrations using automated conversion tools, basically importing physical servers directly into virtual clones. The draw here is the ease, speed and minimal downtime offered. While this method works, it’s basically like hiring movers to pack your house along with all the dirt, dust and trash and move it to your new place. Wouldn’t you prefer to leave the dirt and start fresh?
The same question should be asked when designing for a private cloud architecture. The alternate method for service delivery in private clouds is platform as a service (PaaS.) Rather than building the more common infrastructure as a service (Iaas)-based private cloud, consider building a compute platform that delivers a development platform for new applications. The advantage is that new applications can be highly optimized to the elasticity of the underlying platform and can gain additional availability features by dropping the tie to a server OS and hardware.
This type of application redesign is not a simple task, but the long-term benefits may outweigh the short-term complexity for many organizations. Additionally, like most cloud discussions, it is not an all-or-nothing decision. With the right architecture and design, a PaaS model can live side-by-side with an IaaS model. Legacy applications can be rolled into the IaaS model initially, while new applications and services can be built on the PaaS model. This allows a smooth migration path as long as discipline is taken to enforce a "cloud first" type of attitude for new services.
Like all other areas of IT, there are no one-size-fits-all solutions, and each organization will need to analyze what is correct for them. Most commonly, hybrid models such as the one discussed above will have the largest long-term benefits with the least short-term cost/complexity. Additionally, both methods can be coupled with a sprinkling of public cloud services to reduce some of the burden on internal resources or gain features and flexibility not possible internally.
