Cloud's Value Depends on 'Fungibility' of Applications and Data -- A True Marketplace for Enterprise Services
Cloud's Value Depends on 'Fungibility' of Applications and
Data -- A True Marketplace for Enterprise Services
Transcript of a sponsored podcast discussion on cloud computing 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:
To access and download the "Cloud Lock-In Prevention Checklist,"
Dana Gardner: Hi. This is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're
listening to BrieﬁngsDirect.
Today, we present a sponsored podcast discussion on openness and 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
For enterprises to determine the true value of cloud models and to ascertain if their cost and
productivity improvements will be sufﬁcient 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 efﬁciency and ensure freedom of
successful cloud computing, we're now joined by Paul Fremantle, Chief Technology Ofﬁcer and
Co-Founder at WSO2. Welcome back to BrieﬁngsDirect, 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
inﬂuential 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 a 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 ﬁrst, Miko.
What's the difference between the popular vision of cloud computing and what's really available
now? Is there much fungibility available?
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 beneﬁt
to the business.
The area where we are speciﬁcally 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 ﬂexibility 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
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
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 ﬁne. 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
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
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 speciﬁc 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 signiﬁcant amount of
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
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
uniﬁcation, 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 uniﬁed against the
Russians. Every major advance in technology seems to be associated with everybody getting
together in order to ﬁght 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
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 beneﬁt analysis to ask what makes sense to keep close to
their vest, 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 are 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 ﬁrst steps people go through as they start looking at cloud.
Two other interesting angles need to be looked at. The ﬁrst 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. That's the ﬁrst 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?"
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 towards inevitable cloud services involvement with your business
processes is underway, but without necessarily recognizing that you might not be in a
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 in 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 efﬁciency. It's a highly
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 ﬂoor, security, biometric
identiﬁcation, and all kinds of hosting things." So, maybe they outsource that, because that's not
any advantage to them.
To access and download the "Cloud Lock-In Prevention Checklist,"
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 central. 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 application 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 that metaphor, the seduction of the cloud and how easy it is is really a
wonderful attraction for a man who is ostensibly married to his own IT department. And, the IT
department maybe is not so sexy as the cloud service.
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 that is 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.
We've certainly deﬁned 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.
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?
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
What I mean is that there is this layer, which we call WSO2 Stratos, that can take web
applications, web application archive (WAR) ﬁles, enterprise service bus (ESB) ﬂows, 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.
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'e 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
beneﬁt 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.
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
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 ﬁne
print. The ﬁne 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 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
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 into this monastery?" And the monk said something really
interesting, "I choose every morning to remain here."
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
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 a 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 into your provider has gotten signiﬁcantly higher, because you may be
building applications and putting everything in the hands of a single provider; both software and
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 ﬁnd 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
Fremantle: There is deﬁnitely 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
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 ﬂexibility 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, that involves fungibility.
Then these options and derivative models, where you can basically eke out the most efﬁcient
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
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 sufﬁcient level of transparency, where the
most efﬁcient model becomes the most low-cost model, and therefore in a commoditized
environment, it's where the most consumers go.
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, would 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 disenhances 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 speciﬁcally 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 ﬁnd 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 beneﬁt 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 ﬂexibility, 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 beneﬁt
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 PIO. It also has to combine this feeling about 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
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, 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 Ofﬁcer 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, the author of "SOA Adoption for
Dummies," as well as an inﬂuential 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 BrieﬁngsDirect Podcast. Thanks for listening and come back next time.
To access and download the "Cloud Lock-In Prevention Checklist,"
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor:
Transcript of a sponsored podcast discussion on cloud computing 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:
• WSO2 Data Services Provide Catalyst for SOA and Set Stage for New Cloud-Based Data
• Open Source and Cloud: A Curse or Blessing During Recession? BrieﬁngsDirect
Analysts Weigh In
• BrieﬁngsDirect Analysts Discuss Software AG-IDS Scheer Acquisition and Prospects for
Google Chrome OS