Archive

Interview with Portal Cloud Lead Developer Paul Kelsey (Part 2 of 3)

Share this post:

Read also Part 1 and Part 3 of this interview.

FF:      Do WebSphere Portal and Web Content Management Hypervisor Edition work only in IBM Workload Deployer or can you put the Hypervisor Edition on other virtual environments?

PK:      The Hypervisor Edition has a one-to-one relationship with either CloudBurst or IBM Workload Deployer.

The Hypervisor Edition is physically different than WebSphere Portal Server itself. It comes as an OVA file, which is Open Virtualization Archive. It’s a single, large “tarball” that contains some binary images, and it also has metadata wrapped around it.

That metadata is what helps the appliance orchestrate the distribution of a cluster. So the metadata defines how this part interacts with another part and the dependencies across those parts.

I say parts because those images that are within that tarball, within that WebSphere Portal Hypervisor Edition, are things like Deployment Manager parts, web server parts, Portal parts, and so on. And those are the things that you draw to the free form workspace.

The metadata wraps the images with the definition of those parts, and then it ties together the dependency, the startup order, things like, Deployment Manager has to start before the primary Portal node. That’s a dependency across two different parts.

FF:      Okay.

PK:      And that dependency is displayed or explained in the metadata, part of the OVA.

FF:      So, in the OVA, we basically have a package of various components pre-installed and pre-configured. They fit together as a working environment.

PK:      Pre-installed, pre-configured, yes.

FF:      And so if you want to create your customized environment, you can base it on the  OVA image and create your own OVA template by adding more servers or components into this, and save as a new OVA. Correct?

PK:      There are several ways to customize your OVA. We’re talking specifically about the Hypervisor Edition again, and we’re talking specifically on IBM Workload Deployer, so we’re hosting this on the appliance from IBM that does this.

As I said, there are several ways to customize what that OVA does. As it is now you start it up, your cluster is started. That’s not really valuable if you have to do that every time and then do some manual things to deploy your application.

So on top of the base images, which is what we provide, you can do things like adding script packages. The script packages are another part that’s distinguished and separate from the parts within the image provided, the Hypervisor Edition OVA.

But there are things that can be drawn on top of the cluster pattern to do things like deploying an application. The script packages are these reusable assets that could be drawn on top of the WebSphere Portal deployment.

And they could be used to do various things: configure the database, not to DB2 but to Oracle, for example. That’s one level of customization.

The script packages can do almost anything you want them to do. And they have a certain size. I think they must have a two gigabyte limit. But you can do a lot in two gigabytes. So the script packages are really just things that would be executed on certain nodes. And that can be deployment of an application, a configuration to an LDAP (Lightweight Directory Access Protocol) server. It could be a configuration to a different database. It could be creation and configuration of a new database that’s used for your own application. So, that can be done in conjunction with the deployment of your application. That’s one level, the script packages.

The second level of customizing the OVA is to do something that’s built into the appliance. The appliance, the CloudBurst appliance, WebSphere CloudBurst, IBM Workload Deployer have software in them. It’s management software that controls the user access – who can do what on your appliance. So, who can deploy new images. Who can create new patterns of these parts.

It also controls, and it has aspects of it too, extended capture. I can take my baseline image, and I can create a new image of it based on that. I can extend the base image, and capture it later. So, I can envision myself starting up an instance of WebSphere Portal, the OVA that I provide. I would click extended capture and that would put the application – it would launch the server – in a special state that the appliance knows; okay, I’m going to do something special with this. I’m going to add something to it. I’m going to change the configuration. I’m going to do a new software installation on it. And, at the end of all that stuff I’m going to then recapture it. And there’s a button within the management software on that appliance to recapture that.

And the result of that end is the next version of my portal server. So all of the disks are still there. All of your customizations are then preserved, and your output of that is another OVA file, which would be Feng’s OVA v1.

Right. And you can do that and customize it. That’s actually how we build our OVAs today. We start with a base WebSphere one and we build our portal server and we enter them in extended capture, and then we capture them.

We have to do other stuff too,but in this most simplistic case that’s how we generate the portal server.

FF:      Are we going to provide more of these kinds of OVAs on our hypervisor offering site?

PK:      Right. The versions we have today are 6.1.5, 7.0.0.1. Obviously I would recommended the latest one, 7.0.0.1. You must have a different OVA for 6.1.5 – you have to have a different OVA for a different version. You have to have a different OVAs for 64-bit and 32-bit.

So you can see that very quickly, it’s going to become overwhelming, not only to generate that many images, but for customers to keep track of which one to download. Sometimes after they downloaded the six gigabytes of the 32-bit image. they find that they need the 64-bit one.

I think we are probably going to be in a different direction. As we are today, we’ve got the 32-bit VMware on ESX server. Not only do you have to worry about bit levels, and operating system flavors (currently Red Hat and SUSE Linux), you have to worry about hypervisor levels.

So an OVA that runs on a ESX hypervisor, a VMware server, will be different from an OVA that runs on z/VM. So, z/VM is a hypervisor that runs on top of the mainframe. There’s also Power VM, which runs on top of the AIX platform.

There are three thus far. Now all of a sudden I’ve got three different hypervisors. I’ve got four different combinations of bit levels and operating systems. And, if I wanted to even get it up to the next level to Power VM for AIX 5.6 or 6.0 or whatever the latest level is, I have to create a new OVA.

You can see that quickly we have a lot of images to create, or to maintain, or to download. There must be some tooling to handle things like this. A tool named Image Construction and Composition (ICCT http://www.youtube.com/watch?v=yd_vIswpZMI) was developed for this purpose. We’ve recognized that all these images are going to be impossible for us to generate. What we need is just the right one for every customer.

There’s some tooling around the creation of OVAs. And even to a more extent, because we not only play in the CloudBurst, but IBM also plays in IBM SmartCloud. The IBM Image Construction and Composition Tools was developed for both. It allows you to pick your base operating system and bit options. You pick some software bundles that might be WebSphere, that might be DB2, that might be portal server. You pick other configuration options and then you click a button and the tool builds an OVA file for you, or it builds an image that you can deploy and launch within the IBM SmartCloud, or IBM Workload Deployer.

That’s kind of like building your own image. You can even start with your own operating system. Suppose you’re one of those companies that has a very tight or stringent appliance policy about what is on this Red Hat Linux, what RPMs are installed; you can then bring your own ISO image, feed it into this tool, and it’ll create an OVA file for you to deploy onto that platform.

So it’s definitely worth looking at, especially if some of the things that we already are shipping for you aren’t what you want yet.

FF:      Right. So in the future, our Hypervisor Edition will probably be tied to the ICCT and we’re not going to make these gigabyte images available for download, but rather to give you the option; you can choose your options to build your own. On the next day, you can come to our site and download that image?

PK:      Yeah. We can’t make a commitment yet for Portal Hypervisor Edition. We’re still figuring out which is most valuable – is it more valuable to create the OVA? It’s not the same work to create an OVA as it is to create something to feed into the ICCT.

The ICCT tool takes what are called resource bundles. And that would be a software component. So, WebSphere would have its WebSphere resource bundle, Portal server would have its own resource bundle. But you have to define that resource bundle in such a way that it’s publicly consumable. And, we don’t have that today; we don’t have a resource bundle that can fit into the ICCTas it is today. So it remains to be seen. I think there’s going to be a lot of value.

FF:      What virtual machine types support WebSphere Portal?

PK:      IBM has decided and told everybody that all of its software products support almost all virtualization platforms in the market so far.

FF:      Including KVM (kernel-based virtual machine)?

PK:      Including KVM.

Now it’s different to say we will run on this platform versus saying we will give you a base image, right? With KVM, you have an operating system and you build your portal server, and it should just function, it should just work.

FF:      So we don’t test whether or not they can be installed, correct?

PK:      No. We don’t have any formal test buckets that say this does or doesn’t work.

FF:      Okay. My next question actually is about performance. In a virtualized environment, we assume there must be some kind of reduction on performance versus physical systems, right?

PK:      Yes, there definitely is. We haven’t quantified that, at least I’m not aware of any data in at least a year and a half.

For that, we might have to defer and go to the WebSphere Application Server team, because they have their own benchmarking and their own metrics, and they were the ones who actually came up the numbers. I think a few years ago the overhead was around 30 percent.

It was a significant figure, and I’m not sure if they’ve re-measured that because, you know, virtualization has come a long way in those three years, just how optimized can you get in that stack?

I think that 30 percent was on a VMware stack, for example. I’m not sure if that was just a VMware player, or if that was a “bare-metal” hypervisor doing something. So I couldn’t really comment except that there will be overhead. How substantial it is, I think, is the question.

FF:      So right now we have offerings for VMware. And do we have any others?

PK:      No we don’t. We make our betas sometimes available as VMware images. We don’t have an offering that’s a VMware image of portal. But again that is not something that we even see. So as the people who are providing images on IBM SmartCloud, they give us a base image to start from. We don’t know whether that’s Vmware-based, or KVM-based, or even Power VM-based. We don’t even know what the hypervisor is that it’s running on.

They give us a base image to extend and we extend it by putting our products, our configuration, and our activation on it. And then we capture it and we just have an extension of their base image.

FF:      Are we going to support something in Power VM?

PK:      Sure. There a lot of  hypervisor vendors. We said KVM, VMware, and Power VM. There are distinctions. You have to have a unique image, at least today, for each one of those hypervisors. A VMware image differs from a KVM image, which differs from a Xen image, which differs from a PowerVM image. It would be nice if we have to deal only with a common VM package format like OVA, which we had talked about.

There is no standard out there. Not everybody produces OVA packages or a standard format yet. The disk formats are different, so there’s a little bit of more work to do to make it so that one image can be deployed across multiple, different hypervisors.

When you say really support PowerVM, the answer is we do support PowerVM today. What we don’t have is an image that we, IBM, are producing yet.

So PowerVM, as I’m sure, got its own base operating system images and those are probably AIX. You can extend that. You can run the portal installation on it and then capture the image yourself.

We do have plans for next year to build a portal server that runs on PowerVM so that it can be dispensed through IBM Workload Deployer.

So again, we’re not choosing a specific vendor and saying here’s the image for that. We do that for our beta with VMware because a lot of people can basically stick a VMware player on their server with those desktops and “kick the tires” for the beta.

We don’t say here’s a PowerVM image. What we do is we say here is an IBM Workload Deployer image that can be deployed on a PowerVM.

And here is an OVA right, an IBM Workload Deployer image that can be deployed on a ESX server. So, we really aren’t playing into the vendor-specific things, we’re playing into an IBM Workload Deployer, something that’s managed and has some intelligence. That’s more beneficial I think than just giving customers an image that can run on a specific hypervisor.

FF:      Previously, you mentioned IBM Image Construction and Configuration Tool (ICCT). Can you tell us more about it?

PK:      Yes. It’s a Tivoli product now, and I think even IBM Workload Deployer might have moved over to Tivoli as well, because it’s kind of system management. So ICCT and IBM Workload Deployer are very closely tied together because what one of the things that is generated as a result of ICCT is an OVA file. You can also click another radio button and you get an IBM SmartCloud Enterprise image. The graphical interfaces that you used to build the images looks a whole lot like the IBM Workload Deployer interfaces. So they’re there very tightly married, and maybe that’s for historical reasons, but also originally the only thing that you could output for ICCT was an OVA, which was run on CloudBurst or IBM Workload Deployer.

FF:      Okay. I have several more specific questions about the deployment of WebSphere Portal on Amazon cloud. How does this partnership between IBM and Amazon work? Do we just provide the product loaded on their platform? Don’t we charge anything for development images?

PK:      For the development, we don’t charge anything. The relationship with Amazon is different than the relationship with the IBM SmartCloud.

It’s unique in that with Amazon we have several images. We’ve got one, the developer image, that stays under the control of a global IBM-wide ID.

So, an ID logs into Amazon, and we create an image that has WebSphere Portal and DB2 in all of the whole stack that we use. That ID then takes that image and makes it public for the world to see within the Amazon toolkit, right?

Then we go to our web site, say “hey everybody look at this new AMI.” You can launch this WebSphere portal image and for developer use only, and that’s free from a licensing perspective. But the Amazon cloud will still charge however many pennies per hour for running, depending on how large of a virtual machine is into which you deploy the portal.

Okay so that’s one aspect and that’s where we, IBM, are controlling that image. We say okay it’s public and then we take care of when we take it out. So it’s all under our management.

The process for doing it on the production level images is a little bit different because we have to have licenses associated with it. So it’s more expensive.

But the agreement with Amazon is that we create the image, which is a 64-bit JVM-based image. After we create it, we actually tell Amazon that this image is ready to go. Amazon then takes your image, makes a copy of it, and makes Amazon the owner of that image. Amazon keeps track of the codes that are associated with the image. Amazon changes the manifest in the package, and a couple of the things that Amazon AMIs are known for.

But really Amazon owns that image after we’ve given the okay. So those are just for the production level images.

FF:      So they are still paying us for some commission, right?

PK:      Right. And I’m not sure how this works. It might fall back to operating system level licensing like SUSE Linux, like what kickback does Amazon have to give back to Novell when they’re launching these 64-bit JVM or operating system images?

It might be related to that. However, it was defined when the initial Amazon agreement was made, in that they can control the production use images.

FF:      Interesting. We understand that basically Portal is a UI component. So it has to tie back to enterprise applications like in Lotus Notes or in Domino or whatever back-end systems. If this portal is served on a public cloud like Amazon, how does it establish such a type of connection? Do the cloud users use virtual LAN or something?

PK:      Right, that falls into the realm of hybrid clouds. When you’ve got a public cloud and your portal is talking to a back-end system that still might be on premises or maybe it’s even talking to another person’s portal that’s either running in the cloud, there are lots of ways to “draw” the hybrid cloud. We know that, even within IBM, it’s fairly difficult, everything is very dispersed in silos. It’s very difficult to convince our networking team that controls our firewall to get into the IBM network. They aren’t really willing to poke holes into our own firewall to allow us to do any testing.

But we were able to work around that. And we even launched a public cloud instance, and then we installed our own AT&T VPN client, then tunneled back in through that, and then we connected to one of our LDAP servers.

That’s kind of a poor man’s way, a very quick and dirty, tacky way to establish a hybrid cloud that’s over an SSL tunnel.

There are ways in IBM cloud and Amazon cloud, and there are functions built into each of those that allow you to establish SSL endpoints, VPN endpoints between your enterprise and the Amazon infrastructure.

In that way, you can have a pipe that’s very private, and that connection is fine. Now along with security concerns, you have to worry about latency concerns. Should your applications be running close to the cloud provider’s data centers? Amazon’s got a couple data centers. IBM also has a few data centers.

But depending on your topology, where is your portal instance in relationship to where is your back-end data, and what is the network latency?

Typically on premises, you know, your back-end systems are tied to a dedicated LAN that’s very fast hopefully in response time, whereas now all of a sudden that’s a question mark.

There are several considerations. Security is one. Yes, there are pipes that you can create that are secure. Latency is one. And, the amount of chatter that happens between your application and the back-end systems – whether that’s several requests or a single large request back to the back-end and a single result sent back. You know, much of this will affect the performance and whether or not you even want that hybrid model.

Alternatives to the hybrid model in doing that pipe and doing those connections back and forth is something that moves all the data for the on-premises system out and pushes the data out to the cloud, out to the same Amazon cloud, or out to the same IBM cloud; make sure that it’s done in a way that no confidentiality is breached, and all this other stuff.

But in that sense you have your portal UI component that has portlets that talk to this back end in the same cloud.

And, if this back end is actually hosted on the cloud too, then you don’t have the latency concerns and you might not even have the security concerns because they’re all within the same cloud. You can quarantine off that section of that cloud infrastructure. There’s no SSL pipe, there’s no VPN back through your firewalls and things like that. So there are lots of options to accomplish such connections.

Cast Iron is one product that is focusing in that area. It’s doing a conversion of your on-premises data, and then sends it to the middle point where it comes out from the enterprise, and maybe out there in some other cloud service.

And then, rather than my application going through all the way back to my bac-kend data, Cast Iron helps make that data available in most places and synchronizes it. And Cast Iron can even provide a functionality to tie the credit cards stored in your enterprise with your customers, for example.

Cast Iron has this ability to transform all that data and even mask it, encrypt it, or do all kinds of things, even exclude it for what’s being populated in the cloud service that represents that same data.

FF:      Okay. Now suppose the customer has its applications services on another cloud, not Amazon. For example, the customer’s portal is on Amazon, but its CRM system is on…

PK:      Salesforce.com.

FF:      …Salesforce.com. How do you envision the operation in this system? Is this similar to hybrid cloud system we discussed just now, cloud versus on-premises?

PK:      Almost everything is identical to on-premises. Again depending on how savvy you are from the perspective of your security guidelines you just have to take that same knowledge that you would apply with on-premises to the public cloud.

It’ll be the same kinds of connections, so on-premises is as if I connected to Salesforce.com or another cloud-based service. It’s exactly the same as if I’m doing it from Amazon, from a portal deployment for Amazon to Salesforce.com.

About Paul Kelsey
Paul Kelsey works in the WebSphere Portal Server and Lotus Web Content Management Software Group Division at IBM, serving as the development lead for reducing total cost of ownership for Portal and WebSphere deployments. In this role, virtualization, public and private cloud computing, and alternative multi-node and multi-tenant topologies are explored to ensure customers get the best value in their hardware and software investments.

More stories

Why we added new map tools to Netcool

I had the opportunity to visit a number of telecommunications clients using IBM Netcool over the last year. We frequently discussed the benefits of have a geographically mapped view of topology. Not just because it was nice “eye candy” in the Network Operations Center (NOC), but because it gives an important geographically-based view of network […]

Continue reading

How to streamline continuous delivery through better auditing

IT managers, does this sound familiar? Just when everything is running smoothly, you encounter the release management process in place for upgrading business applications in the production environment. You get an error notification in one of the workflows running the release management process. It can be especially frustrating when the error is coming from the […]

Continue reading

Want to see the latest from WebSphere Liberty? Join our webcast

We just released the latest release of WebSphere Liberty, 16.0.0.4. It includes many new enhancements to its security, database management and overall performance. Interested in what’s new? Join our webcast on January 11, 2017. Why? Read on. I used to take time to reflect on the year behind me as the calendar year closed out, […]

Continue reading