 ServiceNow Knowledge 14 is sponsored by ServiceNow. Here are your hosts, Dave Vellante and Jeff Frick. We're back, welcome everybody. Alan Linewind is here. He's the vice president and chief technology officer of the cloud platform and infrastructure components of ServiceNow. All the stuff that you don't see, it's sort of behind the curtains. All the magic and the secret sauce. Alan, welcome to theCUBE. Thank you very much for having me. So what's the, what's going on? What's new in the cloud platform? You guys obviously started this before cloud was sort of even referred to as cloud, you know? I mean, Fred talks about his vision and sort of clouds in there, but you know, really cloud started mid 2000s, 2006, and then really started taking off sort of latter part of the decade. You guys kind of maybe not predated, but sort of same time, you know? So what's, how was the platform evolved? Yeah, I mean, the platform is really evolving. People like to talk about cloud. I'm going to think about cloud that's a little bit beyond water vapor. So what we understand, it's been in our time doing is trying to make silicon and make aluminum actually perform something for our customers. The cloud platform has really evolved into being a platform that allows people to develop applications that are either both for IT or for the entire enterprise. That's really what we're sort of here to talk about from ServiceNow's perspective in this whole show is what we've done on the platform is beyond IT and it can power services for the whole enterprise. So we've scaled our cloud significantly. We're in eight different regions across the planet, 16 different data center locations, and we're continuing to grow globally on our cloud right now. So these data center locations, you're sort of, you're building out data centers? We're actually using wholesale and resale space. So we're using our data center partners and we're building out large case of infrastructure that we own and operate on our own. Okay, so just to make sure I understand. So you're not building mega data centers? Yeah. That's not your strategy. That's right. And can you talk about why that's not your strategy? Yeah, I mean, we're not building on mega data centers like maybe we hear from Facebook and Google and other folks. We're actually using our data center partners to build infrastructure to sort of meet our customer needs. We don't necessarily host people or do sort of infrastructure services like those guys do. What we end up doing is we end up building very specific cloud platforms infrastructure for the enterprise. It just turns out a footprint for that. This isn't as big as other folks and we scale it as we need to do. And there's confusion also about, and I wonder if you could help us clear it up. You're sort of your approach to multi-tenancy, let's call it, right? So you don't have a multi-tenancy model. That's right. You've got more of a hybrid model. Can you talk about that a little bit and what the advantages are? Yeah, absolutely. There's folks that have a multi-tenant model. And what that really means is that multiple customers' data is interlaced and intersected within the same data structure, within the same database. Sounds scary. It is, it can be a little scary. What we've actually ended up doing is segmenting both the application logic into virtual machines per customer. And then actually dividing up the database itself on a per customer basis. So every one of our customers has their own unique database process, unique to them. Their own tables, their own data, their own isolation, and they have application logic that's unique to them as well. That's very different from multi-tenancy where you have a large database and a large beef of infrastructure that a lot of people share. One of the biggest advantages for that for our customers is really about availability. If I'm a big, huge multi-tenant architecture, I need to take all hundreds and hundreds of customers in this pod and move them somewhere else because of failure, that's a scary operation. But what we actually have the ability to do is move individual customers around our cloud and provide a very high available solution for them because of the fact and the way we've architected it. So if I'm a customer and you're on a sales call and you tell me that, I'm like, good, I want that. Right. I'm like, totally cool with that. I'll stag you some butter. Now, okay, now if I'm a, we're not quite big enough yet, although there's some new products that are coming out that might appeal to us. But now if I'm, let's say I'm an investor, I might say, well, aren't I going to get better leverage if I go multi-tenancy? Think Amazon and some of the larger players. What's your response to that? Yeah, I mean, that's sort of an interesting distinction. When people think about multi-tenancy, versus single-tenancy, what we call it, what you actually find is that they think that the multi-tenancy allows you to scale the hardware better. But the truth is what we've done, what we actually call multi-instance, is the hardware can be shared, but the actual customer deployment, the job of virtual machine, the database for that customer, is laid down on that shared hardware. So we're actually getting good economics at the hardware, and we're giving customers isolation they want. We think it's very unique in the industry. It allows us to do some really exciting things. Well, we heard, actually it was interesting at Oracle Open World, which was here, I want to say two years ago. So it was 2012, maybe it was even 2011, it was 2011. Allison really railed on multi-tenancy. He railed on Workday, he railed on Salesforce, and said multi-tenancy is a bad thing. You don't want to do it in the application. Now I think, I don't know if 12C changes that, I'm not sure, I don't know if he did a flip-flop. Larry does that a lot, but your dogma, if you will, is not going to flip-flop, right? You guys, you can see this, am I correct? Well, let me ask you, does the scale, to huge heights that Frank Slutman wants to hit? Yeah, I mean we have 11,000, 12,000 customer instances in the cloud, so individual instantiations. But let me give you a quick fact, here for knowledge, we spun up 23,000 additional instances. So we have the ability to scale this model in a very dynamic way, in a very well orchestrated way. And we think it really helps our customers. One of the things I like to say about multi-tenancy is I get why it's good for the cloud provider, I get why the folks that build multi-tenancy build it, because you're right, it's, you build it once, you carve it up on bunch of pieces for a customer, customer's data is interlaced. Okay, I'm not sure why I want that as a customer. A customer wants that isolation, and that's what we provide. We're giving both leverage of hardware and isolation of data. Yeah, I mean, again, conceptually you can see how there might be some margin advantages, but then the big question to me is security. Sure. You know, what kind of security nuance, nuance is not the right word. Does it ease the security requirements? Does it make your security cleaner? Easier to scale, replicate, et cetera? You're talking about that a little bit? Yeah, I mean, it clearly makes our application logic easier, because every portion of the application is talking to that individual database instance for that individual customer. But our security focus is really focused on protecting those instances from the various threats. So we're always looking at threats on the internet. We're always adding our perimeter firewalls. We're already doing our third-party audits. We're doing our penetration tests. So just like any other cloud provider, we're continually updating our security model and making sure we're advancing and trying to stay one step ahead of the bad guys. But because we have customer data that is segmented and isolated, it does make our security model easier and more straightforward for the customer. Are you using a lot of open source in the back end? Yeah, we do a bunch of MySQL open source for the database itself. Yeah, of course, right. We do a bunch of Apache on the front end. You're using Mongo, right? We are using Mongo to help secure our document store for our larger customers. That's right. What kind of effect, if any, did Heartbleed have on you guys? Yeah, we looked at Heartbleed and we looked at the effect of it. We didn't really see much of an effect. We weren't using systems that are affected by that. Yeah, awesome. So, Alan, we've been covering a lot of data center stuff actually lately and there's a lot of interesting innovation that's happening in the infrastructure with cooling and power and segmentation and all kinds of interesting things. Where's the line of innovation in the data center between your stuff and the infrastructure provider that you're working with? Yeah, so we spend a lot of time actually focused on the actual server platform, storage platform, communication between the web servers and the network. We don't spend a lot of time on maybe hot aisle containment or cold aisle containment. We're worried about efficiency of the building or air flow through the building. We spend a lot of time sort of utilizing the best practices there. So we go look for our data center providers that are really driving that PUE number down to the 1L level, but we're not architecting the building. We'll look for those providers and then we'll deploy our equipment in a way that takes advantage of that. We're following and using some of the practice from Open Compute. We're looking at the next generation of networking hardware and networking software that's out there. And we're really sort of leveraging everything that they're building in the data center itself. And then I know there's a lot of data regulations that are driving kind of the locations of your data centers. So where, you said you have 16? That's right. I believe they're basically at eight locations, double located, if I recall. Eight countries, yeah. So there's still some open area that you need to penetrate based on customer demand that you haven't gone yet or where the next one's going to be. Yeah, we're going to build where the customers ask us to build. We built into Switzerland and Geneva and Zurich because of that. We built into Canada for data sovereignty issues. We're building into Brazil. We're building into Asia right now, Hong Kong and Singapore. So we're going to kind of go where the customer demand takes us. I had a specific question on Germany. And this came up actually, we were at the AWS re-invent. We did the AWS summit and Amazon doesn't have a data center in Germany. You don't have a data center in Germany. We do not, that's right. But of course, everybody knows German law, everybody knows. But the sort of urban legend is German law says you got to store data in Germany. When we asked Amazon this, they said, well, you have a location in Ireland that's part of the EU. Is that a similar response that you guys have? That's right. We have Amsterdam in London and we serve the EU countries through Amsterdam in London. And so if I'm a German customer, I would store my data there. Is that right? Yes, I mean, that would be the default. I mean, we actually might have a German customer that want to be in the US, but we actually let our customers pick which region of the world they want to be deployed in and we deploy on their behalf in there. That's a prerequisite of going through the process, right? You choose where you're going to store your data. That's right. And then... We'll have to sales guys figure that out. So I asked actually, and I'll ask you as well, from the Amazon perspective, has that ever been tested in the court of law? Do we actually know that this stands up? Because you always hear so much from the anti-Amazon crowd. Oh, well, you can't choose where your data is stored. That's not true. Certainly not true with you. That's right. And Germany and Brazil are very strict. They actually have a location in Brazil, but so are you comfortable that it's sort of compliant with German law in this instance? Do you have those conversations with customers? I mean, obviously you do business in Germany, right? Yeah, I mean, I'll tell you my last name is Austrian German, but I'm not well versed in German law. But everything that people tell me is, you know, we can deploy into... It's always a good answer. We're not a lawyer. I am not a lawyer. But it's not stopping sales, right? It's not stopping sales. I mean, I've seen this. Again, there's so much chatter and noise out there. Yeah, I think it's one of those misperceptions. People like to throw that foot out there. They like to say, oh, you can't do business. I haven't had that objection. I'm sure we may run into it, but right now it's not top of mind. I can say it was interesting at Percona Liveway, actually had a lawyer on which we don't have every often on theCUBE. And he said, you know, there's even different data laws in Massachusetts from Connecticut. And I'm like, well, where is the data? I mean, especially in the cloud and distributed, you're talking about cross-state borders and it has that really been challenged. And apparently it hasn't yet where it's going to get really nasty because cloud, just by its very nature, stuff's distributed, it's replicated. It's all over the place, so it's everywhere. So everybody uses Germany, but he was talking about the difference between two border states. So it could be interesting at some point in time. So we talked earlier about MySQL was really with sort of the data platform that you started with. That's right. And then Mongo came in recently, didn't it? Within the last year or two? What we ended up doing is we deployed the master database of the reads and writes in MySQL. We also have capabilities in the platform that when we start to scale the hardware, we can add what's called read replicas. So we can add sort of versions of MySQL that can take transactions that are read only. And then for people that have large document stores, they're doing attachments, they're doing forms, they're doing images, things are really document-based. We can actually deploy Mongo and then we can use Mongo for that particular type of transaction in the system as well. So that's what you're using Mongo for. That's right. Okay, that wasn't clear to me and it's a relatively new initiative, is it not? Yeah, it came out in Calgary, which was last year, was that release? Right, okay. I remember him talking about it last year, I think at no 13. That's right. Okay, so what's next for you guys behind the curtain? It was not really behind the curtain, but your customers, I'm sure, asked me about this all the time. So say if I'm behind the curtain right now, that's a different story. But you guys, it's not like, this is the main, well, I guess it is part of your marketing, but you're talking about products, you're talking about value, but it's great that we have an opportunity to speak to guys like you actually run in the factory, right? Yeah. So what's next? What are the customers asking for? What are the innovations that you guys are working on? Yeah, I think what customers are really asking for is for us to take the cloud platform and the infrastructure and really to evolve it to be that hardened, highly available, persistent, people want to talk about the cloud being like electricity, being always on. We obviously strive for that, but like any other business, we have issues, you know, hardware does go break and we does go booming all the night and we have to make sure we perfect it. We're constantly tuning that. We're focused very much on availability. You'll see something tomorrow, where we're actually going to show customers their individual availability as opposed to this sort of larger, distributed availability that people talk about. We're also looking into more automation, so that way things that generally break, that we now have humans intervene with, we want to have that automation kickoff automatically and then have people automatically, have the machines do that automatically instead of the humans. And we're spending a lot of time just really focused on keeping the cloud alive, keeping the cloud available and making sure it is kind of behind the curtain. Yeah, and visible is always good, right? You know, I asked Fred this morning and I'll ask you, because I didn't fully grasp the answer and I want to keep pressing at this. Fred was maybe, I don't know if it was a little over my head or it was, I don't know, maybe I just didn't get it. But so, the question I had is, so you're not really like the mega data center, right? We talked about that earlier. You're not like Amazon or Facebook or Google, but you know, you're growing. And you're getting to a scale that's quite large and you can see the future. You could be very, very large. Today, you've got N number of applications. It's not overwhelming. And the question I asked for Fred was sort of architecture question. In the database world, you've got transactions. You're locking on the database, the record. One application says I got it and releases it and the next one has it. As you grow out the applications, my question to Fred was, does that become problematic? Do you get queuing problems, performance issues, scale issues? And he said, his answer, if I could summarize, and I hope I get this right, was essentially we're not a heavy locking environment. Number one, number two, there's a lot of other things that go on, engagements that go on outside of that lock. So, he didn't see it as a challenge because of the nature of the applications and I guess the architecture itself. But as you grow to massive scale, does that potentially become a problem? Have you architected around that? Do you have to architect around that or am I just not understanding it? Yeah, I mean I think if we were multi-tenant where we had thousands of customers sharing a single database, dealing with those locking issues and the semaphoresias, we'd have that issue. But fortunately, because every customer gets their own version of their own unique database, they're just worried about the applications that they're running. So what we end up doing is we're going to monitor in the hardware and monitoring the databases for transaction rates per customer. And as those transaction rates per customer, as they add applications, as they add users, as they're adding joins and lists and building forms and creating services like Fred talked about this morning, we can actually find out if their database has started to see issues and if their particular database has started to see issues. We can then deploy read-up because we can go deploy things like Mongo on a customer by customer basis. So we don't have this scale issue per se. We have to monitor the individual customer transaction rate issue and make sure we're always automating and always upgrading the infrastructure to match. Yeah, okay, so you've obviously thought about this problem and the customer has to be quite large to even encounter the problem. That's right. We've got methods, techniques, approaches, even call brute force approaches. We can, we can solve it with more silicon. There are cases where the bigger box wins, right? Moore's law wins, you can add more metal to the cloud and you can make it bigger. So the point of all, the reason I'm asking all these questions is not just for sort of academic or theoretical. Here's as to, is this a potential constraint to your growth down the road? And I'm hearing no, it's not. Yeah, we don't see it as a constraint. Some of our biggest customers are running very, very large transaction rates. We're able to scale both the core metal to actually drive those transactions as well as tune the system and tune the way the database behaves. So that way those interactions you're talking about those locks, those joins, those select statements can actually be handled by the system in a very efficient manner. And what do you make of all this? You know, it's sort of started at, at VMworld a year or so ago with the whole software-defined meme and the acquisition of NYSERA, software-defined networking. Now they're talking about software-defined storage. You certainly see that from the hyperscale guys. What do you make of that? Is that, is that, how does that affect your world? Well, you're talking to a guy that actually worked on a software-defined networking company. I found it a company called Viata in my past, which Brocade actually bought. So I believe in the software-defined networking I believe that software and algorithms running the metal makes a lot of sense. Our automation, our workflow, our orchestration tools we have on the platform are what we use to bend our metal in the way we like for our customers. And I think really putting logic into the software and letting the software actually change the infrastructure is the way for the future. And so, thinking about your storage and your network and your compute infrastructure, you're sort of buying off the shelf, obviously, right? Standard servers, are you buying from ODMs or a combination? We do a little both. We actually look at our servers on an annual basis. We evaluate both ODMs that are in white boxes as well as your typical OEMs. And then we're looking to understand the transaction rates and the performance of those particular places of hardware. We do a price performance evaluation and we sort of upgrade and continue to migrate the farm forward. And how about the storage? I mean, you're buying big giant container boxes, big sands, so it's commodity storage. It's commodity storage horizontally scale across the servers. We don't believe in centralized storage model. No fiber channel, no infinite band. No fiber channel, no infinite band. And your stack is your stack? Our stack is our stack. So you've written your own stack to do replication and data migration and snapshots. The replication side is actually using MySQL BinLine replication. The backup itself is actually using some open source tools as well as some technology we've stuck on top of it. We actually call it SN Vault, for servers now Vault. And we've actually developed both a hybrid of open source and our own technologies to make that work. Do you use tape? We do not use tape. No tape. Zero tape. Yeah, I think Frank would let me. I'm not surprised given Frank Slutman from front of the company. And what about the networking? What's the strategy there? Yeah, from the networking point of view, we use commodity gear as well from the big two vendors out there, Cisco and Juniper. We're continually looking to upgrade. We're continually looking to drive layer through technologies down close to the user and have a very reliable, very redundant system. Let me give you an example. In every data center cage location, we have at least three tier one providers. We have a fully redundant network all the way from the internet, through the firewalls, through the load balancers, all the way down to the servers in the rack. And we just believe in high availability, enterprise grade, top to bottom. And what about this notion of converged infrastructure? You're seeing that a lot. Is that something that you're looking at, you're staying away from, you're adopting? We actually think it makes a lot of sense. I'm not going to tell you we're doing it right now because it's pretty bleeding edge and we want to be highly available for the enterprise. But this idea of a converged network and systems infrastructure that works together with automation, again, it's just part of our platform, part of our DNA. So kind of a single-throat to choke and reduce patch management, just a block of infrastructure. That's sensible to you. Absolutely. I mean, from our point of view, the ServiceNow Cloud platform would be that orchestration and automation platform. This is like field day for me, being able to ask all these questions from a practitioner that's actually building out a big cloud. And I'm having fun. It sounds awesome. And okay, well, let's see. So we hit on SDN, we hit on all the pieces here, I guess. I think I'm out. I think I'm good. You can tap out anytime you want. Yeah, that's fantastic. I really appreciate the insights. Because a lot of the cloud suppliers don't like to talk about the internal plumbing. But I think it's important that your customers want to know. I mean, at the end of the day, you don't build a great multi-billion dollar business without understanding how infrastructure works in the architecture of the infrastructure. I'm a really strong believer that our applications are driving the enterprise forward. And I'd have a hard time talking to the CIOs I talk to on a regular basis without convincing them that the infrastructure they are relying on for those applications is as solid as it gets. Do you see the need? I do have another one. So do you see the need? Remember the early days, I all thought, okay, here comes guys like Amazon, it's commodity infrastructure, software-led. That's going to bleed into the enterprise. You're starting to see that happen now. But now Amazon's kind of done a 180. They're going highly customized infrastructure. They won't show us their servers, but they'll show us some ODM server that's super dense and they say, we blow that away and because they control their data centers. Do you see that type of customization requirement for your servers and for your networking? Yeah, we spend time looking at that as well. I wouldn't say perhaps we do it quite in-depth because Amazon, we don't run quite the same size of farm they do, but we do look at the motherboards and the PCI cards and the flash disk that's in there, the SSD. We spend time understanding the BIOS. We spend time understanding how many ports we're going to connect to the top of our app switch. We spend time speccing all that. I mean, we're a full hardened enterprise platform and our customers depend on us to do that. So we have to do that diligence. Are you using, all right, we still got time. Are you using flash? Yeah. How are you using it? Yeah, we are using flash. We find that the flash arrays, we use Fusion IO and for those SSD cards, we put them into our higher end database servers, removing actually off spinning media onto flash for the entire farm. And one of the way we use it is it helps us get IOPS out of the database servers and it actually helps in replication because the way replication works is I'm operating in data center A. I do my transaction in that database. I write it out to the flash because the database is in memory. I send it over the parasite. The parasite's got to read it off disk and rerun that transaction and keep that replication in sync so that IO actually does help us keep replication going. So are you using Pocono MySQL or no? No. OK, so do you. We're using our MySQL. OK, do you do atomic writes with Fusion? We are doing some writes with Fusion, yes. OK, so you're essentially bypassing the SCSI stack and writing directly to. We have the ability to do that with a new Fusion IO driver, so I'm not sure they're widely deployed right now. But does it have potential? Absolutely, it has potential. That's an amazing performance. If you can go straight from memory, straight to SSD, just like you're actually a RAM chip, why wouldn't we want to do that? So not only am I eliminating the spinning disk, I'm eliminating the overhead of the storage protocol. We'd love to be able to do that, yes. OK, that's. And you're extending the life of the flash per David Fleurer's article that we covered the other day because it's written specifically for flash as opposed to written for disk onto flash. How about object store? Is that something that you're? We generally don't have a ton of object stores that we do, but when we do, they're document types, they're attachments to an incident, they're graphics on a particular application, they're part of a workflow that pops up or presents something to the customer. And if those sort of documents become heavy transactional types for reads in the database, we'll put those on Mongo. OK, so, and you're doing sort of a combination of block and file? It's all block. It's all block. All block? Yeah, well, file against Mongo. Except for, I guess, what you do in Mongo, that's the worst file or quasi-object. That's right. Awesome. That's how I'm having a field day. I really appreciate all the insights, you know. This is good. I'm going to actually go back and watch this several times. I mean, the truth is for us, it's all about, like I said, it's all about talking about folks, about infrastructure. We think the infrastructure is the core foundation for everything we do in the enterprise apps. The apps are really what our customers are about, letting them be creators and letting them do is our applications. But let's face it, we build the cloud and the cloud's got to be solid to run those apps. My last question, so we've been talking about all these cool innovations. When do you see these, or do you see these seeping into the enterprise on-premise? Do you see that as a sort of viable approach for CIOs, or in your view, are they just going to sort of outsource it mostly to the cloud over the next decade? I'm pretty clearly biased at the moment, but you know. Well, but you're application-driven. We're talking about infrastructure from the side. I mean, I think the things that we're doing in the cloud and the infrastructure are sort of leading edge. I do think the enterprises are going to adopt that. But I'll be honest with you, there are certain enterprises that are ahead of us, right? There are certain folks that are thinking one or two steps ahead of us, because they're at just a bigger scale than we are. Not most, though. Yeah, not most, but there are some, and we've learned from them. Yeah, I'm thinking the big banks, the big financial institutions, we spend time with them learning what they're doing inside so we can actually make the cloud better. And they're sharing with you, okay. Absolutely. Yeah, because they're trying to learn, too. Yeah. They don't want to outsource to somebody that's running on bailing wire. They don't want to outsource to solid. Yeah, amazing innovations actually going on in financial services. It's like the downturn never happened. Ella, thanks very much. I really appreciate the insight. I appreciate it. All right, great stuff. Keep it right there, everybody. Jeff Frick and I will be right back. We're live from Knowledge 14. This is theCUBE.