November 5, 2013
What’s our advice to those building out an internal cloud management practice? Don’t get overwhelmed by trying to revamp all of your IT management processes Day 1. Cloud’s not supposed to make things harder, remember. Keep three things in mind from the outset and you have the foundation for a cloud management practice: monitor, standardize, and automate.
What you monitor in your cloud dictates what you can manage, of course, so focus first on monitoring what you can control. In a private cloud, that means monitoring the compute, storage, and network resources you’re delivering as a service. In a public cloud, instrument your apps first. Then you need to standardize on a reasonable set of app and infrastructure templates you’ll offer to your cloud consumers. And finally you’ll need to automate the way you build instances of those templates on demand. These are the basics: monitor what you control, offer standardized services from a catalog, and automate how you deliver them.
This week’s OpenStack Summit in Hong Kong comes on the heels of the latest OpenStack release, called Havana. Havana includes two fully integrated projects that have been baking for a while, Ceilometer (monitoring and metering) and Heat (orchestration). These two enterprise-focused features aim to make it easier to build a real production-quality cloud on top of the OpenStack open source cloud building platform.
Ceilometer offers central collection of metering and monitoring data to gather usage information (for example) to feed downstream billing or chargeback systems. If you don’t plan to track utilization (and eventually bill back for it), you’re probably not building a true cloud. If you are, OpenStack now has something useful to work with. Heat is a template-based orchestration service that lets you coordinate and automatically execute all the steps required to bring a multi-tiered, more complex application up on your cloud (called a “stack”). Templates describe requirements and capabilities of app components.
You can go out to GitHub and grab a template, or you can use templates you might have built on AWS’s very popular CloudFormation service (Heat is based on CloudFormation syntax). In the future, Heat will probably support the emerging TOSCA standard for describing cloud apps: the idea is that you should be able to define once and deploy (and move) across clouds easily. We’re not quite there yet, though IBM, HP, Red Hat, Cisco and other big OpenStack members are also on the TOSCA technical committee, and all have at least some vested interest in portability.
My take? Monitoring, orchestration, and a better dashboard are terrific enhancements to the OpenStack offering. Does Heat go far beyond what AWS already offers with CloudFormation? No. That’s OK for now, as OpenStack continues to try to coopt AWS. But as the major vendors in the OpenStack community try to climb up the value chain and compete around management, orchestration, monitoring, and all the related cloud operations capabilities, we’re in for a confusing and competitive ride. You can align yourself to AWS syntax, or Heat, or TOSCA, or orchestrate your cloud with a commercial offering from HP or IBM or Cisco or others…and it’s likely you’re going to be able to use what you build in multiple places, but that’s by no means a given. That’s a lot of decisions to make for a service that’s supposed to take the heavy lifting out of cloud formation (pun intended).
In all, OpenStack continues to mature, and as it does, it needs a standalone orchestrator, monitoring service, and dashboard – and they have to be good enough. I understand that. And these are good enough, for now, but the real maturity at the cloud operations level will come from the vendors in the mix, because someone has to differentiate to make a buck. Forrester cloud team members James Staten and Lauren Nelson have our ears on the ground in Hong Kong, so watch this space for their take on how these new features play to the faithful.