by David Kang (Red Hat)
Cloud is not software, cloud is not hardware, cloud is not virtualization, and cloud is certainly not a panacea for broken IT. Cloud is an architecture: a set of fundamental tenets that have different implications at different levels of IT, from network, to hardware, to applications, and to the IT process itself. To say you have a cloud is to say that you have a cohesive architecture, technology set, and most importantly processes, that work towards a defined goal under a set of well-understood principals. Building your cloud is as much about defining your goals and governing principals as it is about investing in technology.
Building your cloud and consuming cloud services
Step one is defining your governing principals. This is a crucial step before embarking on your cloud journey as the policies and principals you define will help you navigate your journey through the rapidly expanding cloud ecosystem. This is also an opportunity to ask tough questions and examine what your principals and processes are, and why you have them. Process is ultimately about managing risk, so consider what risks are acceptable under your governance policies and weigh them against the potential benefits cloud can offer. Both Facebook and Google have adopted “deploy to production” models that seem to fly in the face of process conventions such as ITIL or RUP, yet somehow they seem to survive. The penalty for not doing this exercise is ballooning adoption costs, or failed rollouts all together.
Step two is defining the building blocks of storage, network, compute, and software that will be used to build your enterprise cloud services aligned with the principals and goals of your enterprise. Classically these blocks have been homogenized and encapsulated in blocks by virtualization, but recently a number of projects and services have started to abstract the storage layer into a service all itself, while virtualization is starting to migrate away from vertical slices of a single box to horizontal slices of compute clusters. In deciding which building blocks to consume there are a couple key questions to consider which may seem trivial but in the context of cloud have dimensions of complexity.
What does the service do?
In the case of something like storage, this may seem trivial. The service stores data and provides it back to me when I want it. This is the service approach offered by many of the big cloud service providers such as Google, Amazon, and Rackspace, and software platforms such as Swift and Gluster. The complexity is introduced when you consider the security and governance policies these platforms must support in your enterprise. Can I control the geographic location of my data to comply with regulations? Can I restrict the co-mingling of data and data access for regulatory compliance? How do my HA and DR requirements for business continuity affect the capital and operational cost of the platform as my enterprise grows?
How do I consume the service?
For cloud services this is critical. Choosing a service technology or provider will ultimately marry you to the API of that provider for all of the mission critical applications and services in your enterprise that build on top of that service. This can have huge implications for business continuity and operational cost modeling. Look for services that have well defined and standards-based APIs with a number of supporting providers and vendors. In the old days your applications didn’t need to care if you adopted SCSI or SATA as your storage interface, but that choice drove the available vendors and products you could use to deliver storage. For some services the market is either still fragmented or the Beta vs VHS war has yet to be one. Enter the Cloud Services Broker (CSB). A cloud services broker abstracts vendor specific implementation details across various providers into a consolidated interface for your applications. This is accomplished by either serving as the translation layer between your applications and the target platforms, or by modifying your applications at run time to consume the right resources. The cloud ecosystem is still rapidly evolving and the services have yet to be fully commoditized into well-defined standards. The scalability and agility that cloud promises will only be achieved if your IT infrastructure and architecture allow you the same agility to consume new cloud services and scale across the expanding cloud ecosystem.
How do I maintain the service?
When consuming a service, such as Amazon or Google, it’s very simple. I use it with some expectation of a SLA, they bill me and the complexity of running it is abstracted away. This is not the case, though, with running a cloud in your own datacenter and it is key you have a conceptual understanding of the operating model and cost associated. They key factor to understand is the scaling model of resource consumption vs. service consumption – this is as much about process as it is about the technology. In a utopian world, you want an operationally optimized, linear scale ratio of capacity consumption to resource consumption, but in reality there are various thresholds of capacity which require different classes of operational models. Web scale providers have nailed this down through years of refinement in their technology, as well as their process, which is why they are able to reach such economies of scale in the services they provide. As an organization you need to consider the current and projected scale and consider the operational models you will need to support. No technology or platform will allow you to infinitely scale your datacenter, but you can select the right tools and products that will allow you to linearly scale your resources and capacity in predictable models for your enterprise.
How much does the service cost?
Chances are you are interested in cloud because of a perceived cost savings in either capital or operating expenditures. If you have reached an enterprise scale you probably have teams dedicated to developing cost models and business intelligence calculating things like customer acquisition costs, and margin scale thresholds around your core business. However these mature models typically do not extend into the IT enterprise, and the utilization based costing model of cloud is what makes cloud based systems so attractive. For instance if you are running a web store on Google app engine you can deterministically model how much each user transaction costs in IT infrastructure. This is a powerful capability and the reason why cloud-based services have taken off. I think that many people will agree that one of the largest SaaS providers in the US has a pretty terrible user experience, yet they are dominating the CRM space for enterprise customers. The difference is in the cost model from a licensing model to a utilization model, allowing enterprises to predict relatively accurately what the IT costs will be in the near term. The challenge is that for the private cloud the software models have not yet evolved to a utilization-based model. Running 365 versions of software X for 1 day is typically vastly more expensive that running 1 version of software X for 365 days. These variables factor heavily into determining the actual impact of cloud scalability on actual cost of consuming a service.
Does it scale?
I recently sat in on a vendor presentation where they claimed their software as “cloud ready” and had the word “cloud” peppered into every other slide. Upon some further probing, their definition of cloud ready was that it deployed on EC2. By that litmus test, and for grins and giggles, I deployed a program I wrote in Turbo Pascal circa 1998 to EC2 on Linux, yet I would hardly consider that a “cloud ready” application. Just because it virtualizes or can run on EC2 does not mean it scales. The application itself needs to have some context of scale and elasticity to take advantage of the elastic capabilities of cloud and if that inherent logic is not built into the application, running on a cloud platform doesn’t buy you much. In fact the next generation of scalable applications, such as Hadoop, don’t benefit from virtualization and scale horizontally quite well on physical commodity hardware. The ‘does it scale’ question should be used as the sniff test for the services and products you choose to adopt to cut through the marketing jargon, and “cloud ready” promises too prevalent in the marketplace today.
So now that you have determined the building blocks of your infrastructure, step three is determining what are the services your IT organization wants to build. This may seem as simple as deciding between self-service IaaS or self-service PaaS, but the decision may drive operational paradigm shifts you need to reconcile with your business goals. You may decide to deliver IaaS because you want to retain control of your platform in an IT ops model, but do your consumers have any real need to request infrastructure to build their applications or do they only need software components? Once you deliver VMs or infrastructure via self-service how do you control configuration drift away from corporate standards and prevent “rouge” VMs? Abstracting further up into a PaaS stack may make sense if your consumers really just need building blocks such as databases, app servers, and instances of specific software, but you also need to understand the limitations this may impose on consumers in their ability to effectively tune and configure the specific applications they are consuming. As well, if you do not have a corporate standard service catalog and development environment then you may spend all the time you saved by enabling self service to continually keep up with the demand from your organization to incorporate new applications or services into the service catalog. Perhaps you don’t need IaaS or PaaS and only need a single place to provision and audit the cloud services you consume, such as Salesforce.com or Google apps for internal auditing and cost allocations.
The conclusion is that cloud means different things for different organizations and is an architecture and methodology that drives towards cost effective, agile, and scalable IT. No technology or platform will transform broken IT because building your cloud is as much about understanding your organization and your culture as it is about any specific technology.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.