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

Share this post:

Read also Part 2 and Part 3 of this series.

Fang Feng interviewed Paul Kelsey, WebSphere Portal Cloud Deployment and Security Architect, on November 7 and November 12, 2011. The main topics involved cloud computing, IBM SmartCloud Enterprise, IBM Workload Deployer (IBM CloudBurst), Amazon Web Services, and WebSphere Portal’s deployment in these cloud offerings. In the following transcript, the names are abbreviated.

FF:      As a convention before our interview, we have to ask you to please tell us your official title.

PK:      My name is Paul Kelsey. My official title is, WebShere Portal Cloud Deployment and Security Architect.

FF:      Architect? Okay, the first question is, what cloud offerings does IBM have that include WebSphere Portal as a component? I understand that we have IBM SmartCloud Enterprise. We have the CloudBurst. How else are we going to promote Portal, or do we have a new form of promotion?

PK:      Portal has presence now on the public front. It’s not to say these are the only things that Portal will run on. But the ones that we actually participated and created images on, are  Amazon (EC2) and the IBM SmartCloud Enterprise. Both of these are infrastructures as a service (IaaS) type offerings where you get a single image: in Amazon terms, an Amazon Machine Image (AMI); and in IBM SmartCloud Enterprise, I think they just refer to them as images. But the image with WebSphere Portal consists of the entire deployed Portal stack, including a web server and a DB2 server.

FF:      Okay. Why is it IaaS, not PaaS [platform as a service]?

PK:      IaaS is infrastructure as a service. That’s where you’re kind of just renting the hardware. So you’re getting the whole stack. But at the root, it’s a single machine, whether that’s virtualized or not. However, the cloud vendor does the package. You get a single machine that you would use Secure Shell to get into the images, and then you’d have full control over it at the root operating system level. So that’s typically termed infrastructure as a service (IaaS).

FF:      Okay. How is PaaS different?

PK:      PaaS takes a little bit more than just that single machine. You can’t consider the single machine as a platform as a service. That’s almost the next level up where you kind of have a coordination of a bunch of infrastructures the service knows. And the coordination has a couple of roles. Some of those are fail over, disaster recovery, and multi-node tenancy kinds of things, and clustering if you want to use some WebSphere Application Server terminology. You can’t really consider a single WebSphere node a platform of anything, because if that thing goes away, it’s all gone.

You have to have some kind of resiliency. And that’s more of the definition of a platform. So it’s kind of a coordination of multiple nodes to give you a platform, not just a single operating system; instead it’s really a software that’s built up on those multiple instances of those operating systems.

FF:      Okay. Thanks for the explanation. Now the next question is, are we going to have PaaS offering for WebSphere Portal?

PK:      Currently, I just described to you the public offerings. I said that explicitly. The private cloud offerings is where you mentioned things like CloudBurst. CloudBurst was the WebSphere data power chassis appliance-based kind of thing. It consisted of a disk and some management software. But it also has the concept of images.

CloudBurst differentiates itself from others. CloudBurst was still at the end of the infrastructure as a service. So it stood on individual nodes. But because CloudBurst was something that IBM designed, it knew about WebSphere, it was even branded as WebSphere CloudBurst. It knew very well what images were on it. And it knew about WebSphere clustering. It knew about, you know, some of the things that Amazon and even IBM SmartCloud didn’t necessarily know about to the intricate details of what is in WebSphere application server.

So CloudBurst actually knows how to cluster multiple nodes. It can take the concept of setting up individual infrastructure as a service and almost get to the step of being a platform as a service, because it can coordinate the starting up of multiple nodes for you. So that’s where CloudBurst is different from the public cloud offerings.

FF:      So in the IBM SmartCloud Enterprise, can we not set up multiple Portal nodes like farms or clusters?

PK:      We can. You can. You can set up anything you’d like to. But it’s up to you to do that. As the image provider on Amazon or IBM SmartCloud, we don’t start up a WebSphere cluster. And that’s a statement at this time, which can change. I think all of these cloud providers are trying to get to platform as a service.

You know, you’ve got multiple node coordination aspects into each of these. You’ve got cloud prints within the IBM SmartCloud. You’ve also got (I think it’s called) CloudFormation in Amazon. But they’re just beginning to scratch the surface on what really is the creation of a platform. With CloudFormation in Amazon, you can say, okay, I want this node to start up and then this node, and then this node. So you do have multiple nodes, but that’s all it is. It’s starting up in the order you specify. If one of them fails to start up for any reason, it will sequentially break down your entire topology. So CloudFormation kind of gives you the start of the multinodes. But then it’s still up to you to say, okay, on my third node I know I have to run a cluster type of task or something if it’s a WebSphere node.

So there are some things that you have to do manually on each of them, knowing that you’re in a CloudFormation.

So back to the CloudBurst, and I stumble over CloudBurst, because in the new version is renamed to IBM Workload Deployer, and new features were introduced.

FF:      Right.

PK:      That carries some significance, especially when it comes to the WebSphere brand. Because now we’re no longer tied to just doing the WebSphere Application Server or WebSphere Portal server, but also information and network management in which Tivoli is participating as well. So, we took away the word “WebSphere” and actually introduced a new concept called workload. Thus “WebSphere CloudBurst” became IBM Workload Deployer. This is really taking platform as a service to the next step.

So from my perspective, we’ve got three offerings in cloud – IBM SmartCloud Enterprise, Amazon Web Services (AWS), and IBM Workload Deployer. We’ve got two public ones, IBM SmartCloud and Amazon Cloud, strictly infrastructure as a service. As we were talking about, you can tie them together with scripting yourself. You can tie them together with some of the tooling around those offerings like CloudFormations or Cloud prints. But it’s up to you as the owner of those multinode things to generate the scripts.

The way that IBM Workload Deployer or CloudBurst differentiate themselves is that typically IBM Workload Deployer is housed on your own premises, because it connects to your own hypervisors, your own hardware, your own network storage, and things like that.

But IBM Workload Deployer also differentiates itself in the fact that it’s got the concepts of WebSphere clustering. So it can create something like a platform for WebSphere Portal.

And then on top of that is a workload aspect. And that’s a whole other set of capabilities that we would probably need another whole session to cover.

FF:      Are we going to provide some features in Portal version 8 to facilitate or to fully take advantage of these workload functions in IBM Workload Deployer?

PK:      IBM Workload Deployer’s functionality is divided into two sections. One of them is virtual systems, which is kind of like how CloudBurst was today. So IBM Workload Deployer  is like  version 2.0 of CloudBurst Appliance. And that gave you the ability to deploy WebSphere Portal clusters.

You could deploy a ten-node cluster of WebSphere Portal simply by drawing your cluster on a free form workspace, using widgets to drag the components into. You would drag on a Web server node, 10 Portal nodes, the Deployment Manager, and a database server.

And then you would click a button to deploy it. And the CloudBurst appliance, and the virtual system part of Workload Deployer would throw that out to your hypervisors in the correct order, provisioning and clustering, running all the ConfigEngine tasks that we would normally do manually. It does that, and it’ll build it.

FF:      Okay.

PK:      At the end of your 45 minutes or so, you’ve got a fully running portal cluster. By then the virtual systems is really functional.

The second half of the function that was introduced in Workload Deployer was a workload pattern. Instead of your knowing about your topology type and knowing that you needed 10 cluster members, all you fed into the workload engine was your application, whether that’s a WAR file or an EAR file, or whether that’s a database.

You know, you would give them to the Workload Deployer. And you would represent just your portion of it, your application, your database interaction. Not anything to do with portal, not anything to do with WebSphere clustering, but all you would draw is your application and your database and simply host it.

And so for that sense, you would have to define a pattern type. So, included in the Workload Deployer there’s a web app pattern type and then a DBAS, a database application system pattern type. That would be a web app talking to some database.

I mean, typically you’re not going to have just a web app. You would have some interactions with some databases. So there are two to those workload patterns.

And then instead of saying I need this to be hosted on 10 cluster members you would attach policies on it along your lines of service level agreements (SLAs) saying: I want the response time of this application to be under five seconds for a request response.

And then the underlying infrastructure would know how to grow and shrink to maintain that SLA. So it’s a whole other abstraction on top of the abstraction put on with virtual systems.

FF:      So this function is similar to Amazon’s automatic scaling that creates farm nodes?

PK:      Are you referring to the Amazon farm demo that we did on YouTube?

FF:      Right.

PK:      It was exactly as I described you could do it. It was something that we provided, a base image. And then we provided a whole bunch of automated scripts. Then, we would manually launch and actually assign certain things within Amazon’s infrastructure.

They have as their services something called Auto Scaling, which can monitor the usage of resources and automatically scale up and scale down. The workload pattern is very analogous to that, except that for the farming in Amazon I had to generate the scripts that were configuring it to launch and to start new farm nodes, and actually to create the images that were launching.

So there was a lot of manual stuff that I had to do in Amazon;  IBM Workload Deployer basically does the similar things using widgets.

FF:      Okay.

PK:      So all the stuff you can also do on Amazon Web Service today. Again, however, you have to manually create it, manually script it; and you have to tell it what to do. And, that’s different from platform as a service, such as IBM Workload Deployer.

FF:      Okay. What do you see the role can WebSphere Portal play in cloud computing?

PK:      I see WebSphere Portal playing lots of different roles. And what we provide in the Amazon coud and IBM SmartCloud from the public perspective – and even in the Workload Deployer – is a building block. All we can provide is a base building block that we can give to our Business Partners for them to then build up the platform, create content, or anything like that, and work with our customers.

So one aspect of it is to let the Business Partners take this base building block, add onto it, customize it in some way, whether that’s customized in a reusable way for 10 customers or whether that’s strictly customized for a single customer interaction. That’s up to them.

But we give them the base WebSphere Portal platform, and then they can take it to the next level, customizing it where they’re not having to do the installation. They do not have to do the database transfer, and they do not have to do some of the more mundane parts of generating a portal server.

These templates are reusable. Business Partners can add customized applications and components, and supply them to various customers according to their requirements.

It doesn’t have to be limited to a Business Partner. Any customer can do the exact same process if they’re savvy enough and if they’re comfortable enough working with the infrastructure, the service in Amazon.

If they’re familiar with Amazon and they know how to launch a base operating system, then they already know how to launch a portal search. And they know the techniques to get and interact with them from all aspects of the various functions that IBM SmartCloud and Amazon have. That’s one aspect, to simply give the building blocks for people to customize and add components.

Another aspect is that someone can take advantage of the building block idea to set up a hosting type of solution, where it is hosted doesn’t have to be IBM. But, somebody could take our base image and build a platform similar to how we did our Amazon farm. On Amazon, we automated a lot of things to take a significant amount of load and then grow and shrink.

Somebody could package that up and say, hey, “we can host your WebSphere portal and have a virtual portal, for example, for each customer.” You know, it’s similar to how they used to do with web servers back in the day when they hosted Apache web servers, and all of a sudden you’ve got a cool little web server that’s your piece of the Internet.

You can have your own virtual portal or you can break apart a larger portal server platform. And you could sell that in some way. But we’re not going down that road.

So today our only plan is to provide that base image. It’s up to Business Partners, it’s up to customers, it’s up to somebody else to then draw the rest of the lines.

FF:      So I can see this business model definitely will change our old licensing model, right? Or will license be very different in the cloud?

PK:      Yeah. That was probably why Marshal Lamb started doing this a couple of years ago, to learn how this works on Amazon. Marshal started this in 6.1 portal, putting things out on the IBM and Amazon cloud.

And the hardest part of setting up things in on Amazon EC2 wasn’t technically getting it to run on the cloud. There’s stuff that we put back into the product to make that available and possible. But the harder part was trying to figure out how to charge per hour.

They went through a great deal of non-technical procedures that technical people normally don’t have to deal with. The hard part is getting it to meet legal guidelines and the financial people agree with.

So within the public cloud offerings – we’ve divided it into three kinds of licensing models. One of them doesn’t necessarily count: DUO, which is Developer Use Only. And so we provide Developer Use Only offerings, which is free.

You can use portal server for Developer Use Only on Amazon for free; on IBM cloud it is for free today. Now I say for free, and I mean that from a licensing cost. You don’t have to pay any loyalties to be using it. You do have to pay Amazon however many cents an hour, depending on what you configure that portal server to run on. You have to pay Amazon per hour for that or to IBM SmartCloud.

So on the IBM SmartCloud Enterprise is a title called IBM WebSphere Portal Version (Developer Use Only). And then in the description underneath it, there’s a title and a description. DUO is one of those images.

Within the Amazon I think it’s a little harder to find the DUO images. IBM has a static web page that we update with the latest Developer Use Only AMI. So, AMI is what Amazon calls it. We’ve got a public web page that says launch AMI <the package #>, and that’s your Developer Use Only. There’s a link, and then you have to kind of correlate that with the image that you’re launching.

So, that’s how you’d look up your DUO. The other models, the closet one to DUO that might be used for a production type of use would be a bring your own license (BYOL). And really that’s exactly the same from a cost perspective as Developer Use Only.

But that’s geared for people who might already be Portal customers who have a number of PVUs (processor value units) of Portal already purchased, and maybe they’re not using all of them on premises, in their own data center.

They can bring those licenses or those PVUs to the IBM SmartCloud. think that’s limited to the IBM SmartCloud, because the Amazon has Developer Use Only and then the production level pay as you go. So there’s no middle – there’s no BYOL option on Amazon EC2.

However, for IBM SmartCloud just as there was an IBM WebSphere Portal Server (7001-DUO) there’s one called BYOL. That means we assume you bought this from IBM. You bought portal server licenses and you have the right to use them.

And I think there are entitlements-checking and other things to make sure the users are entitled, meaning they do have license. Again because you’ve already purchased the products and bought licenses, all you’re paying is the infrastructure charges. However many cents per hour is what it costs to run that virtualized machine on IBM SmartCloud.

And the third type (after DUO and BYOL) that is shared across IBM SmartCloud and Amazon Cloud is this pay as you go (PAYG). That means along with the infrastructure, along with bringing up the machine and the Amazon charges or the IBM SmartCloud charges, you also have a little bit of fee for portal server licenses.

That amount is typically broken down to per hour basis, because, you know, you might start a machine and then stop it. The hardest part was figuring out how much it costs per hour.

It’s not broken down by PVUs anymore; it’s now per hour. That’s how you can get it. And so depending on your business model, depending on what you’re using it for, there is cost benefit analysis that you can do.

You can talk to some finance people who have a chart that shows you the benefit of how many years it would take you (using per hour) to get to the same that you would pay if you bought the PVUs and a traditional portal license.That’s a pretty valuable model to go through anytime you look at doing this for a long term.

FF:      Okay. So, this is not upfront that you pay millions of dollars, but you pay as you go?

PK:      Over the course of three, or four, or five years, you might reach that same amount that you pay for upfront. But, you know, a lot of people like the idea of not buying any hardware, not buying any licenses, not committing to anything, and saying at anytime: “I’ll just shut this out and all my costs just stop; and I don’t have to recover that hardware, and I don’t have to recover that software.

There are people who do like that. And, there are people who are more traditional and would say: No, we need to follow this process and acquire the hardware. Or maybe not acquire the hardware – that’s kind of one of the benefits of also in the cloud, which is kind of skip that approval process and whatever it is to get capital simply to run hardware and then simply to configure the hardware.

All of that is kind of skipped over. However, from a license-purchase perspective, there might be some more traditional customers who say: I just want to buy – I know I’m going to need this many licenses, and I want it for a year; I’m going to buy this many PVUs.

If I want to skip over the procurement of the hardware and the configuration then I can just take those PVUs and take them directly to the cloud, and I’ve got it up and running in two or three months quicker than that approval cycle might add.

FF:      What do you see the difference between the public offering and private cloud offering?

PK:      The difference from a functional standpoint or from what aspect?

FF:      More from the business investment and maybe security concerns.

PK:      Right. All of this is a transition, and you could say it’s even a disruptive transition. Cloud I’m sure has the word disruptive. I’ve used the word disruptive when it is about abstraction of topologies when it comes to workload patterns.

Disruption can be good, but it’s also very difficult to adopt, especially if you’ve got shops that have a set of security policies and have a dedicated set of things that have to be on every single operating system. And they have certain guidelines.

Even IBM has ITCS (Information Technology Corporate Standard) classifications of our assets. So there’s a lot of governance. A lot of things are in place, depending on the company you work for, that lend themselves more to being a private cloud.

Because when you push something to the public cloud, you’re all of a sudden told what operating system you’re running; you’re all of a sudden told (if installed on this directory) you can change it with a little bit of work. But you’re giving up a level of control. And you’re giving up a level of SLAs and off loading that, pushing that, to somebody else.

Now if you can come to some kind of contract with IBM SmartCloud or Amazon Cloud that satisfied your own SLAs then maybe you’re a step there. But if you’re a traditional shop you like the idea of on-premises.

On-premises doesn’t mean you can’t take advantage of virtualization or cloud. And that’s why IBM Workload Deployer or CloudBurst comes in very handy, because it helps with the transition going from the traditional “let’s build it ourselves” model and then it moves you to “let’s offload some of this stuff but still have it under our control, in our data center, following our guidelines.” And we can control lots of things within this CloudBurst-based private cloud. But at the same time take advantage of some of the virtualization, the consolidation, and having a single large hypervisor that hosts all these things.

You know, we’re definitely moving in that direction. We’ve got a level of automation that IBM Workload Deployer adds to it. It helps with the transition to finally get past private cloud and into public cloud. I think we’ll see more and more adoption as we go – as we make the transition, as more and more people are comfortable and feel secure in doing it, and feel better about the stability of the platforms of the IBM SmartCloud and the Amazon Cloud.

So it’s going to be a transition. But we have kind of a stepping stone to get there. Portal server plays in the private clouds with the CloudBurst and IBM Workload Deployer. And then we also give you IBM SmartCloud and Amazon in the public cloud, so you can make that transition.

FF:      Definitely security is a major concern for many corporations, like banks and insurance companies. Do you see WebSphere Portal in the public cloud as more vulnerable than on-premises physical or even private cloud?

PK:      I think they are, but that’s not a specific portal question, right? The same vulnerabilities done incorrectly on-premises would be done incorrectly on the cloud.

Similarly there are security measures and mechanisms in cloud you can take advantage of. There are firewall zones you can set up in Amazon Cloud. There’s functionality within each of the clouds – you can dedicate your virtual images to a dedicated virtual network, so that only you have access to that environment. And so, you can tie that in.

And it’s been described as an extension to your data center in the firewall rules, all of the things that you set up within your data center tend to be extended and reserved out on public cloud resources. You have the same level of control that you have on your own data centers.

So from that aspect, from a security and vulnerability standpoint, the fact that you’re having somebody else host these isn’t introducing a risk. Although the risk is that you’re on a shared infrastructure, a lot of those risks can be mitigated. You really need to pay attention to how you’re doing it. That is my longer answer, thus it’s not just a portal-specific issue.

I mean, how are you going to fix this (security and how to keep the Portal and website data safe) with your web server and firewall infrastructure; and anything that’s  confidential being hosted on the cloud needs to be addressed also in a similar way with portal.

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, 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