Showing posts with label WSO2. Show all posts
Showing posts with label WSO2. Show all posts

Wednesday, January 12, 2011

Move to Cloud Increasingly Requires Adoption of Modern Middleware to Support PaaS and Dynamic Workloads

Transcript of a sponsored BriefingsDirect podcast on how to modernize infrastructure to enable IT to become better "business service factories."

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Learn more about WSO2 and cloud management
Download "Effective Cloud Management with WSO2 Strategies"
More information on WSO2 Stratos
Attend a WSO2 SOA Workshop to Energize your Business with SOA and Cloud

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on the role and importance of private cloud infrastructure models as a stepping stone to much needed new operational models for IT.

A lot of the interest in cloud computing generally has been as much about a wish to escape the complex and wasteful ways of the old as an embrace of something well understood and new. [Disclosure: WSO2 is a sponsor of BriefingsDirect podcasts.]

So, how do large enterprises remake themselves into business service factories? How do they modernize IT and Internet-enabled ecosystem processes in the same ways that industrial engineering, lean manufacturing, efficiency measurement, just-in-time inventory, and various maturity models revolutionized bricks and mortar businesses a generation ago?

This larger question of how to attain IT transformation is what cloud computing purports to answer. But, the question itself may be more important than any yet defined answer. If public cloud computing is an end goal that provides a catalyst to such needed general transformation, all ends well and good.

Meanwhile, what of the practical steps that can help an organization now? How can enterprises learn to adopt new services sourcing models as well as to attain the means for better consumption of services, regardless of their origins?

Today, we’ll examine how enterprises can appreciate the transformative role of private cloud, and begin to focus on dynamic workloads and agile middleware as essential enablers along the way to even larger process-level business benefit -- and then ultimately to a more fully cloud-based IT models.

To discuss how workload assembly in the private cloud domain provides a big step in the right direction for IT’s future, we're joined by Paul Fremantle, the UK-based Chief Technology Officer and co-founder of WSO2. Welcome, Paul.

Paul Fremantle: Hi, Dana. How are you doing?

Gardner: I'm well, thank you. We are also here today with Paul O’Connor, Chief Technology Officer at ANATAS International in Sydney, Australia. Welcome to you as well, Paul.

Thanks, Dana.

Gardner: Paul O’Connor, tell me a little bit about why a transformative new approach to IT is necessary. It seems as if incremental improvement is just not good enough.

Past failures

O'Connor: It’s unfortunate, but it’s fair to say that all of the past initiatives that we tried in
large, complex enterprises have been a failure. In some cases, we’ve actually made things worse.

Large enterprises, at the same time, still have to focus on efficiency, agility, and delivery to their end users, so as to achieve market competitiveness. We still have that maniacal focus on delivery and efficiency, and now some new thinking has come in.

Specifically, we have cloud or the everything-as-a-service operating model coupled with a series of other trends in the industry that are being bolted together for a final assault on meaningful efficiency. You hit the nail on the head when you mentioned industrial engineering, because industrial engineering is the organizing principle for weaving all of these facets together.

When we focus on industrial engineering, we already have an established pattern. The techniques are now lean manufacturing, process improvement and measurement of efficiency, just-in-time inventory, maturity models. Ultimately, large enterprises are now approaching the problem effectively including cloud, including moving to new operating models. They're really focusing on building out that factory. I'm sure we’ll be able to tease out some of those specifics at a slightly lower level of detail as the podcast goes on.

IT itself is transformative and you have to be pushing the boundaries in order to compete in the modern world.



Gardner: Well, great. Maybe you could also tell us a little bit more about ANATAS International; what sort of organization is that and what do you do there?

O'Connor: I'm CTO. We serve the Asia-Pacific region and have focused for a number of years on next-gen architecture -- technical architecture, enterprise architecture and service oriented architecture (SOA). In the last couple of years, we’ve been focusing as well on cloud, and on how these things come together to give us a shot at being more efficient in large complex enterprises.

Gardner: Paul Fremantle, why do you think that the idea of cloud computing has really caught on, whether it’s private cloud, public cloud, platform as a service (PaaS), or infrastructure as a service (IaaS)?

We're adding more "as services" all the time, but this really seems to have just caught in people’s attention in the last two or three years, and seems to be gaining. It doesn’t seem to be waning. Is it this need for a transformative approach that has made cloud somewhat of a silver bullet? Why is this so important to people?

Fremantle: It’s a fairly straightforward story. We've discovered that you cannot just build an IT
system or an IT infrastructure, put your feet up, sit back, and say, "Well, that will do the business," because the business has learned that IT itself is transformative and you have to be pushing the boundaries in order to compete in the modern world.

Effectively, it’s no longer good enough to just put in a new system in every 5 or 10 years and sit back and run it. People are constantly pushing to create new value to build new processes, to find better ways of using what they have, linking it together, composing it, and doing new things.

So the speed of delivery and the agility of organizations have become absolutely key to their competitiveness and fundamentally to their stock price. A huge move in agility came first with web, with portals, and with SOA. People discovered that, rather than writing things from scratch, they could reuse, they could reconfigure, and they could attach things together in new ways to build function. As they did that, the speed of development and the speed of creating these new processes has skyrocketed.

Unfortunately, the speed and agility of the infrastructure and of the ability to take these things and host them has not kept up. What cloud has done is that it has suddenly energized the infrastructure, energized the platform, and has given people a way of not just building things quickly but hosting them, deploying them, and managing them in an agile way. Fundamentally, what’s driving the cloud revolution is speed of delivery.

Gardner: I’ll go back to Paul O’Connor with his comments about architecture. As we do what Paul Fremantle has suggested, we seem to also hit up against scale. Automation needs to kick in, and that can perhaps only be best attained through an architecture built for scale. How do the modern platforms and systems that Paul Fremantle is discussing provide a catalyst, or at least a cohort, to this need for better architecture, Paul O’Connor?

Better architecture

O'Connor: When we say better architecture, I think what we are talking about is the facets of
architecture that are about process, that are about that how you actually design and build and deliver. At the end of the day, architecture is about change, and it must be agile. I can architect a fantastic Sydney Opera House, but if I can't organize the construction materials to show up in a structured way, then I can’t construct it. Effectively, we’ve embraced that concept now in large enterprises.

Specifically in IT, we find coming into play around this concept a lot of the same capabilities that we’ve already developed, some of which Paul alluded to, plus things like policy-based, model-driven configuration and governance, management and monitoring and asset metadata, asset lifecycle management types of things relative to services and the underlying assets that are needed to actually provision and manage them.

We're seeing those brought to bear against the difficult problems of how might I create a very agile architecture that requires an order of magnitude less people to deliver and manage.

It helps with problems like this: How can I keep configured a thousand end-points in my enterprise, some of which might be everything from existing servers and web farms all the way up to instances of lean middleware like WSO2 that I might spin up in the cloud to process large workloads and all of the data associated with it?

Gardner: I suppose also, Paul Fremantle, that a secondary or additional motivator at this time is the need for pervasive security, for baking security and governance in across the board, not as a bolt-on, not as an afterthought, not as some sort a requirement of that is separate and distinct from the entire IT lifecycle.

There's an opportunity to turn that from a negative into a positive by fundamentally building secure systems from day one, rather than just relying on them being secure from where they are located, which is kind of the current model.



So, is there also a bit of a catalyst when it comes to making security pervasive that's also driving folks to better architecture and more agile middleware that will perhaps ultimately move toward a cloud-based model?

Fremantle: Absolutely. The biggest concern in everyone's mind around cloud is security. I think there's an opportunity to turn that from a negative into a positive by fundamentally building secure systems from day one, rather than just relying on them being secure from where they are located, which is kind of the current model.

I'm a firm believer that the real success in cloud is going to come from designing systems that are inherently built to run in the cloud, whether that's about scale, elasticity, security, or things like multi-tenancy and self-service.

Those concepts of building things that run in the cloud and making the software inherently cloud aware, comes back to what Paul O'Connor was talking about with regard to having the right architecture for the future and for the cloud.

Gardner: So, when we look at security as a positive, rather than a negative, as we transform and transition with cloud models, is there more than one layer or level of security? How do we approach this? How do we get our hands around it, so that it can be something that's implemented, rather than almost just at the division or abstract level?

Federated security

F
remantle: The first and most important thing is to use middleware and models that are designed around federated security. This is just a simple thing. If you look back at middleware, for example message queuing products from 10 years ago, there was no inherent security in them.

If you look at the SOA stack and the SOAP models or even REST models, there are inherent security models such as WS-Trust, WS-SecureConversation, or in the REST model things like SAML2, OAuth and OpenID. These models allow you to build highly secure systems.

But, however much I think it's possible to build secure cloud systems, the reality is that today 90 percent of my customers are not willing or interested in hosting things in a public cloud. It’s driving a huge demand for private cloud. That’s going to change, as people gain confidence and as they start to protect and rebuild their systems with federated security in mind from day one, but that's going to take some time.

Gardner: Paul O’Connor, do you share Paul Fremantle's concept that good architecture and building for cloud models has an inherent security benefit to it? Are you at ANATAS also architecting for both security and a services factory model?

O'Connor: Absolutely. You're not allowed to do anything in large enterprises architecturally without getting past security. When I say get past security, I'm talking about the people who have magnifying glasses on your architectural content documents. It's important enough to say again what Paul brought out about location not being the way to secure your customer data anymore.

The reality is that today 90 percent of my customers are not willing or interested in hosting things in a public cloud. It’s driving a huge demand for private cloud.



The motivation for a new security model is not just in terms of movement all the way to the other end of the agility rainbow, where in a public cloud you’re mashing up some of your data with everybody else's, potentially, and concerned about it going astray.

It’s really about that internal factory configuration and design that says, even internally in large enterprises, I can't rely on having zones of network security that I pin my security architecture to. I have to do it at the message level. I have to use some of the standards and the technologies that we've seen evolved over the past five, six, seven years that Paul Fremantle was referencing to really come to bear to keep me secure.

Once I do that, then it's not that far of a leap to conceive of an environment where those same security structures, technologies, and processes can be used in a more hybrid architecture, where maybe it's not just secure internal private cloud, but maybe it's virtual private cloud running outside of the enterprise.

That brings in other facets that we really have to sort out. They have to do with how we source that capacity, even if it's virtual private cloud or even if it's tenanted. We have to work on our zone security model that talks about what's allowed to be where. We have to profile our data and understand how our data relates to workloads.

As Paul mentioned, we have to focus on federated identity and trust, so identity as a service. We have to assemble the way that processing environments, be they internal or external, get their identities, so that they can enforce security. PKI, and, this is a big one, we have to get our certificates and private keys into the right spot.

Policy-driven governance

Once we build all those foundations for this, we then have to focus on policy-driven governance of how workloads are assembled with respect to all of those different security facets and all of the other facets, including quality of service, capacity, cost, and everything else. But, ultimately yes, we can solve this and we will solve this over the next few years. All this makes for good, effective security architecture in general. It's just a matter of helping people, through forums like this, to think about it in a slightly different way.

Gardner: As we're moving toward new kinds of architectures that can be inclusive of the past, but prepare us better for the future with this full set of requirements in terms of scalability, security, openness to sourcing elasticity, and so forth, what do we need to look for in terms of the underlying infrastructure itself?

Are there some key requirements that we would look for in terms of how the performance, technical characteristics, standard support, all come together in such a way that we can move forward including compatibility with what's in place -- and still start meeting up with what we want around performance, the sourcing flexibility and security? Let me take that first to Paul Fremantle. What needs to be in place?

Fremantle: I believe that the world has slightly gone backward, and that isn't actually that surprising. When people move forward into such a big jump as to move from a fixed infrastructure to a cloud infrastructure, sometimes it's kind of easy to move back in another area. I think what's happened to some extent is that, as people have moved forward into cloud infrastructure, they have tended to build very straightforward monolithic applications.

The way that they have done that is to focus on, "I'm going to take something standalone and simple that I can cloud-enable and that's going to be my first cloud project." What's happened is that people have avoided the complexity of saying,"What I really need to be doing is building composite applications with federated identity, with business process management (BPM), ESB flows, and so forth."

Learn more about WSO2 and cloud management
Download "Effective Cloud Management with WSO2 Strategies"
More information on WSO2 Stratos
Attend a WSO2 SOA Workshop to Energize your Business with SOA and Cloud

And, that's not that surprising, when they're taking on something new. But, very rapidly, people are going to realize that a cloud app on its own is just as isolated as an enterprise app that can't talk to anything.

The result is that people are going to need to move up the stack. At the moment, everyone is very focused on virtual machines (VMs) and IaaS. That doesn't help you with all the things that Paul O'Connor has been talking about with architecture, scalability, and building systems that are going to really be transformative and change the way you do things.

From my perspective, the way that you do that is that you stop focusing on VMs and you try and move up a layer, and start thinking about PaaS instead of IaaS.

You try to build things that use inherent cloud capabilities offered by a platform that give you scalability, federated security, identity, billing, all the things that you are going to need in that cloud environment that you don't want to have to write and build yourself. You want a platform to provide that. That's really where the world is going to have to move in order to take the full advantage of cloud -- PaaS.

Gardner: Paul O'Connor, from your perspective, what are some key characteristics that that platform should have? What are the necessary ingredients in order to make this automated, controllable, governed, and to scale across these new sourcing models that we're approaching?

The name of the game

O'Connor: I totally agree with everything Paul Fremantle just said. PaaS is the name of the game. If you go to 10 large enterprises, you're going to find them by and large focusing on IaaS. That's fine. It's a much lower barrier of entry relative to where most shops are currently in terms of virtualization.

But, when you get up into delivering new value, you're really creating that factory. Just to draw an analogy, you don't go to an auto factory, where the workers are meant to be programming robots. They build cars. Same thing with business service delivery in IT -- it's really important to plug your reference model and your reference architectures for cloud into that factory approach.

You want your PaaS to be a one-stop-shop for business service production and that means from the very beginning to the very end. You have to tenant and support your customers all along the way. So it really takes the vertical stack, which is the way we currently think about cloud in terms of IaaS, and fans it out horizontally, so that we have a place to plug different customers in the enterprise into that.

And what we find is, just as in any good factory or any good process design, we really focus on what it is those customers need and when. For example, just to take one of many things that's typically broken in large enterprises, testing and test environments. Sometimes it takes weeks in large organization to get test environments. We see customers who literally forgo key parts of testing and really sort of do a big bang test approach at the end, because it is so difficult to get environment and to manage the configuration of those environments.

One of the ways we can fix that is by organizing that part of the PaaS story and wrap around some of the attendant next-generation configuration management capabilities that go along with that. That would include things like service test virtualization, agile operations, asset metadata management, some of the application lifecycle management (ALM) stuff, and focus on systemically killing the biggest impedances in the order of most pain in the enterprise. You can do that without worrying about, or going anywhere near, public cloud to go do data processing.

I think we will see larger appetites by the business for more applications and a need to put them into a place where they are more easily managed.



So that's the here and now, and I'd say that that's also supportive of a longer term, grand unified field theory of cloud, which is about consuming IT entirely as a service. To do that, we have to get our house in order in the same way and focus on organizing and re-organizing in terms of transformation in the enterprise to support first the internal customers, followed by using the same presets and tenets to focus on getting outside of the organization in a very structured way.

But eventually moving workloads out of the organization and focusing on direct interaction with the business, I think we will see larger appetites by the business for more applications and a need to put them into a place where they are more easily managed, and eventually, it may take 20 years, but I think you'll see organizations move to turn off their internal IT departments and focus on business, focus on being an insurance company, a bank, or a logistics company. But, we start in the here and now with PaaS.

Gardner: Okay. Paul O'Connor, if I can just add one more thing to that. I read in some of your literature -- and I quote from you -- “Work load assembly in the cloud is the name of the game.” It seems that you're talking about private cloud first, then, ultimately, any number of other hybrid cloud scenarios. Is that what you mean across this development, test, deploy, workload assembly? What do you mean by that?

What is it doing?


O'Connor: Workload assembly. What I mean by that is that we need a profile of what it is we do in terms of work. If I plug a job into the wall that is my next-gen IT architecture, what is it actually doing and how will I know? The types of things vary. It varies widely between phases of my development cycle.

Obviously, if I do load and performance testing, I've got a large workload. If I do production, I’ve got a large workload. If I move to big data, and I am starting to do massively scalar analytics because the business realizes that you go after such an application, thanks to where IT is taking the enterprise, then that's a whole other ball of wax again.

What I have to do is understand those workloads. I have to understand them in terms of the data that they operate on, especially in terms of its confidentiality. I have to understand what requirements I need to assemble in terms of the workload processing.

If I have identify show up, or private key, I have to do integration, or I have to wire into different systems and data sources, all of that has to be understood and assembled with that workload. I have to characterize workload in a very specific way, because ultimately I want to use something like WSO2 Stratos to assemble what that workload needs to run. Once I can assemble it, then it becomes even easier for me to work my way through the dev, test, stage, release, operate cycle.

Gardner: Paul Fremantle, tell me what WSO2 is doing to help people like Paul O'Connor reach this workload assembly capability?

That starts with some very simple things, like identity as a service, so that there is a consistent multi-tenant concept of identity, authorization, and entitlement available wherever you are in the private cloud, or the public cloud, or hybrid.



Fremantle: What we have done is build our Carbon middleware on OSGi. About two years ago, we started thinking how we're going to make that really effective in a cloud environment. We came up with this concept of cloud-native software. We were lucky, because, having modularized Carbon, we had also kernelized it. We put everything around a single kernel. So, we were able to make that kernel operate in a cloud environment.

That’s the engineering viewpoint, but from the architecture viewpoint, what we're providing to architects like Paul O’Connor is a complete platform that gives you what you need to build out all of the great things that Paul O’Connor has been talking about.

That starts with some very simple things, like identity as a service, so that there is a consistent multi-tenant concept of identity, authorization, and entitlement available wherever you are in the private cloud, or the public cloud, or hybrid.

The next thing, which we think absolutely vital, is governance monitoring, metering, and billing -- all available as a service -- so that you can see what's happening in this cloud. You can monitor and meter it, you can allocate cost to the right people, whether that’s a public bill or an internal report within a private cloud.

Then, we're saying that as you build out this cloud, you need the right infrastructure to be able to build these assemblies and to be able to scale. You need to have a cloud native app server that can be deployed in the cloud and elastically scale up and down. You need to have an ESB as a service that can be used to link together different cloud applications, whether they're public cloud, private cloud, or a combination of the two.

Pulling together

And, you need to have things like business process in the cloud, portal in the cloud, and so on, to pull these things together. Of course, on the way, you're going to need things like queues or databases. So, what we're doing with Stratos is pulling together the combination of those components that you need to have a good architecture, and making them available as a service, whether it's in a private cloud or a public cloud.

That is absolutely vital. It's about providing people with the right building blocks. If you look at what the IaaS providers are doing, they're providing people with VMs as the building blocks.

Twenty years ago, if someone asked me to build an app, I would have started with the machine and the OS and I would start writing code. But, in the last 20 years we've moved up the stack. If someone asked me to build an app now, I would start with an app server, a message queuing infrastructure, an ESB, a business process server, and a portal. All these components help me be much more effective and much quicker. In a cloud, those are the cloud components that you need to have lying around ready to assemble, and that to me is the answer.

Gardner: Paul Fremantle, you're describing what you think is the best way to support a workload assembly capability, but how is that different from what we're seeing from some of the service delivery platform vendors, and what we could call "cloud in a box?" What's the difference between what they're talking about and what you're talking about?

The thing that those PaaS providers are missing, and most of the PaaS that I see out there is missing, is a real enterprise architecture view of the world.



Fremantle: I'm seeing various things in the marketplace. Obviously, there are people like Eucalyptus, Ubuntu, and of course VMware, who are providing private IaaS, and that’s very important. We work on top of those layers. I'm also seeing a lot of people producing PaaS. December was an exciting month. We've had two acquisitions in that space.

The thing that those PaaS providers are missing, and most of the PaaS that I see out there is missing, is a real enterprise architecture view of the world. It's fine to provide a web app as a service and a database as a service. Those are the basic building blocks that people need. But, if you don't have an open, clear definition of identity, governance, business activity monitoring, BPM, and ESB, you're stuck in a 10-year-old architecture.

So, for me, where you're going to have to move is to a complete platform that understands enterprise architecture (EA). It isn’t just about saying, "I've got a web app and a database that are somehow provided in a cloud native fashion."

Gardner: Paul O'Connor, I'm an advocate of showing rather than telling, when it comes to these sorts of complex issues. Do we have any examples of perhaps companies that ANATAS has worked with, where they have employed some of these approaches, whether from a position of the technology, the actual implementation of certain products and services, the methodologies, or all of the above? What do you get? What happens when you do this properly? What sort of business and/or technical benefits can we expect based on the record so far?

O'Connor: I'll tell you about a large enterprise that we have been working with for a good long while. They are building an internal PaaS, an internal platform which is operated as a service. This is key. They're looking at that as a way to achieve some tangible benefits right out of the gate, while supporting a longer-term vision, which is about beating back into submission as much of the sprawl that has grown up over the course of time in large enterprises.

The immediate benefits in that case are about efficiency and business service architecture and constraints. By that, I mean that if you have one standard service delivery process that’s highly efficient that starts with modeling and works its way all the way through to operation in a business sense of business services, what you wind up with is an approach on the business side itself to use that as a lever to go out and directly be able to add in efficiencies, attack new markets, and really focus on some things on the business side that were latent, because there was a feeling that it couldn't be delivered efficiently by IT or may not work.

Seeing it work

We're really seeing that lever work. It's right there. We're also seeing a focus on a broader picture. I want to make one point following up on what Paul Fremantle was saying earlier. We really need to have, and this is what this client has done, a reference architecture that is sort of the antithesis of cloud in a box.

It's structured so that you don’t get tied into one particular vendor's view of cloud or anything else. You’ve really taken an Architecture 101 approach. You build a reference model, you build a reference architecture, you go execute against that, and you don’t have either an inheritance from the IaaS guys up into the higher parts of the stack or the sprawl from the existing platform players down into the infrastructure space.

Ultimately, and this is how this client views it, cloud is more than a way of thinking. It’s open and it’s about getting your house in order, but it’s also about not being locked in and trying to, in the case where we feel like we should, turn the table on our existing vendors.

And that’s what WSO2 is doing in terms of a feature-driven lean middleware and also the way that they are approaching delivery in terms of a professional open-source model, and is very much in keeping with the way that my clients view the cloud.

Gardner: Paul Fremantle, we only have time for one additional example. Do you have some customers that you've been working with that are perhaps what you would consider a bellwether for where the rest of the enterprises are likely to go?

It’s something I'm seeing a lot of software companies looking at as well, which is to start converting their applications into SaaS.



Fremantle: I want to put a different spin on this, which is that as well as the companies that are doing what Paul O'Connor was talking about and using PaaS to create the software factory concept within their organization, there is another angle on this, which is interesting. It's the ability of people, not just software vendors, but also system integrators and even service providers, to start using PaaS to create their own cloud software as a service (SaaS).

This was brought to mind to me by one European-based system integrator and business process outsourcer. Unfortunately, I can’t name them, but they're a partner of ours. What they've started to do is think, "When I'm building an application or a process for customer, is that something that is really applicable just to this one customer or is it something that is a reusable asset, that can be offered as a service to multiple customers?"

Of course, that may not be offered over the public cloud. It may be hosted in a private cloud and different companies give a VPN access to their own tenant within that. It’s something I'm seeing a lot of software companies looking at as well, which is to start converting their applications into SaaS.

And as you do that, you quickly find that the things you need, the capabilities that you need, in order to offer SaaS are the same capabilities that you need in a platform. They're the things I was talking about before, things like identity, governance, metadata, monitoring and metering billing.

To me, the interesting thing here is the intersection between how large enterprises are treating their software development and how software companies are treating their software development, and system integrators and business process outsourcers are treating their software development. They're all converging on the most efficient model that we have come up with yet.

Gardner: Very interesting. It sounds as if the IT ecosystem is marching in tandem towards the same vision, and that will perhaps enable these enterprises to move all the more quickly, rather than the enterprises doing it essentially on their own.

Fremantle: Absolutely.

Gardner: Well, very good. I'm afraid we're about out of time. We've been discussing how workload assembly and the concept of a business service factory are important attributes to private clouds, and how private clouds when established using these best practices and principles, can provide a huge stepping stone in the right direction for the future of IT, a transformed future of IT.

I want to thank our panelists. We've been joined by Paul Fremantle, the UK-based Chief Technology Officer and co-founder of WSO2. Thanks so much, Paul.

Fremantle: Thank you very much.

Gardner: And, we’ve also been joined by Paul O’Connor, the Chief Technology Officer at ANATAS International in Sydney, Australia. Thanks for joining as well, Paul.

O'Connor: Thanks, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Transcript of a sponsored BriefingsDirect podcast on how to modernize infrastructure to enable IT to become better "business service factories." Copyright Interarbor Solutions, LLC, 2005-2011. All rights reserved.

Learn more about WSO2 and cloud management
Download "Effective Cloud Management with WSO2 Strategies"
More information on WSO2 Stratos
Attend a WSO2 SOA Workshop to Energize your Business with SOA and Cloud

You may also be interested in:

Friday, August 06, 2010

Cloud Computing's Ultimate Value Depends Open PaaS Models to Avoid Applications and Data Lock-In

Transcript of a sponsored podcast discussion on open markets for cloud computing services and the need for applications that can move from one platform to another with relative ease.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Get the free
"Cloud Lock-In Prevention Checklist"
here.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on openness, portability and avoiding unnecessary application lock-in in the use of cloud computing.

A remaining burning question about the value and utility of cloud computing is whether applications and data can move with relative ease from cloud to cloud -- that is, across so-called public- and private-cloud divides, and among and between various public cloud providers.

For enterprises to determine the true value of cloud models -- and to ascertain if their cost and productivity improvements will be sufficient to overcome their disruptive shift to cloud computing -- they really must know the actual degree of what I call "application fungibility."

Fungible means being able to move in and out of like systems or processes, like a bushel of corn is fungible regardless of the market you buy it in. You can buy and sell a bushel of corn as a commodity across multiple markets and across multiple buyers: They know what they're getting.

But what of modern IT applications? Wouldn’t cloud models be far more attractive, and hybrid cloud models much more attainable, if applications (or instances of applications) were largely fungible -- able to move from cloud to cloud -- and still function?

Application fungibility would, I believe, create a real marketplace for cloud services, something very much in the best interest of enterprises, small and medium businesses (SMBs), independent software vendors (ISVs), and developers.

Fungible applications could avoid the prospect of swapping on-premises platform lock-in for some sort of cloud-based service provider lock-in and, perhaps over time, prevent being held hostage to rising cloud prices.

Today, we'll examine how enterprises and developers should be considering the concept of application fungibility, both in terms of technical enablers and standards for cloud computing, and also consider how to craft the proper service-level agreements (SLAs) to promote fungibility of their applications.

Here to discuss how application fungibility can bring efficiency and ensure freedom of successful cloud computing, we're now joined by Paul Fremantle, Chief Technology Officer and Co-Founder at WSO2. Welcome back to BriefingsDirect, Paul.

Paul Fremantle: Hi, Dana. Nice to see you again.

Gardner: We're also here with Miko Matsumura, author of SOA Adoption for Dummies and an influential blogger and thought leader on cloud computing subjects. Welcome back, Miko.

Miko Matsumura: Great to be here.

Gardner: So, as for this ability to bring an open vision of cloud computing, I think many people have a vision that it's perhaps a little bit more grand than the current reality. Let's go to you first, Miko. What's the difference between the popular vision of cloud computing and what's really available now? Is there much fungibility available?

Low fungibility

Matsumura: Fungibility is very, very critical, and one thing I want to emphasize is that the fungibility level of current solutions is very low. It's very logical to understand the history of this.

One of the things that really we need to understand about cloud computing is the word that you used in introducing the topic, which is this concept of "disruptive," the notion that you can have this kind of elasticity and the application can actually scale pretty radically within cloud a environment. This is one of the primary attractive aspects of entering into a cloud paradigm. So, that's a really neat idea.

The economics of upscaling and downscaling as a utility is very attractive. Obviously, there are a lot of reasons why people would start moving into the cloud, but the thing that we're talking about today with this fungibility factor is not so much why would you start using cloud, but really what is the endgame for successful applications.

The thing that's really intriguing is that, if your application in the cloud is unsuccessful and nobody uses it, it doesn’t really matter. You don’t need to move it. You don’t need to pay for it. In fact, the requirement that you don’t pay for an app that isn’t successful is a very good benefit to the business.

The area where we are specifically concerned is when the application is more successful than in your wildest dreams. Now, in some ways what it creates is almost an unprecedented leverage point for the supplier. If you're locked in to a very high-transactional, high-value application, at that point, if you have no flexibility or fungibility, you're pretty much stuck. The history of the pricing power of the vendor could be replicated in cloud and potentially could be even more significant.

In terms of a direct answer, fungibility, as its being offered today, is very poor and there are very few solutions in the market that offer a way for people to pragmatically move, once things start to take off and are successful.

Gardner: Paul Fremantle, do you also share this perception that there isn't very much fungibility? Why is it that people would allow themselves to get in a position where their applications are locked in, perhaps even more severely than had been in an on-premises deployment?

Fremantle: That's a really interesting question, Dana. The reality of cloud is that people are jumping on it, and I can understand why. In the current situation, many infrastructure teams and infrastructure providers within large organizations unfortunately have got to the point where it takes many months to provide a piece of hardware for a new app.

Just roll back a few years. Imagine it took 12 months to build the app, and it took 3 or 4 months to provide the hardware. That's fine. You have 8 months of developing, before you even need to go talk to the infrastructure guys and say, "I need some hardware for this."

Roll forward now, and people are building apps in a month, a week, or even a day, and they need to be hosted. The infrastructure team unfortunately hasn’t been able to keep up with those productivity gains.

Now, people are saying, "I just want to host it." So, they go to Amazon, Rackspace, ElasticHosts, Joyent, whoever their provider is, and they just jump on that and say,"Here is my credit card, and there is a host to deploy my app on."

No way out

The problem comes when, exactly as Miko said, that app is now going to grow. And in some cases, they're going to end up with very large bills to that provider and no obvious way out of that.

You could say that the answer to that is that we need cloud standards, and there have been a number of initiatives to come up with standard cloud management application programming interfaces (APIs) that would, in theory, solve this. Unfortunately, there are some challenges to that, one of which is that not every cloud has the same underlying infrastructure.

Take Amazon, for example. It has its own interesting storage models. It has a whole set of APIs that are particularly specific to Amazon. Now, there are a few people who are providing those same APIs -- people like Eucalyptus and Ubuntu -- but it doesn’t mean you can just take your app off of Amazon and put it onto Rackspace, unfortunately, without a significant amount of work.

As we go up the scale into what's now being termed as platform as a service (PaaS), where people are starting to build higher level abstractions on top of those virtual machines (VMs) and infrastructure, you can get even more locked in.

When people come up with a PaaS, it provides extra functionality, but now it means that instead of just relying on a virtualized hardware, you're now relying on a virtualized middleware, and it becomes absolutely vital that you consider lock-in and don’t just end up trapped on a particular platform.

One of the things that naturally evolved, as a result of the emergence of a common foe, is this principle of unification, openness, and alliance.



Gardner: Miko, we used to hear, going on 15 years ago, the notion of "write once, run anywhere," and that was very attractive in that time. But, I think what we're pointing out now is this ability to write once and deploy anywhere.

Maybe you could tell us how "write once, run anywhere" got going, because I know that at that time you were involved quite a bit with Java. Is there a sense of an offspring with cloud that we should look to in terms of this ability of fungibility?

Matsumura: That that's a very good and exciting parallel. On the development side, one of the things that naturally evolved, as a result of the emergence of a common foe, is this principle of unification, openness, and alliance.

It's a funny thing. It goes way farther back than even the ancient Greeks banding together to attack the Hittites at Troy, or the moon landing, where the United States was unified against the Russians. Every major advance in technology seems to be associated with everybody getting together in order to fight a common foe.

So, it's a very funny thing to see, because "write once, run anywhere" was really just a response, in Java terms, to the emergence of a dominant Microsoft, and in some ways it's an interesting emergent phenomenon.

Emergent players

The things to look at in the cloud world are who are the emergent dominant players and will Amazon and Google or one of these players start to behave as an economic bully? Right now, since we're in the early days of cloud, I don't think that people are feeling the potential for domination that would drive such a friendly, open behavior.

People who are thinking ahead to the endgame are pretty clear that that power will emerge and that any rational, publicly traded company will maximize its shareholder value by applying any available leverage. Because, if you have leverage against the customer, that produces very benevolent looking quarterly returns.

Gardner: Paul Fremantle, as I mentioned a little earlier in the set up, it's now the time when enterprises are starting to do their cost benefit analysis to ask what makes sense to keep close to their vests, within their control, and on-premises, and what might be more of a commodity function, application, or service that we would look to a cloud model.

But, it seems to me that you can't really take that without considering what degree of fungibility is involved. So, from your perspective, what are the potential economics here?

Fremantle: The economics are really interesting, and there are two ways of looking at them. A lot of people are looking at economics to say, "What is the internal cost of hosting? Can I move my CAPEX to OPEX and pay-per-use?"

Unfortunately, the big issue that comes in there, in most people's mind, is security. Can they move things to a public cloud because of security? Do they need a private cloud? Those are the simplistic first steps people go through as they start looking at cloud.

That's a very important aspect to look at when you move to cloud, both software as a service (SaaS) and the lower level functions, because you don't want to move something that you consider a core strength out to be a generic service.



Two other interesting angles need to be looked at. The first of those is about exactly what you just came up with, which is, what is my competitive advantage? Where do I particularly gain advantage over my competitors, and through which services?

That's a very important aspect to look at when you move to cloud, both software as a service (SaaS) and the lower-level functions, because you don't want to move something that you consider a core strength out to be a generic service.

So, if you think that your proprietary algorithms for customer relationship management (CRM) are absolutely vital to the success of your organization, the last thing you want to do is dump those and go to Salesforce.com. That's the first aspect.

The second aspect, is can you apply a portfolio model? Can you look at the aspects that are high value to you, the aspects which are business as usual, and , "Well, I can get not just basic cost improvement by moving my customer relationship to Salesforce, but can I still apply my own special sauce, even when I am using low-value cloud services?"

Simple example

This is just a really simple example. When WSO2 uses our CRM, which is a cloud-based provider, it's a Sugar On-Demand. We also have mashups, which we host in the cloud, that take those Sugar On-Demand systems and mash them up to provide extra value to us.

So, we're going beyond the basic commodity service and starting to get extra value. To me, that's one of the really cool things to think about in cloud. Not just thinking about private cloud, public cloud, and hybrid, but about, how can I mashup the internal secret sauce of my company, the stuff that gives me competitive advantage, with the low-cost commodity services on the web, and start to get more out of those?

Then, if you think about that in a fungible environment, where to move those pieces of code, how to host it, where to run it, then you start to get a dynamic IT organization that can drive business value for the company.

Gardner: Miko, I mentioned a little earlier the idea of a marketplace, where competition and freedom of movement and transparency would have a positive effect and allow the buyers of services to pick and choose freely. Therefore the onus goes to the provider to have the best service at the best price.

What I think Paul just described is an opportunity where processes are composed of services, some of which might be coming from a cloud of clouds, both on-premises and off. So, it seems as if an insidious movement toward inevitable cloud services involvement with your business processes is under way, but without necessarily recognizing that you might not be in a true marketplace.

To some extent, there already is a marketplace, but the marketplace radically lacks transparency and efficiency. It's a highly inefficient market.



Do you think that this is going to happen whether people plan for it or not, and should they therefore recognize that they need a marketplace now, rather than waiting for these services to be actually put well into use within their organizations?

Matsumura: It's always wonderful to get the clear thinking rationality that comes from analyzing things, like you guys. From my perspective, to some extent, there already is a marketplace -- but the marketplace radically lacks transparency and efficiency. It's a highly inefficient market.

The thing that's great is, if you look at rational optimization of strategic competitive advantage, then what Paul says is exactly the perfect mental model. "My company that makes parts for airplanes is not an expert in keeping PC servers cool and having a raised floor, security, biometric identification, and all kinds of hosting things." So, maybe they outsource that, because that's not any advantage to them.

That's perfectly logical behavior. I want to take this now to a slightly different level, which is, organizations have emergent behavior that's completely irrational. It's comical and in some ways very unfortunate to observe.

To create a little metaphor, in the history of large-scale enterprise computing, there has long been this tension between the business units and the IT department, which is more centralized. In a way, the tension Paul alluded to is this idea that the business department is actually the frustrated party, because they have developed the applications in a very short time. The lagging party is actually the IT department.

It's a bit like what happened to the actor Mel Gibson. He left his wife and his kids and went off with a mistress. In the metaphor, the seduction of the cloud, and how easy it is, is really a wonderful attraction for a man (or enterprise) who is ostensibly married to his own IT department. And, that IT department maybe is not so sexy as the cloud service.

Eventual disappointment

So, there is this unfortunate emergent property that the enterprise goes after something that, in the long run turns out to be very disappointing. But, by the time the disappointment sets in, the business executives that approved this entry point into the cloud are long gone. They've gotten promotions, because, their projects worked and they got their business results faster than they would have if they had actually done it the right way and actually gone through IT.

So, it puts central IT into a very uncomfortable position, where they have to provide services that are equal to or better than professionals like Amazon. At the same time, they also have to make sure that, in the long-term interest of the company, these services have the fungibility, protection, reliability, and cost control demanded by procurement.

The question becomes how do you keep your organization from being totally taken advantage of in this kind of situation, and how do you avoid the Mel Gibson-esque disappointment of whatever happened after you left your wife and went with your new sexy girlfriend?

Gardner: Are you sure you don’t want to bring up Tiger Woods at this point?

Matsumura: Another, perhaps more universally understood metaphor.

Gardner: I was thinking of multiple clouds in that case.

Well, we've certainly defined the problem. Now, what can we do about it? Clearly, if you have some good lawyers and some history of dealing with software licenses, you're going to be very careful about how you craft your SLAs.

What we are trying to do at WSO2 is exactly to solve that problem through a technical approach, and there are also business approaches that apply to it as well.



We would hope that your business units would do that as well as your IT department or within consultation with the IT department or at least the legal department. Clearly, one buttress or defense against lock-in and lack of a good relationship over time with your cloud provider would be the agreement, the legal bond.

Also, we mentioned standards. There need to be standards that people can point to and say, "You must adhere to this or I won't do business with you." They seem to be slow in coming.

Paul Fremantle, what else is left? Is there a technology perspective, a middleware perspective, or something that might borrow from the Java approach that could reduce the risk, but allow companies to also pursue cloud computing in an efficient market?

Fremantle: That’s a very nice lead in, Dana. What we are trying to do at WSO2 is exactly to solve that problem through a technical approach, and there are also business approaches that apply to it as well.

The technical approach is that we have a PaaS, and what’s unique about it is that it's offering standard enterprise development models that are truly independent of the underlying cloud infrastructure.

Infrastructure independent

What I mean is that there is this layer, which we call WSO2 Stratos, that can take web applications, web application archive (WAR) files, enterprise service bus (ESB) flows, business process automation (BPA) processes, and things like governance and identity management and do all of those in standard ways. It runs those in multi-tenant elastic cloud-like ways on top of infrastructures like Amazon, as well as private cloud installments like Ubuntu, Eucalyptus, and coming very soon, VMware.

Get the free
"Cloud Lock-In Prevention Checklist"
here.

What we're trying to do is to say that there is a set of open standards, both de facto and de jure standards, for building enterprise applications, and those can be built in such a way that they can be run on this platform -- in public cloud, private cloud, virtual private cloud, hybrid, and so forth.

What we're trying to do there is exactly what we've been talking about. There is a set of ways of building code that don’t tie you into a particular stack very tightly. They don’t tie you into a particular cloud deployment model very tightly, with the result that you really can take this environment, take your code, and deploy it in multiple different cloud situations and really start to build this fungibility. That’s the technical aspect.

Before I hand it back to you, I also want to talk about the business aspect, because technology doesn’t live on its own. One of the things that’s very important in cloud is how you license software like this. As an open source company, we naturally think that open source has a huge benefit here, because it's not just about saying you can run it any way. You need to then be able to take that and not be locked into it.

Our Stratos platform is completely open source under the Apache license, which means that you are free to deploy it on any platform, of any size, and you can choose whether or not to come to WSO2 for support.

We think we're the best people to support you, but we try and prove that every day by winning your business, not by tying you in through the lawyers and through legal and licensing approaches.



Of course, we think we're the best people to support you, but we try and prove that every day by winning your business, not by tying you in through the lawyers and through legal and licensing approaches.

Gardner: Miko, we seem to have quite a few technologies, open source, licenses, and standards in place for doing enterprise software. Can we overlay what is a longstanding approach to openness and interoperability in the traditional enterprise on to the cloud and, in a sense, virtualize the cloud services in such a way that we can still use the tools and middleware, so we don’t get locked in?

Matsumura: The great thing that Paul is articulating is essentially in regard to a sort of promise. What's exciting about the promise is that trust has some very interesting properties, which is that one of the things you need to do is to look at the will and the ability of the partner.

As a consumer of cloud, you need to be clear that the will of the partner is always essentially this concept of, "I am going to maximize my future revenue." It applies to all companies, and dare I say, WSO2 included.

WSO2, as a new entrant, as a disruptive entrant, and as a company that has built this incredible technology, is both from a technological perspective and contractual perspective, using open source and empowering the promise in a very manifest form by providing value-added services.

As Paul said, to prove to you each day that they are going to be the best support for your deployment, is almost like a laying down of arms. If the opponent is disarmed from the get-go, then their ability to stick you in the back, when you are not looking, is gone.

Thing that’s fascinating about it is that, when a vendor says "Believe me," you look to the fine print. The fine print in this case is the Apache license, which has incredible transparency.

Free to go

It becomes believable, as a function, being able to look all the way through the code, to be able to look all the way through the license, and to realize, all of a sudden, that you're free. If someone is not being satisfactory in how they're behaving in the relationship, you're free to go.

If you look at APIs, where there is something that isn’t that opaque or isn’t really given to you, then you realize that you are making a long-term commitment, akin to a marriage. That’s when you start to wonder if the other person is able to do you harm and whether that’s their intention in the long run.

Fremantle: This is really interesting. Let me tell you a slightly opaque story and I'll try and bring it back around to this.

The school I went to was run by monks, and one of these monks was 80 years old and had been in the monastery for 60 years or something. A reporter asked him, "Don’t you miss the freedom? Don’t you hate being locked-in to this monastery?" And the monk said something really interesting, "I choose every morning to remain here," he said.

Now, what’s WSO2's lock-in? What Miko has been trying to politely say is that every vendor, whether it’s WSO2 or not, wants to lock in their customers and get that continued revenue stream.

Our lock-in is that we believe that it's such an enticing, attractive idea, that it's going to keep our customers there for many years to come.



Our lock-in is that we have no lock-in. Our lock-in is that we believe that it's such an enticing, attractive idea, that it's going to keep our customers there for many years to come. We think that’s what entices customers to stay with us, and that’s a really exciting idea.

It's even more exciting in the cloud era. It was interesting in open source, and it was interesting with Java, but what we are seeing with cloud is the potential for lock-in has actually grown. The potential to get locked-in to your provider has gotten significantly higher, because you may be building applications and putting everything in the hands of a single provider; both software and hardware.

There are three layers of lock-in. You can get locked into the hardware. You can get locked into the virtualization. And, you can get locked into the platform. Our value proposition has become twice as valuable, because the lock-in potential has become twice as big.

Gardner: If you were to find a cloud provider that shared that long-term view, they don’t lock in, but their value proposition locks in, but for the right reasons, then the other cloud providers would be at a distinct disadvantage. So, do we have an opportunity now for a marketplace with an open middleware approach? And who are the cloud providers that should or perhaps will follow suit?

Fremantle: There is definitely an opportunity for an open market. I don’t want to go into naming names, but certainly you're bound to see in the cloud market a consolidation, because it is going to become price sensitive, and in price sensitive markets you typically see consolidation.

Two forms of consolidation

What I hope to see is two forms of consolidation. One is people buying up each other, which is the sort of old form. What would be really interesting, to circle back to what Miko said at the very beginning, is that it would be really nice to see consolidation in the form of cloud providers banding together to share the same models, the same platforms, the same interfaces, so that there really is fungibility across multiple providers, and that being the alternative to acquisition.

That would be very exciting, because we could see people banding together to provide a portable run time.

One of the really interesting things that you can get with fungibility is what we have in various markets, the idea of options, derivatives, and all of that. That would be cool. Imagine that you need to get your jobs done every Friday at lunchtime. And, Friday lunchtime is an expensive time to get your jobs done, because everybody needs compute time at Friday lunchtime.

In a truly fungible marketplace, you could buy options on having compute power on a Friday lunchtime at a certain price. If you don’t end up needing them, you could sell that at a higher price to someone else who does need it. Then, you start to get the real flexibility that markets provide in the computing industry. That would be pretty cool.

Gardner: So what about that Miko? If Paul’s vision holds out, at least a critical mass of cloud providers pull together and recognize they have a common destiny and that working together at a certain level will provide them a better future long-term, one that involves cloud fungibility.

People are branding electricity as wind power, renewable power, green power, and that has certain different economic dynamics. I think we will see similar things emerge in the cloud.



Then these options and derivative models, where you can basically eke out the most efficient way -- both from the supplier as well as the acquirer of the service, and incidentally probably reduce the carbon footprint across the board -- that would be a good outcome. Do you think that that’s pie in the sky? What needs to happen for that sort of vision to unfold?

Matsumura: What we're talking about is the inevitable market consequence of commoditization. So what Paul is speaking to is something a lot like the spot energy market, which already exists. You have direct conversion of one form of electricity, which is a sort of common denominator of power transport, into other forms of electricity. That’s a very interesting thing.

People are branding electricity as wind power, renewable power, green power, and that has certain different economic dynamics. I think we will see similar things emerge in the cloud.

The thing that really critical though is when this is going to happen. There is a very tired saying that those who do not understand history are doomed to repeat it. We could spend almost decades in the IT industry just repeating the things of the past by reestablishing these kind of dominant-vendor, lock-in models.

A lot of it depends on what I call the emergent intelligence of the consumer. The reason I call it emergent intelligence is that it isn’t individual behavior, but organizational behavior. People have this natural tendency to view a company as a human being, and they expect rational behavior from individuals.

Aggregate behavior

But, in the endgame, you start to look at the aggregate behaviors of these very large organizations, and the aggregate behaviors can be extremely foolish. Programs like this help educate the market and optimize the market in such ways that people can think about the future and can look out for their own organizations.

The thing that’s really funny is that people have historically been very bad at understanding exponential growth, exponential curves, exponential costs, and the kind of leverage that they provides to suppliers.

People need to get smart on this fungibility topic. I appreciate, Dana, that you're helping out with this. If we're smart, we're going to move to an open and transparent model. That’s going to create a big positive impact for the whole cloud ecosystem, including the suppliers.

Gardner: Paul Fremantle, Miko seems to think that this bright possible future could happen fast, or it could happen 30 years from now. How do we make sure it happens fast?

Isn’t there a built-in economic incentive? If there is a sufficient level of transparency, where the most efficient model becomes the most low-cost model, and therefore in a commoditized environment, it's where the most consumers go.

It's up to the consumers of cloud to really understand the scenarios and the long-term future of this marketplace, and that’s what's going to drive people to make the right decisions.



Is there something about WSO2’s approach and this notion of a shared destiny that almost guarantees it to be the lowest-cost provider? That is to say, wouldn't the commercial lock-in provider naturally have to be more expensive in this cloud environment?

Fremantle: There is that. One of the most important things, though, is what Miko just said about education. It's up to the consumers of cloud to really understand the scenarios and the long-term future of this marketplace, and that’s what's going to drive people to make the right decisions. Those right decisions are going to lead to a fungible commodity marketplace that’s really valuable and enhances our world, rather than dis-enhances it or makes it less good.

The challenge here is to make sure that people are making the right, educated decisions. From my perspective, obviously, I'd like people to try out WSO2 Stratos. But, at a higher level than that, I'd really like people to make informed decisions, when they choose a cloud solution or build their cloud strategy, that they specifically approach and attack the lock-in factor as one of their key decision points. To me, that is one of the key challenges. If people do that, then we're going to get a fair chance.

I don’t care if they find someone else or if they go with us. What I care most about is whether people are making the right decision on the right criteria. Putting lock-in into your criteria is a key measure of how quickly we're going to get into the right world, versus a situation where people end up where vendors and providers have too much leverage over customers.

Gardner: So, as you're doing that cost-benefit analysis and looking at these new models of cloud, you need to go beyond just the notion of doing away with CAPEX costs and move to OPEX cost. You need to think about what the long-term operating cost would be if there is a lock-in variable involved?

Fremantle: Not just the operating costs, but the flexibility, the freedom, and the ability to achieve your long-term objectives.

Gardner: Any last words on this notion of what to look for in terms of your cost-benefit analysis, Miko?

Worth exploring

Matsumura: Without being overly skewed in this discussion, WSO2 has provided a very interesting topic of conversation worth exploring. Smart organizations need to understand that it's not any individual's decision to just run off and do the cloud thing, but that it really has to combine enterprise architecture and ... cautionary procurement, in order to harness cloud and to keep the business units from running away in a way that is bad.

One of the culprits in this emergent behavior is the short lifespan of the CIO. The CIOs tend to job churn and they tend to be a little shortsighted about cutting costs. So, they get into an unholy alliance with business units that just want to slash and burn expenses for all existing IT. All of these unholy alliances create these negative choices.

In the long run, having a vendor agreement and relationship that forces them to be continuously pleasing to you and having agreements that you can walk away from at a moment's notice -- both technologically and from a business perspective -- is a completely new way of looking at this cloud market. WSO2 has a unique offering in this regard. So it’s certainly worth a look. That's my perspective.

Gardner: I'm afraid we'll have to leave it there. I want to thank you both very much. We've been discussing how enterprises and developers should be considering the concept of application fungibility, both in terms of technical enablers and standards, in order to best understand what their real potential cost over time would be for enjoying the best of cloud, but also looking out for the inevitable risks in a commercial environment, and avoiding potential lock-ins.

I want to thank our guests. We've been joined by Paul Fremantle, Chief Technology Officer and co-founder at WSO2. Thank you very much, Paul.

Fremantle: Thank you very much, Dana. It's been a fascinating discussion.

Gardner: And we've also been joined by Miko Matsumura, author of SOA Adoption for Dummies and an influential blogger and thought leader on cloud-computing topics. Thanks so much, Miko.

Matsumura: Great to be here. Thanks again for a great talk.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect Podcast. Thanks and come back next time.

Get the free
"Cloud Lock-In Prevention Checklist"
here.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Transcript of a sponsored podcast discussion on open markets for cloud computing services and the need for applications that can move from one platform to another with relative ease. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in: