Windows Azure SQL Database Marketplace
Jason Bloomberg is managing partner and senior analyst at the
enterprise architecture advisory firm ZapThink LLC. He is a thought leader in
the areas of enterprise architecture and service-oriented architecture, and he helps
organizations around the world better leverage their IT resources to meet
changing business needs.
He is a frequent speaker, prolific writer, and pundit. His
book, Service Orient or Be Doomed! How
Service Orientation Will Change Your Business (John Wiley & Sons, 2006,
coauthored with Ron Schmelzer), is widely recognized as the leading business
book on service orientation.
In this interview, we discuss:
Robert Duffner: Could
you please take a minute to introduce yourself?
I am managing partner with ZapThink. We are an industry advisory firm focused
on service-oriented architecture, enterprise architecture, and broadly
speaking, helping organizations be more agile. We take an architectural
approach to dealing with the issues large organizations face in leveraging
heterogeneous IT environments.
recently wrote, “Without
cloud brokering, managing a hybrid cloud may be more trouble than it’s worth.”
Can you expand on that a little?
enough, I wrote that article just a few days before the most recent Amazon
cloud issue, where several different parts of the Amazon cloud infrastructure
went down. A lot of companies were caught unaware by that and had cloud-based
applications that went down as a result, since they were under the common
perception that the cloud is inherently fault tolerant, so by extension, Amazon’s
infrastructure is inherently fault tolerant.
There are multiple availability zones. We are doing all this
great stuff in the cloud and it’s still going down. In fact, companies that
were betting on the Amazon cloud had actually violated one of the core
principles of compute systems, which is no less true of the cloud than anywhere
else: you need to avoid single points of failure.
By putting all of their eggs into a single cloud basket, those
companies actually made the Amazon cloud itself a single point of failure. That’s
where cloud brokering comes in. If you are using the public cloud, you need to
have multiple public cloud providers and broker across them. That requirement
obviously raises the bar in terms of how organizations can leverage the public
Robert: When all
this happened, the last thing we were going to do at Microsoft was engage in
any schadenfreude, and for us, it was an opportunity to bring the issue to our
customers and partners around their deployment strategy, and have conversations
about architecting for resiliency.
inevitable that outages are going to occur to everyone, and you are inevitably
going to get egg on your face when the problem hits you. There is nothing
perfect in the world of IT, and you can depend on the fact that problems are
going to develop where they are least expected, whoever you are.
exactly right. We have some customers who deploy to just one data center, and
we have other customers who deploy to multiple data centers. It seems that the Amazon
customers that only deployed to a single data center probably experienced the
most serious outage.
Jason: That’s the
single point of failure problem again.
You made another great post called “Failure
Is the Only Option,” where you talk about the importance of architecting
for failure. Can you expand a little bit on that?
Jason: That also
touches on this same topic of avoiding a single point of failure. You should expect
failure anywhere and everywhere in your overall IT environment, asking what
would happen if each piece failed: the database, the network, the processor,
the presentation tier, and so on.
For every single question, you should have a good answer,
and if anything fails, it shouldn’t cause everything to go down. The cloud
actually makes that precept even more important, because the cloud’s inherent
resilience leads cloud providers to use cheap hardware and cheap networks.
They use commodity equipment and rely upon dynamic cloud
provisioning and failover to deal with issues of failure. The customer has to
understand that the cloud is designed and expected to fail, and they need to build
You can’t put everything into a single cloud instance,
because the cloud provider doesn’t have any sort of magic, no-failure pixie
dust. These considerations often mean raising the bar, in terms of how you
architect your applications.
Robert: You deal
with a lot of enterprises. Where do you often find the low-hanging fruit, in
the sense of the things where cloud computing can make the most difference
computing is still relatively new, and most enterprise organizations are still
at the phase of dipping their toe in the water. There are a few early adopters
that are willing to place bigger bets on some of the more advanced capabilities,
but that’s the exception more than the rule.
Most enterprises are still at the level where they will do
some storage in the cloud or maybe some virtual machine instances, but they
haven’t yet gotten to the point of thinking about application modernization or
application consolidation leveraging the cloud.
That step requires much more of an enterprise-architected
perspective on how to leverage the cloud. Some organizations are working
through that now, and we are placing a great deal of focus there, helping
organizations understand how the cloud adds to their options.
It has to fit into their architecture, and the cloud is not some
sort of magic alternative to their data centers. The right approach is for them
to think of it as one of the different options they have.
Robert: I get to
do a lot of executive briefing presentations for customers from all over the
world, and it seems that most of the enterprise interest has been around
infrastructure-as-a-service versus platform-as-a-service. I think they are
looking for the low-hanging fruit, in terms of just taking existing apps and
having someone host them in the cloud.
Jason: That’s the
most straightforward aspect of cloud adoption, and it’s something of a “horseless
carriage” approach. Those organizations understand how to build an app and host
it internally, and this approach allows them to extend that understanding to an
external hosting model.
It does over-simplify the problem, and it carries some
missed opportunity. On one hand, you need to re-architect your apps to take
full advantage of the cloud. On the other hand, the cloud opens up new capabilities
that you didn’t have before. That’s where the big win is, as opposed to
something like just taking your existing ERP solution and sticking it in the
That’s not the right way to think about the problem. The way
to think about the problem is that the cloud is going to reinvent what it means
to have enterprise applications, but that’s going to take time. We are not
ready for that yet.
Robert: What do
you see as things that may never move to the cloud?
reluctant to use the word never, because when you start thinking about the
long-term prospects of a trend like this, what it means to do cloud computing
becomes broad and ubiquitous. The cloud is just going to come to mean dynamic
provisioning and virtualization deployed in an automated fashion.
We can do that internally or externally, leveraging
resources wherever they happen to be. In 5, 10, 15, or 20 years, we probably won’t
think of it as cloud anymore. It’s just going to be the way IT is done.
Therefore, it’s not really a question of whether something
is cloud or not. It’s really just a question of where you want your
virtualization. Where do you need dynamic provisioning? Where do you need your
levels of abstraction? How are those abstractions going to provide flexibility
to the users?
With that perspective in place, it becomes a continuum of
best practices, more than seeing cloud as a particular thing where some things
belong and some don’t.
Wilkinson is giving a talk at the Cloud Expo on “Overcoming the Final Barriers
to Widespread Enterprise Cloud Adoption,” where he says many organizations
view moving to the cloud as a leap of faith. Do you think organizations
typically worry about the right things?
companies that are placing big bets on the cloud are early adopters, and they have
a particular kind of psychology. They are willing to place the bet on something
that has risks, because they perceive that they can get a strategic advantage
by being first.
Those companies are willing to assume the risks of the cloud
in exchange for beating their competition to the cloud, and then taking that to
the customers before the other guy. Only certain companies have that psychology;
most companies are too risk-averse to do that.
A few are willing to place larger bets, and most understand
that there are risks from the fact that it’s still a new approach, with missing
pieces, a lack of standard support, and all the other issues you have with an
Weinman put up a recent
post on the Cloudonomics blog, where he offers some details around his “10
Laws of Cloudonomics.” One is the notion that on demand trumps forecasting. Do you have any thoughts around that?
Jason: I guess it
depends on what you mean by “forecasting.” In the context of a traditional way
of thinking where you have existing on-premises infrastructure, you know how
many servers you’re going to need in the future, because you’re going to track
your usage patterns and things like that.
The cloud frees you from matters such as having to forecast
how many servers you need to buy, but on the other hand, it opens up new kinds
of forecasting. We now need to forecast how we’re going to leverage the cloud
and take advantage of cloud-based capabilities as they mature.
That different type of forecasting is very hard to do this
early in the market, because there are too many unknowns. It’s easier to say, “Based
upon the usage trends, I’m going to need to buy 10 servers next month.” That
sort of forecasting is pretty straightforward.
Robert: More and
more, I’m starting to see a blurring between infrastructure and platform-as-a-service,
and even, to some level, software-as-a-service. A lot of what I call SaaS 2.0
vendors are fundamentally building platforms. Do you see infrastructure and
platform-as-a-service coming together?
Jason: I would
say, actually, that the distinctions among the three different deployment
models were a bit artificial to begin with. That model was based on some early
thinking about how these things would play out. Now we’re talking about how
infrastructure as a service grew out of virtual servers and things like that,
and we have this notion of platform as a service as well, sort of in between,
as an outgrowth of middleware markets.
As time goes on, it’s
really more of a continuum. How many capabilities do you put into your infrastructure
before you have platform-type capabilities? Likewise, some of the elements that
characterize platform as a service include application frameworks that you can
build applications with. How robust does an application framework have to be
before it’s software as a service?
Those answers don’t really matter, of course, because these
terms are just meant to help clarify. They’re arbitrary distinctions to help
conversations along, more than they are hard and fast distinctions in the
Robert: That’s a
good point. For example, with Beanstalk, Amazon is offering abstraction layers
on top of the simple ability to run a VM hosted on one of their servers.
an interesting case, because they’ll run anything up the flagpole they think is
cool, and Google does the same thing. If it takes off, great. If not, they’ll
do something different. That means that, just because they’re doing something
doesn’t mean it’ll become an established market, or even that it’s necessarily
a good idea. It just means it was something they could do and they thought it
was cool, so they figured they’d do it.
We’ll have to see how all this plays out. Over time, the
individual market categories will consolidate and become clearer, but for the
moment, it’s sort of all over the place. Of course, from the customer
perspective, that just makes things even more confusing.
just published a research note saying that three
quarters of respondents were pursuing a private cloud strategy and would
invest more in private cloud than public. I’ve also seen some good research
from James Staten of Forrester. One piece I specifically remember was called “You’re
Not Ready for a Private Cloud.”
I think that discussion centers around what it fundamentally
takes organizationally to deploy a private cloud. It’s one thing to virtualize
workloads and reduce the number of physical servers through consolidation, but
it’s a whole other thing to fundamentally deploy a private cloud and services
What advice do you have for organizations looking at a
private cloud strategy? And do you think this is really only for the IT shops that
have huge budgets, such as large multi-national banks?
Jason: I would offer
different advice for different customers, depending on what problems they want
to solve. Keep in mind, though, that there’s been a disproportionate emphasis
put on private cloud, and I see that as being a result of vendor spin.
From the vendor perspective, private cloud is a great way to
sell more gear, so the big middleware and hardware vendors are pushing private
cloud on the one hand because it sells more gear. On the other hand,
particularly in IBM’s case, they see themselves as providing the gear to the
service provider market.
They’re looking to the telcos who have been IBM customers to
provide cloud capabilities to their customers. And of course, who are the
telcos going to buy the underlying gear from other than IBM?
So there’s this emphasis on that because the vendors want
you to do that. In reality, in many cases, there’s a better value proposition available
from public cloud for enterprises, as they get a handle on what that means.
After all, public cloud gives you a lot of the cost
advantages, the shift to operational expense, and some of the dynamic
provisioning capabilities. One of the challenges of the private cloud is the need
to support the ability to handle spikes in traffic, just as with your own data
centers since day one.
With the public cloud, there are multiple customers, and
hopefully everybody has spikes in traffic at different times. That’s the bet,
anyway, and if it comes true, everyone benefits from much better utilization of
the servers. The private cloud doesn’t provide that advantage, so in many ways,
cloud value propositions are watered down in the private cloud.
Vendors are giving a lot of play to security and governance
issues with the public cloud. Some of that is true, but you also have those
issues in the private cloud as well. So some of it is vendor “fud”—fear,
uncertainty, and doubt—and some of it is just a reflection of the immaturity of
It is important for cloud consumers to consider the role of vendor
spin, as they are trying to push big enterprises to buy more gear. Many times,
the story they tell is, “You have a data center, but now you need to build another
one, which we’re going to call a private cloud. You need to buy all new racks,
blades, and software.”
Some telcos want to build a private cloud to offer cloud
capabilities to customers, and essentially, they’re building a managed service
provider infrastructure. Conversely, some large enterprises think of a private
cloud as their own internal service provider that will provide cloud
capabilities to multiple divisions across a large enterprise.
There are still value propositions for companies in the
public cloud, and over time, they’ll figure it all out. They’ll say public
clouds are good for this and private clouds are good for that, with best
practices that help define the pros and cons of each. For the moment, though,
there’s an excessive emphasis on private cloud, in large part because the
vendors see more dollar signs there.
Robert: That’s the
end of my prepared questions. Is there anything else you’d like to address or expand
Jason: I recently
published an article called “Cloud Multi-Tenancy: More
Than Meets the Eye.” Multi-tenancy, as you know, is a key characteristic of
public clouds, but I have found that there are actually different kinds of
multi-tenancy at different levels.
First, there’s full multi-tenancy, or shared-schema multi
tenancy, which is the kind that Salesforce has, for example, where everybody is
essentially in the same application and the same tables. That model brings
certain advantages, such as being easy to manage and scale, but it’s a
one-size-fits-all kind of option.
There are other approaches as well. For example, there’s the
clustered, shared-schema approach, where there are clusters of customers on
different SaaS applications. Each of those can be configured to meet the needs
of particular customers, which provides a bit more flexibility, but it’s also
harder to manage.
Another model is what you might call isolated tenancy, where
a big vendor might move a legacy app into the cloud, with a different instance
for each customer. It’s not really multi-tenancy at all, at that level, but from
the customer perspective, it can look like multi-tenancy.
That could actually encompass a bit more vendor spin, where
every customer still gets their own application stack, but it’s now
theoretically in the cloud, although, in reality, it’s more of a hosted
great. Thanks for taking the time to share your perspectives.
Jason: Thank you;
it’s been a pleasure.