 Welcome back to SiliconANGLE TV, live broadcasting from IBM Storage Edge 2012. I'm John MacArthur, President of Walden Technology Partners, and I'm here with David Fleuer, co-founder of Wikibon. We're on SiliconANGLE TV talking to today, right now with Jason McGee, IBM Distinguished Engineer and Chief Architect of WebSphere Cloud Computing. So welcome, thanks for joining us today. Yeah, thanks for having me. So you just came off the main tent presentation. Can you give us a quick synopsis of what you discussed there? Sure, sure. So I was talking about our Pure Systems family, a new set of integrated systems where we've tried to take infrastructure, compute storage and network and combine it with management and middleware to build integrated systems that are really easy for customers to use. David, you were at the launch of Pure Systems. What's your sort of assessment of IBM? I was at the launch and I was at the presentation. It was an excellent presentation. I particularly liked the time-lapse photography, collapsing four hours down to, what was it, 90 seconds? 90 seconds, yeah. That was a very effective way of doing it on that. So how long have you been, has this been in gestation, the Pure Systems? I thought it was a very, very broad announcement. So how long have you been working on this? Yeah, it is a broad announcement. I think many of the pieces have been in the works for three or four years on both the hardware side with a whole new set of hardware components that we've built and on the software side with some of the work we've been doing around cloud management, around this idea of patterns and pattern-based deployment, three or four years. The actual kind of Pure App system and Pure Flex system, final integration has been kind of the last year and a half or so, but a long investment over time to really get us to the point that we're at. So there's been a number of announcements by other vendors. There's the B-Block from VCE and there's Flexpods from NetApp and Cisco and there have been people in this market placed the ISV, not the ISV, it's the integrators have been putting together systems of their sort. So what is it in the marketplace that's been behind this investment in integrated systems in there? Yeah, I think there's a number of things that are kind of motivating people in this space. I mean, at the end of the day, IT is complicated. It's hard for people to put together. It takes them a long time. I mean, I always kind of use this analogy of IT today is like, you were gonna custom build a house with an architect, right? And you go hire an architect and you build some plans and then you hire a contractor and you custom build all the pieces. That's kind of how we run IT today, but that's great in the sense that you get exactly what you want, but it's time consuming and expensive and it takes a really long time for people to put all these pieces together. And I think this trend you're seeing around kind of converged or integrated systems has really a recognition that to get to the next level of efficiency and optimization and cost savings in IT is gonna require us to start breaking down the traditional silos and building systems that are integrated together from the beginning. You know, you see some of our competitors are going down that space and certainly with pure systems at both the kind of infrastructure levels and up at the kind of middleware and application levels we've tried to say, okay, well, how do we actually start to pull some of these pieces together and deliver you an integrated system? I mean, there's no way you could get a four hour setup like I showed in that video if your job was to put all the pieces together yourself. So what's the trade off between best of breed? You know, you have a lot of storage in IBM, you've got the V7000, you've got the XIV, you've got all these different storages. How do you trade off best of breed for a particular environment? They're all good products and they all have their spaces against simplicity. Well, and you're obviously spending more money if it doesn't fit exactly your requirements. So what's the trade off between those and how can you navigate that? So I think that's why when we talk about this we talk about a family of systems. And the reason that it's a family of systems is that different members of that family are optimized around different workloads and different scenarios. And so I think the way we balance that best of breed versus integration, attention that exists is by having a clear understanding of what kind of workload a given system is designed to run. So you look at your flex, which is designed to be integrated at the infrastructure level, but quite flexible frankly because you can run a whole variety of different workloads on it. You look at pure application and we said look, while you can run any kind of application on it you want we kind of optimized the design around web and database workloads. And we said okay, if I was running a mix of web and database what kind of compute and storage and network what I want to run that kind of workload well. So we're able to kind of make some good choices by having a clear understanding of what kind of workload the system is trying to run and therefore pick the appropriate configurations for that kind of work. So is the idea then to take maybe 80% of the workloads that are operating in an environment put them on highly optimized, easy to implement sort of solutions and then spend the other 20% on these highly customizable sorts of. Absolutely, absolutely. And I think you'll get a lot of our customers and what they really wind up doing is they come up with a process for deploying applications. They tend to design that process around their hardest, most complicated applications and then they apply that process to everything. And then they step back one day and go it's really expensive and time consuming for me to deploy new applications. And a system like a pure application system allows you exactly to do that kind of 80-20 and it says the bulk of your apps will run great with the decisions that we've made, with the pre-integrated patterns that we have. And you might then wind up with the top 10% that it's worth the effort to do a custom system design but you're only doing it now for that upper tier and not trying to do it for everything. So again, going back to the different philosophies and the business case for them. A single SKU, which is the system, FlexSystem, single SKU has a huge advantage in terms of simplicity or maintenance and things like that. And the more flexible apps then obviously are multiple SKUs. What's the trade-off, in terms of advising customers, how would you trade off those two? What's the savings that you might get of a single SKU versus the flexibility that you get with the other approaches? Yeah, I mean, again. From a line cost point of view. Yeah, I mean, I think if you look at what we've done with the single SKU, it's a very attractively priced set of capabilities. If you really look at the full stack of infrastructure plus management and middleware all combined together, it's certainly much more cost-effective than buying all the individual pieces. And that's just acquisition cost. If you try to then factor in the labor associated with putting all that together, there's no comparison. Give me a figure. I mean, I think order of magnitude, you're talking four to five X cheaper setup. Total system kind of complex that you're putting together. So over a three-year period, what percentage of the cost would that reflect? Yeah, I mean, we've done some interesting, it's hard to answer directly in the sense that, you know, we've done some interesting things. Like for example, with pure application, we've included Webster and DB2 middleware as part of the system itself. In a kind of unlimited use on the rack kind of model. So a little bit different than our traditional licensing model. Which allows a very different dynamic for the customer about how they deploy those types of applications. And they can have much more freedom. You know, there's a lot of customers who frankly spend a lot of time optimizing their environment around software license costs. And trying to, they change how they deploy applications, of course, to minimize software license costs. And you look at something like Pure App where a lot of that's included, then you kind of get this freedom to use the system much more deeply because you're not worrying about how do I optimize license costs for this set of middleware software that's included on the system. So changes that dynamic. I mean, you can look at the acquisition costs. You can look at labor. I think the labor savings are pretty significant. But you also look at these changing dynamics around how the software's licensed. And that really changes how people actually deploy when they use the system. Would that go as, would you go as far to say that you could make savings from Oracle with this type of approach? Because Oracle have a renegotiation every now and again, don't they? We certainly have customers who have been looking at these systems as a place to move workloads too that are Oracle-based customers today, partly driven out of licensing concerns that they have around Oracle. And we've done some things, like for example, the DB2 support within Pure Application System has an Oracle compatibility model which will allow you to take an Oracle database and move it onto DB2 on Pure App without changing anything about the application. You don't have to change the SQL. It's compatible with the existing Oracle PLSQL and application structures. And so you can kind of easily move the application onto Pure App, onto DB2. Changes your DBA's job a little bit, of course. Oracle DBA versus DB2 DBA is just a new title. But at the end of the day, the application is the hard part, right? And not having to change the application code. So are you saying that Oracle Database Administrator who's been trained up in Oracle Database would be able to then, after migration, continue to manage without additional training on a DB2? No, I'm not saying that. I think the DBA job is different. Although we've certainly done things within the patterns to simplify some of the administration around the database itself. But what I'm saying is that applications that a customer might have that are hosted on Oracle Database today could move onto a DB2 hosted database on Pure App without having to be rewritten or changed. And therefore you have compatibility in the application layer, making that more feasible. Clearly the DBA is going to have to learn some DB2 DBA skills. But the inhibitor a lot of times is really, it's easier to train some new DBAs than it is to rewrite 50 applications that are averaging Oracle Database. So that's a marvelous negotiation opportunity when the Oracle renegotiation is coming up. You have one of these around so that you could. Right, and then the flip side too. Just set one on the old procurement guy's desk, at least. Right. So, I mean the other thing that I think is interesting in that space as well is that these systems are open. So you also can run competitive software on the platform. So if you look at what we're doing versus some of the competitors in the Converged Space, especially Oracle themselves with their Exa Suite, they're very restrictive about kind of what you can run on those systems. And with Pure Systems, we've taken more of an attitude that said, these are open systems that you can run a variety of software on. We've built a bunch of optimized content around IBM middleware. We've worked with our partners to build optimized content around their applications. And we've provided the tools to enable customers to build their own custom content that's optimized to run on the system. And that could include running Oracle Database on there, or running, you know, open source, or running other competitive software on there. I did some work recently on looking at Exadata and the two things, first of all, comparing it with the best of breed storage. And there's a huge number, it really is not best of breed. And also comparing what it saves, obviously, which is goodness as a single skew. But what the added complexity it brings into the data center because now you've got a little island of computing, which is sitting there. So could you expand a bit more on how you avoid that here's an island of computing that needs to be done separately, and I need to get another island for development as well, and another island for another... You can really easily get into that silo mentality and really suffer because you don't have best of breed. Could you expand a bit on how you can fit in with a data center? Yeah, you're right, that's a real challenge I think with these integrated systems is that because you're kind of crossing roles and crossing silos and technology domains that you run a risk of building this nicely integrated system that is an island within the data center, and that doesn't work for customers. And so we've tried in peer systems to strike a little bit of a balance. So if you look at what we've done a lot of those systems, they have integrated monitoring, they have integrated problem determination and eventing, but they also have plug points where you can hook them into the external data center, plug into your external security infrastructure, plug into your data center level monitoring. And what we've done is say, okay, well if you're using some of our stuff, like you're using Tivoli monitoring for example, then we've made that as easy as we possibly can. Like turn on external monitoring, tell me the IP address of your monitoring server. If you're using some third party monitoring, then there's a little more steps involved of course to extend the system to know about that, but we've provided all those kind of plug points and tools that you need to extend the system to allow it to integrate in with the external data center. So it's just a constant battle really to kind of strike this balance between being deeply integrated within the system and then reaching out into the data center. If you'll get our patterns, for example, I showed this morning in my demo, I showed a couple of examples of patterns and the example I showed there was a kind of fully self-contained pattern, like everything ran on the rack. But you know, the patterns we have support the other model as well that says, well maybe a piece of the app is running on the rack and talking to existing stuff that you have in the data center. And you can model those things in the pattern as well. So you can say, maybe I have my web application running a web series talking to Oracle database that I already have sitting in the network somewhere. And I can build a pattern that says, deploy my app and here's the database that I want you to use. And with that knowledge, I can configure the firewalls and the network to talk to that guy and I can do all the client-side driver configuration and everything to allow you to talk to that database. So we've tried to recognize both sides, the connect to existing and the create new. Right. One of the things you talked about is sort of crossing lines within the IT department. So there may be silos for networking, silos for storage, silos for computing, silos for applications, and they have their separate budgets too. And so your approach requires to sort of some consolidation across those. And a reorganization as well. Yeah, you may have to reorganize some portion of it. Because you previously got your DBA as separate from your system separate from your storage and now you're integrating. And that may not. Is that a major friction? It is a friction, absolutely. It's also part of what we're trying to get changed with these systems. So it's like a necessary change. And the reality is I think most customers, organizations are organized around how technology was 10 years ago. Right. And so it's gonna have to evolve. The trick is how do we get you to evolve to a new model and allow you to do it incrementally in steps along the way. And so what we've tried to do in some of our peer systems is all those people have a role still. The network guy has a role and the OS level guy has a role and the virtualization guy still has a role. But the way they execute their role is different. So instead of passing a work item through a bunch of different teams to have them manually set up systems or configure the network or set up storage, they collaborate on the definition of a pattern. And that pattern captures all of that institutional knowledge, all of those standards and standard configurations in the pattern. So the network guy or the OS guy will come along and provide the base OS image. And the network guy will come along and validate the network configuration. And once they've defined the pattern and it kind of goes into the catalog and people can have self-service access to it with some assurance that when the thing deploys, it'll be set up in the right way. So. Of course, if you don't want to fight the organizational battles, you can always outsource your IT and your service providers are sure. And the service providers seem to be embracing this model because it's a more cost-effective way for them to deploy. Yeah, sure, through outsource, they have to maximize their profit margin, right? Right, and their budgets get quickly consolidated. So, Jason, I appreciate you joining us today. I'm glad to have you here, and we'll look forward to seeing more progress. Thank you. With Pure Systems, I'm John MacArthur, President of Walden Technology Partners here on SiliconANGLE.TV at IBM Storage Edge 2012. We'll be right back after a short break.