I guess I'm going to go ahead and start, it's 3.30 so we'll kick this off. This talk is Model View Web Sockets. My name is Garen, I live here in Austin. I am the organizer of a few groups here, meetups, and I'm going to apologize to you guys because I'm not feeling really well. So this talk is going to go one of two ways, either it's going to be really hilarious or I'm going to fall asleep halfway through. But hopefully the former. So due to me not feeling well, if you feel like you want to shout out questions in case I do fall asleep before the end, feel free to. So let's just jump right into it. So JavaScript is, historically it's been a pretty simple place. We were doing okay for a while without patterns, without frameworks, without any of the things that we usually see in computer science. And then its potential sort of got the better of it. So we noticed that we could be doing more with it and we started doing it all at once, which was kind of great, but it was also kind of confusing. So now we don't have the simplicity that we used to have, which is not a terrible thing because now we can do more. And thankfully we have patterns that help us combat the complexity that we've introduced. So that's kind of where we're at. And we've been doing a lot of single page applications. There's a lot of this stuff around now and there are some problems with them. There's some questions about them. And hopefully we're going to talk about how to combine patterns and help solve some of those problems. So today we have single page applications just everywhere. And we also see a lot of single page application like behavior in otherwise static pages. So for instance, if you have a third party tool, more and more there's a possibility that that's going to need its own sort of dependencies. It's going to need its own framework and all that stuff. And the systems of dependencies really have something in common with single page applications when you start building up stacks of modules or tools or pieces. You're getting close to something that looks like an application even though it may not have all the things you would expect to see in an application. And you have the same challenges. So these are pretty easy to set up, especially if you're using a framework. But what do you do with them then? How do you scale them? How do you modify them? That's probably the next question that we would want to look at with regard to where we are right now and where we want to be going. There's some tradeoffs like with everything. So obviously the time to render an application to begin with can be an issue. Depending on how heavy the application is and how much of it can live on the server and if your logic is shared or not, your templates are shared. For the same reason SEO can be a concern. And then of course if you have an application that's doing a lot of communication with the server or passing things back and forth frequently, you end up with a lot of HTTP requests which can be difficult to manage and figure out how to package up. So you have to create good packages that have the code that you need when you need it and don't, on the other hand, introduce a bunch of junk that you're going to be storing in memory on the client and not need. So some of the implementation issues that you might see would be creating the scaffolding for the application itself. You have to do a lot of setup with certain frameworks or just even without a framework for some of these things and that could be a concern depending on how quickly you want to get up and running and how certain you are that you're going to need all that. And when you want to redraw, when you want to touch the DOM, you want to be careful with that. And so although it might be easy with these tools and these frameworks that we have available to us to just redraw everything all the time, you obviously have to be smart about that.  And of course, again, the HTTP requests. So I wanted to look at a few approaches really quickly that people are taking just to single-page applications before we jump into combining all this stuff together. Twitter just, this is a recent blog post from Twitter. Did you guys see this blog post about flight? It kind of catches us up with where Twitter's stack is and I think flight is a pretty cool thing. I'm pretty excited about it, but that's not this talk. So basically what Twitter is doing is they have a lot of their HTML rendered on the server and then they're sending it down to the client to be used in a single-page application and they're controlling a lot of this stuff with flight on the desktop, I think, primarily. But they have essentially a very lightweight single-page application and the trade-offs they've made are interesting because they don't want to do a lot of client-side rendering so their application looks slightly different than what others might. Airbnb also had a blog post recently about their stack. Did you guys see this one? Yeah, I'm going to hope you did. So they're doing something kind of cool. They've got Backbone on both the client and server and people have been talking about this. I think SenseNode was released, but it's nice to see more and more people doing it and it's nice that they're doing it with Backbone, which is something that a lot of people are familiar with. So this is kind of cool. I'm also using CoffeeScript if you're a fan of that. Where's that CoffeeScript? There it is. And then Meteor is not actually an implementation, nor is there a blog post. Sorry, I know the blog posts are really exciting. But Meteor is an interesting approach to a full stack application, again, that is node-based and doesn't have as prescriptive architecture as perhaps Backbone, but does offer some sort of architecture. And unfortunately, I linked to the video, which doesn't really give us a lot to look at. So my apologies. But you have models like you would in MVC, but then you have messaging like you would in maybe an event-driven architecture. So speaking of event-driven architectures, let's talk about MVC and EDA and what's going on there. We'll start with the familiar one, or hopefully more familiar one. So the model view, whatever concept has been around since the late 1970s, it's very closely tied to object-oriented programming. It was first implemented in Smalltalk. And now we see this implemented in pretty much all of the popular frameworks that... We've seen historically that this has been implemented in more and more popular frameworks. Java.net, you name it, basically. There's probably an MVC implementation, and it may or may not be the default way to go about doing things even. And traditionally, of course, it was on the back end because we didn't do applications on the front end. So the model in the MVSTAR concept, you could think of it as an object. I like to think of it because it's basically just your data. You can think of it as a place to store data. And they tend to relate to each other like tables in a relational database as well. The view would be the presentational part of the application, OBS. It draws the interface for you and it can interpolate the data that you're sending down from your server. And optionally, it can also track your user interaction, but that depends on the variant of star that you're using. And we'll talk about the stars in more detail in just a sec. So in JavaScript, it looks a lot like traditional object-oriented programming. But once we get to the rapid development craze of whenever the heck it was, we see more and more people wanting to use a good framework with an understandable architecture to get up and running quickly and organize their code quickly. So where that leaves us today is that we have a bunch of options, which is cool. A lot of different variations on the MV family pattern. But we don't have a whole lot of options outside of that pattern or that family of patterns. So cue our introduction to EDA. These are slightly less formal than MVC.  But these suit highly interactive systems pretty well. If you have a lot of IO going on, then you have a lot of events. So why not make your application event-driven? And they're simple, fairly reactive, but you could certainly make them more complex and you could make them less reactive, like with web sockets. And we see this probably more in tools or pieces of applications than running applications themselves. But it's also something that I think we're considering more and more as our applications scale bigger and we pull more pieces into them. So the events and the objects. The objects tend to have less data persisted in this pattern. Again, they don't always have to if you're combining it with something else. But by default, you would assume that you don't have an object that models exactly what's in the database. More likely your objects or your models would be the state of your application or the state of some part of your application. The events themselves cover pretty much everything that you would do with an application. From the user's interaction with the view to the server's interaction with the state or whatever data you're tracking. And of course the messaging that the application does within itself. And this is all really decoupled or it can be really decoupled because you're just passing messages around. So you don't have to set up chains of functions that have to be called or anything like that. You can let all of the pieces of your application manage themselves as they see fit rather than having them be dependent upon each other. So in JavaScript, E is basically what we've been doing since the dawn of time. And that worked for a while until we started getting into actual architectures. So originally, of course, all JavaScript is triggered by client-side events. So everything starts with a client-side event even if it's JavaScript that gets run when the page loads, the page loading is an event. So everything starts with an event and that's evolved over time as far as how we handle it. So we move from the on-click within our tags to where we are now with smart ideas like event delegation and PubSub libraries. But we don't have a whole lot of frameworks that support this. We can manage our events, we can do event delegation, we can do PubSub, but we can't really tie any of that together into an application or a cohesive whole. So my opinion is that MVC and EDA need to get together and make it happen. There are a few differences in how these two patterns or architectures deal with, well, start with data. In MVC, you can expect everything to be in models and the models will be very nice and tidy and that's all they'll do. EDA, you might have models, you might have models that reflect your data, you might have models that reflect something else that are caches or whatever. In MVC, you can easily do crud and it might be difficult to do something besides crud, but it works very well with, again, that sort of database way of looking at the world. EDA, on the other hand, might work better for sort of ad hoc updates if you're not changing an object, if you don't want anything to do with the database or if you want to combine things. The views might be a little bit different as well. In MVC, of course, you have a view that corresponds to your model generally. In EDA, you wouldn't necessarily have that. You'd probably have some sort of composite, not that you can't make a composite out of the views that correspond to your models in MVC, but you'd have no reason not to combine them if you were modeling your view on a state rather than a model that is in turn modeled on something that's in the database. In MVC, your view is often responsible for its own interaction. In EDA, conversely, you'd probably want your interactions to be a first-class component because they are events, they're going to generate events, and so at least the view into those interactions is probably something you'd want available throughout your application and not confined to the view or some part of your application. Okay, so where the action happens, which is the fun part. In MVC, it's all pretty triad-specific, so things tend to happen within their model view controller segment. In EDAs, you wouldn't want them to be confined, but again, to a specific set of models of views and controllers, you'd want them to be available to everything because that's the idea, right? That anybody can subscribe to an event and anybody can do anything they want with it. In MVC, you don't have your objects influencing your controllers. It generally works the other way around. In EDA, your objects would be aware of the events and be able to listen to events much like a view would observe a change in a model. So let's talk in just a little bit more detail about the MV star in the, we're getting to the star part. So I want to kind of try to break down the differences, and this is all kind of up for a debate, so if you want to disagree with me, that's cool. MVC is these tight triads of model views controllers, and the view tends to, or the information in the view tends to bubble up through the controller. A lot of you presenter, you have a model and a view that are paired, and the presenter has the option of working between the two, and it should work between the two. They shouldn't talk to each other directly. You can also have a presenter that kind of floats, and you can do the same thing with a controller, but the sort of interesting differences that the view doesn't directly talk to the model. So a model view view model, you have a model and a view that are super tightly coupled via the view model, which does observer-ish kind of things, like listening for changes on the model and then updating. So the appeal of this, again, this showed up in JavaScript when object-oriented programming was super popular and we had all decided as a species that object-oriented programming was the only way we were ever going to program anything ever again. And it was useful because around the same time we were building web applications on really big teams, or even slightly big teams, and separation of concerns was becoming more and more of an issue. If you have a whole bunch of people, you want people to be able to work on different parts of your application without, you know, merge conflicts. And then shortly thereafter, we were in the age of REST, and REST got really popular, and we were like, oh, hey, if our client-side applications look like our server applications, it will be easy to map the client-side applications to the code that's on the server, and these objects and the data that we're passing back and forth will just fit in. And of course, the bottom line, as far as I'm concerned, of the appeal of MVC and its ilk is that we have awesome tools already, and awesome tools make people excited to use things. So what we're doing right now, we see a lot of lightweight MVC frameworks, or MVSTAR frameworks. The controllers might be in routers and views, or in controllers themselves. We also see really good presenter abstractions, where people have enabled us to do a little bit of magic, I guess, and then we see the real magic, which is automatic binding. We see a lot of frameworks that now will let you write HTML or templates that correspond directly to your model, and you really don't have to do a lot in the middle to make those things line up. So there's a wide variety of approaches that are readily available. The choices that we have to make in selecting one, of course, there's a few. Obviously, we don't need boilerplate, which is kind of cool. We don't have to write all these abstractions ourselves, which is great. But you might ask if you have a really small app, if you need all that stuff, if you need all the magic that you're not writing, and if you need all the setup that you will do for using a framework rather than just writing something bespoke or whatever. And on the other hand, if you have a really large app, like your framework might be good and it might be a good place to start, but it's probably not going to give you everything that you need to do in your application. You're going to need to pull in additional tools to make it function. Basically, your separation of concerns depends on how many concerns you have. So let's talk about what those stars actually mean. So let's start with a controller. This is a pretty straightforward controller. It has interface events, binding to app functions, managing model properties, and rendering and initialization. And this is just going to look at a bunch of to-do MVC code because it's fairly consistent in what it's doing. So we can see our interface events getting declared here. Oh, yeah. Sorry. Bigger. Okay. So this is the controller for... What is it? Spine. And we're wiring up our interface events. We've got a bunch of... We've got a bunch of functions that get added to the object itself. Got some initialization stuff. And it's pretty straightforward. Oh, everything gets bound to functions in the application and we directly control the model properties. So that's a controller. A presenter. This is kind of up for debate. You can fight me on this if you want to. A lot of people think of backbone as more MVP than MVC. So backbone makes an interesting example of a presenter, I think, because it's just doing these sort of events. It's going to do the interface events, the observer events, and then they're rendering an initialization without a direct connection to what's going on in the other layers. So if you've seen... If you've used backbone, this is all familiar. These are interface events. Here's our initialization. Again, rendering, blah, blah, blah, blah, blah. And it's almost the same stuff, but we're not doing a lot directly on the model, and we're not doing a lot directly on the view. We're simply... Oh, I'm sorry, we are doing a lot directly on the view. My bad. But we are kind of keeping the two away from each other. So the listen to here, these observers, is one of the most interesting parts, I think. And the new view model is again slightly different. We do our interface binding there, and then in a knockback in particular, we have some magic interface stuff that happens, which is kind of cool. And then observers. Because it's just a view model, it's not a controller, somebody else is going to handle rendering initialization. So where is this? I'll show you guys these magic functions here, which we don't ever actually declare in here. So these functions are coming from somewhere else, and we're just going to deal with the things that correspond to this particular view, which is to do again. I would recommend taking a look at those in more detail. I don't think we can cover each individually in, what, 20 minutes? So, but just to kind of give you an example of how these things are basically very similar, and the differences between them are subtle. So, now let's talk about what happens outside the client side. We need somebody to make our application worth having. So we always assume that the first renderer is going to come from the server, and that can be data, but it's probably HTML because you don't want to get the data and then have to render the whole page. Of course, the server is going to update your application, or your application is going to update the server, probably a little of both. You might also be storing things locally. So you have communication going in both directions. And this is easy to do when you're using things like CRUD, or a CRUD kind of model, or like a REST kind of model, things that are very compartmentalized and predictable and correspond easily to your properties, your models, whatever. And that stuff becomes highly automatable and fairly predictable. So it's easy to magic that stuff up. I think it's harder when you have to change multiple models, or if you have to do a lot of quick changes to the state, like one after another if you're trying to, if you have some sort of game or something like that, where you're making a lot of quick changes that need to be reflected and you're not sure that you want to push all those to the server. And uploading offline data could be tricky because you have a whole bunch of stuff that you want to upload at once. And again, not necessarily corresponding to a specific model. So that's where we get to WebSockets. If you're not familiar with WebSockets, WebSockets is its own protocol. It runs over TCP on port 80. The prefixes are WS and WSS, or WSS for secure. And it basically allows the server to push data down to the client. If you've done long pulling in the past, then this is essentially a replacement for that, a much better replacement and not a one-to-one replacement because, of course, long pulling is still a request response. And if you're completely, you've never seen WebSockets in action before, that we would look at this guy real fast if it loads. Have you guys seen this? Some of you have? Okay. So this is basically a gigantic Scrabble game. And it goes on forever over the whole world. And you can just keep adding things to it. I apologize if you see any bad words. It just occurred to me that this is the Internet. So yeah, we'll just shut that down. But the idea is that people are playing while you're playing. I should have stayed where I was so we could have seen if somebody was going to put something down. But yeah, so I don't think I can do that. I forget the rules also. But just something like this is a very extreme example, but it doesn't have to be a game, obviously. Talk a little bit more about it. So this is not Comet.  And what we do still, if we don't have WebSockets available in a browser, it's bi-directional. So either side can push or listen. And again, there's no request and no response. So you don't ask for something and then get it back. You get something without asking for it, whether you want it or not. And then it's your choice whether you want to observe that event and respond to it. It's got cross-origin support built in, which is kind of cool, but also means you have to be careful with it. And the API is just incredibly simple compared to XHR. This is a cakewalk. So it's available now in most of your desktop browsers. Firefox, Chrome, IE, Opera, and Safari. Mobile, not so much. I think it's available on iOS, not Android and not Opera Mini. So it'll work basically on your desktop, but you probably wouldn't want that much information coming down on a smaller device. Anyway, at least not over a great length of time. I don't know.  There's a lot of chat examples. Collaborative editing is my favorite. If you want to do any work with other people in your, like, in a distributed environment, you want to share those updates and you want to see them live, like you do in, like, Google Docs or whatever, but hopefully working better than Google Docs. Of course, games. Everybody loves games. And every single no-knock application that I've ever seen uses WebSockets in some way because, why wouldn't you? And I think that kind of underlines the appeal. It's much easier than AJAX. So let's talk about how we combine those two things to make our relationship with the server a little bit cozier. So if we wanted to take our controller's presenters, whatever, and put a little EDA stuff in there, we're already in pretty good shape. They're already full of events, right? There's a lot of, a lot, we looked at those, just those three really quick and obviously, again, those are very simple applications, simple to do application, but there's a bunch of events going on in there. And so if we have events, we're much closer to being event-driven, right? But we need to free those events from the triads that they're locked into before we can use them globally in the application. We want to be able to have the application subscribe to them and to have anything within the application, anywhere in the application, subscribe to them. And this is, it's trivial. You can use, you can use a small PubSub library. You can write the little thingy yourself. You can use jQuery, and probably if you're using a framework, it already comes with some sort of event system within it that you can easily tap into. And then you want to be able to pipe those events. So the user and server interaction are not, are not events that you're able to subscribe to, usually on a global level, so you have to pipe them into something else to decouple them from whatever segment of the application they showed up in. So if it's, you've got your to-do view and you get a click there, you don't want everything to have to listen to the button that got clicked. You want to be able to publish an event that everybody can see without having to know what the selector is for the button that you're expecting to click from. The nice thing about this is that once you're piping them, you can do all your validation and stuff. They're in the object that generated the event and then pass the global event on only after it's verified or do whatever other modifications you need to if you don't need to do validation. You can have as many subscribers as you want, so the whole application or pieces of the application from all over the place can listen for whatever you're publishing. So putting WebSockets together with this is just the same as putting, connecting it to the server events or the user events and they get chained the same way. And then your specific controllers again can subscribe to global events or vice versa. You can pass WebSockets events in specific controllers up to the global level. And you get the opportunity this way to cache and or bundle your updates. So let's say you're playing a giant game of risk similar to the giant game of Scrabble we just looked at and you don't want to publish the player's move until they've taken their whole turn. I haven't played a risk a lot, but I remember you have to do three different things before your turn is over with. So they need to get their stuff and then move their little guys and whatever else. And only then do you want to update the server and broadcast that event out to the other players. So you have the opportunity to do that, which is kind of nice if you're looking at events that come from different parts of the application in different models and different views. So let's talk about how we would actually implement this stuff. So DIYing this up yourself is really trivial. You just declare a socket. You give it a URL to listen to and a protocol. And then you can do one of two things. You can either send or receive. So you want to listen for an open connection before you try sending messages from the client. You can also listen for messages from the server immediately. Of course you can close the connection if you're not going to be talking to the server anymore. And it's, like I said, really simple API. So we've got some DOM element here that we're going to save. And then we've got this variable s here that's our WebSocket. And we're just passing it the URL and the protocol. And then the first thing we'll do is listen for the connection to be opened, which is on open. And then we can send back a message to the server saying that we're good. And then we can also listen for messages from the server. And notice that this doesn't care what kind of message is coming from the server. Whatever message it is, it's just going to push it into that DOM element. So the server side of this, you can also DIY that part up yourself. But you might not want to at that point. You're DIYing on the client. You're DIYing on the server. That's kind of a pain. And there are so many lovely utilities you can use. They also abstract out things like broadcasting to multiple subscribers. I wanted to show you guys this list very briefly, in case you're not a node person. So pretty much every backend that you might use under the sun has at least one implementation, if not many. Oh, you can't even see that. Sorry, you guys. Where are they? Here. Even Haskell.net. Yeah. So Socket.io is the one that I'm most familiar with and have used most often. Actually, probably the only one I've ever used. So this is exactly the same thing we just did in Socket.io. And all that's really changed is that, instead of declaring a new Web socket, we're just calling this connect function on I.O., which is a global object that we import when we import the Socket.io client-side library. The API is a little bit closer to node or now jQuery. So we use on. And then we, instead of having the name of the event appended to the word on, we just listen for on and then we give it a string that's the type of the event. So connect is a built-in one. So essentially the same as on open. However, the interesting thing is down here, we listen for on new message. So instead of just listening for a message from the server, we listen for a specific type of message. And then if we're expecting different kinds of messages from the server, we can put a whole bunch of these listeners in and we don't have to do any branching within our listener. Oh, and we use the emit function instead of send, also for sending stuff back to the server. We also use send. That's my bad. And of course the API goes on from there, but this is the simple version. So if we want to connect this up to what we've already got, there are a number of ways we can do that. You can add messaging, just sort of ad hoc anywhere you want in the presenter control or whatever. And if you want to just, if there are only certain parts of your application that you want to share, whether it be collaborative or just, you need the server to know right away when they happen, then you're set. Or if you're rolling your own framework, you're not using something, you can use WebSockets for syncing from the get-co, which might be kind of cool. If you are using a framework which is more likely, you can swap out any explicit sync calls within your code with a WebSockets connection with a socket of it. And that way you don't have to use whatever methodology they were, presumably Ajax, they were using to send your info back to the server. Most practically, you could try to find a WebSockets plug-in for your framework. So I wanted to show you guys this one real quickly. Backbone.io, which is, as you might suspect, works with Backbone and socket.io. This is the server implementation, so pretty simple. Basically, we're just... It's not much more complicated than setting up WebSockets, but the important thing to note is that here we've given a back-end called messages, or it's called messages, and this is the messages property. Then here in our index, we just connected up much like we would socket.io, and this is just a friend-in on socket.io, so it wraps up socket.io's stuff. And then down here, we set up this back-end, and that's it. Now, all your syncing happens via socket.io to the store that this thing contains. So you could, if you feel real comfortable with whatever framework it is you use, you could probably write something like this yourself, assuming it's not Backbone, but it's an easy replacement for whatever you're doing if you need to have that sort of instantaneous communication with the server. But I think more probably you're going to want ad hoc kind of stuff. So let's talk about using these WebSockets to actually control the application. I think one of the most interesting possibilities here is getting action based on messages you get from the server. So instead of waiting for the client to tell you what to do, wait for the server to tell you where to go next in the application. You can pipe those events the same way again. And you subscribe on the Models and Views, so you end up with something that's very similar to Model View Presenter, where you have this controller that's listening for WebSockets events, and then your Models and Views just take their own action, and your controller becomes sort of very consistent in what it's handling. So this is like super simple fake example, but here it is. So let's say you have some sort of event store somewhere. Oops. I don't know how I did that. You have an event store, and there's like some simple PubSub or something in there, and you're just going to connect up a socket, and then when you get a new object, you pipe that event, and you pipe the data that you got to a global object-added event. And then somewhere in a collection, you get an object-added event, cool, you add that to your collection, done. You have the same thing on your view. You get an object-added event, you have the container for that view, and you render that data into your container, and that's it. This, I think, is an interesting way to think about replacing all the stuff that you would have wired up in a controller, all the sort of back and forth. And having it directed by the server, which is not something we normally think about in client-side applications, but we talk about putting our templates on the server or our logic on the server, but not generally the control of the application itself. So it's an interesting thing that might suit your application. So there they are, together, MVC and EDA. Really, it's a tool to use within your pattern. It's not a replacement for your pattern. You can use it a little bit to just do ad hoc communication, or you can use a lot to do syncing and every other thing. And it's a piece of cake to add. And that's it. Questions? Thanks.


Good evening, everyone. On Merry Christmas, we are going to anticipate our service this evening by singing together our little medley of carols that are identified in your program. And so if you'll turn in your hymnals to number 226, join your voices with mine and song. Hymn 234, In the Jettle of the Moon. Once again, we gather in the last flight of deep December to turn our anxious jaded hearts toward jubilation. For decades, flames have flickered inside the windows of our meeting house on Christmas Eve, like small watch fires kindled to soothe the unsettled spirits of shepherds and wandering magi. With a rising sense of awe and expectancy, we, like our ancestors, have fled from our chores to a place of peace, hoping to be reminded of the power still latent in ancient mysteries and to feel kinship with all who have hoped and dreamed and prayed for mid-winter miracles, for new birth, new possibilities, new beginnings. Let minds and hearts now make room for wonder. I invite you to rise and body your in spirit for the lighting of our chalice. On this Christmas Eve, our words of affirmation are responsive. Would you please join your voices in reading the bold and italicized sections. In the winter season of the year, dark and chilly, let us come to Christmas here. Let us find in the shadowed corners of our souls the light of hope, a vision of the extraordinary in the ordinary. Let us find the child in each of us, the light of new life rekindled and resurrected. And now remain standing if you will now turn in your hymnals to number 57, O beautiful the March of Days. Can you be seated? I'm going to start off tonight with a question.  You want to raise your hands? Are there any three generation families here tonight? Anyone? Nice. Are there any four generation families here tonight? Anybody? No? Thanks for coming out. I'm going to have you participate in just a second. This week, all over the world, children have been asking their parents the age-old question. This is where you participate. If you can turn to your parents and in your most whiny voice, no matter how old you are, ask, when will it be Christmas? And why is it taking so long? I think I know the answer. It will finally be Christmas when every crib is a shrine. It will finally be Christmas when every child is received as though he or she were the Messiah. It will finally be Christmas when we learn to see that the holy, the sacred is not up there or out there, but in here, readily apparent in this ordinary world of sight and sound. It will finally be Christmas when we learn to value our differences rather than fear them. It will finally be Christmas when we recognize that the holiday is the anticipation, the foretaste of the peaceful kingdom for which our hearts long, and not just the vague remembrance of a particular birth that took place so long ago. It will finally be Christmas when the birthing of a new consciousness takes place in all of us, all year long. May we each do what we can to hasten that day along. Blessed be and amen. I now invite you into a moment of silence, and we will now sing, and I will invite you to stay seated, carol number 241. Long time ago, you were people. And almost none of the houses had a second story. So people who lived there had a much better view of the sky. They didn't have electric lights, so at night the stars seemed very bright against the dark sky. There were wise men, or magi, living in that time whose business was watching the sky for signs. People then believed that important events about to happen on earth were revealed, or announced, by the movement of heavenly objects. When the magi saw something strange or remarkable in the sky, they reported it to the people. And so it was that when God decided that a very special event was about to occur, he sent word throughout the heavens. A special star was needed, God said, to mark the birth of a child born with the light of love in his eyes and the knowledge of love in his heart. When the stars heard this, they became excited, and the bright stars began shining up their coats, each one sure of being picked. The twinkling stars danced ever so gracefully, each one sure of being selected. The huge red stars glowed and glowed, each one sure that he or she would be chosen. Up in the north of heaven, the pole star heard the call for a special star. He was bright and beautiful century, all spit and polish. The perfect star to serve as messenger. But I know my duty, he thought, and he did a smart about face standing firm in his sentry post, facing directly into the solar wind. A single tear ran down his face and froze there. Off in the corner of the heavens, a small dim star named Natalis sat with his friends, an asteroid, a burned-out comet, and a white dwarf. Tali, as his friends called Natalis, was the kind of star that you couldn't see by looking at him directly. But if you looked hard to the left or to the right, this faint light would appear, only to disappear the moment that you tried to look directly at Tali. Now, Tali's friends were a cheerless lot.  The comet was burned out and said to have a drinking problem.  Now, Tali's little corner of the sky was just the right place for them because Tali was a small dim star who didn't outshine his companions. And Tali was a very good singer. When the others first came to his place, Tali would sing sweetly for them. Lately, however, they had been all singing in four-part harmony, singing rather quietly, often a corner, entertaining themselves and bothering no one else. Back on Earth, the magic I noticed changes in the sky. The stars all seemed brighter, more twinkling, glowing with a deeper red. Some things up, they said to themselves. They started paying closer attention than usual to the sky, even going so far as to place Tali on their charts, which they had never done before. And when these four friends heard news of the big event of this child being born with the light of love in his eyes, Tali stopped singing for a moment and said, you know, if God is going to let the light of love shine in that child's eyes, that child's going to need some light. Now, if I took off my coat and gave it a good squeeze, we could get enough light to do the job. You'd lose all your light if you do that, cried the white dwarf, who knew how that felt. What need do I have for light, Tali replied? We can sing in the dark just as well. That's true, said the asteroid, who was very self-conscious about his face anyway. And the comet who had been quietly humming throughout this exchange said, I know how to fly through the universe. The asteroid said, you could store the light in the large crater on my back. I promise not to spill a drop. And the white dwarf who was beginning to get excited said, I could lead the way and probably tip our friend here to spill the light out just at the right moment. So Tali took off his coat, squeezed the light in the asteroid's back, and it got very dark. On Earth, one of the magi noted the sudden disappearance of this dim little star. He turned to his colleagues and said, it is beginning. So the four friends set out for Earth for the town of Bethlehem, which is the place that God had chosen for this very special birth. The white dwarf was leading the way. And the comet huffed and puffed because he was very much out of shape. And the asteroid, true to his nature, was silent and still. Tali was dark now and almost blind, following behind and singing. When God saw the four strange, dark friends laboring across the sky toward Bethlehem with their gift of light, he was exceedingly pleased. And as Tali and his friends marched on, a wonderful thing began to happen. As Tali passed the other stars, a little light from each one began to cling to his dark side. And soon he began to glow. The magi by this time had figured out the big event was about to occur. And they saw Tali begin to glow brighter and they saw the direction in which he was headed. We'd better get going, they said to themselves, and an important birth is due and a very special leader will be delivered somewhere in the West.  They didn't need to be wise men to know a big event was happening. Even the shepherds on the hills who had no education knew something was up. In fact, Tali was so bright, it was almost as light as day in the middle of the night. And that frightened the poor shepherds. Now as the child was born, the comet who was old and wise said, now and the dwarf shoved the asteroid with all of his might and slowly the asteroid turned on his side and all that beautiful light streamed down around the manger where Jesus led. And at that moment, the infant knew more about love than anyone ever had before. And yet he was only a few moments old. Well done cried the comet. Thank you replied the white dwarf. Isn't he beautiful side the asteroid who had forgotten all about his unattractive face. The night was magic. Love light was in everyone's eyes. The angel sang, Tali shone brightly. This is Christmas, Tali said. And we can all go home now. And so the four friends made their way back to their home. Tali giving up a little light to each star on the way. But when he got home, he wasn't dark. He still had enough light that the friends could see one another. They were all smiling. And if you are out on a hill late at night, away from all the lights of the city, you go out and you peer into the dark part of the sky, you might be able to see Tali. But don't look at him directly with your eyes or he's going to go away. You have to look with your heart and that's when you'll recognize him. And if you are very, very still, you just might be able to hear him sing. And now I invite you to sing. Carol number 259, we three kings. One of our two unusual Christmas legends is the doe and the child, which is an ancient Christian legend. It is said that in the weeks after the birth of Jesus, when Herod's men searched the land for newborn babes with orders to kill them all, the holy family fled from one village to the next. But they were so tired and their little donkey so near exhaustion that they finally had to stop at a cottage and knock on the door. Come in, come in, came the voice of a woman. My hands are deep in bread dough and I cannot open the door for you. Joseph tied the little donkey by the gate and followed Mary in. No sooner had they entered and settled by the fire as their good hostess had bid them, than there came a loud banging on the door. Open up, a horse voice called. Open up in the name of Herod the King.  But Mary took the babe from her breast and handed him into the woman's dough-covered hands. Here, you must hide him, quick, Mary said. Quickly the good woman dropped the child into the dough, folding him up as if he were filling. Now I'm just gonna take a moment, a personal moment here. Atticus and Tallulah up there, they were the ones, my kids, they were the ones handing out the candles. No putting the new baby into a, into any dough. No baking it as bread. Quickly the good woman dropped the child into the dough, folding him up as if he were filling. Then she went back to kneading and shaping the bread. The door was flung open and six strong soldiers stomped in. They looked at Joseph who had his arm around Mary. They looked at the woman who was kneading her bread. Where is the child one soldier demanded? We know one must be here, another said. But though they turned the entire house upside down and inside out, they could not find the babe. So at least, so at last they went on to the next house, grumbling and slamming the door behind. As soon as the soldiers were gone, Mary lifted the old Jesus from his doughy manger and noticed that a strange thing had happened. The bread rose higher and higher as light as any dough could be. And no matter how much of it the good housewife shaped into loaves and put into the oven to bake, there was always some left. Long after Mary and Joseph and the baby Jesus went on their way, this baker woman pulled pieces of dough for folks far and near. And to this very day, small portions of that dough are saved for the next rising. The second bread of unusual legend comes from Germany. So once upon a time in Germany, a long time ago, a gentle mother was busily cleaning the house for the most wonderful day of the year, the day on which the child Jesus was to come and to bring his gift on Christmas Eve. Not even a speck of dust was left. And even the spiders had been banished from their cozy corner in the ceiling. To avoid the housewives busy cleaning, they finally had fled to the farthest corner of the forgotten attic. Then it was Christmas Eve at last. The tree was decorated, the children delighted, but the poor spiders were frantic where they could not see the tree, not be present for the Christ child's visit. But the oldest and wisest spider suggested perhaps they could peep through the crack in the door and see him. So silently, they crept out of their attic, across the floor to wait in a crack at the threshold. Then the door opened, just a wee bit, and quickly the spiders sneaked into the room. The tree towered so high that they could not see the ornaments that had been hung near the top. In fact, their eyes were so small that they could only see one ornament at a time. What to do? They scurried up the trunk, out along each branch, filled with happy wonder at all that glittering beauty. But every place they went, they left this trail of dusty gray web. And when at last they had inspected every bit of the Christmas tree, it was shrouded in dusty gray spider's webs. Well, the Christ child smiled when he thought of all those happy spiders seeing his tree. But he thought how brokenhearted the mother would be when she sees this dusty tree. So he reached out his hand, touched the webs, blessed them, and immediately they all turned to shimmering silver and sparkling gold. And the tree glistened with even greater beauty than ever before. And that is why it is still the custom in Germany to have a spider among the decorations on the family Christmas tree. Was a chipmunk, and he lived in a burrow. Built beneath an old oak tree, it was as sound and safe as could be, and it gave him great peace of mind. The previous owner, however, had left it in a terrible mess. But Mr. McPhiz could see what might be done with a little hard work. Unfortunately, there was nothing that he enjoyed more than cleaning. So the job was a happy one. He was swept, he'd be scrubbed, repaired, and painted. And when everything was in good order, Mr. McPhiz was as pleased as punch. He took immense pride in his little home. So imagine his horror. When a pack rat family, the Griswolds moved into the hollow stump next door. Now Mr. Griswold wasn't a bad sort, he was just a little messy. He was a serious collector, forever finding treasures in other people's trash, which he dragged home and stockpiled, believing that someday they would come in handy. Sound familiar? Now Mr. McPhiz could barely stand to look at the growing pile of rubbish in his neighbor's yard. The situation went from bad to worse, and McPhiz's irritation turned to disgust, disgust turned to loathing as the clutter gradually accumulated. But it wasn't until December that his feelings about Mr. Griswold turned into genuine hatred. Like most fussy creatures, Mr. McPhiz had few friends. In fact, he didn't have any. And most of the time this didn't bother him because he was always so busy with his cleaning. But at Christmas time, he got a little sad. And every day McPhiz would sort through his mail, which consisted of advertising circulars and bills, and he wished someone, anyone, would send him even one little personal Christmas card. Now in the past, he'd been able to cope with this emptiness in his life, but then one horrible day in December, after another disappointing trip to the mailbox, he noticed several large square envelopes in Mr. Griswold's mailbox. Could it be? He examined the envelopes, and they were all addressed to the Griswold family. Surely they were Christmas cards. And then he realized that Mrs. Griswold was standing on her porch watching him. How embarrassing. Mr. McPhiz walked back to his house, feeling very guilty. However, this was one of only many bad days for Mr. McPhiz as he observed a steady flow of Christmas cards delivered to the Griswold household. Mr. McPhiz was never so relieved to see a holiday pass as this Christmas. But instead of forgetting about it, he worried about it all into the next year. And when Christmas approached again, he decided to play a nasty trick on the Griswold's. His plan was a simple one. In late November, Mr. McPhiz bought up all the Christmas cards that his limited savings would allow, and he addressed them all to himself. He mailed a few each day, increasing the volume as Christmas drew near. And then, knowing where the postman stopped for coffee every morning, he crept up to his letter bag and actually stole all of the Griswold's Christmas cards before he could deliver them. Mr. McPhiz then settled into what he thought was going to be a delightful daily routine of collecting his own Christmas cards, the one he had sent to himself, and watching with satisfaction as Mr. Griswold opened his empty mailbox every afternoon. That would serve him right for being such a slob. But to his surprise, Mr. McPhiz didn't feel all that good as he watched his neighbor walk sadly back to his front door empty-handed. He actually began to feel pity, was strangely moved one evening, and so he addressed a Christmas card not to himself, but to Mr. Griswold. A few days later, when he watched Mr. Griswold find and open his card, Mr. McPhiz caught a glimmer of what Christmas is really all about. He felt warm and good inside. But the best part was he had to come. For the very next day, he found a Christmas card in his mailbox that he had not addressed to himself. Not only did it wish him a very merry Christmas, but also a happy new year, and it invited him to Christmas dinner at the Griswold's, where he met Mrs. Griswold and the numerous Griswold children. When they drank eggnog, they ate chestnuts, and they sang Christmas carols before a roaring fire. Mr. McPhiz could not remember a time when he had enjoyed himself so much. Even so, throughout the evening, he wondered what he could possibly say to convince Mr. Griswold to clean up his yard. Oh, well, he thought. Maybe that conversation can wait until Easter. And now I would invite you to turn to our next carol, number 248. We believe in Christmas, the American tradition. A brief story composed by M. Scott Mamaday, a member of the Kiowa Indian tribe, former professor at Arizona State University. And he composed the following dialogue between two beings, Urset and Yahweh. Now, according to the Kiowa tribe, bear, or Urset, is the symbol of the wilderness. He represents the spirit of the unspoiled natural world. Yahweh is one of the names that's used for God in the Jewish scriptures. And so in this conversation, Urset and Yahweh are sitting across from each other in a table, eating berries, and drinking cups of cold, fresh water. And we're including this conversation in this evening's service because of the way that Native American storytellers present prayer, presenting it as a movement of the soul toward kindness and appreciation for the blessings of a peaceful life, quintessential Christmas themes. Urset, my old friend, I perceive you are restless that you wish to speak to me. Yes, great mystery, I have something in my mind. Oh, you needn't be shy, Urset. I think I already know what you wish to say that that's a talent of mine. But I would like you in your own voice to tell me what is on your mind. Praytell, what is it? Praytell, praytell indeed, great mystery. Praytell, I have been thinking of prayer. Prayer, yes. So, and what have you been thinking about, Urset? I have been thinking that I would like to pray, but I don't know how. Oh, that's nonsense. Of course you know how to pray. You knew that from the day you were born. I saw to that it's a thing that I give to all of my creatures. But truly, I don't know what prayer is. How can I know how to pray? Tell me please, what is a prayer? Well, it's talking to God, Urset. It's simply that. And it's the silence from which your words proceed. Am I praying now, great mystery? Even as we speak. Do you pray, may I ask? Devoutly, unceasingly. It's what I do. It's what I am. Would you be so kind as to pray for me, just now, for me? I pray that you are kept safe throughout this day, Urset. That you live as holy as you can. That you see things that you have not seen before. And that more of them are beautiful than not. More of them are delightful than not. I pray that you hold easily in your hands the balance of the earth and the sky. That you laugh, cry, know freedom and restraint. Some joy, some sorrow, pleasure and pain. Much life and just a little of death. I pray that you are grateful for the gift of your being. And I pray that you will celebrate your life in the proper way. With grace and humility, wonder and contentment in the strong, deep current of your spirit's voice. I pray that you are happily in love at the dawn. You are more deeply in love at the dusk. Amen. Amen. Early this morning, Urset, when you were walking along the creek, what was it I heard you say? This morning I said that the morning is crisp and bright. I expected that something would pierce the air momentarily, perhaps the shrill cry of a rabbit or a wren. The water of the creek runs southward through splinters of sunlight and patterns of shade. It runs without urgency as I walk. I hear among the stony churns of the creek words that I heard from an old man when I was young. Muy bonita día, what a beautiful day. Our laughter, his and mine, echoes on the cliffs close by. It is the first of all mornings and it is unspeakably old. Amen. You see, Urset, you do know how to pray. With that, it is time for the giving and the receiving of our offering. And on the back of your program, you will note that your gifts this evening will be given in their entirety to our eviction prevention program. So please be generous. Lovely are the stars of the wintery night, sprinkling the mantle of heaven with their lustrous and far shining light. And gorgeous is the moon that seems like a lovely maiden walking in the fields of sky, clothed with the raiment of wondrous golden light. Glorious is the sun with its great brightness circling the seasons, bringing the benediction of ever renewed life on the earth. Comforting are the hearth fires, the lamps and tapers that hallow our homes and make a reassuring glow within the surrounding shadows. And beyond all of these, we cherish the light that lights everyone who comes into the world. The imperishable flame of the human spirit touched into being by the eternal one.  Oh divine spark burning at the center of every human heart, the sacred flame discerned in every age by Persian and Jew, Hindu, Christian, by pagan, prophet, scientist and sage. Come then apostles, come fellow pilgrims. Come dreamers and singers and poets. Come builders, come healers. Come those of the soil and those who command the might of great machines. Come all and carry the sacred flame to light up the windows of the world. Now there is light, light where all was shadowed before. For a few moments may we dwell in the mystic fellowship of love, peace, hope and light as we sing together silent night. We will light the candles of this holiday season. Candles of joy despite all sadness. Candles of hope where despair keeps watch. Candles of courage for fears ever present. Candles of peace for tempest-tossed days. Candles of grace to ease heavy burdens. Candles of love to inspire all our living. Candles that will not burn, not just tonight, but all year long. Blessed be and please enjoy the postlude. And now it is time to extinguish your flame, but you may take this candle home from this place of sharing. And you might want to light it again tomorrow in the days ahead, taking a few moments on each occasion to think about the warmth, the love and the peace that you can share with others. And in so doing, cause your own inner light to burn even brighter. It all begins with one light, one child, one adult, with you and with me, bright blessings, Merry Christmas and good night.


Live from Vienna, Austria, it's the Cube, covering .next Europe 2016. Brought to you by Nutanix. Here's your hoes, Stu Miniman. Welcome back, happy to welcome to the program a first time guest on the program, you, Piscar, who is the CTO of OGD, your customer of Nutanix as well as basically your service provider. Thanks for joining me. Yeah, no problem. Happy to be here. You give us a little bit about your background, how long you've been with OGD, and what it tells about the company. Sure, so I've been with the company for about 12 years, so a pretty long time. I kind of grew up within the company, I started as a service desk employee, made my way all up to the level of the CTO, but I do have a very technical background, so I'm a VExpert, I'm a VCDX. I basically do a lot of the technical side of our business, and as a CTO I'm responsible for our technical services portfolio, so amongst other things we have an IS platform, which we run and operate for our customers, but I do all the technical services, and also the skillset required for our employees to be in those kinds of roles. So I'm transitioning our company from being a primarily operations-based company into a services-based company, which requires a whole different skillset. Yeah, and just organizationally, is there CIO also, or what's your relationship with the CIO then? So we kind of tackle the problem from two sides, right? So he does the business side of things, he does all the systems that we use to engage your clients, and I kind of do the fundamental technical decisions behind that, so we kind of work and tend them together to provide the services both to our own employees and to our customers, and my role's more of the public-facing, and he's more of the internal CIO. Okay, and how many locations, what countries are you in, data center footprint kind of thing? So we're a Dutch service provider, which means we operate in our country, we're not international, that might come in the future. We've got five offices, we're located in each city where there's a technical university, because that's where we get our employees from, so we hire students, and we basically give them a year to acclimatize to being a professional, and then we picked a really good ones, we'll give them an education, we'll make professionals out of them, which means we're a young company, so I'm 32, and I'm pretty much on the average. And you've been there 12 years, correct? Yeah. Yes, so I've been there, you know, way too long. Like I said, I grew up there, but I'm kind of like the average age for our company, and that kind of makes us unique in the enterprise world, because we do service, the bigger enterprises in the Netherlands, whilst we are a pretty young company ourselves, and it gives us a nice fit with a lot of customers that want flexibility, that want a provider that thinks with them instead of just offering standard services. Great, so do you do hosting, or what services do you offer, and what customers do you serve? Yeah, so we're an outsourcer, which means we're kind of broad in the services we offer, we go all the way from services-esque, skilled or unskilled into the IS realm, the data center realm, and kind of everything in between, so we do a lot of service management, system operations, that kind of thing. And our customers, you know, they used to be mainly either government or schools, or you know, somewhere in the public realm, but in the last couple of years, we've seen a pretty big uptake in the financial services industries, which is, you know, a good learning curve for us, and a great match for those types of customers because they want that flexibility. Great, things have changed a whole lot in the last 12 years.  So we basically decided for our IS platform, specifically a couple of years ago, we were, you know, deciding whether we're going to do IS or not, and we were kind of seeing how the maturity of the technical solutions were compared to what we thought was the right way to go. So we figured, well, we don't want to go with, you know, the older, either build it yourself, design it yourself kind of solutions, and we don't want to go with the older converged systems as well because one of the key principles behind everything we do is we want to automate it. We want to be able to make sure it's repeatable. So a converged solution or a build it yourself solution would require like a team of 20 people to manage and operate, right? So we thought, well, that's just too expensive. Customers don't want it. It'll create some kind of inflexibility our customers are not looking for. So we instead went the hyperconverged route, of course, with Nutanix in this case. And we also put on top NSX and VEM and Exegrid and a whole bunch of products that gave us a solution that's flexible, specifically in the sense that we have complete control of the platform and we hand that back to the customer. So customers are able to create their own networks, create their own firewall, create their own load balancer to walk into the data center with a physical server, put it in a rack somewhere, a color rack and attach it to that virtual environment. So we have customers running virtual machines on top of our environment, as well as physical machines in like the next rack over. And we integrate that with the WAN solution, as the WAN solution, to manage their connectivity as well. And that's the kind of flexibility that's just awesome. So you've got the broad spectrum of offering. Your customers, where are they on that spectrum? Are they more conservative? Are they starting to do a mix of everything? What's the option look like? So what we're seeing is a good question. So what we're seeing is we're primarily matching with customers that are starting their transformation into the digital world, right? So we have our banks, we have insurers that are starting off that transition into the digital transformation. And they're not entirely sure yet they want to hand over all of the control of their environment because they want to innovate fast. They want to make decisions, test it out, get it into production fast like an MVP style product. And that's what we're seeing, where our IS platform really helps because they're able to create projects themselves, spin up a couple of VMs, create the networks, create the connectivity needed for it, and just try out all these new types of innovative products themselves. So did you get to catch the opening keynote yesterday? I'm curious what you think of the positioning that they had is customers want that Amazon experience. So now they can buy it from Amazon or they can do it themselves. I would have to say you probably think that you do something similar, right? Oh yeah, so absolutely. So we're in the enterprise space, right? So Amazon is more suitable for like development shop, DevOps shops. And our IS platform is mainly aimed at the enterprise customer that still has VMs, that still has monolithic applications. So our goal is to kind of marry the two concepts, right? I have traditional applications whether they're monolithic or not, but also give them all the advantages of that one click, you know, the one click experience, the ability to do everything in that environment themselves. And we see that as a true differentiator between the two worlds. So here's a question I have for you, because I looked at what they said and I understand it and there's a great reason why customers do things. But the challenge in the enterprise today is if you look at utilization.  What's utilization in your environment? So we actually cap it at 80%. Okay, but what do you typically find?  So for us, as a service provider, we want to optimize that, right? So we're always looking to basically cram everything we have full of services. We want customers on there. That's just basic economics, right? On the other hand, we want to be flexible as a platform, as a service provider to onboard new customers. We kind of want to make the promise to a customer that they can start within a day. So we need that, you know, that headroom to be able to help the customer start quickly. On the other hand, we do see that, you know, it is never as much or as little as the customer is reflecting. So they'll start a project and they'll say, well, we're going to bring 10 terabytes of data to you. And it's going to be 20 or three. And there's really nothing in between. So it's hard to actually accommodate for that. But having a shared platform, having something that is so scalable really helps us to keep that cost and that risk down, basically. Yeah, absolutely, the premise I was trying to bounce off you is the enterprise, you know, even big enterprises, very few of them are going to be able to get to what a service provider can do, let alone one of the big public cloud environments. How do you guys position and compete against the likes of an Amazon, Google, you know, Microsoft even? Yeah. Yeah, so that's another good question. So what we do again is we focus on the enterprise features, right? So an enterprise cares about availability. They care about performance for specific applications. They care about security. They care about all those kinds of things. So what we did with our platform is basically differentiate solely on recoverability.  But if you look at the public mega clouds, their, you know, their story on availability and recoverability is completely different than what an enterprise customer is used to. So what we said is we're going to differentiate solely on SLA for the ITO and the RPO. So we go all the way up to one hour or back down to 24 hours. And that's basically the only differentiating feature we have in our platform. And we see customers really liking that concept because kind of they get all the benefits of the cloud. It's not their hardware anymore. It's not their data center. It is all full service, self-service. Although they do have those enterprise or enterprise-y features, right? How did Nutanix fit into the mix of what you do? So what we wanted is a platform that's scalable. So we don't want to buy a big, you know, big box that does everything for us. And then, you know, replace it. And I'm sorry, what does scalable mean to you? So scalable to us really is, so we do a lot of work in the public space. So we have a lot of public tenders. So it's pretty difficult for us to gauge how our pipeline's going to fill up. So one month we might get just one or two customers. The other month we'll get 10. And the size of those customers and the size of their workloads is going to vary a lot. Can you share how many nodes in Nutanix? What do you have multiple clusters? How do you manage that? So what we do have is two data centers fairly close to each other. One in Delft and one in Amsterdam, which is about 80 kilometers apart. And we do basically just trench clustering between them. So it's one big data center, at least from the customer perspective. We run about 85 nodes right now, and we're going to go up to 100 before the end of the year. And that's one single cluster spread between two sites, you're saying? Well, technically it's two clusters because Nutanix works that way. But from the customer perspective, it's all managed as one big resource pool. The customer can set policies on performance and availability and that kind of stuff. But that's basically it. Gotcha. And is that your infrastructure as a service is it built on top of Nutanix? Yeah. Is there anything that's in that piece that's not Nutanix? From a physical server perspective, no. So well, there's one exception. So we do offer a physical colo facility right next to our IS platform, which integrates with the NSX bits. So customers can bring their physical SQL server, their old backup repository, their connectivity, et cetera, et cetera. It's similar to like a direct connect that Amazon has, right? Absolutely, that's where we borrowed the concept. Yeah, absolutely. Amazon does the same thing, it's really good. How about your customers? Do you have customers that bring in or use Nutanix gear, or do you offer that to them or are they just still buying their own stacks? Well, we kind of want them to land on our IS platform, right? So as an outsourcer, we typically don't sell IS as a separate service, but we do it as part of a larger deal, as part of a larger contract, where we also do a service desk, also do system operations, also do all the ITEL processes. So we're not very active in the space of just reselling Nutanix hardware. It happens once or twice. But again, our customers are mainly looking to outsource to us, so they're fine with this concept.  How does Nutanix serve your needs for, do they do any special financial packages? Are they their services, spares, things like that? How's the experience for you? Yeah, so the experience is pretty easy for us. So what we do is we just send an email to one of our Nutanix reps saying how many nodes we need. And that's it. So they'll come in within a week or two, drop the node into our data center, and it takes care of itself, basically. And we're working into a system where we have a spare parts depot just outside of our data center, where we can physically take our own server from Nutanix and put them in our rack and just send an email, we took seven servers from you. So you're delivering to your customers something at a utility pricing model? Do you look for that as a customer too, or is that something that you need? Yeah, so we put everything we do into an OPEX model, so we lease everything. And it's just to be able to get new resources into that environment fairly quickly. So like I said, we do a lot of public tenders, and it's very erratic as to when a new customer wants to start when we win a deal. So we need that fast time to market for us to get those resources into our data center. So everything is in lease, we do everything from an OPEX perspective. Okay, Nutanix has been talking a lot about kind of their ecosystem, how they're growing. What do you like, and what things are you hoping to see expanded over time? So the biggest thing is going to be networking, right? So Nutanix is fairly strong in storage and compute, and they're just starting out in a networking field. So as a current NSX customer, it's pretty difficult for me to gauge where they're going. But I'm welcoming the competition in that perspective because NSX, although it is a great product, it's one of the few products in that space. So I'd like to see more competition to have VMware up their NSX game as well. So networking is one of the big ones. And then also the whole backup area, that's still in development. And that's something we're actively monitoring to see if we can optimize that experience for our own data centers. Okay, so you want to give you the final word, just kind of your take on the market, being service provider, Nutanix. So I'd say Nutanix is absolutely on the ride track, right? So they basically created a new market, created a new term. And what I think Nutanix is absolutely doing right is their focus on customer experience. And I'd just like to see more companies go that way to really put the customer first and innovate with customers instead of against customers or competing against each other. You, Piskar, really appreciate you joining CTO of OGD, service provider, talking about how many things are changing, making it easier for his customers as his infrastructure providers make it easier for him and his company to do more. We'll be back with more coverage here at the Nutanix.next conference 2016 in Vienna, Austria. You're watching theCUBE.


Live from Orlando, Florida, it's theCUBE. Covering Pentaho World 2017. Brought to you by Hitachi Ventura. Welcome back to theCUBE's live coverage of Pentaho World. Brought to you by Hitachi Ventura. I'm your host, Rebecca Knight, along with my co-host, Dave Vellante. We're joined by Brendan Aldrich. He is the Chief Data Officer at Ivy Tech, which is Indiana's community college system. Thanks so much for joining us, Brendan. Thank you very much. I appreciate it. And congratulations, because I know that you've just won the Pentaho Excellence Award for the Social Impact Category. At Ivy Tech, you are using the power of data to combat one of the toughest problems in education, higher education dropout rates. So tell us a little bit about what you're doing and how you're using data. Certainly. Well, Ivy Tech has been really one of the more innovative players in the higher education space when it comes to how we're utilizing data. Both from the work that the data engineering and our Chief Technology Officer has done, the work we're doing now from my area to make that data very useful and very usable for the organization. And we're tackling it on multiple fronts. We're using data in order to help more quickly identify students that have already completed the requirements to graduate or if they are close to or have already potentially completed the requirements to graduate on another major other than their declared major and starting those conversations with the students. And then what about the dropout too? So you're obviously also looking at students who are at risk. We've been engaged in a project called Project Early Success where we work in the first two weeks of a 16 week term to identify which students we believe are at risk for failure. And then we spend the next two weeks, weeks three and four of the term, coordinating hundreds of faculty, staff and administrators to reach out and try to talk to those students and see if we can move them back on track. The first term that we did that we saw a great success with. We by midterm were showing a 3.3 percentage point drop in our number of Ds and Fs being reported for an organization our size that meant over 3,000 students, more students who were passing their courses at midterm as compared to failing them compared to the year before. Scope of the organization, students size. Ivy Tech, we are Indiana Statewide Community college system, so we have 19 campuses, almost 9,000 employees and we educate around 160,000 students per year. Wow, so we're just getting back to that college dropout. So professors are putting in the data about who's going to class, who's not going to class, grades that they're getting and then that's all being fed in and you're finding out who the at-risk people are and it's really just reaching out to them and it's saying, hey, what's going on? Absolutely, and in fact, a lot of the work was done with our engineering team to actually identify data that related to the behaviors of the students. So it's not just their attendance, it's not just previous performance in similar classes but it's really finding those data elements that relate to behaviors of the students that we believe are going to put them on a less successful track. Brent, I wonder if we could talk about the role of the Chief Data Officer. When we talk to CDOs in for-profit organizations, they always say we start with an understanding of how data can help with our monetization strategies. Now, let's translate that for community college. Is that a reasonable starting point if I frame it as how data adds value to the organization? Is that where you started and take us through sort of the journey of your role? Absolutely, well, first of all, Chief Data Officers in higher education are still fairly rare. At the time that Ivy Tech hired me in December of 2015, I was only the ninth Chief Data Officer working at any college or university in the country and the first that had been appointed at a two-year college. So whereas a public institution like ours is not necessarily as driven by profitability, student success is something that's very high on our priority list and being sure that we were able to make data very available to everyone within the organization that was working with our students. So that they could use that data to more directly target the areas that they could help the student best. Now, there can be profitability components. As a public institution, we do receive funds from the state of performance funding for students who successfully graduate. In some ways, we've been able to use data to help our registrars identify those students more quickly, which certainly gives us a lot of opportunity not only to help the students on their own educational goals and careers, but to be able to increase the amount of performance funding that Ivy Tech receives from the state each year as well. So you've brought it to the other point, CDOs tell us is data access, making that data accessible. And then there's a trust component too. It's got to be reliable and it's hard with all this data and all this data growth. How are you addressing those challenges? One of the things that's really unique about how we're approaching data at Ivy Tech is this idea of a data democracy. It's more than self-service business intelligence or self-service analytics because instead of just providing access, we wanted to make sure that once our employees had access, that the data was intuitive, that it was relevant to their responsibilities, that it was interactive so that as their needs and challenges and questions evolve, they could continue to use data to answer those questions without having to go back to a central IT team or a central research team. So the data democracy is a really unique aspect of ours that was important to us. And I think at the moment we have about 4,000 of our employees trained and running on our platform today. So everybody wants to be data-driven these days. Your job is to actually affect that data-driven initiative. Culturally, people say they're data-driven, but they don't necessarily act that way. They still act on gut feel and this is the way we've always done it. How have you been able to affect the cultural transformation? Well it's important to remember that if you can make the right data available to the people who are ready to use it, that's a transformational opportunity. For us, before we began on this project, less than 2% of our employee base actually had the ability to create a report. Everyone else had to make requests, wait for data to be made available. It could take time and maybe that data wasn't available by the time they actually needed it. So if you think about that, moving from a place where less than 2% of our employees had access to data to a point where we're approaching 50% of our employees now having really good access to data, we didn't want just a few silver bullets. We feel that every one of our employees has the potential if they had the right data available to test their ideas with data and come up with brand new innovative ideas so we could have thousands of silver bullets coming to rise throughout our organization. So give us some examples. I mean we've talked a little bit about how the data is transforming the student experience and student success rates, but what are some of your grand ideas about how faculty and how employees can use data to test ideas and make their lives easier and make Ivy Tech more successful? Oh absolutely, well and even if you think about project early success and the idea that we were helping to identify students that we believe may be struggling behaviorally in being successful in their courses. Now if you can take that as an attribute and you can surface it through our system to the employees that are using it, which includes our faculty. Our faculty members now have the ability to see very quickly which of their students may be struggling and have the chance to intervene with those students as well on a regular basis. So it's not just one phone call in the beginning of the term, it's not just project early success but now what we're talking about as project student success. How do we continue to use that kind of information to engage the student over the entire course of the term to ensure that we're not just changing their trajectory a little bit in the beginning but that we're following that journey with them over the course of their educational goal. Can you talk about the regime in your organization, the reporting structure, to whom do you report? Is there a CIO? There is. What's the relationship there? There is a CIO who I report to, the chief technology officer and I both report to the CIO. And we had a recent change in our leadership within the organization as well. Back a year ago this last July, we have a new president of the statewide organization, Dr. Sue Ellsberman, who was formerly our Lieutenant Governor for the state of Indiana. So that's interesting that you report to the CIO. Most chief data officers, we find, I wonder if we could comment, don't report into the CIO, there's sort of a parallel organization for a variety of reasons. People generally believe that while it maybe one day was the CIO's job, it's sort of the CIO's job morphed into kind of keeping the lights on and the infrastructure going. But what do you see amongst your colleagues with that regard? You know what's important for me and I think if you look at every organization across the country, there's this data knowledge gap. This idea that you've got your IT and engineering staff that knows everything there is about how to build, support, augment and decommission these systems. But generally have not been as involved in what the data means inside those systems or what decisions are being made off that data. On the other half of that gap, you've got all of the rest of your organization, the people that are using data to know what it means and who are making decisions from it. But generally don't know enough about how to think about structuring that data so that they could get the engineering teams to build them new tools. This is really the place where a chief data officer in my mind comes to sit because my goal is to build those bridges between the organization so that we can help engineering learn more about what we're doing as an organization with data and then use that information to build tools that will drive the rest of the organization closer to those goals through data. Now you're not a bank so you got imagining a pretty small team. Maybe you could talk about that and how you manage with such a small team. You know, it's interesting, most organizations when you think about a build versus buy scenario, you think about, well, I don't have a lot of people, I don't have a lot of bandwidths, maybe we need to buy. Now, Ivy Tech went through that process and every one of the RFPs that came back were too expensive, we couldn't afford to do it. So as a team we had to sit down and think about how do we really rethink the way that we approach this in order to still accomplish what we need out of data and out of our data warehouse and analytic systems. Part of what I'll be speaking at the conference today is some of those entrenched data practices that we had to overcome or rethink and rewrite in order to get to where we are today. Well, Brendan, it's been so much fun having you on theCUBE, thanks so much. Well, thank you, I appreciate it. I'm Rebecca Knight for Dave Vellante, you are watching theCUBE, we will have more from Pentaho World in just a little bit.


We've heard zero timeout play callers getting in a rhythm. How often would you say have you experienced that this year? And what can you describe the feeling when you get into a rhythm? It's just been the same message all year, just week to week. Learn from different lessons as you go throughout. Try not to make the same mistake twice. And in a lot of that end game, you're seeing how the game's going and how you prepare going in the week. And then obviously you're always going to have to adapt. And that's every NFL game. And then it'll be the same thing Saturday night. And that's the challenge that I love about this job. It makes it fun. You're curious to see, I mean, that they have the reputation for taking away something from every offense they face. You're kind of curious to see what they're going to try and take away from you? Yeah, it's always a chess match. And that's the most NFL games it usually is. But these guys have been the standard for the last 20 years around the NFL. So you go on there Saturday night and understand that it's going to be a sparring match. And we've got to make sure that we're prepared at every play.  You feel like you're in good position for that? We just feel like week to week and we've tried to create the atmosphere here that no matter who's in there, I know that's an old coaching with cliche, but our numbers back it up. We've spread the ball around. We've got a lot of confidence in whoever lines up out there. And we'll be ready to roll. And we'll have to, if they show us something different, we'll adapt. And that's what you have to do week to week. So what's Corey Davis do so well as a blocker? And did he start that well coming out of college? Or has this been proven by leaps and bounds over the years? Like a lot of players. That's the thing that it's proud to get to coach these guys because they buy in. They all, AJ does it. Tajah, Khalif, Adam, all those guys have tried to. And like those, Corey's done a nice job. And he's tried to improve week to week. And he hasn't gotten down. And it's been fun to coach those guys. What are some of the successful ways whether it be yourself or seeing other coaches, Coach Dews, Coach Rable, be able to inspire and bring the best out of Derek Hamlin? I think there's a lot of factors into it. And it's been good. It's just like the question about Corey. Derek's the same way. As he's gotten every year, he's had the right mindset and work ethic to come out of here and try to improve. And he's really worked at it. And it's nice to see a guy that's worked that hard for him to have some success and really has the team and has the offense. Same with the line. And he's focused this year, Arthur, even though he's in a contract year. And you made it clear to start a camp that he wasn't looking at that. Have you seen that focus on the task at hand through the year? Well, I mean, that's his personal situation. And the way I always looked at it from coaches and players, you kind of treat almost every day and every year as a contract year for you. You never want to get comfortable in any situation or any job in this business. But I can't speak for how Derek felt about that. I just, the way he worked out here as a teammate, it's been fun to see. Did he look more like himself, you think, in the game on Sunday? And did you take some pride in having the NFL's leading rusher? Well, I think it's a credit to the players. They did a nice job all year and stuck with it. And it was good to see Derek do that. And it was really happy for the offense and the offense in line. And as part of that, the tight ends deserve some credit. And so the receivers, we preach all 11. They've run away from people as much as they've run over them. But you think in Henry, AJ, and Johnny, you've got a trio that's maybe as tough to tackle or guys are as unexcited to have to tackle over the course of a game as well? Those guys have done a nice job. And you've got a factor in Corey, too. Corey breaks tackles as well. And those guys have done a nice job in getting open. And they all block for each other. I mean, go back to AJ's touchdown on that first third down.  But that's what you want to see. Like, that excites me more than just to play AJ made, because those guys are committed to it. The easy thing to do is to act like I almost had them. And you see plenty of that around. But it's a credit to all those guys. Combo of size and speed there. You've got to affect your career. Those guys, it's been proven this year, they can create yards after contact. You factor into your game plan and all that we wear and tear that Derrick has on defenses as a game goes along? Well, as a game, and that's to me the running of football, especially late in the year. You hope that it has that effect. And you hope that you're not playing in certain situations. You want to be able to still dictate what you want to do, not become obvious. And it is nice to see, as a run game, you stay committed to it, and it just chips away at it. And Derrick's done a nice job with that, and so is the line. Do you have any more for a big guy like him that might be for a smaller man? You can certainly see it. I mean, the numbers are there. He's a big guy, and I like giving him the ball, especially late in the game. When you guys were two and four, and you made the switch to Ryan, has the evolution of the offense and his play been as bad as good as you could have possibly hoped at that moment? Well, like I said, I never looked at anything as catastrophic or got too high one way or the other, because you just kind of looked at it from week to week, and there was a lot of factors into it. And I know that was obviously a big decision, and Ryan's done a nice job. But it's a lot of the offense. The line settled in, the receivers, everybody got more comfortable with each other, and Ryan did a nice job of leading them. But you just kind of look at it week to week.  And it'll be, as we're working here to Saturday, the same thing, and that's just keep improving. Has he done anything in his play that's maybe, obviously, you hadn't coached him before, unlike a lot of these guys. Has he done anything in the 10 weeks that maybe surprised you a little bit in his play? I wouldn't say surprised me.  So he's done a nice job of taking what's been given to him, and his role has increased, and he really has done a nice job. But it hasn't surprised me, no. How do you like the poise that he's played with maybe in tough situations, and how you anticipate it maybe going into his first playoff? Again, it's hypothetical to get in somebody else's mind. I don't know. All I see is the way he works, the way he approaches it, and we've been consistent from week to week, and we'll continue to be consistent this week.


Hi, everyone. I'm Manu Dasari, Senior Project Manager and Agile Consultant with ThoughtWorks.  Now, let me ask you how many of you actually use agile practices today, along with artificial intelligence and automation? A show of hands. For those interested, you could also scan in the QR code on the screen. For putting in your inputs in a short survey as well. Now, based on what I have seen in the past, I would say not many. Now, this is sad, given that hyper automation is one of the latest trends from Gartner, which combines automation and intelligence. And I would define hyperagility as augmenting automation with artificial intelligence to the agile practices. How does this all work? Let us take a scenario. For example, Meet Pete, he's a product owner for a financial services business, and he would like to create a web platform solution for his customers. Now, he's never done user stories before, and he's new to the agile ways of working. Now, Pete takes a long time to brainstorm his user stories and to come up with the priorities for his backlog, as he doesn't have the right data insights to make the right decisions. Can we help Pete? Pete can use hyperagility in various examples. For example, in the first one, there can be intelligent user storyboards that help Pete to augment his everyday activities during the discovery and inception phases of the agile project lifecycle by giving helpful hints for the user stories, something like Google. Secondly, he could also have machine boards that help with the auto grooming of the product backlog with priority suggestions based on the data analytics that is integrated and delivered to the product backlog. Thirdly, he could also integrate his DevOps dashboards with the real-time mining of the customer data insights to identify the value delivered. Now, Pete benefits with hyperagility because he has improved productivity as is able to come up with a breadth of user stories prompted by the intelligent bots. He has better access to data and is able to prioritize the stories in his backlog based on the customer insights suggestions by the intelligent bots. And more importantly, his company has improved ROI with the optimized deployment of resources. It's no surprise that Pete benefits from hyperagility. In fact, nine out of the 10 AI leaders are advanced in data management and 74% of them who are planning to implement, these are having sophisticated data management systems plan in place to be done by 2023, according to a benchmarking study of over 1200 companies. Now, what's next? Does it mean humans will be replaced by robots? Not really. They will be augmented by robots for better productivity. So what tools can be tapped? You can refer to the ThoughtWorks Looking Glass, which provides a list of trends that you can watch out for and best practices to adopt. And what does it mean for my business? You can explore how artificial intelligence and automation may join your mainstream agile practices in the next five years. Now, this is a snippet of the ThoughtWorks Looking Glass that you can have a reference to. That's all for my talk today. If you have any inputs, please scan the QR code here and give your thoughts on hyperagility. Thank you.


Our force is over here in their own nations, and it's not until we get together here in Latvia that we start to build together. So today is really the culmination of three or four months of us bringing all the ten nations together, learning how to work together as a common voice of battle group. We do it at night. But when you're not having breakfast lunch and supper, where are you in there? Yes. We're reinforcing the art of different capabilities of the work in Latvia. The missile, yes, of the rail, they're going to do the maintenance. If they do it again, it would be fine. Okay. Can you take it out? Yes. Your positions? At 30 degrees. Of course. I'm ready. Okay.