Alright, so I'm Gabbo and this is David and we're going to be talking about flux architecture and also we're going to be talking about some flux, which is basically an implementation that we wrote, a library that we wrote for using flux inside of AngularJS. Now we won't be getting too deep into the Angular part. This is more about how you can use the flux architecture in whatever language or whatever part of the stack you're in, actually. So with that said, what is flux and where does it come from? So basically flux is a pattern that Facebook came up with not too long ago, like I would say around the year, and that emerged from them using React. So React is a JavaScript library that is just a view layer and this library is basically very unidirectional, so everything that comes in, there's just one way data binding and when you're using this pattern or this library, like when they were creating Instagram, they saw this pattern emerge and they decided to formalize it and call it flux. And then the main thing about it is that it's a pattern not a framework, so you can use it anywhere, like I said earlier. And then the unidirectional part is the really, really important part about flux, like the name flux is Latin for flow, so it's all about having one direction and if you're doing two-way data binding and stuff like that, in a way that is mutating your models, you're doing it wrong. So that being said, this pattern is not completely new. It's basically variations on PubSub, Messaging, and CQRS, which I always get wrong, Command Query Responsibility Segregation. So this pattern, like when we used it for Angular, the way it came out was Angular 1.3 came out and I saw that we had some features that made directives, Angular directives, or you could call it views for those that don't know. So I saw that we could use it in a way that was very reactive, so it's all very component-based, there's no non-mutation from the top, so it just started, I started using it that way just to bring in the cool things about React that I liked into Angular. I wasn't trying to make Angular behave exactly like React, but I wanted to take the good parts and bring them into Angular. And then what happened was I started seeing that naturally this flux pattern started showing up in different scenarios. And I was telling David, oh, this is really cool, like I want to see if I can come up with some sort of bastardization of flux, and David was like, no, we should just go full flux and try to put in all the pieces and just make it like the formal pattern. And then after a million arguments and discussions, we came out with song flux, which is the library. So that said, I'm going to be showing you a lot of rectangles and arrows. I'll be going over mostly over the patterns and how does flux fit, like what are the squares that make up flux, and then I'll let David go into the nitty-gritty part. So actually, and a little precursor to your talk about MVC, usually we use, what? So if you look at the small talk version of MVC, it looks very one-directional. You have your model which populates your view, and then you have a user that creates a user interaction, and then that tells the controller to do something on the model, and then the model updates the view. So you have this, what you could almost say it's very, you know, it looks like what you'll see in flux later. And the problem is that that's what we do with small talk, or people do with small talk. I've never personally done it. But that's not what we do today. In contemporary MVC, we put it all in one flat line. And here in this slide, I kept the same arrows. So now I have those same arrows, they're going in one direction. So obviously my view can tell the controller to change the model, and then the controller can change the model, but my model can't tell the view what to show, or the controller can't tell the view what the model has. So what you usually do is you add that extra arrowhead on that line. This is, there's nothing wrong with this, by the way. I think this is pretty nice, it's elegant. The problem is that you do have to have some, you have to be strict about how you write your code, and constantly make sure that you're refactoring, because the moment you start adding complexity, it can get pretty gnarly. That's this next slide, where you can literally see wires being crossed. If I start adding more, you can see that there's a lot of different things going on, and it's a lot harder to tell what is coming from where, and what is doing what. For example here, I have the view in the middle. I have two controllers affecting that view. Now that might sound like, oh, that's not something you do in web development, that happens a lot. Like, I've done it, I'm not proud of it. I've done it, and the first thing I have to do is write it to do, and go back and change that, because if I leave it like that, it's going to make it a lot harder to add more features to the application. And then you have, in this little scenario, you have two controllers affecting one model, and the model affects two controllers. So the problem with that is, if the one controller does something, how do you need to make sure you have the mechanisms for that model to tell the other controller, hey, I updated myself. You need to have some sort of eventing, and you've got to wire it on a per instance basis, and that makes it really, really tough to scale up. So you definitely, with NBC, as good as it is, you definitely have to have that discipline on making sure everything is as many straight lines as possible. So if we go to Flux, how does all these rectangles and arrows change? Well, first I'm going to take away the complexity, because keep it simple, and then I'll bring it back and show you.  Now, a store is not a controller, even although sometimes I'll catch myself calling it a controller, but it's not. A store just stores your model, and then tells the view what information to display, and it has the ability to do operations on your model. That is all the store does. So that being said, now that we have that our store, it tells the view what to do, we take away the arrowhead, let me show it back, that arrowhead here, we take that away, because the store always tells the view what to do. The view never goes back to the store and says, hey, you need to do something. So since the store then also has the model, we take that away, and now we only have these two squares, or rectangles. And then so now that we have these two simple pieces with one direction, how does the view then go and tell the store that it needs to change? Well, it has to take what's called a round trip, and the first thing it does is creates an action. So the view then creates this action that says, this is what you need to do, like for example, if you have a user that you need to update the details, like you say, update users or user, and you give it the user details, and that's what the action contains, that's it. So now you have this action, you gotta send it somewhere. So you don't send it back to the store, because if you do, basically you're then making this two directional arrow again. That's not good. So you need to pass it somewhere to update the store. So what that happens, that happens through what's called a dispatcher. So the dispatcher takes actions and sends them off to all the stores. The dispatcher is pretty dumb, all it does is it takes this action and to any stores that are subscribed to it, it will then send off the action data. So obviously then the dispatcher tells the store, hey, your user details got updated, update yourself, it changes the data, and tells the view to update itself. So in a more concrete way to see this, oh, wrong slide, all right. So if I add complexity, well, I'll talk about the other part later. If I add complexity in this example, you see that it still goes in a circle. I can add more stores, I can add as many things as I want, and it'll still always be circles. And then the dispatcher, you usually have one. Facebook is pretty adamant about having one dispatcher per application. Us, when we did some flux, we were like, we'll give you the ability to create more than one, because why not? But we do try, you should try to only have one. This is your central, this is like your bottleneck, but it's not really a bottleneck, I don't know how to, so yeah, this is the other slide I wanted to get at, the flux to do. So how does a to-do work in flux? So if you have your to-do view, and you wanna create a new view, so how does that work? You first have your user interaction, which is user clicks, hey, give me a new to-do, and then that goes down to then create that action data, create that action with the data. So this create to do action is created with that to do information. So obviously this needs to be sent to the dispatcher, and the dispatcher receives it. So now the dispatcher has this create to do action. It says, okay, any stores that are subscribed to this type of action, I got a new one you need to update yourself. So the to-do store gets the create to do action, and it has, for example, the title or whatever. It adds the to-do to the to-do list array, for example. And then it says, hey, views, any views that are subscribed to me, you need to, I updated myself, so you need to get this data. So it emits that event, and then the to-do view gets that new to-do list, and then updates itself, and then you have in your list that new to-do. So that is the long way of how it goes. And if we were gonna look at it in a more like coding code way, this is almost Angular code, took a little bit of some shortcuts. So this is, if I'm gonna save a user in the more MVVM pattern, you get the details, and then you map that to your, let's say this user thing is what's called an Angular resource. So you just hit save, and it'll send it back to the server. So you need to map your details from your view back to this model, and then click save, and then send it off to the server and save. And that's pretty simple. And then how would you do that with Flux? You actually have less code, because all this logic would actually live in the store. You send off that action and not worry about it. The view just does what it needs to do. Just sends out that action, and then the store does what it needs to do, and then the view just updates itself. So the difference is if we start adding complexity. So let's say the user got updated from the server, not by user interaction, what do you do then? So now you have to map the details that you got into the model. And now you have, you can see there's some sort of code repetition to a certain degree, you have to map things back and forth, and it's a lot more work. Well, with Flux, what you do is nothing. Because the store took care of updating, it's giving you your view model. The store took care of everything. The view got created itself or re-rendered itself, so it got the data again on construction. And that's why it's like, the views are just that simple. Now, if you're looking at this example, you might be asking, and you know a little bit of Angular, you might be asking why didn't I use two-way data binding? And that is a good point to bring up. It does alleviate code repetition because now you have your two-way data binding. But the problem is, now if I have my view here and it's got two-way data binding, and now let's say this are my user details over here, and then I have a user list, and I start changing the user details here. The name in the list of the preview is gonna change, and you're getting that side effect with that two-way data binding. That's bad because you're sharing state, and that's always a very bad thing to have in your application. So you're gonna end up having that duplicate view model. So you make sure that things don't affect the other side of your app unless you hit that Save button. When you also have that mutation, you have what I call stealth bugs. So if this can affect the model and this can affect the model and these two views are live, you don't know where the bug is coming from. Whereas if you're using Flux, it's pretty simple. It's gonna be in one of three places. It's either gonna be the store, the actions, or your view. So if you look at your store, if the data is coming in correctly and it's coming out correctly, then you know it's not your actions and it's not your store. So then the data is correct, so it's just a display. So you just look at your view and maybe you have some view logic that's saying, hey, you find the bug in there. And that's what makes Flux so amazing because you can then find everything pretty easily. And you don't have to know the system. So if you're going into that shared mutation NBC state and you have a large scale system, you're gonna have to know all the moving parts to know where to look. Whereas with Flux, you just gotta know the pattern and you just know, okay, so these are my stores. This is where the data is coming in. Where is it being sent next? And it's gonna be one of the places of the views and then if not, it's gonna be one of my actions. It's that simple. Now with that being said, I'm not saying NBC is bad. It's just, there are different scenarios for different situations where you want to use these tools. And David's gonna get more into that, but this is something that's really good that you really want to have in your tool set. So, yeah. But David, take it over now. For the first half and all of our code examples, I only have my phone. I don't have fancy note cards, sorry. So I'm gonna have to be doing both to see what I'm doing next. And so, Gabbo just showed you kind of the 101. If you go to the Facebook Flux page, that's kind of what they'll go over. I just wanted to kind of take another chance to reiterate and ruminate on what some of these different pieces are meant to encapsulate and meant to do. A store, like Gabbo said, he motivated it by taking the model and the controller, the controller telling the view what to update, the model having this reference to all the data and knows how to save it. And kind of merging them into this one thing, which kind of makes sense. Kind of pull away the view update logic out of the controller and pull the model synchronization issues. Put them into one thing called a store that just understands how to deal with all of your data thing. And now you have a really great single source of truth. You have one place where you know that this is exactly what the user model is going to be. You don't care that there is possibly a disconnect between the input field on the view and the actual memory value that you have in the browser, versus what's being sent over the wire for your rest interface. You've got one source of truth that is the store and anything that the browser touches, it's going to go through the store and you know that, you've really focused that responsibility. And you have lost something though, you now can't have the controller updating the view. Well, you don't need the controller updating the view anymore because we have the store emitting mutation events. And suddenly we have this great little messaging system where any number of components can jump on, listen to events, any number of other stores. If they needed to, could jump on and listen to events. So you're building a chat application and you have various threads for your various chats. Your threads themselves will have a number of unread messages count. And when they increment or decrement, if my messages have been read, they'll emit an event, my little chat bar will see that and it'll change its value from ten unread messages to no unread messages. Congratulations, you've cut up on your inbox. And at the same time, the overall inbox store will also be listening to the same PubSub system. And now I can say, hey, you have one fewer thread that you need to pay attention to and it'll reduce your total unread thread count. So having these single sources of truth really simplifies. It kind of shifts that MVC triangle a little bit and really simplifies some of these pieces. Views, we also, again, we've shifted kind of the other. We've also shifted back a little bit. Instead of the view only being our display and our rendering itself, the Java days of swing tables or even our HTML DOM. This is going to be a little bit more intelligent now. It is going to be responsible for some of its own logic. Let's say you have a mildly complex wizard that walks people through a four or five step configuration. That's only one piece of data on the back end. That's only one piece of data in your store. But the actual state for moving between pieces, between your four fields of your wizard, your four wizard pages, is managed in the component itself because that really, the step that they're on in the wizard doesn't map one to one to the data model that you have. So by moving that back, your view gets a little bit more intelligent. We actually start calling it a component, not a view. On the other hand, that greater intelligence is much less repeated, much more focused, and much more single point of responsibility. Of course, you do need that last piece. Instead of our view model constantly updating or two way data binding, I type something into my input field that's immediately updated in my model. And as soon as I've stopped typing for two seconds, the model goes off and fires a rest save request. I don't get that anymore, so we need this way to get data back into our system. And we do it with another messaging channel, in this case, we call them actions. The view has finished whatever it wants to do. The user has indicated that something else is going to happen, save my new contacts, send my chat message. This action will get generated and sent into the dispatcher for the dispatcher to manage. And I like to view these actions, and I haven't really seen anyone else do this. So take this part with a grain of salt. But I like to view these actions as a user request for change. And as the user is encouraging your application to go to a different state. There might be a very valid reason to not allow that. The database connection might be out of date, or the thread might be out of date, and so all the people have left the chat room so it doesn't make sense to do this action. But most cases where normally you'd have this method called this action will be much more decoupled and much more flexible in sending itself through. We do want one last little piece, and this is in smaller letters because you don't manage this yourself. The dispatcher is this core kernel of an idea that manages this all together. It's really just a fancy pub sub bus. That's all it is. Facebook tries to make it more complicated in a lot of their documentation, but you just send something in with the string tag and it sends it out to whoever is listening on the string tag. A little bit of discussion as to whether you want one dispatcher per application. I prefer one dispatcher per unified module. This means that all of your chat widgets are going to be, if you think about Google Gmail, you've got all of your chat, or Facebook as well, you've got your chat functionality sidebar with your contacts list and the chats along the bottom, and then you've got the main inbox, your main wall feed along your back end. I would separate those into two modules. If for some reason you needed to send a message between them, usually you're going to be within your own ecosystem, but every now and then you can fire a message off to the other ecosystem saying, in inbox for example, open a new message composing field in the chat bar usually when you go to edit the more rich text editor. So that's kind of an interesting examination. One last little piece to point out here is that the dispatcher is a little bit smarter than a regular pub sub in that Facebook has a concept called waits for, which allows you to declare within your store asynchronous dependencies between receiving actions. So back to the earlier example we had where we had a thread store and an unread thread store where the unread thread store keeps track of how many unread threads we have. When you get a new message coming in, the unread thread store will say, before you let me take care of the new message, go ahead and pass it off to the actual thread store so that I can put it in the right place, update the right counters, and then I will take over. So that's a really interesting place that you can have a variation on a traditional pub sub that is very useful. And the dispatcher does also manage that only one dispatch is going to happen at a time, which means that you know that only one action will be processed at a time, which means that you won't ever end up changing an input field one place, watching the model change, that model fires an event, that triggers another update over here, and so then we have this mutation cascade where all of our models are listening to all of our other models, and everybody's trying to update all of the same model at the same time because they're all trying to keep track of the same things. We stop that, all of those pieces can fire their own actions, which will get triggered in their own dispatch cycles, but we're only ever going to have one thing happen at a time, and if we ever put a break point in there, we only get one unit of flow going through our application, makes debugging very, very easy when you get some pretty complex interactions going on. Song Flux is a library, like we said. It's specifically a southern, overgone, angular flux, we're very clever. It's an angular module, you can drop it in. It gives you the dispatcher, and we have some documentation on some little utilities, angular utilities that'll kind of flesh out that ecosystem, make that a little bit easier to work with. Catch up on my notes. Where are we at on my notes here? Do we have some of these? Oh, right, this is Song Flux. So the Song Flux dispatcher, again, it's the same thing that the Flux guys, that the Facebook guys have, you can get multiple dispatchers, you get your dispatchers lazily. If you're working with angular, this is kind of a really fun way to pull it on. Facebook does something where your actions are registered via a string. We don't like that, because you end up with some really ugly event handlers that have some weird switch statements in them. We've actually found that it works very well, where the action will be an action constructor, a function that you can instantiate with a JavaScript new keyword, and then you get this great instance of a constructor. You can use the constructor itself as your management, as your key in the PubSub. It works really well. It's a lot of fun. Oops, our stores. If you're familiar with angular, there is a way to create a controller on a module. Our stores work the same way, and they provide a little bit of utility. It's very, the store itself has a method to just quickly register based off of one of those action controllers that we described a minute ago. Not every dispatch needs to go through a store, but again, this just provides some one-liner utilities. This.register, action name, this.prototypeMethod.bind this. And you've got your handler just all nice and easily contained. And our code that we've used this way looks pretty nice, if I may say so. Actions, like I said, and action is just a constructor object. Usually, it is a simple wrapper around a plain JavaScript object. Function, newMessageAction takes a message object, this.message equals constructorMessage, and you dispatch that along. They also do have a little bit of benefit in that we can attach a dispatch method to them, which will provide a little bit of boiler, reduce a little bit of boilerplate in that you can just pass it right into your dispatcher without actually needing to go through and telling it which module it's dispatching to because it knows from the context of where it was created. Views that we do, again, are inspired by React. Angular has this concept of scope, which is a second prototype chain for your view layer, which lets you have a parent-child relationship between views. We issue that. It's very powerful to the point of being too powerful, where you can very easily make a brittle application. Instead, we make every component its own little self-contained thing. I'm passing in data, passing out data, passing in data via store observations and mutation events, passing out data by creating a new action. And we actually go so far as to use a component, define a new thing called a component. Again, for those of you who use Angular in-depth, this is a variation on a directive where we isolate our scope. We bind all of our scope properties to our controller directly. The controller itself is also a constructor function that can be instantiated. It has its prototype chain to create any methods that you want for any activity. This is the thing that is responsible for creating and dispatching events. The instance of the constructor within the component is exposed always as state. This is an idiom thing. It doesn't have to be state. We use state as an idiom. So whenever you're looking at a view template, if you see a binding to state.whatever, you know that's coming from the controller. Again, this lets you implicitly create a view variable that will let you, for the wizard page, maintain which page of the wizard you're on without having to go full bore into a constructor method or a full-on observation of a data model. Again, that's an idiom that we've found very useful, and you'll see more examples of that in some of our documentation online. And finally, you can just use either your inline template or a template URL if you're bindling. We've seen all this before. We really have. The Angular stuff is specific to Angular Shore, but this is just another way to do the small talk model view controller back when every arrow was one direction. Two-way data binding is really strong. It's really powerful. It's almost too powerful for what we're capable of handling on large teams where you start getting a lot of churn. A lot of people online will say, that's just CQRS, Command-Query Responsibility Segregation. Yeah, it is. It's just PubSub. It's just another way to do it. It's just another variation on this. Like I said, there are some nice idioms that we've found and enjoyed with the Angular side of things. The waits for is a nice idiom for enforcing asynchronous dependencies. A lot of ideas from reactive programming. Basically, no one has a direct reference to anybody else. You just say, inject the store that I want, and I will listen to whatever I got injected. If it's a test mock, if that's the actual instance. If the view is backed by a REST connection or a web socket, we don't care. That happens in one place. Everything else is events and PubSub, and we can just do what we want. So again, why do we choose this variation on MVC? It scales very nicely. It's very self-contained. It's a higher barrier to start building an app, but once you're used to the pattern, it's such a useful pattern that once you start seeing it, you can really easily jump in and be effective on using that pattern. Both of us have gone off and built apps for a week over here, a week over there, jumped onto the other person's code, and immediately seen where everything just falls into place, where everything is supposed to go. You're listening to events, which are by definition self-documenting if I describe which event I'm listening to. And it just focuses everything in these few one, two, three very focused places of your application. Why is my store sending bad data back to the database? Drop a debugger in the store. Click, click, click. That's where the data got wrong. That's the line that's wrong. Fixed it. Moving on. We're done. No weird dependencies between anything. There are still really good times to not use flux, and this is definitely something that we think is important. If you're not larger than four or five views and one or two models, you're not going to see any benefit of this.  So for a small application or for a small self-contained piece of code, probably don't use flux. Probably use MVVM or more traditional variations. On the one hand, it is, I think we have these. Yeah, it's pretty easy to add a new piece, but you have to add this piece in three places. So again, if you're not to the size where you need it, it might not necessarily be the best choice. It's a pattern. It's another tool. It works very well. We would implore you to go forth and think about maybe considering these ideas. Facebook wants them to be really hot. They're cool. They're great, but they're fine. These slides will be online. You can go on. Most of this, the precursor to this talk was a blog post that we wrote together. It's published on Medium. We have a sample app up on GitHub, and we'll add another couple of links to some other apps that we've built since we've written these slides to that. And is that the? Yeah. Finally, the library itself is on GitHub. And the easiest way is to MPM install SongFlux. The libraries themselves are in the disk folder. They're in the browser folder. So SongFlux, for those of you familiar with Node Modules, it'll be in NodeModules SongFlux slash browser slash songflux.js. So with that, thank you very much for your time. And does anybody have any questions? And does anybody have any questions?


Okay, we're back live inside theCUBE here at the IBM Edge 2012 live in Orlando, Barry Cohen, the CTO of the Edison Group. Welcome to theCUBE. Thank you. You guys are a research firm, do a lot of hands-on testing. Yes, you work with IBM, the big guys, HP, EMCO, and all the above. So tell us one, what have you been working on with IBM and share with us some of the recent work you just produced? Well, most recently this year, we've been working with V7000 Group on two aspects of the platform. The first part of the year, we've been looking at manageability of the platform and we've produced a white paper comparing the ease of management with V7000, with EMC and NetApp storage systems, showing the great ease of management, ease of use that the V7000 offers. And I know they were talking this morning about it in the presentation yesterday about the ease of use and the manageability is significantly superior to most of the storage platforms on the market, especially in this market space. How do you measure ease of use and manageability? A few years ago we created with one of the other vendors a way of counting and comparing complexity. Okay. And basically, when you perform a task on a computer, it's a series of things you do that you generally call steps, but the interfaces vary, some have wizards, some have a tree-shaped view, others have a command line or a menu-based view. But the task itself is do this, do this, do this, do this, so we've came up with a way of counting that with calibrating mouse clicks and things like that that seems to work for almost any context. We know that that's the case because we've done the same research for Oracle and IBM and HP showing for each of their products how they are manageable and it's a good tool that gives, I like to call it a pseudo-metric because it's still subjective, but it does give a way of comparing within its context that works. So when you think across all technologies and you look at usability index, who's the rock star? Other than Apple, you mean? Well, you can throw Apple in. I wanna know what you think. In enterprise computing, it depends on what we're talking about. On storage right now, it's IBM and followed by Sun with the Oracle, the ZFS platform, and I'm not familiar enough with a couple of the others that are emerging to give a good judgment on them as far as manageability is concerned. The database market, which is where we started with this, has changed so much that our original star is less of a star now and everybody's becoming more complicated rather than less, so I don't know where that's coming from. So you've got, is there technology areas that are going in the wrong direction from a use of use perspective? Yeah, I think databases have a problem in that they're being called upon to do so many different things that no matter what they do, they're not going to be easy to manage right now. The major relational database companies are trying to also be big data, how to put database systems and things like that, so they're trying to do too many things at once, so can't possibly make that easy to do in the short term. Okay, but some people are trying to turn what were discrete systems into appliances, a collection of systems into appliances, and certainly that's a big part of IBM's initiative here. What's your, and you contrast that against buying best of breed solutions, right? Well, let's look at the things here which is vSouth 7000 as its role within the pure systems environment, which is appliance might not quite be the word because it's awful big appliance, but it is by taking a series of good or even best-in-class components and abstracting their physicality, you enable rapid deployment, lower cost, and often better management. You lower the cost of the system in general and you simplify IBM's pure systems environment integration on some of the other unified systems. I don't know what this category of computing should be called. Work pretty well within themselves, but they don't play nice with others. Vblock, for example, is really, if you don't have Vblock, you can't use it. If Flexpod, you don't. HP is moving toward the pure systems model but is really not there yet. So if you look at an appliance that way, it's the right direction because once everything is working, your main concern is running the workloads that device is supposed to be using and therefore an appliance model gets that complexity out of the way. When you look at, so you figured out a metric for measuring ease of use, have you figured out a metric for measuring the ROI on ease of use? Well, our method, we do a cost of ownership. We look at it point of view of management cost. In other words, if you can save administrative time by 10%, 20%, 30% in some of our studies, these 7,000 is about 30%. 30% savings in terms of management? Over other systems. It doesn't, it means your storage administrators have more time to do the more complex, difficult things than they would otherwise. They're more efficient. They can manage more storage devices. One of the things this type of metric requires to some extent is a waiting factor. What do people do?  And so what we focus on is that combination. And if you can save 30% on the day-to-day, mundane maintenance test so that you can deploy more storage for VMware, or you can simplify in the pure systems model the deployment of workloads without even worrying whether it's on VMware or a Power VM or stored on this or stored on that, you've tremendously lowered the cost and you can get more efficiency out of your team. The, as you mentioned, VMware and virtualization, we just had John Twigel on recently just a little bit earlier and he was quite negative on virtualization in general unless it's mainframe virtualization, level of virtualization. What do you think is the state of the industry in terms of ease of use in terms of virtual VMware? Well, VMware does a very good job of simplifying the interface to the degree that it's influenced what IBM has done with Power VM. It's influenced what HP is doing with HPUX virtualization. It's influenced Microsoft and Hyper-V. Oh no, Hyper-V, yep. And dealing with managing ever more complex environments. When VMware was new some years ago, it was pretty simple. You had a server, you couldn't even cluster before you clustered it and you could do stuff, but now you have these complex, very large environments with thousands of virtual machines and it's more of a big deal and manageability is the big deal in virtualization. You look at it on the storage side. The storage appliances, the mid-range storage market, which is the prime storage environment for VMware and virtualized environments. Especially with unified storage, where you have block storage and file-based storage, which fits into how VMware works and even Power VM and the other types of virtualization. The model of managing the storage through the virtualized environment starts making sense. After all, if everything is virtualized, you don't care about hardware. What's a drive? It doesn't matter. What's a line? It doesn't matter. All that matters is the thing that that system is doing and all the, as an engineer, I do care about those things, but ultimately my job as an engineer, if I'm setting up a system for work, is that it does the job. If it doesn't do the job, I don't care how pretty it is, but if it does the job, the easier it is, the more work I get done in the day and the easier my life is. What do you think about the flash movement? Obviously, the theme here is flash everywhere. That's going to change some of your hands-on approach. Obviously, different configurations. Some on an extreme level will say the disruption is massive in the sense that it's a complete re-architecture change. Others are saying something different. Obviously, the elephant in the room has a different perspective depending on the view you look at. So what's your take on that? It's still pretty specialized. I know that we've been looking at some testing that shows that with, I can't really talk about that. It's not, we've been doing testing that shows that the new technologies that IBM is coming out with this week with flash storage has even better performance than could possibly be expected. So it's- We're hearing numbers from SAP and we're at Sapphire. And then, obviously, the suspects are Fusion and Violin. Two players have done these tests with SAP. Five minute page loads with apps of big data to five seconds. Five minutes to five seconds. That's massive. That's not like a little rounding error. It's pretty substantial. And that kind of testing is where the real value, I think, is going to come. That you can get ridiculously high IOPS from a database is nice, but it's really in this cloud app environment where response time to the application through a relatively slow network. Network, yeah. Is the critical factor. The performance on the back end of the storage starts helping because you've eliminated all the, the more of the bandwidth, restraints, performance restraints you've removed from the back. People understand that their 3G or 4G network connection is slower. So they're willing to cope with that a little bit. But still, for a while. Yeah, for another year or so. Do you see any on the technology side? Obviously, what are the top changes you're seeing? Because obviously in the marketplace, there's a lot of obvious advantages. The business models are somewhat changing. You know, storage is kind of wrapped in as an element of a bigger solution. But at the tech level, what are the top three things you're seeing? Well, first of all, because of one of the reasons I'm here today this week is talking about RTC, real-time compression from IBM, which actually works just like they say it does. We've done three or four sets of tests on it so far. And it works like they say it does and it makes the storage systems you're using more useful. We're talking about that VMware environment where you have to throw all sorts of workloads at a single storage system. Most organizations are not going to have 10 storage systems with different management setups for a VMware environment. They're going to sort of blend it all in together. And we've seen with the V7000 that you can save your capacity. You have huge capacity efficiencies because of the compression with no performance hit. That's a gigantic change. And something that people aren't really conscious of because compression on most mid-range storage arrays is not really very useful. I'll be talking about that tomorrow. I think you're absolutely right. I think compression is one of the areas that no one's talking about yet that's right around the corner because even in some of our research around the Hadoop community where huge batch is trying to meet more real-time and high availability, they're compressing everything. Facebook was telling me privately that they're running compression on all their bad stuff because of the network. The network problems are focusing on compression mindset because of the network level. Because you have to move less across the wire. Yeah. How do you think about compression versus deduplication? They're good buddies. They do slightly different things. Good buddies. Like brothers, cousins, like buddies. Cousins, they ain't enabled. No, they're very related. The underlying algorithms of compression and deduplication are very similar, pretty much the same in certain respects. The math is probably very similar. It's just how they work. Deduplication, you need lots of identical data to see an effect. Compression doesn't care about that. It just compresses. Matter of fact, in the research we've done with the RTC and data domain where you do deduplication of compressed data, you get even greater efficiencies and capacity utilization. That's a tremendous boon on that type of market. So do you dedupe and then you compress or you compress and then dedupe? Compress and then dedupe. Why? Mostly because of the architecture. The real-time compression appliance, the RTC-A, goes on the network between the servers and the data storage system. So that's why. And then there's the question that a lot of people don't talk about, which is encryption, right? So how do you apply encryption requirements to either deduplicated or compressed data? Can't do it right now. You just can't do it. Let's say in a practical general market, it can't be done because the algorithms that do compression and decompression have to be, and deduplication, have to be able to see into the files and by definition encryption is preventing you from seeing into the files. I would think there are certain organizations in the United States and elsewhere for whom building a system that could see inside that encryption might be possible. But our hosts here today and all the other folks who might build that will never talk about whether they actually have that. So we'll never know if that works. Okay. Barry Cohen, CTO of the Edison Group. Thanks for coming on theCUBE. We appreciate it. Great work, cutting-edge work. I love the angle on compression and the cousins or friends comment was good. Best friends. Best friends, good job. Thanks so much. And we'll be right back with the wrap up here on day two right after the short break. Great, thank you. Thank you.