- How to build a service catalog
- How a service catalog is different from a golden image
- How service catalogs enforce policy
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:
Post a Comment