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:
- Fault tolerance and cloud brokering
- Architecting for failure
- Making the cloud part of your enterprise architecture
- The shift from forecasting demand to forecasting usage costs
- Public versus private cloud
- Different models for multi-tenancy
Robert Duffner: Could you please take a minute to introduce yourself?
Jason Bloomberg: 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.
Robert: You recently wrote, “Without cloud brokering, managing a hybrid cloud may be more trouble than it’s worth.” Can you expand on that a little?
Jason: Interestingly 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 cloud.
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.
Jason: It’s 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.
Robert: That’s 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.
Robert: Indeed. 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 applications accordingly.
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 immediately?
Jason: Cloud 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 cloud.
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?
Jason: I’m 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.
Robert: Mark 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?
Jason: The 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 emerging technology.
Robert: Joe 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 technology.
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.
Jason: Amazon’s 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.
Robert: Gartner 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 layer.
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
hemselves 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 the market.
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 on?
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 provider option.
Robert: That’s great. Thanks for taking the time to share your perspectives.
Jason: Thank you; it’s been a pleasure.
Tweet