Monday, March 26, 2012

Podcast: Red Hat's Chris Wells talks cloud service catalogs (Part 2)

Service catalogs enable user self-service while retaining IT control. They're an important way of balancing the desires of users and the needs of IT in a cloud environment.In Part 2 of my conversation with Chris, we discuss:
  • How to build a service catalog
  • How a service catalog is different from a golden image
  • How service catalogs enforce policy
Listen to MP3 (0:05:30)
Listen to OGG (0:05:30)

Listen to Part 1 of this discussion.

Transcript:


Gordon Haff:  Hi, this is Gordon Haff, cloud evangelist with Red Hat. I'm sitting here with Chris Wells, product marketing manager with Red Hat who, among other things, is responsible for Red Hat's CloudForms hybrid infrastructure as a service cloud management product. Hi, Chris.
Chris Wells:  Hi, Gordon.
Gordon:  Hey, Chris, you've talked to us before about this idea of service catalogs and user self-service. Maybe you could start by talking about how does this service catalog get built in a cloud management product like CloudForms?
Chris:  The way we would do it inside of CloudForms is that what you're going to start with, once you have all your infrastructure in place where you want to be able to deploy the different systems ‑‑ your physical, virtual, different public cloud providers ‑‑ what you're going to focus on is creating what we call the application form or the AppForm Blueprint. The AppForm Blueprint is really the outline of what is all the software and configuration that you want to be able to provide to someone. Think of that as I want to built out one for a database server or a web server, an application server, you're going to define what that app form's going to look like, and all the content that's going to go into it.
You're also going to define all the policy that goes around it, like who has access to it, what the application itself has access to, what kind of infrastructure is it allowed to run on. Can it run on a public cloud provider? Does it run in a test environment? A virtual environment? Does it run production on a physical environment? You're going to define all these requirements.
And then, finally, you're going to actually publish into the service catalog. The easiest way to think of a service catalog is just think of it as a web portal, a web page that's going to have a list of all the things that an end user is allowed to have access to.
It could look as simple as, "Here are all of our different flavors of a base virtual machine. It has just an operating system in it." You could layer it on with middleware and application tools. It could have a database, it could have a web server. It's really whatever you want to define.
I think a lot of people would think of that as a golden image, if you will. To be able to click on that and get a golden image. That's conceptually what it is. The way that we do it in CloudForms is a little bit different than a pure golden image, but it's the same kind of concept.
Gordon:  How is it different, a golden image and CloudForms?
Chris:  The way that it's different is that most people like images because when you've built an image and you have all of the content and configuration in it, it has two really big advantages. One advantage is you've got it all defined in one file so you've got that gold master that you're going to build everything from so it's very repeatable. The other thing that's very nice about an image is that it's very fast to deploy. It's basically all executable and ready to go, so when it comes time to deploy and provision a new system you can do it very fast. The real downside to an image is an image is like a big blob. It's a big file, if you will. So if you need to go in and make any changes to it, like make a small, one percent change to update a particular software package for a security concern or something, you essentially have to update the whole image. You can't just manage that one little piece.
CloudForms [uses] an AppForm template. Think of it almost like a kickstart file or a configuration file that basically outlines all the different components that are going to go into it, that always goes out and grabs the freshest software, if you will, the software that's the most up to date security wise, package wise, whatever you've tested and certified. You kind of get the best of both worlds. You're not having to manage really large files and images yet the speed to deploy is very fast. It's a very automated process that you can repeat again and again and again.
Gordon:  The admin has put something into a service catalog now, has wrapped a bunch of policy around it. This basically says, for instance, this production template doesn't get to go out on Amazon. The user can't do that. What do things look like from a user perspective?
Chris:  From an end user perspective, if I was a developer, for example, and I wanted to go get a new middleware sandbox, it's literally just a web page. I'm going to go into it. It's got a user ID and password. Based on who that is, it will change based on what items I'm allowed to have access to. The service catalog will only show me the app forms that I'm allowed access to. That could be different than what you would be allowed to have access to.
Gordon:  Do I then decide, as an end user, where I want to deploy it?
Chris:  No, as an end user that's all controlled by the policy that the administrator has defined. If the administrator said, based on my job title and my job function I'm only allowed to access certain AppForms, he will also then define where those AppForms are allowed to run. For example, you may say, "Hey, because I work on financial applications that are highly secure, he's probably restricted me that I can only run on our private cloud internally that has our end line virtualization provider.” Whereas if I'm working on something more generic, I'm allowed to burst out into Amazon.
As an end user, I have no idea where I'm running because that's all abstracted away from me. I have no idea or control.
Gordon:  This is really the idea that you're bringing together the self-service ease of Amazon and other public clouds with IT compliance and governance, all that kind of good stuff.
Chris:  Absolutely. I think that's what the hybrid cloud is all about. The hybrid cloud is all about being able to leverage all of the infrastructure that's appropriate for that job, whether it be your internal infrastructure or external infrastructure, but really having all the policy and control around it.
Gordon:  Great. Thanks Chris.

No comments: