I wanted to take a moment to introduce you to two new friends here at the BMC Cloud Community.
First, meet Dr. Cloud - a sympathetic ear to all the cloud-troubled. The doctor is glad to take questions and answer quandries from folks around the world. The sage advice can be found to the immediate right side of the screen - or at http://communities.bmc.com/communities/blogs/askdrcloud.
Second, but certainly not least - though he might interpret it as such - The Cloud Curmudgeon. Always ready to complain, the curmudgeon is the naysayer of the cloud computing world. Though I have on good authority that he has a heart of gold, we're letting him vent his frustrations here every week, as part of his therapy. He, too, is located on the cloud community page or directly at http://communities.bmc.com/communities/blogs/cloudcurmudgeon
This week, I woke up to the sound of a bat. In my bedroom. It was a lovely bat – very cute, a little stupid. Bats aren’t really the sort of nighttime visitor most people welcome – and indeed, I was more than a little shocked. Without getting into the somewhat embarrassing details, the window was opened, and the door shut, and by morning, it seemed the bat had made his way out. Why wouldn’t he? My bedroom is short on bugs to eat. With a broom, the closets and the drapes were rustled around, and indeed, in the bright light of an August morning, there was no bat.
But I couldn’t help but think – we hadn’t seen him leave. We just trusted that he did the right thing and … left. There was no way of really verifying it. It was like making a configuration change to a server… and hoping it happened. But never checking.
We needed closed loop compliance on the bat.
5 rather painful rabies shots later (as a precaution – apparently bats are not painful biters…), and back at home the next night, I turned the corner out of the kitchen, and saw the graceful flapping of – you got it – the bat. He was back. Or more accurately, he never left.
This time, we cornered him by a window and forcibly coaxed him out with a pronounced flap. Closed Loop. The bat was gone. For sure.
Between The Bat Experience and The Bat Experience: The Return of the Bat, I was pretty uneasy. The lingering thought that maybe this little vampire was still hanging upside down among my business suits was constant. It troubled me. I told myself I didn’t have to worry – though clearly, I did – but nothing stopped the latent concern. It made me realize, when you have that perpetual, annoying little bug in your mind that something might not have been done – or might not have been done right – it can really tax your mind.
In a cloud infrastructure, where everything’s so hard to SEE, it’s even harder to convince yourself that you’ve checked all the boxes and dotted all the I’s. That’s why automation is so important – and closed-loop compliance on both configuration and regulatory policies. That peace of mind is not only the right thing to do, as a best practice, but also just cuts down stress.
Because, like me, all you want is a good night’s sleep.
I received an interesting email from one of our sales reps recently, reflecting a conversation he had with one of BMC’s customers – a regional (UK) service provider. This service provider was developing their strategy for cloud offerings, and weighing whether and how much to invest in directly providing cloud services (e.g. IaaS) versus acting as a cloud broker.
This is a timely question for many of the Service Providers that BMC is working with – and it’s especially relevant as “plain vanilla” IaaS continues its march toward undifferentiated, cheap/free commodity status. It’s clear that Service Providers are going to need to add value on top of IaaS, and that there are many different ways for them to do so.
In this particular case, the customer was considering two approaches
•Value-add on top of IaaS – holistically through complete service management, or tactically via differentiated offerings (such as security or performance SLAs)
•Cloud Brokering – adding value by being able to broker a customer’s needs across external cloud providers
For brokering, this provider was considering scenarios where it made economic and technical sense to act as a consumer of another cloud provider – taking into considerations the implications for profit margins. Given that this Service Provider was local to the UK, brokering would allow them to offering (for example), cloud services based in continental Europe where geographical proximity was important, or services running on a cheaper infrastructure where cost was a primary concern.
In many ways, internal Enterprise IT should also consider itself as a service provider – aiming to offer differentiated and economically competitive services for its internal customers. The role of cloud broker is something that IT must consider, in order to offer the Lines of Business a full set of choices while still meeting its responsibility
IT folks dream of greenspace. A nice fresh clean slate upon which a whole new, properly-working, well run, solidly-architected infrastructure can be built, unencumbered by the multitude of processes, poor decisions and legacy madness that exists today. For some, the cloud feels like that opportunity.
For most, it is not.
Why? Well, on one hand, you could argue that there is new or reasonably new hardware, storage resources and network. There might be new stack elements like virtualization – and new paradigms, like mobility. There are probably some new components – like customer self-service and the service catalog. So many things are shiny and new. So, to some extent, it is greenspace.
On the other hand, the cloud is still part of your IT infrastructure. You are still serving many of the same customers, and hosting most of the same applications. You're still bound by the same security guidelines and audited according to the same regulatory compliance rules.You’re probably even dealing with some of the architectural realities of your datacenter, network configurations, procurement processes and approval rules.
I don't mean to burst your bubble here. I like a good day dream too. But, I learned long ago that you’re better off setting your own expectations accurately from the start than suffering the tragedy of grand disappointment. But that’s another story.
There is a silver lining to this.. ahem… cloud. All those processes you built and policies you created should pop in seamlessly into yourcloud infrastructure. No need to redefine HIPAA compliance for the cloud, and congeal those guidelines into governing policies. You should be able to apply the same HIPAA policies to cloud services and you're off! No need to start fresh with a change management process – just modify it to address the cloud use cases. No need to build a second CMDB – creating a “dual source of truth.”Keep the same one – and toss those cloud resources in there as well.And if vendors are telling you to start over and wipe the slate clean, that’s because they are dreaming of greenspace too.Wouldn't you, if you were a new company?
To overuse too many tired clichés - no need to toss the baby out with the bath water. Your cloud environment need not be an island in order to be fresh.
If you missed them, check outPart 1 and Part 2 of this 3 part series.
Once you've identified your customer, you're ready to design your cloud offering. But, you're not alone in this. Think about it – it takes a village to build a cloud:
You – or your buddy – the server guy. Possibly the virtualization gal. Definitely the CPU keeper.
Storage Czar – the person with all that “extra” space
Network Knight – the knight or lady who hooks it all together with bandwidth, load balancing, multi-tenant support, etc.
Middleware Maven – there is a layer of middleware that is often provisioned with the underlying resources
Capacity Captain – the person who is relentlessly driving to increase utilization, decrease hardware spend, and stack everything in sight
And the oft-ignored Application Squadron – the folks who build and maintain the applications in the environment
Each of these folks has a role to play in building even the most rudimentary cloud environments. They each are needed to meet the requirements of your cloud customers. Questions you'll need to answer as a team include:
Will there be a one-size-fits-all approach to the cloud services, where everyone gets the same amount of everything – or Small-Medium-Large sizing or some other parameters that the user can choose from?
How much flexibility can a user have in commissioning resources along each dimension?
Will all users have the same options – or will some be limited in their choices?
How will service levels be tiered to address different performance requirements in the cloud environment?
The final question is: How far up the stack will the cloud be provisioned?This is the critical question that ropes in the application team into this autonomous collective. Certain applications might be appropriate for true-end users to provision fully. Consider instances of statistical software packages or R&D applications, for example. Others clearly are the domain of a sophisticated user on the application team – like a CRM or supply chain application.
Cloud gives you the power to automate a tremendous amount of the process of procuring IT resources – but that automation should always be done in the context of the user and their needs.Building the wrong thing quickly doesn't meet anyone’s objectives. First, we asked for whom we are building – and now, we’ve decided what to build.
Before building any new product, a company has to consider the target market. For whom are we building this product? If you're building a computer for a teen, you might include awesome speakers and blazing fast graphics card. If you're building a computer for an executive, you might shrink its weight and extend its battery life.
If you're building a cloud, similarly, you should start withdefining your target audience. Some common candidates inside an organization include:
The development team of software engineers
R&D groups (for example, those engaged in scientific research)
The application team in charge of building and maintaining internal applications
It’s probably self-evident that each of these customers would have a completely different set of requirements from their cloud offering – and you'd have a completely different goal with each. Let’s explore a couple of permutations.
Developers probably want a whole copy of the multi-tier application on which they are working. They probably need a few copies at different times, for testing purposes. They can easily use a self-service portal to request such an instance – and are probably thrilled to be done with the human intervention.
On the other hand, development managers are probably pretty keen on ensuring that each developer is working with the latest,properly-configured version of the environment. Variability leads to bugs. So,configuration management would be pretty important in this environment. Also,developers might be less inclined than – say – paying consumers of public cloud resources – to ensure they return the resources when they are done. So, development instances should be stamped with a decommissioning date, to ensure the timely return of resources into the greater pool.
The applications teams tend to have a different set of goals. They need an underlying OS – with a very solid service level associated with it. They might also be looking to provision some middleware, monitoring, security software and other components into a multi-tier, often multi-VM environment. They will typically load the application on themselves, but want everything else in place and working properly first.
Since most application stacks are not identical – or even the underlying components – you'd expect that to serve these disparate teams,you'd need a very flexible provisioning solution. You also might want to work with the application team to pre-define the options from which they will select.
R&D sits somewhere in the middle, needing elements from both of these two options – but the point, I believe, is made. Know your customer – then design your product. Otherwise, you end up with a magical solution and no takers.