 Cloud can be a dark and stormy place, offering little visibility into how your cloud is performing, how your cloud is managed, how your cloud is secured. The cloud can be a place where customers are forced to follow and not lead. A place where it's all or nothing, where the hows and whens are left to the wizard behind the curtain. But not all clouds were created equal. Clouds have taken on their own shape to serve a specific purpose. Some were built for the consumer market, others built for departmental use. The Enterprise IT cloud is different, built to deliver services, to be used by the entire enterprise, built to automate the mission critical, to operate around the clock and around the world, with more transparency, more flexibility, more control. The Enterprise IT cloud, a cloud where all applications are built on a single platform. Developers work together to deliver innovation at the speed of light. And application quality trumps everything else. The Enterprise IT cloud, a cloud where go live happens in weeks or months, not years. Prototypes quickly become production applications. Citizens are empowered to create new services on the fly, and users are delighted with the new service experience. Customers wave goodbye to the department of no, and celebrate the department of now. Implementation is a rallying point for transformation. Services are easily delivered to every department in the enterprise. Productivity soars, adoption skyrockets, and the entire enterprise becomes service oriented. The Enterprise IT cloud, a cloud where exceptional service is not optional. For instances are monitored and managed individually, security is constantly challenged and tested. And investing in customer compliance is a top priority. A cloud where redundancy exists at all levels, software, hardware, network, paired data centers. The Enterprise IT cloud, a cloud where high availability exists across the globe, powering the service oriented enterprise, in the new age of service. The Enterprise IT cloud, a cloud where exceptional service is not optional. Service now, senior vice president of engineering and cloud operations, Dan McGee. Lots of happy faces this morning, great to see you all. Welcome to the last day of knowledge, thrilled you're here. How about that party last night? How many went to the party? Wow, what an unbelievable venue, and you know the weather could not have been more spectacular. A great view of both bridges. Do everybody appreciate the extra hour of sleep we all got this morning? Yes. I know I did. So that video you just saw was actually shot at service now, not the cows, but all those people you saw. That's actually what it looks like for real back at home base where we reinvent all this stuff. And they actually do move that fast, right? We give a lot of caffeine to our engineers and that's how we get so much done. So this is the third installment of the trilogy of keynotes that you've been hearing this week. So on Tuesday morning, you heard Frank talk about extending the context for where service now is used throughout the enterprise. Then yesterday, Fred hit on continuing to really empower the application creators. It's really a big important focus for us to continue to do what Fred started with, which was make it really easy to create and deploy applications. What I'm going to talk to you about today is actually operating the cloud and specifically operating the service now cloud using service now. We're really in the unusual position of actually inventing the very thing that we use to run our own business. So we're hoping that we're going to show you some things that maybe you haven't seen before. Maybe a few things that will inspire you to try something that maybe you've always wanted to do, but you didn't realize you could do with the product. And also for maybe some of the folks out there will answer the question, you know, is service now is cloud really ready for our business? This is basically what we're going to go through today. We're going to talk a bit about some facts and figures about our size, our scale, where we're deployed, what we got going on. We're going to talk about security that's clearly on everybody's mind. Availability, I'm going to be a little bit controversial. So I think you'll enjoy that. And then we're going to wrap up the end of it with a really nice demo that also is going to be somewhat unique. And I think that'll be quite fun for you all to see. All right. I'm going to start here, though, if there's one thing everybody remembers from the chat today, it's this, not all clouds are created equal. What do I mean by that? Well, I sort of got on this slide three flavors of software as a service or clouds out there. And let me sort of compare and contrast them a little bit. We're going to start at the bottom with the consumer based clouds. So what's primarily on the mind of those folks that are really trying to address the consumer segment? What they're really trying to do is get more eyeballs to their property, their revenue is fundamentally driven on a revenue model. And so they're investing heavily in software features and other kinds of things that will drive and get more of us to try to go to their sites. After all, most all of us are actually using their properties for free. So what goes along with that is things like reliability and availability, not necessarily top of mind. They're not necessarily really bad at that. But their design point is not really at the enterprise level in terms of reliability and availability for their sites. Move it up a notch to the departmental clouds. Now these folks, many of them today are trying to extend their applicability into other parts of the enterprise. But they fundamentally started with a very narrow focus, Salesforce on sales, NetSuite on finance, so forth and so on. And as a result, if you look at things like maintenance windows, which we're going to talk about later, these folks actually take their systems down on a very periodic basis to go do maintenance. And that's an okay thing to do for the departmental clouds because on Saturday afternoons, the sales guys are playing golf anyway, right? They're not out there trying to book more deals. So that works for them. Again, it does not work for the enterprise. ServiceNow has a number of customers in the healthcare business where they actually use our product bedside with the patients. It's not going to work for us to take the system down on a weekly basis. I don't care what time of the week it is. So then you get into the enterprise. And this is where I sort of was making the point. The system has to be up. It has to be up basically like the power in the wall has to work. We can't afford to be taken the system down periodically to do maintenance or whatever. We have to find other ways to do things. The other thing that really differentiates us from some of the folks on the right side of that slide is, again, ServiceNow is really the only platform up there that has targeted people that don't necessarily have a software degree, right? Trying to make it easy for the common man to actually create applications and get them deployed. So let's get into some of the facts and figures here. We're going to start with what's sort of the extent to our infrastructure today. So we have grown quite rapidly. We have more than 800 engineers and technicians across our organization focused just on developing our product and operating our infrastructure. The data centers are largely on the West Coast. We have a big presence in Seattle, Washington, San Jose, California, down in Silicon Valley, and of course, San Diego, where it all got started. Then in Europe, we have a very big presence in both London and Amsterdam, so strong talent in both of those regions. But perhaps more interesting to you is where we have our data centers. And I'm going to show you a slide later on that contrasts us with some of the other folks out there. We have 16 data centers worldwide. These are actually paired data centers in eight regions. And, you know, why did we do that? We didn't necessarily want to create more work for ourselves. Well, it's data sovereignty. Again, the enterprise class customers want to put very sensitive data up in the cloud. And in many cases, that data needs to reside in the region where they exist. So we have paired data centers in Switzerland. We have paid data centers in Australia, obviously paired data centers in the US, and so forth and so on. We've made a tremendous investment to put our iron where customers want their data to reside to deal with the data sovereignty topic, which is even bigger right now, thanks to the Edward Snowden news. So, building out all that infrastructure, and I'm going to show you some statistics on availability later, getting better at availability doesn't come for free. Just in the last year or two, we've hired 250 people specific to the infrastructure side of our business, and we've spent more than $50 million in getting all this stuff together. Where are we in terms of user count? We're getting close to 12 million users. And some of you folks can do the quick math. Frank announced on Tuesday that we're about 2,100 and change customers, 12 million users. You can see the folks that are using us are really using us at a very large scale. This number's going to come up a little bit later in my presentation, so hang on to it, 12 million users, big number. Instances, right? So instances are basically the things that you guys provision and the things that you, you know, it's sort of our, if we were a hardware manufacturer, this is the widget that we produce. We provision an instance that you all can use. We're up to 12,000 instances and you can see the number of instances that you all are purchasing and that we are deploying is growing at a very rapid clip. Just in Q1 of this year, we actually deployed 975 instances. And in the demo, you're going to see a little bit about how we do this. Provision an instance at ServiceNow is actually done with ServiceNow orchestration. We have to do it that way because we have those 16 data centers around the world, we have a very involved CMDB that tracks all this stuff without automation, there is no way we could accurately and reliably provision that many instances in that short a period of time. But wait, there's more. Just at this show, for all the labs and all the work events that you guys are going through, ServiceNow orchestration actually provision nearly 24,000 instances, just over the course of this week. All administered by basically two people. Could have been one person but somebody had to go home in the middle of the week. So again, it's something that we just could not do without ServiceNow orchestration. All right, more big numbers. So we are provisioning this stuff in our cloud. We are populating our own CMDB. We're up to about two and a half million CIs, two and a half million individual entries in our CMDB. Frank showed you on Tuesday and you will see it again today in our demo. Our ability to actually reference a service. So in our case, it's one of your instances all the way through all the network layers, all the hardware layers, all the way down to the lowest layer of the product. Why is that important? Well, if you call us and say, I'm having an issue, something isn't working, we can very quickly go through the tree in CMDB and figure out, hmm, here's where the problem is. And we can go the other direction too. Likewise, if we get a low level alert that say there's some very high CPU utilization on a particular server, we can go the other direction and see all of you that might be enforced. And where the money really meets the road with this is we're able to actually typically notify you and fix an issue before you even see it happen. How about change? Our change process has actually gone through quite a metamorphosis. We didn't really have a very good change process maybe three or four years ago where today we have an extremely well articulated change process. We do probably several orders of magnitude more change than many of you out there. Most of the folks I talk to are doing maybe 50 changes a month, 100 changes a month, 250 changes a month, maybe even 500 if it's a really big place. We're doing over 6,000 changes every month. You're gonna see this in the demo again as well. What's really driving all this is all of you, right? Every change that you make, every time that you are doing a clone or an update set, that's a change. And we need to make sure that that change goes well and actually doesn't create an outage for you or another kind of problem. Again, you'll see that in the demo. How about incidents handled? So we handle a fair number of incidents. We're almost up to 6,000 incidents per month. Not a number we really want to be big, by the way. But the reason why I'm highlighting it here is this ranges every single inquiry to the company. So when you call about how something should work all the way up to you have an outage or a serious problem, that's in that number. We have strong support organizations both on the West Coast of the United States in those two European locations I described earlier and we just went live with an office in Sydney. So we've got round the clock capability to handle basically any of your needs. And our customer satisfaction scores that we get for handling incidents are consistently well above nine. So you folks seem pretty happy with what we're doing. But more important to us, and I think more important to you is we've actually reduced the amount of times you have to call us and deal with us. Over the last year, the average first person that's a customer service now had a 32% reduction in the number of difficulties or questions. And this is a key metric for us within the company. All right, another big number. One more time, there we go, great. 3.6 billion transactions per month. So a lot of people when they think about cloud they think of very sort of storage-centric terms. You think, wow, we're storing lots of bits, lots of pictures, lots of other kinds of things. That's really not what our product is used for. Our product is fundamentally driven on transactions. Folks are making updates to incidents, updates of problems, updates to conference room scheduling like we saw yesterday in the innovation of the year award. Those things are really driving volume. All those users I showed you earlier that are using the system, every single one of those folks are driving transactions. Our skill at actually driving very large transaction rates is what we're good at, scaling our infrastructure to actually be able to achieve that. And 3.6 billion is not the biggest number you hear SaaS providers out there quote. Salesforce has a bigger number that they actually quote. But I think this next slide's gonna make it more clear why this matters. When you actually take the average transaction rate per customer and compare us to those other folks you can see that our customer base is typically 3x the magnitude of anybody else out there. And actually delivering on this there's some fundamental architecture and some fundamental things that we deploy behind the scenes. You don't even know we're doing it. You don't have to buy extra hardware, you don't have to buy extra widgets for us to be able to deliver this. We actually are able to deliver this like nobody else in the industry and we think it's gonna be an enormous competitive advantage. And the way you're gonna feel it is you won't feel it at all. It's just going to work for you as you scale. All right, let's talk about security and compliance. Clearly on everybody's mind you look at the headlines. It's funny, every time we update this slide something else happens and we have to add another headline to the slide. And in fact, this week is no exception. AOL got hit this week if you guys have been paying attention to the news. They had a loss of a lot of their email address and so now a lot of their customers are getting spammed by other folks out there. So security is clearly on all of our minds. We all worry about what we don't know. And when I hear customers chat about security frequently they say, you know, we want to keep our most sensitive data ourselves and we're really afraid about putting our sensitive data in the cloud. And I want to suggest a slightly different way for people to talk about security. I think what we should be doing is we should be examining what are the policies? What are the postures? What are the compliance track record of the cloud provider? And let's compare that to how we might do it in our own data center. And then let's make a decision about who do we think is really going to be more secure. It's a natural human tendency to want to control those things that are most important. But I think if we actually look at, in our case, how ServiceNow does things and then compare that to how we do things that might lead you to a different answer. And there's a subtle thing in here that I think many people overlook. You all, in terms of running your data centers are running a quite complex operation. You're hosting hundreds of applications, maybe thousands of applications, maybe some of the larger companies, 10,000 applications. There might be things you're hosting in your data centers that you're not even aware you're hosting in your data centers. ServiceNow is doing only one thing and that is hosting the ServiceNow application. We have an extremely homogenous environment. And the way I like to think about it is, we have doors in and out of our data centers, but I think we have a lot fewer doors than many of you do. So I think we should have a stronger dialogue about exactly how does ServiceNow do security and how might that compare to you and then make the decision about where you want to keep your sensitive data. So to help you with that, I'm just going to cover some of the things that we do. All the time we have conversations with customers with more detail about this kind of stuff, but it starts with development, right? We have product features in the product that you can turn on and off encryption at rest. We can encrypt certain fields. There's many things that you can actually add into the product to actually lock it down more tightly than it comes out of the box. In the development process, we're also doing a lot, right? Security is so critical for us. It's actually, if we had a big security problem, it would be a real issue for our business, right? It's clearly on everybody's mind. So we are doing screening on nightly builds that we do every single day and static code analysis, many other things done on a nightly basis. When we're getting close to doing a release, now we start doing more sophisticated, longer running kinds of tests. So you can see third-party penetration and code inspection is stuff that goes on. Once we release the product, and it's now in the data center up and running, we don't rest, right? We have a group of folks that exist in our network operations center that are constantly watching for what's going on. We're using a security event monitoring with tools like Splunk to actually search for crazy things that might be happening. We're also paying broad attention to what's going on in the world outside ServiceNow so that we can actually get ahead of the game and perhaps defend against something that hit somebody else, but hasn't hit us yet. We're constantly monitoring and modifying our perimeter also to trap sort of bad things that might be going on. And then lastly, we don't rely just on ourselves. We have a lot of other people that are helping us out and making sure that we're not missing something. So I'm gonna show you another slide in a minute with sort of the alphabet soup of compliance standards that we're a part of and we do well with today. They're constantly coming in and recertifying us. And then a number of you actually are doing audits on us in periodic times as well. You come in and inspect us. So we're very transparent about what we do here and how we do it. And we're always trying to get better. Security is one of those things that's a war that's never really won. And we really do spend a lot of time on it. On the compliance side, here's sort of the list of the compliance standards that we're actually certified on today. Save the very last one. FedRAMP is a very new requirement. We are now officially in the in process state. These certification standards may not mean a lot to everybody in the room, but for your chief security officers or for the folks in your organizations that do worry about these things, these levels of certifications are gonna make them feel much more comfortable about what we're doing. So if you have people that are worried about what the service now doing, show them this slide, this will help a lot. One thing that's going on in the industry that I just wanna make everyone sensitive to is SAS, it's not so new anymore, but these standards have been around for a very long time. So many of these standards are actually sort of modifying their posture from the on-prem environment to what they really mean for the software as a service or the cloud environment. And I think the federal standards in particular are things that are changing. So I think this is a good list to keep paying attention to, but we are among the leaders in cloud providers with these kinds of standards and where we're at. All right, availability. This is actually gonna be a fun topic. So everybody's got a phone at home, right? Many of us still have a wired phone line, I hope. I don't have that necessarily in my house, but I gotta tell you, whenever the power goes out or whenever some other sort of fundamental utility has a problem in my house, I can almost always pick up the phone and I'll have that dial tone. I remember I was in the Bay Area during the Loma Prieta earthquake a number of years ago and the phone was the first thing to come back on and that's probably the same experience you folks have. What service now is really trying to do and our standard for you is to deliver that dial tone level of availability with our cloud service, right? And we control a lot of that, but we don't control all of it. And so there's a lot of things we do to try to mitigate things that we don't control. And you're going to see the results of that in this next slide. This is the measured availability for service now over the last 18 months. You can see we are now well north of four nines of availability. Okay, what's a nine? So 0.01% is about five minutes of downtime a month, right? So we're better than that. If you're performing, I'm going to show you another slide in a minute so these numbers will matter. If you are experiencing 0.1% of downtime, that's about an hour a month, right? 50 minutes. If you are at 1% downtime per month, now you're talking about eight or nine hours. And you can see when you're starting to experience that kind of downtime, it's just going to be a major problem for anybody trying to use the system. So how does that four nines of availability for service now compare to some of the other folks that you're familiar with that are also providing cloud services? So here's the comparison. Salesforce doing pretty good. Workday not quite as good. That's sweet, pretty good. Amazon, okay. Concur and jobbite, not even in the same neighborhood. We're going to come back to this line in a minute so don't get too excited just yet. But you can't just talk about planned uptime. You also need to talk about scheduled maintenance. I inferred earlier on that a lot of the departmental clouds take their systems down once a week, right? For whatever reason, it's sort of like rebooting your Microsoft Windows computer every day because you worry about it going blue screen on you or something. These folks you can see are taking their systems down for planned maintenance, a significantly long period of time every quarter. Not everybody on that list is not doing so good, but look at service now. Service now six hours a quarter. Why is there such a difference? Well, it's not, despite the video, it's not that we work faster than everybody else at repairing things or doing scheduled maintenance. It's we have a fundamentally different architecture. Most of the folks on the right side of the screen are actually running a multi-tenant architecture. What that means is all of the customers are actually sharing a common database. So it's very difficult for them to actually fail over a one customer and operate on that one customer. They have to fail over everybody, which is a very scary, scary thing to do. Service now is a single instance architecture. So every one of you is running on an individual instance of service now. So we routinely will fail you over to the backup side in order to do maintenance on the primary side. And so that six hours is basically made up of the time to do the fail over, which is typically a couple of minutes these days. We do it frequently and we're actually quite good at it. And that's gonna come up again in a minute. So when you add that uptime number to the plan maintenance per quarter, now you're starting to get a sense of what the real availability is. We're not all the way to real availability yet. But you can see these numbers now are starting to differentiate themselves a lot more. And if again, you're in a hospital, you're in a mission critical situation, or even if you're not mission critical, but you know your customers are gonna get mad if they can't get into the system, these numbers are starting to get very significant. Recovery time. So I talked about fail over a minute ago. Recovery time is how long it takes to actually get you back up after an adage, after something broke or something goes wrong. So we target two hours in reality, I mentioned we're actually doing this in minutes these days, most often much, much faster. The big difference is when we have a problem that we think is going to be resolved by a fail over, we will fail you over quickly and very fast. We don't spend time trying to figure out necessarily what was the fundamental thing that broke and trying to repair what broke. We will fail you over and then go work on figuring out what broke after the fact on our dime, not on your dime, right? Everybody else, because they run this multi-tenant architecture, because if they have a problem with one customer, it's a scary prospect to fail over 200 people at the same time. They don't do fail over when you have an adage. They do fix in place, right? So they're scrambling, if it's a hardware failure, they're scrambling for a new piece of hardware, trying to get things put back together, back up before they come back up, and that directly leads to these very long recovery time objectives or they don't even bother to publish it. I'm not gonna cover a recovery point objective this morning, but I did wanna go back to data center locations. So that very first slide I talked about all the places that ServiceNow actually has redundant pairs of data centers. That's what that clever little cloud pair looks like. You can see many of the other folks on this chart do have redundant data centers in the US, but only Workday has a redundant data center in Europe and nobody has redundant data centers anywhere else, right? So there's a reason why Salesforce, for example, doesn't do a lot of business in Europe and this is exactly why. They don't have a data center there. They're planning on putting one there this year, but been saying that for a while too. Actually, could you go back a slide for me please? I clicked too soon, thank you. So back to that top slide, uptime, right? Average uptime. These are the numbers you hear us all talk about. I just did it, right? Beat my chest, big number, four nines, really cool, right? Now I'm gonna tell you that number isn't very meaningful. Is this system up? Look at right there. There was a problem displaying your upcoming trips. Right, so this we actually use Concur at ServiceNow to do our travel, sorry for picking on Concur, but Concur's uptime is going to register their system is up, why? The way uptime is actually calculated for every single one of these vendors is they try to ping the instance. If the instance replies, it's up. Doesn't say anything about whether it's useful or not and in this case, it's clearly not useful. So there's nothing more annoying to you, for that matter of me, when we're claiming the systems are up and working fine but they're not usable and they don't work for you. It kind of defeats the whole purpose of measuring uptime, like who are we trying to make feel better here? So ServiceNow has actually launched just in the last month and it's on every customer of ours instance today, something you're gonna see in a minute and let me build into it. So this entire space here actually reflects the total uptime, so it's 100% uptime, nothing has been down, everything's great, everything's happy. Okay, one thing that actually can lead to downtime is the thing that's covered by the ping. If you have a hardware failure, you have an in-house network failure so you can't actually make the ping work, yeah, that's downtime, okay? So that was one category. But there's more, that concur slide I just showed you, probably a software bug in concur. Maybe a performance issue with the horsepower they've got deployed on that particular instance. I don't know what the problem was, but yeah, I could ping it because it gave me the technical difficulty slide, but I couldn't use it. There was something wrong in their architecture and their software and their release, whatever, took the system down, it was not usable. But you know what, there's things outside the SaaS providers control too. There could be third party issues. So the best example of this is sort of internet cloud issues, right? We've seen situations where our network is working fine, your network is working fine, but there's somebody else in our neighborhood that's getting perhaps a denial of service attack and there's a tremendous amount of traffic on the line that you use out of your plant that happens to find its way into one of our data centers and that could cause a slow performance issue. Another more less esoteric version of this is Netflix prime time. So it so happens that I read a report the other day in the northeast part of the United States during prime time hours, Netflix can occupy as much as 25 or 30% of the entire network bandwidth out there. So outside the scope of what we're gonna chat about today, ServiceNow is actually doing some very interesting things to mitigate those exact issues, just general internet clogs that have nothing to do with you guys or nothing to do with us, but they fundamentally impact your service. Happy to chat with folks about that after the chat today. And lastly, there are things you guys can do that could actually create problems. The very common one that happens is, we authenticate your users using your LDAP, for example. Right, and so when one of your users logs into our system, we're checking back through into your network through your firewall to your authentication machines and validating their credentials, and then we let them in, that's how it works. Well, if some of your networking team actually changes your firewalls around or do things so we can't access your LDAP servers, your customers aren't gonna be able to log in. So customer authentication and customer sort of induced problems with authentication is actually not an uncommon occurrence. Also, you gotta remember, this is a development tool, right? So we've all written infinite loops in our days and you can still do that with our product. You can actually invent things that will cause things not to work so well, which is why testing is important. So the point of all this is, your real availability is made up of things far more than just that stupid ping, right? So what are we doing about it? Well, we're talking about it here and now we've introduced, this was asked for last year, a real availability dashboard. So on every customer's homepage today, you can go here and you're going to see all of your instances. So in this case, this particular customer has two production instances, those are the ones that have high availability assigned to them, and three non-production instances. Every little chicklet, every little dot across the screen represents a day. There's 90 days worth of history here. If it's green, you had no issue. If it's yellow or red, you had an issue, okay? If you hover over that, it'll actually show you the incident numbers and it will show you the length and duration of that particular outage. You click on that, it'll open up the incident, you can read what the cause was. And the important thing here is we're not trying to worry about who is at fault. We're just trying to reflect your experience, not our spin, your experience on what your real availability is. And that number in the upper right-hand corner, then that is going to be your computed availability and that ought to resonate with how you feel the service is working for you, okay? Again, every customer has this working for them today. Go take a look at it. And we're gonna demo this in a second. In fact, we're gonna demo it right now. So I'm gonna ask a couple of buddies of mine to come up on stage. If we could advance the slide one slide, there we go, fantastic. So I got Pat Casey coming up here on my right and Alan Lyon one coming up here on my left. Yay. So what we're gonna do, we're gonna go through a very specific scenario. It's sort of an eight-step demo for you here. And I was joking with him earlier, of course we rehearsed these things. I told him we were gonna do it backwards today just to really confuse him. Now we're gonna go forwards. But what we're gonna do is we're gonna show this demo from two perspectives, right? Alan is going to show you and represent the Service Now perspective. This is what Service Now sees while we're going through this stuff. And then Pat is gonna actually represent your perspective, the customer perspective. So you're gonna be able to see how this all works. We're gonna go through these eight steps. I'm gonna go through them real quickly right now and then as we go into each one, I'll introduce it a little bit more completely. So the first thing we're gonna do is provision a new instance. The scenario, the broad big picture scenario is Pat is already a Service Now customer. He's already got that customer availability dashboard. But he's been asked to go generate a new application, all right? So one of the things Pat's gonna, the first thing he's gonna do, he's gonna ask for a new instance. Why is he gonna ask for a new instance? Well, he doesn't wanna do development on the production instance, right? So he wants a fresh instance where he's gonna go be able to play and wreak havoc without causing any sort of production problems. Then we're gonna request a clone. We'll talk about that when we get there. Creating the application. That one's pretty self-explanatory. That'll be step three. Step four is gonna be promoting that application into production, right? He's done with it. Now he wants to publish it and get it out there. Then we're gonna go into sort of the steady state stuff. We're gonna show you how we're monitoring it, both from your perspective, what you can do to monitor, and we're gonna show you what we're up to. Then we're gonna inject a problem. We're gonna have an outage. That's the Trouble in Paradise section. Step seven, we're gonna review now that we've completed that outage what that dashboard I just show you looks like, because it's updated in real time. So it will show you what that looks like based on the outage we just had. And then lastly, Fred introduced Share yesterday. We're actually gonna show us promoting this thing to share and show you how easy that is. All right. So we're gonna go now to step one. So just to remind you again, Pat's now, he needs to provision a new instance so he can start doing his development. So we're gonna switch it over to Pat. We're gonna flip flop back and forth. So hang with us as we go through this. And off to Pat, he's gonna introduce his company. All right, thank you very much, Dan. I do wanna spend a couple minutes talking about our corporate entity and the kind of challenges we're facing and what we're actually working on. We're Acme Incorporated. We're actually not that well known a brand. I wanted to share a couple of our products here for you in case you missed it. If you have an Acme brand, Dan, well we are in fact that Acme rubber bands. That's also us, especially the giant kinds. We're especially proud of explosive tennis balls. That was a huge seller in the 1990s. That was actually a joint venture between our sporting goods and home defense divisions. There was that unfortunate incident at Wimbledon and then the congressional investigation, but they were so well for a while. And our rocketry division also saying we were very proud of it, at least temporarily. All that said, the challenges for the company these days are we've actually seen a decline in sales. Things have been a little tough. There's the Great Roadrunner-Coyote Peace Treaty. A lot of our sales in the Southwest have declined. So the board has actually kind of been on a retreat for about 17 years actually in Napa. And they've been working really hard on a new business venture. Something radically different to take us into the 21st century. And they really think at this point that they've picked out exactly the right business opportunity for us to go into. And they've asked the IT department to take a key part in that. We have to write a new application to support this. So with all that said, I actually need to get ready and get a new application instance ready. So I'll turn over Dan for a second just to kind of talk about how that's gonna happen. Thanks, Pat. So the story gets better every time he tells it. Really good. All right, so normally what happens when an instance gets provisioned, if you're a current customer, is there's a sales transaction that takes place? We didn't wanna let any sales guys up on the stage. So we're just gonna imagine that happen. Alan's now going to say I've got the order for a new instance and he's gonna show you actually a little bit behind the scenes of how that happens, it gets provisioned. So Alan? Thanks, Dan. Yeah, so I just received the order from our sales ops team and we're gonna go provision a new instance with Inside Service Now. It might not surprise you too much to learn we use Service Now, Service Catalog to do that. So here's the Service Catalog that we actually use internally. You can see there's a bunch of things around here for us, people that like three letter acronyms like DNS and DHCP, I guess that's four letters. And other things that we actually do inside of our infrastructure. But you'll see that right here we actually can provision a new instance. So I'm gonna go into that screen. This is the actual screen we use when we provision up an instance. I know that Pat's a pretty demanding guy so I better get his development instance up and going because Lord knows road runners need that. We're gonna have a change control because we go through change control properly within our infrastructure for all those changes that Dan mentioned earlier. As soon as a couple of things we need to quantify here in terms of whether this is gonna be a production or sub-broad, it's gonna be a sub-broad for Pat. I know that these guys are really big in the American Southwest so I'm gonna provision that to be in our US pair of data centers and make sure that gets provisioned in the proper location. And with all that said and done, just like shopping online, I'm gonna order now. And what this does is this begins an orchestration in workflow similar to what you've seen before within Service Now. And you can see that that orchestration in workflow is provisioning through multiple steps. And you know, booting up an instance and sort of finding the right things takes a little bit of time. So I'm gonna go in and actually show you what's going on behind the scenes a bit and go in and look at the workflow and actually scroll down here and get the graphical view of this workflow to see what's actually happening. And this is literally the workflow that goes on and it's what's executing right now. So you'll see that we do things like we pre-provision and pre-validate that we have capacity. You'll see that if it's a federal customer, I heard Pat mention something about government and exploding tennis balls so there might be some fizzle approvals we have to go through. We make sure we have capacity for storage. We make sure that we set up the databases. We zebra the instance. We add the JVMs and the nodes. All of the stuff behind the curtain that actually occurs. We make sure that we're provisioning the plugins they may have bought. We do a little bit of post-provisioning validation and then we kind of reach the end of the workflow. And at that point, the instance is up and ready to go and ready for our customers to use it. So with this in mind and taking a look at this workflow then it looks like things are moving along pretty nicely. So I'll hand it back to you for the next step. Awesome, thanks Alan. So that is exactly how we're able to provision across this very complicated infrastructure and populate our CMDB so that later on when we have issues we know what's related to what and we can actually figure out what's going on. We couldn't do it without our orchestration product. All right, we're gonna move to step two now. So we have two forms of copying instances in the product today. We're gonna talk about the both today. First one is cloning. Cloning is exactly what it sounds like. We actually completely replicate one instance onto another. Why do we wanna do that now? Well, the reason why is if Pat's gonna go develop a new application right now, it's just a fresh blank slate. It's right out of the box. It doesn't have any of Pat's current production personality in it. So we're gonna clone the production instance as it exists that act being incorporated onto that development instance before Pat starts doing development. That's gonna make sure that whatever he's developing it actually mimics the environment and he's eventually gonna be promoting this thing too. So let's go over to Pat and see how he does that, how that happens. All right, thanks a lot. So probably not surprisingly, the way I clone ServiceNow instances is from within my ServiceNow instance. So I'm here on my production instance. You can kinda tell because it says production up on top. So we'll actually start with the request clone button here. A lot of you have probably used this. This is nothing special about this. There's nothing unusual about the Acme instance. I'm gonna choose I want to clone onto my freshly provisioned K14 Acme Dev. It's a little bit of a tongue twister but we wanted to keep it straight so we figured we could remember that one. And I'm actually gonna specify that I want this clone to happen next month. The last thing I wanted for the clone to actually kick off right here, right now during the demo because that could add a bit of a challenge. I'll add my well understood email address here and then I hit submit. What the system's actually gonna do behind the scenes is do some quick validations to make sure I'm actually allowed to do the clone that I wanted to. It's gonna make sure I'm actually an administrator on both systems. It's gonna make sure I actually own both systems. You know, the last thing you as a customer want is for some other customer eventually to make a typo and clone on top of your instance. So it's actually going through all of this validation now. It's finished the validation. It says, hey, look, are you really sure you want to do this because the target's gonna get overwritten? Yes, I am. I'm gonna go ahead and hit okay. And then as far as I know, my work here is done. But I think there's some work that ServiceNow is actually gonna do on the back end to make sure that this clone actually happens. Right, so remember I said we do over 6,000, like 6,600 changes per month. A full third of those are exactly these clone requests. So we want them all to be automated but there's some checks and balances we actually do before it actually continues with that automated process. Because again, cloning can be a very dangerous thing, right? You're physically copying one instance onto another. So we do some additional things to make sure that that request is not a questionable request. If it is, we'll actually pick up the phone and call you before we let it happen. We're gonna go over here to Alan and he's gonna show you sort of the behind-the-scenes side of that. Yeah, so send in the clones, I guess. What we did in this particular environment is we didn't want the automation and the cloning to go ahead automatically. It might actually provision while we were standing here, as Pat said. So you'll see we have the clone request here. We've manually set it to pending approval. We actually have a bunch of things we go through before we actually allow the clone to go forward. We don't want a clone overproduction. That would be a bad thing. We want to make sure the clone is happening in the right geography. I don't want a clone from the US over to Switzerland or Australia over to a different region. We need to check on compliance issues. We need to make sure there's no legal restrictions for doing the clone. There's a number of things we have to do. So let me just take a quick glance at everything that's going along here and make sure that everything is provisioning and look like it's proper. And it does, Dan. So what I'm gonna do is I'm gonna actually move that to the approved state. And as you see, I move it to the approved state and update it in the system. The clone is now provisioning along and Pat should have something to develop on. Awesome. So this is a perfect example of using ServiceNow to remove the human being from the request fulfillment process. Pat requested a clone and it's the automation that in 90% of the cases is gonna fulfill that clone. If we didn't have this process in place, we would have 2,200 and some more things to do every month for human being. And they would screw up a certain percentage of those, right, because we humans make mistakes. So cloning and our ability to actually automate it with ServiceNow is something you can do. It's a great thing. All right. Now we're gonna move on to creating the application. Fred talked a fair amount about this yesterday. Pat's gonna now introduce his application and show you a little bit about it. Sure. So one of the interesting things about writing an application is that it's actually really, really boring to watch. So we struggled to find something interesting for you to look at while I did this and we decided we couldn't. So while I actually write my application, Dan's gonna talk a little about what's happening in the backend and then we'll kind of cut back in a few minutes and then I'll show you what I've got. Yeah, so just a couple of quick points about application creation. So everything that Pat's doing, all the development is actually done from his web browser. There's no client application that is required on his machine, doesn't exist on his machine, other than the browser itself, which means he can do this from any computer anywhere and he can log in and get the work that he did last night on a different computer. Likewise, all of his teammates can actually co-develop with Pat on their computers using their web browsers. The other benefit of this is sort of the behind the scenes piece, all the artifacts that Pat's using to create his application, his forms, his lists, his workflows, any content that he's creating, all of those things are stored within the database themselves and by storing everything within the database, it allows us to make backup easy, it allows us to do the replication for the production instances, it allows us to do everything we need in a very simple way to take care of your instance so all you have to do is focus on creating the application. We take care of everything else for you in the background. All right, let's go back and check with Pat and see how he's doing on this app. Thanks, and actually this platform is so powerful and I am that good that I just wrote the whole application while he talked. Okay, maybe not. We did do some of it beforehand, but I turned it on. So at this point, I'll kind of tell you what we actually wrote in this case and we really do think this is the new application for the future. Our new business venture, Acme Incorporated, we're going into llama farming. We really think that that is the great future of a 21st century industry and I'll kind of talk you through what we've done here. If you're gonna farm llamas, you do need to track your farms. This is one of our test farms. It's in Oregon, it's about 300 acres and it's got three llamas. It will be more llamas, they're sort of like rabbits. You start with three and you get more over time. That's kind of the point of the farming. We're actually targeting 2,100 llamas here. We also have some of our test llamas. We can look at Frodo, the test llama here for example. He was pretty happy to see us. I think he was happy, either better, he wanted to bite me, but we'll move on. And he's actually got a mother and a father. With the llamapedia, one of the things we discovered when we started talking about this internally was that llamas are kind of misunderstood animals. They're not well understood even inside Acme and since it's a new line of business, we wanted to kind of talk more about them. So you can get some things about the characteristics of llamas here. We can learn a bit more about their nutrition. Llamas are actually very picky eaters. I think they're not like panda picky, but they're still reasonably picky. It's a bit of a challenge for us. Worth pointing out as well though that this application is not just about the production of llamas. This is also an end user portal where you can buy llama related products from us. So we actually have a llama service catalog we produced here with the llama catalog. Talk about some of the things that you can actually do with our llamas. First of all, you get a llama flotation device. Talk a little, one of the things we discovered when we were working on the farms is llamas are buoyant. And so naturally we thought there was an opportunity in the aviation division. So we did a joint venture with Boeing and we were gonna fold llamas up and kind of put them under the seats in lieu of those little yellow seat cushions because if you're gonna go into a water landing, wouldn't you rather have a llama with you? I mean, they're warm, they're comforting, they're soothing animals. We did have some challenges though, to be honest. For one thing, llamas fold up small, but it's coach. I mean, there just isn't space. We tried, it just couldn't be done. We did have one engineer who had a really good idea. He wanted to puree the llamas, but the ASPCA kind of got in our case about that one. So we have an inflatable float instead. You're welcome to get one from us though. These are actually available. And I'll also point out the llama pack train. You can get this from us, it's delivered anywhere with a rail depot in the United States in 48 hours. You can get as many llamas as you want. We will provide thousands of them if you're so inclined. We'll provide TAC and we'll deliver them, as I said, on a 48 hour notice. So with all that said, we're really excited about this application. It's ready to go, it's past internal QA. We haven't actually deployed it yet. So I'll pass it a little bit to Dan to talk about that process. You know what, I woke up this morning and I looked a lot like that picture of Frodo the llama makeup helped a lot. All right, so Pat's now got this application still sits in his development instance. It's all working, he's ready, it's all signed off on. And now he wants to deploy it to his company. He wants to get it on to that production instance. So now we're actually gonna talk about the other form of copy. So we don't wanna do a clone in this direction. Why? Well, we'll be gonna write over everything in the production instance. It's changed since Pat started doing development. That would be a bad thing. So this is where we use a technique called applying an update set. Where Pat's actually able to select just the artifacts that he's modified that actually mean and make up his llama farming application and move just those artifacts actually into the production instance. So again, this can all be done from the instance itself. Pat's gonna show you how that works. Great, so those of you who've used older versions of our system are probably familiar with the lovely update set UI. Those of you who've worked with Calgary or Dublin have probably seen the new team development feature. Behind the scenes it's a very similar mechanism but it does give you a much more natural UI if you're used to working with a more traditional source control system. Here you see I've got my local changes. I've got the world of llama and I wanna push this to production. Pretty straightforward. I go ahead and I cue it for push and then you can probably guess I push the button marked push. So I'm gonna push that one. I gotta name this deploy the llamas or unleash the herd. I don't wanna type that quickly. We'll go ahead and push changes. What this is actually doing as I'm talking is it's actually taking the changes on my development instance and pushing that to production. For those of you who've done, for lack of a better word, a real one, you probably realize that it takes more than about five seconds. I'll let you in on a very well kept secret. I actually pushed the app to prod earlier. This is just the application menu but it should be there now. So I'll pass it back to Dan to talk about some of the next steps. Great. Okay, so now it's all up in production. Now we're gonna go to sort of step five which is monitoring. Pat's actually able to monitor a lot of the performance of his particular instance directly, again, from the instance itself. So why don't we switch back to Pat real quickly before we go to Alan and we're gonna show you some of the graphs that Pat's actually able to take a look at in terms of monitoring the activity on his instance. Thanks a lot. So these are my instance activity graphs which I can pull up anytime when it's by service now instance. I can get a trend based on different time as to how things have been going in my instance. In this particular one, you can see that the activity on this app has been fairly low. In fact, I've had all of zero users until relatively recently when we've actually had up to four people on the system. I think that might have sounded like they'd actually announced the application is live yet. So we're really looking forward to the users getting on with that and go out tomorrow morning and we're all waiting with bated breath. In the meantime, Dan can talk about what service now is gonna do to support us while that happens. Great. So the point of this demonstration from Pat is there's a wealth of information about how your instances are being used in the instance itself. So your admins have the ability to go in and look at all this data. But let's go check it with Alan because obviously service now needs to monitor all 12,000 instances I told you about earlier. And that's not a trivial thing to do. So he's gonna show you a little bit about how service now is monitoring things back at the knock. Thanks, Dan. Yeah, we're monitoring llamas, all sorts of farm animals back there. We spent all of our time looking at all the 12,000 instances that you are running across our infrastructure. We spent a lot of time doing this. This is actually an application we wrote in service now called the Alert Console. And the Alert Console is what our site reliability engineers are looking at 24 by seven by 365 in our knocks in San Diego and London. So we'll always have eyes on these monitors. We're looking for a lot of different things. We're looking for monitoring servers and storage. We're applying software patches. We're looking for networking issues. We're looking for all sorts of things that might actually affect the availability because as Dan said, that's really, really important to us. We know the Cod needs to be available and we need to understand the status of everything that you have all deployed on the infrastructure. So you'll see we have a category of critical alerts and thankfully since I'm up here on stage, we don't have any at the moment. You'll see we have alerts about your specific types of instances. For those of you who notice your CI name in here, no instances have been hurt in the making of this demo, unlike perhaps some llamas. And you'll see that there's some performance issues. We have a CPU problem that came in this morning and a couple of other things. We're looking at backups that might have failed that need to be rerun. Looks like we got a chassis that's got a voltage problem, little bit of system temperature stuff. We're doing thousands of these checks every minute across the entire infrastructure against all the different data centers, all 16 of them. And we want to make sure that everything's doing the right thing. And Dan looks like all the llamas are flying through the cloud just fine right now. So I'll hand it back to you. Awesome. All right, so you just heard it. Alan just said everything's working fine, right? So what always happens after somebody says that, right? So we're now going to simulate an outage. So something's gone wrong and we're going to show you what that experience is for both us and how we use our tool to sort of figure out and fix. And we're also going to show you what it's going to look like from your side. So Alan? Yeah, right back in the hot seat. So you'll see that the alert console has changed a little bit now. And this is actually what happens when something goes bump in the night for us. We get these alerts, we call them fire alerts. And you'll see that I have a fire alert here showing that a database server is unavailable. And I have a bunch of instances unavailable. One of them unfortunately is Pat's. And since he's right there, I probably need to pay attention to this a little bit. You know, if we also open up an incident for the fact that this database server is down, I noticed just from the DNS name that this is on our Virginia data center. So we've already got techs on our way to Virginia to take a look at this particular machine to see what's going on with this database server. We've also started to update the incident to sort of give some information back to the customers that potentially are affected here. And you know, Dan, I love the channel a bit more, but give me a sec, okay? Great. So what Alan's doing basically is telling me to get lost. He's got work to do. And that's exactly what really happens. When there's an issue or an outage that's serious, we go into two very definitive workflows. The first one is the folks trying to figure out what happened, right? And their focus is fundamentally trying to get you back up, the service restored as fast as we possibly can. And as I showed you a little bit earlier on in our statistics slides, we're actually doing that in minutes pretty good these days. But the other thing we need to do is kind of keep everybody informed. So there's another track called the communication track which gets launched. And what do we use for that, right? We use incidents. So I get an email when there's an outage, Frank gets an email, Fred gets an outage. And you, the customer, is also gonna get an email trying to explain what's going on and keeping you informed. So we're gonna go check in with Pat and see what that experience looks like from the customer side, Pat. All right, thanks. Or I guess maybe not so much thanks, but I'd rather know than not know. So actually, I wasn't at my desk when this happened. I was actually at lunch naturally. And so I didn't have access to a browser, but I did have my phone. So I got an email from service now. And the first thing I did was I just take out my phone and I went into the high system. And I can pop over and look and, you know, low and behold, I do in fact have an instance, instance, incident, excuse me, that my instance is unavailable. And it looks like it's an active outage that's going on right now. Actually need to start calling some of my customers about this, because they're gonna start calling me relatively quickly. I want to get ahead of that game. So while I call my customers, why don't I talk to Dan a little bit about what service now is doing to get my great backup. So we're gonna now go check in with Alan. So you've been informed, you know, we still haven't figured out what's going on, but you know what's something's going on. We're gonna now check in with Alan and see how is he figuring out what the problem is. And more importantly, how's he gonna restore service quickly, Alan? Yeah, thanks, Dan. So I've been talking to the guys over in the Virginia Data Center. And it looks like that, you know, it looks like we have a rate controller. So basically we have a rate controller failure on this database. And I'm really suspicious because I see they have a database failed and I've all these instances fail that roughly the same time. So what I'm gonna do is I'm gonna use the power of our CMDB and I'm gonna dig in a bit to this particular configuration item. When I can dig into this particular configuration item, you'll see we have the impact view. And the impact view shows the impact of this particular database in the services that are then affected and the customers that are then affected. You'll sort of see it jiggles around a little bit and you'll see right over here, as I zoom in, I see that Pat's K14 ACME instance is actually red. ACME as a company is up because his development instance is probably up, but his production instance is down. And this view gives me a real good feeling of that this is the database that actually is affecting these customers. And because of that, I need to check a few more things here to look at what's actually going on. But I really think what we wanna be able to do now is we wanna fail them over, use those pair data centers and fail off this database and move those instances onto the data center pair. So with that, I'm gonna go ahead and invoke the failover button using ServiceNow workflow and orchestration. I'm gonna watch this impact view as this failover occurs. And while this is going on, Dan, why don't I turn it back to you and I'm just gonna make sure the failover works right. Great, so that's really that simple in terms of how a failover occurs in these emergency situations. There are certain checks and balances we do, but not nearly as many as we do for a planned maintenance kind of activity. And if we watch this long enough, you'd see those red circles begin to turn green again. But the only thing we can do is just check back with Pat and see how does the instance look? Is it actually working in back up for him, Pat? Great, so actually I can tell from my phone, which I've kind of been, I don't know if I've been clicking it like a rabid badger, but it stopped, I can see now, we actually, ServiceNow has told me the update has happened. I can see on my history that Ellen told me there was an outage, she told me the instance was down. About nine minutes later, he indicated there was a failover in progress that didn't give me an ETA. And then about four minutes after that, it says the failover actually completed. Let me pop back to my instance very quickly here. Wrong one, wrong one. This is why I'm not a professional demo person. It does look like it's up again. Let me see if I can see some llamas. Yeah, I think we're looking good. I have my llama farming back. So I need to start calling some of my customers, let them know the system's back up and available. And while I do that, Dan will talk a little about some options I have. Great, so it's usually that simple, right? Failover is usually that simple, diagnosing issues. Sometimes if we think the issue is a network issue at your facility, we need to get on the phone with your network and team. Things can take a little bit longer, but it really goes well the vast majority of the time. All right, so now we just had an outage. Let's go back and review that customer dashboard that shows what your real availability is and how that event we just had is reflected on that dashboard. Let's check back with Pat. Thanks. So I've had a few minutes to kind of relax. I've talked to my customers, the instances back up. I actually finished my lunch, but I do kind of want to pop over to my availability dashboard here and get a look at what's been going on. I've actually had kind of 90 days or 89 days of perfect availability here, but I do see that today, I do have an outage against my instance. It lasted about 13 minutes, which is actually pretty good. I wasn't sure if it was 10 or 17. It probably felt like a lot longer for me, but it's good to have these exact ups and down times. If I wanted to drill through directly in there I could, I can also see that over here on the open issues side of the house, I do actually have that incident is still open. I assume in service now is still working out a re-cause for me, but I'm back up at this point and I've got visibility into what happened. So I'm in a pretty good state right now. Great. So just to sort of hit the hammer one more time on that, this is going to reflect your experience with the instance. So if you open a P1 for whatever reason, it's going to show up on this graph and it's going to affect that availability calculation. Okay, so now everything's back up and running. Pat's actually got a lot of internal activity, but he's been sort of out there showing this to his colleagues in the industry and he's getting a lot of requests for other people that want to build a llama farming app just like the one Pat did. Well, now we have the share website to be able to do that. So we're going to start with Pat, he's going to show you how easy it is to actually take that application and upload it to share. Once Pat's done that, we're going to get a little bit of a more complete tour from Alan. So let's start with Pat. All right. So here I am logged in to share. I'm logged in as me, probably not too surprisingly. I'm going to go ahead and upload some new content and I'm just going to do that by clicking upload new. And the first thing I'm going to do is I've got to categorize my content. There actually isn't one for farming per se, but I think custom apps is a pretty good general case assumption here. So we're going to call this the world of llama, the best damn llama farming app ever on this platform at least. And we're going to go ahead and say everyone can see it. All I'm going to do now is actually have to add the artifacts here so we actually have someone to upload. I actually unloaded this previously, so let's go ahead and grab the llama file. If I had some documentation, I could include that in the supporting file section here. I got to tell you though llama farming is such an obvious activity, we really felt documentation was really unnecessary in this case. And also point out that the share portal is usable by anybody in any version of service now, but the applications we put up there may have a version dependency. This one actually requires Calgary or Dublin. And I'm going to go ahead and push the share now button. I'm actually not going to do this now because I did this backstage just to make it easier for you. It's worth pointing out that if you go to share right now, you can actually download your very own llama farming application. It's available and I've a bet going backstage. I actually want to see if I can get the top downloads for the next week. So please help me out on this one. With that said, why don't Dan pass back over and you can talk a little more about share. Is there a warranty with that application? Caveat M Tour. Yeah, okay. Great, so let's go check over there. He's going to give you a bit more of a full demo now of share and you'll see what it's all about, Helen. Yeah, Pat, you're going to lose that bet. So yeah, I want to spend a little bit of time talking to you about share. This is a sharing portal that we've put out. We're very, very proud of this sharing portal. You know, one of the things we heard at K13 last year is that people wanted to have a community of extensions and have a community of ideas being shared. You want to extend sort of the great energy and excitement around the platform beyond just the knowledge events throughout the entire year. So we really built ServiceNow Share to make sure that this content could survive and thrive through the entire year. You'll see when you come to the app, you'll actually see that there's a search box. You'll see you can find top downloaded content here. Don't see where the long is there yet, Pat. You're going to see a highest rated content and top contributing partners. And again, it probably won't surprise you that ServiceNow Share is written on top of ServiceNow. This is an application we wrote on our own platform. You can go in and look at various categories of things, application extensions, custom applications, dashboards, integrations, scripts, et cetera. But you know, I'm going to go in and look at one particular application if I could type. Harder than it looks. And there's an exam manager application that was written. And this gives you sort of a flavor of everything that's available on Share. You get a description of the application. You can see what versions it's available on. You, as a user, can rate the application. You get comments from various developers and users on what's going on. You can subscribe to the application to actually get updates when new content is updated. And because what you're actually doing is downloading an update set to your local machine and then importing that update set onto your instance, people generally want to know what's going on. So you can go into particular client scripts and you can actually look at the actual script that's actually going to be uploaded and sent to your instance when you do the import. And we really think that this is a powerful tool, a powerful community building site. We think that it's going to be extensible and used for a long time coming. Matter of fact, we're looking forward to seeing a lot of submissions from those of you here in the hall and including the folks we saw in the hackathon on Tuesday. Great, good transition. So this was just one scenario of how we actually use our product at our company. Obviously we're just sort of scratching the surface. We'll extend the offer for anybody to come in and visit with us and ask us more questions about these particular applications and maybe you'll see some other things we're doing that are kind of exciting too. Like I said, much of what we do here does find its way into our product in upcoming releases. So coming up next is actually the hackathon awards. Alan went, a lot of crazy folks were up really late Tuesday and they did some really cool stuff. So Alan's going to walk us through the hackathon awards and then I got to step back up and do a couple more things before we're done today. Alan? Thanks, Dan. So yeah, Tuesday night, that was a long, fun event. We actually had about 25 teams of people creating custom applications on the platform. We gave them from about 3.30 in the afternoon to about midnight to create them. And then at midnight we judged them and culled them down to the top five. The top five then got to display their applications at the expo floor yesterday and you all voted using SMS and American Idol to figure out who won the hackathon for us. We had things from major league BS ball fantasy teams to conference rooms, scheduling, to somebody working on stuff for the World Cup. But I do want to do one quick honorable mention. There's a gentleman who showed up at the hackathon named Rich Acosta. Rich had never touched service now, showed up at the hackathon the day he first touched our platform and wrote a Hootsuite-like sentiment analysis for social networking in one day. Major props for doing that. We really thought that was awesome. But without any further ado, let me tell you about who our finalists were. There we go. Our five finalists. We had a team that built an application for doing cable car management within San Francisco, kind of the San Francisco treat. We had a team that actually built a hub for schools and communities between teachers and students. We had a team that was actually building something to manage your social networking and social programs called Social Loop. We had a team that took me back to the 80s. You guys remember the adventure chat game? You're in a long dark hallway, many twists and turns. They did that in our chat application. That was really, really cool. And we had a team that made password management. There was a really creative set of applications. I hope everyone had a lot of fun at the Hackathon. And I hope we see a lot of you at the Hackathon next year. But moment of truth, who actually won our Hackathon? I know you're all sitting here. We are stomachs in your throat, so I'll tell you. Winner of 2015, sorry, 2014 Hackathon is the School Hub. These folks train an amazing application for us, help education, help schools communicate, video classrooms, video learning. It was just an amazing app that they created. So we're gonna congratulate them, have a little show until later on. Hope you go to the share site and see all the Hackathon creations that are up on share. But with that, I turn it back to Dan. Great, just one last thing before we go today. So there's a full day of activities still planned. So the show's not over. There's labs, there's other kinds of breakout sessions. So check your schedules and see that there isn't something that you're dying to go do and take advantage of today before you blast off. But let's look forward to next year. So start putting it on your calendars. Knowledge 15 is gonna be back in Las Vegas at the Mandalay Bay April 19th to the 23rd. So let's get that on your calendars. It's gonna be even bigger and better than this year. And with that, as you're leaving today, we've got some film here for you to all watch. It's a little bit like the outtakes or not, but you'll be able to maybe look for yourself and see some of yourselves in this video. Everything that happened this week, it was a great time. Really happy you're here. Looking forward to seeing you next year in 2015. Thank you. Thank you.