The joint work with Navneet Agarwal and Sanath Anand, who were undergraduate students at IIT Bombay. So I'm talking about MPC, or Secure Multi-Party Computation. So let me just start by reminding you the setting.  They all have inputs. And they may all want to compute some function, so they could all potentially get outputs. And to compute this function on their inputs, they run a protocol. They talk to each other. And the requirement is that they should learn nothing other than their own inputs and the outputs of the function. So what else they see in the protocol could have been simulated. It's a very fundamental model. Since the 80s, cryptographers have been working on this. We know a lot about it. And one of the foundational questions, the fundamental questions about MPC is which functions that met Secure Multi-Party Computation protocols. And you'd think that by now, we should know everything about it. Unfortunately, even in the most basic setting for this problem, things are wide open. So what do I mean by the most basic setting? Information theoretic security with no restrictions on number of parties were corrupted. We do, of course, know a lot of very important, powerful, positive results when you do put restrictions. But I would think that this would be the most basic problem if we didn't have all those positive results. The first thing you would think of. We know a little bit for the setting of two-party functions deterministic two-party functions. We do have a full characterization of what's possible and what's not. And in this work, we are interested in more than two parties. And we'll study mostly in this talk. I'll talk about passive security. So the honest bit curious adversary setting. And we do have results on UC security also, which I'll mention towards the end. So to understand the feasibility question for MPC, we also, in this work, introduce some minimal or simple models of MPC for aggregating functionality. So what do we mean by aggregating functionalities? There's just one party who has output, the aggregator, and all the other parties have inputs. They don't have any outputs. So simple models of MPC for these aggregating functionalities have been around for a while. And one of the most influential works in this setting is by Phi Gake-Leon and Naur from the 90s who introduced the private simultaneous messages model. So in this model, all the input players send a single message to the output player. And it has to compute the output. But we also want security. So for that, they allow a trusted party, a coordinator, who can a priori send some correlated randomness to the parties. They also require security only against the corruption of the output party. So none of the input parties can be corrupted. More recently, Amos and Scott has introduced another model called NIMPC, where they do allow all parties to be corrupted, any subset of parties could be corrupt. But they make another restriction on security. Namely, the adversary is allowed to learn not just the output of the function, but the residual input, the residual function of the inputs of the honest players. That is to say, the adversary is allowed to learn the output of the function on all possible settings of its own inputs, of the corrupt party's inputs with the inputs of the honest players fixed. So you can evaluate the function on, keep the honest players' inputs fixed and run through all possible inputs of the corrupt players. So that is allowed in the ideal world. That's given as legitimate information. And in either of these models, we understand feasibility fully. In fact, every function can be securely computed under these models. So these models are not so much trying to learn about feasibility question. It's about asking questions like computational complexity of these problems. In our case, we are interested in the feasibility question of MPC. So what we introduce is a new model called, we do, of course, talk about MPC, but we also introduce a new model called Anastashstich NIMPC or UNIMPC. So how does it work? It's like NIMPC, but we don't have the coordinator. And also, we don't allow the output party, the star, and the output party have removed it to say that the output party is not allowed to learn the residual function. So it's just like an MPC protocol. But we do allow us two-phase computation. So there's a first phase before the inputs come in, where the input players can talk to each other. And then there is a phase when the input come in, they just send a single message to the output player. So that is unassisted NIMPC. Our most minimal model is what we call UNIMPC star, where in the pre-input phase model, in pre-input phase, the party send a single message to each other over in private channels. So it's a single message, and then they get the inputs, then they send a single message to the output player. So that's our basic model. So why are these models relevant to the study of feasibility question in MPC? If you show an UNIMPC star protocol, it's automatically UNIMPC protocol, which is automatically an MPC protocol. So the security notion, and the communication pattern, everything here is consistent with the corruption model is all what is allowed in MPC. So a protocol that's secure in either of these models is also an MPC protocol. So now let me actually show you the results we have before I explain them. So this is a landscape in the sense every point here is supposed to be a function, a functionality. And we have these three sets, right? The set of functionalities which have MPC protocols, and some subset of them have UNIMPC, and some subset have UNIMPC star protocols. We don't fully understand what these sets are. Even after our work, we don't fully understand what we can to use a following. There is a class which we'll define in a combinatorial or algebraic way, a class of functions called CPS. So I'll describe what CPS is in a bit. And all MPC protocols live inside this class. All functionalities with MPC protocols live inside this class. And on the other hand, we can sandwich all these classes within, or we have another class, the CPSS, which also I'll describe in a second. It's also defined combinatorially or algebraically. And we show that the class of CPSS functionalities do actually have UNIMPC star protocols, right? So the gap is between these two things. There's an extra S that's confounding S. And so let me first tell you about these two results. And we have a few more things in the paper which I'll mention towards the end. OK, but first I should really vote CPSS and CPSSR. These are names we came up with. If you have seen these things elsewhere, I'd be happy to know. They're very natural objects. I just don't know any standard name for these things. So what is an NMCPS? A CPS stands for commuting permutations system. So you should think of N as the size of the output alphabet and functions we'll be describing. So N is one to N are the possible outputs of some function. And each of these x1 to xm are the input sets of m players. And what each input is is actually just a permutation of these n numbers, right? So each element in the input set, each element in xi, is a permutation on these n elements. Just put it another way, xi is a subset of the group of our permutations. That's called a symmetric group, Sn. And it's OK. So far, there is nothing commuting about it. Permutations don't usually commute. The commuting part is a following. Suppose I took m permutations, one from each of these sets. And I applied it to one. One is some designated special element in the output set. So I can apply one after the other these m permutations on one. I'll get some other number in the range one to n. That number should be the same even if I applied these permutations in a different order. So the row is some permutation of these m permutations. So I applied them in a different order. Just to illustrate, so pi1, pi2, pi3 are three permutations that color differently because they're coming from different sets, x1, x2, x3. And you apply them to one. It's the same thing as if you applied them in a different order. And in any of these six orders, you apply them. You'll get the same thing. That's what the definition of commuting permutations is. It's very simple. Just to point out, the commutativity is required only across the sets, xi, and also only for applications to that one value, one. So as permutations, they may not commute with each other. But when applied to this one value, the order doesn't matter. So that is the definition. And I'll hopefully make a little more sense soon. But let me go ahead and explain. Oh, so CPS is not a function.  The function that we associate with the CPS is the following. Just the inputs correspond. Inputs are these m permutations, one from each set. It's one from each party. And the output of the function is just evaluate those m inputs on one. That is a function associated with the CPS. And CPS says it's just an extra requirement. So there's a subgroup system, which means each of these xi's should be actually a subgroup of the symmetric groups. So symmetric group is a group structure. There is a group structure with composition as a group operation. And these sets should be all subgroups of this set. So that is a requirement of CPSS. OK, so where does the CPS thing come from, right? So let me explain it. Actually, I think fairly intuitive. So suppose somebody gave you a function, an aggregating function F, and they said it has an MPC protocol. Information's very strictly secure against passive corruption. Then let's consider a partition of this set of m players into two parts. So one part consists of just the output player, which I'm calling P0 there, and one of the input players, Pi. And the other set is the remaining set of parties. Now think of this as a two-party setting now between the set R and the output players. So it's not easy to, it's not hard to see that if you have a secure protocol, the only thing you can effectively do is the set of parties R. They're not supposed to learn anything other than their own inputs. So they have to just send out their residual function to the other two players, so that they can evaluate their function correctly. And so if you have a secure protocol, or if you have any protocol which R doesn't learn anything, then this is the only way it can work. But on the other hand, it's also a secure protocol where these two parties, P0, Pi, should learn nothing. What that means is residual function that they have to learn is something they could have learned just from the output of the function. So without, just by learning, with PI's input, fixed input Pi I, whatever they can learn about the input players, inputs of the set R is all that they should learn even if they learn the residual function. So the residual function is nothing more than what the input and output reveals to the set P0, Pi. And CPS captures exactly this condition. It may not look that, look like that immediately, but if you play with it a little bit, you'll see that CPS is exactly captured in the condition that the residual function is for free, in the sense that it's already implied by just one input for Pi and the output corresponding to that. Up to relabeling of inputs and outputs. And one direction is very easy to see. Suppose I gave you a CPS, then it indeed is a case that, so if you consider the function applied on Pi 1 to Pi M, by commutativity, I could just apply Pi I at the end. So I apply all the other permutations first, so I'm calling it Pi R, the composition of those things. And so the function is actually just Pi R of 1. So Pi R of 1 is all the information that you need to evaluate this function on any input, on Pi I in particular. So that is the residual function, Pi R of 1. And if I give you Pi I of Pi R of 1, since Pi I is a permutation, I can compute Pi R of 1. So at least it's very easy to see that if I give you a CPS, it does have this property that residual function is for free. And the other way is something in pro, you need to go over things and ensure. So that also works out. So that's one way to think of what CPS is doing. It is that condition. Another way we could look at it, there's a class we didn't give a name in the paper. So I'm just calling it NIMPC without leakage. So remember, in NIMPC, the output party was allowed to get the leakage, the residual function. So you could imagine a model where everything else is as an NIMPC, I just remove this condition. And then actually, CPS is an exact characterization of which functions are securely realizable and not. Which functions are not. It is a characteristic of which functions are realizable in this model. And I'll also mention one connection with another recent work of Hallevi et al. from last year's TCC. They defined a notion called best possible information theoretic MPC, which I don't have time to go into right now. But actually, the definition is actually very simple. Same as this NIMPC with the leakage allowed to the aggregator, but it just removed the trusted coordinator. So in our case, in this slide, we are keeping the trusted coordinator to remove the leakage. If you do the other one, you get this bit MPC. So the reason I mention is I'll show the connection here. So to remind you, this is our landscape, which I have not yet proven anything to you. I just defined CPS and CPSS. And we can all actually show that these things are actually, there is a gap. So these are two combinatorial classes. We can show there are functions which are CPSS, and they are not CPSS. In fact, they do not embed into any CPSS. And the thing about bit MPC is that inside CPS, the residual function is for free. So there is no distinction between MPC and bit MPC in that gap, inside CPS, rather. So if there is a gap between CPSS and MPC, that means that's also a gap, that's also a set of functions which do not have bit MPC protocols. We don't know if this gap exists or not. But it's an open problem whether bit MPC is possible for all functions or not. If this gap exists, then it is not. So now let me tell you about CPSS. Why is it inside this UNIMPC star? So that is actually a protocol.  And I think it's kind of a huge protocol which generalizes this very natural and simple protocol for summation that you might have all seen. So let me tell you what the protocol is. So suppose this is your function defined in terms of M subgroups of SN, of the symmetric group. And suppose there are three parties, so M equal to three. And before getting their input, they are going to talk to each other a little bit. So here's what they will do. So each party, so in this case, P1 picks three elements in the groups G1, G2, and G3, one each. So that's their color hood differently. And the condition, I mean, they're a bit randomly subject to, one is a fixed point of their composition. So if you apply these permutations to one, you can apply in whatever order. That doesn't matter. If you apply to one, you'll get back one. Once you apply all three of them. So P1 picks such permutations in its head. And each of these guys, P2, P3, they do that independently. And then they've not communicated yet. What they will do is just send, so all the group one permutations are sent to P1, group two permutations sent to P2, group three permutations sent to P3. That's all the communication they do before the input comes in. And then they get their inputs, pi 1, pi 2, pi 3. They do a secret sharing as follows. And they compute these additional sigma 1, 0. And so P1 computes sigma 1, 0, such that if you composed all of them together, you'll get pi i. And why is this possible? Because it's a group. The blue things all live in a subgroup of SN. So you'll be able to find this. And they send, each of them computes this and sends it to the aggregator, the output party. Who does something somewhat strange? It takes its permutations and applies them to one. And outputs whatever comes out. So let me at least tell you why it's correct. It's the correct thing. The correct thing would have been the following. What you would really like to compute is pi 1 up to pi m applied to one, where each pi i is the composition of the sigma i's in a row. So this is what you'd like to do. Compose all these sigma's in the bottom row. They'll give you pi 1. Then compose them with these and so forth. And apply all of them to one. This is what you would like to do. What our protocol does is this somewhat strange thing. It just applied these things to one. OK, so let's try to make sense of it. We know a little bit about how these other things look. They all keep one as a fixed point. So at least we can do this. Instead of saying the application was oblivious of the other shares, you can at least write it this way. But still, they don't look the same. So let me just show you that they are actually the same because of this commuting permutations condition. So I'm just going to focus on these two sets of columns for now. So the order in which you are starting off is applying them in this order. That's the order in which they are written. And what you can do is you can bubble this green thing from here all the way up to here, relying on the fact that when applied to one, the order doesn't matter. So you can bubble up that green thing all the way to the other green thing. And then since they live in a subgroup, you can put them together. And you can do this and bubble up things appropriately. And you will get this other order, which is, if you notice, the same as first do these two, then compose with these two, then compose with these two. Within the group, you don't change the order. But across the groups, you can change more. But across the groups, you can move them around. And you can work this out. And you can do it more cleanly. It works out. And it can also be shown to be secure. So that is all about the passive security. Let me spend just a couple of slides on one slide on UC security. So UC security, you might have, there's a myth, or you might have heard that there's very little you can do. If you do not have any setups, there's virtually nothing you can do, no interesting functions you can do. But that is for two parties. If you go beyond two parties, there are interesting functions you can do. Well, there are some limitations. You can only do either aggregating functions like we are talking about, or they're kind of a dual disseminating functions where one party has input and all the other parties are output. And you might have seen broadcast with abort is possible in there is a UC secure protocol. It was observed by Golders and Linde. And there are also some other special cases for disseminated functions that I've shown up. Our first result here is that actually every disseminated function has a UC secure protocol, not just these few. So that is about disseminated functions. How about aggregated functions? Well, there are aggregating functions. There, our protocol doesn't work for all of CPSS to get UC security. But it works for something called complete CPSS. Complete means it's like a Latin square where everybody has n inputs. So everybody has n permutations, where n is the output alphabet size. And it's not just that functions which are complete CPS, even functions which embed into a complete CPS function to CPSS can do a UC secure protocol. And that requires, for UC security, you need to show that if you restrict the domain to a subset, you can still get UC security. So there's a new protocol needed to get that. Let me just finish off by this one thing. So UC security is a nice notion. You think of it as a very strong security. But it has some idiosyncrasies. It doesn't always imply security against passive corruption. So we go ahead and define. And I know people are, it's a foreclosure notion, I guess. But I don't think it has a name. So we just call it strong security. So a strongly secure protocol is one which is UC secure and secure against passive corruption simultaneously. And from whatever I said, and a few little observations, what you can say is that we pretty much know which functions have strong MPC at this point. All disseminating functions have aggregating functions which are necessary and the sufficient condition, but they are not the same condition. And otherwise, if it's not disseminating or aggregating, it's not possible. So the gap that is left is CPS functions which are not complete CPS. OK, so to conclude, we have this new algebraic structures. If you look at the paper, you'll find a few more things. You'll find some cute examples, some open problems on, and about these algebraic structures. And also, we, of course, gave connections to all these new models of computation, as well as MPC itself, the standard model itself. And at the end of all of this still, the full characterization, the exact characterization remains open for the standard MPC module and even for some of the new models we have. All right, so that's all. We have time for one short question. OK, so let's thank the speaker again.


So, this is on VSTS architecture, I'm Buck Hodges, I'm Director of Engineering for Visual Studio Team Services, and we're going to talk about our journey from taking what was TFS and turning it into a service. And one of the things I always get when I talk to customers is, hey, should I go refactor my software, whatever it is, into a cloud service before I move to the cloud or should I go ahead and move? We did the latter. We went ahead and moved. And I'm going to talk about what that looked like. One of the things that I think we learned along the way is if we had decided to try to, quote, turn it into a cloud service without actually going and doing it and living it, we would have made a bunch of decisions that in the end wouldn't have been the right decisions. We made different and better decisions, I think, because we took the approach that we did. And then I'm going to talk about some of the things that we did as part of becoming a cloud service. Things like feature flags, being able to control exposure, resiliency, which I'll touch on circuit breakers and resource utilization or throttling and how that is important. And then finally containers, which is where we're headed. So let's dive in. So in the beginning, it was 2010 when we started this journey. It was, I forget exactly when we decided to go do it, but our target was the October PDC in 2010 when Brian got up on stage to demo what was then a prototype of a service of TFS running in Azure. So to set some context, 2010 is when we had just started to adopt Scrum. You all saw Aaron Bjork's presentation. This is going all the way back to August 2010. We had just started the Agile transformation. So we're at the beginning of this whole thing. So we had TFS, it's an on-prem product. It's a product we'd ship every two, three years. We had some good stuff there. The 2010 release, in part, set us up for being able to move to the cloud. It was the first release where you could have load balanced application tiers. It was also the first release that had the notion of a collection. And that became important because a collection becomes an account in VSTS. And another piece that I'll talk about is we had something, essentially the server framework. Now, it was all TFS. And part of what you're going to hear is we ripped a lot of things out of TFS to go reuse them. But we had some good parts to start with, but it was still an on-prem product. We had no experience with Azure whatsoever. It was brand new to us. Of course, it wasn't very old then in 2010 to begin with. All of our data was in SQL. All of you, of course, know TFS on-prem, shoves everything into SQL, file content, metadata. SQL's the answer for our storage. Can't be that way in the cloud, but that's where we started. We only have the notion of active directory identity.  There was no notion of a Microsoft account or AAD or any of the rest of this stuff. And of course, a notion of an account, not even close, right? There was nothing like that in the product. So this is where we started. And with that sort of starting point, we're going to move into Azure. And let's take a look at sort of what does that mean? So when we started, we had a single tenant system, right? What does that mean? It means every time you signed up for an account, that collection, as I mentioned before, is an account in the cloud. In the beginning, every collection was its own database. So every time somebody signed up in VSTS, we go create a new database. At one point, we had 11,000 databases in Azure North Central, right? We had a lot of DBs. And we were going to go broke if we kept it that way, but that's where we started. Upgrades are offline. Some of you maybe who've used the service forever may remember, because it took us a while to fix this, we'd have to take service down. So we'd schedule maintenance windows, which of course is completely awesome, because everybody loves maintenance windows. We had no telemetry. And in fact, I mentioned we were pushing for this proof of concept, which we did in October of 2010 at PDC. Our next big milestone was the build of conference in September of 2011. Compared to what we have now, we had no telemetry. Like we had kind of started, we thought we knew, hey, we should trace this, trace that, of course, we were super naive. But this was actually why I signed up for Twitter. Some of you follow me on Twitter. The whole reason I signed up on Twitter was so I could keep track of what was going on with product, because I figured if it broke, somebody complained on Twitter, right? That was telemetry. We had no deployment cadence. Our deployments were months apart. Ed Glass is going to talk about how we do deployments now, later today. But at this point, they were months apart and really random. Meaning there wasn't real thought into, hey, over the next year, when are we going to deploy? How does this work? No clue. We had no life-site culture. I mean, this is a team that was built, recruited. The whole culture was built around. We ship a box product. I give you the product. You run it, not me, right? So this is a big shift in how to think about engineering. And of course, you'll hear more from Tom Moore on life-site and that whole, everything that's involved in life-site. But it's also a cultural thing. And we didn't have that. And of course, nobody who joined our team ever thought, oh, I could be on call 24-7. Yeah, that's a big, big change. So let's flip now to architecture and talk a bit about how is this thing put together? So you heard about the starting point. In the beginning, there was only TFS, and there was only one instance. And it was only in Azure North Central, which is Chicago. That was it. It was a single global instance. We had everything there, verge control, work on tracking, build test, identity, account, of course, things like release management didn't even exist back then, code search, all this stuff didn't exist. But everything that we had was in one place. And what we did is we took, so the application tiers that you see there, that of course you're familiar with TFS, we put those in virtual machines. And we use what is now known as Paz, Platform as a Service VMs 1.0. Web roles for the application tiers, worker roles for the job agents. So it means when we build the product, we literally put together the packages that you need to deploy for Paz, and that's how we do deployments. As I mentioned earlier, we're gonna move to containers. It's still a work in progress. But this is where we started and honestly where we still are in a lot of ways. The content's really interesting. On-prem, we shoved everything into SQL. In the cloud, A, it wasn't possible because the SQL DBs, the maximum size limit was much smaller than it is now. I wanna say it was something like 100 gigabytes at the time. I might be wrong about that, but it was something like that. It was certainly not the 500 gigs to a terabyte that you can get now. But more than that, it was too expensive. I mean, per byte, SQL Azure is way more expensive than Azure Blob Storage. So we had to then farm out the content that's file attachments, the files you have in work item tracking, be it Git repos, be it TFPC, whatever it is. So we had to split all that out into Blob Storage. And you remember earlier, I mentioned with TFS, we had the notion of a framework. And I'm gonna talk about that here in a minute. But that allowed us to start to change how things worked on-prem and in the cloud, and still say sane with the same code base. So we'd put all the metadata in SQL. We'd put all the file content in Blob Storage. But it was still a single tenant system, as I mentioned. Every account, new database. We hadn't gone through that yet. We hadn't pulled out the notion of identity and account. It was literally a true monolith, in one instance. Totally global, every deployment was instantly live for everybody. If anything went wrong, it went wrong for everybody. Not an ideal place to be, to say the least. But we got it started, and this allowed us to start learning. So I'll talk a bit about multiple tenancy. This was one of the first things we had to go solve, or we wouldn't be here, that we'd be too expensive. So, how did we do that? We needed to have many accounts per database. And so in early 2012, we introduced literally a partition ID column in every table that has customer data. And that partition ID says which customer owns that data. And this is important because now we pack, we pack something on the order of 40,000 accounts in a given database today. Versus at the beginning when it was a single tenant. But there's a gotcha here, right? The worst thing is, if I get your data and I give it to him, I failed, right? And if I write his data into your account, I failed. So how do we protect against that? We came up with an interesting way to do that testing. And this is really cool. If you're trying to build a multi-tenant system in SQL, one of the few cases where we can take advantage of the fact that we have both on-prem TFS and VSTS in the cloud. Since the same code runs on-prem, SQL Enterprise has this notion of file groups. And we can assign file groups to the data. So we assign partition ID 0 to a file group that's always offline in testing. Which means if you run a query that doesn't specify the partition ID as part of the clause, the where clause, it's going to fail because the file group's offline. Which meant that we had a great system to go find problems. Because you probably remember, everything was in SQL, right? So all of our logic was in SQL. When we began TFS, SQL is where the data is. So we put a ton of logic into sprocks, stored procedures. And as a result, to really test the product, you've got to test it in SQL. So since we're doing so much logic there, and including now the multi-tenancy, you can imagine how many lines of SQL we had to go inspect to go find, okay, where all the places we need to add the partition ID clause. So having this approach to test it was incredibly valuable. And it kept us from some really, really bad experiences trying to untangle customer data. So, all right, so we fixed the multi-tenancy problem. But we still only have one single global instance. That's bad, bad for a whole bunch of reasons. Two reasons, one is every deployment is global. Two is I have no way to go build more services without adding to the monstrosity that is TFS. I don't want to grow that monolith. I want to be able to build services outside of that monolith. So we had to go split out what we call shared platform services. And this is account, it's identity, it's licensing, it's profile. It's a lot of sort of common services that every service in VSTS is going to need, it's going to need access to them. And we did this on the fly, in production. So we split this out in spring of 2013, while the system was live. And we're literally ripping, essentially the heart out of TFS, pulling it out into a separate service. We did it on a Saturday. If my memory's correct, it was March 23rd, 2013.  But we all get together, we take the system down and we spin up SPS for real, turn it all back on. And then we fix the issues that came out as a result. But again, we started with TFS. We're evolving our architecture in the cloud on the fly. And we're kind of doing heart surgery in the middle of a marathon. So the next thing we need is another instance so that not every deployment is global. And this is when we created TFS SU-0. It's our dog food scale unit. Those of you who've heard of the MSNJ account, that's where it lives. Our whole team lives in SU-0. Every deployment that happens, and Ed will tell you more about how we do deployments through rings. But every deployment we do starts in SU-0. We get every change that goes out. With the goal, of course, being if we screwed something up, we want to feel that pain. We want to fix it before it gets to you. Now, I'd love to say we catch every bug that way. Clearly, you know that we don't. But it's so valuable, it's saved us many, many times. And it's a fantastic practice. And we also have a luxury. We develop a product for engineers, for developers. We are developers. So the fact that we can use our own product is really nice. But every deployment goes out through SU-0 first, MSNJ. That's got, I forget how many people are using it. One stat that might give you some sense of scale. In our repo, which is VSTS, 430 people checked in to VSO over the last 30 days. So those are engineers pushing code. And of course, we've got program managers and so forth. And that's just one repo. We've got a number of other internal accounts that are in SU-0. But our whole principle here is it's only internal accounts. If we do something bad, and sometimes bad things happen, it only affects us. It doesn't affect our customers. So from then, from there, we started adding more. And I put SU-7 up here, which is Australia. But we now have 15 instances of TFS. The latest, of course. Great timing. Yesterday, Brian writes blog post. We've got one in Canada now. Yeah. All right. Good reaction there for me, too. So we're going to continue to add more. But right now, it's a service with the most instances, the most locations around the world. And that allows us to do deployment in rings. It's no longer one shot. Everybody gets it. We deploy to SU-0, then we deploy, and that's ring zero. Then we deploy to ring one, which currently is Brazil. Ring two, which is SU-3, which is down in South Central, et cetera. And Ed will really walk you through how that process works. But it's been critical to changing how we roll out changes. And by the way, that includes not only code changes, but also config changes, because we all know a bad config change can take you down, too. Most recently, we added a second instance of SPS. Until February of this year, SPS was purely global. And we finally added a second instance. We call it SU-0, because it's paired up with TFS SU-0 and the SU-0s for the other services. And that allows us, for the first time, to start deploying changes for SPS non-globally. We have a whole effort underway to be able to partition SPS itself into multiple instances around the world. That works ongoing. Hopefully, if I were talking to you a year from now, I'd be telling you how we did it and how it's turned out. But we're in the midst of that. So talking through that split, we got SPS pulled out. That then enabled us, and I'm going to fast forward in time quite a bit here, we have now 31 services. And they all kind of revolve mostly around SPS. Some, of course, have dependencies on TFS. Code search doesn't have anything to index if you don't have code and so forth. But we have all these services that can build out on the foundation that SPS created and therefore not contribute to building a giant monolith. And this was an important thing for us. Taking a small deep dive here into what exactly it looks like to have an instance of any service, be it TFS, be it SPS, code search, RM, any of them, they basically look, they're all like this. The only question is, how scaled out are they? So a typical scale unit might be four DV2 instances of, again, a PAS web role. Job agents, let's say three instances of a DV2 VM. And by the way, I don't think I explained exactly what the ATs and JAs do earlier. So an application tier is responsible for all the communication with clients.  So it's got the REST endpoints, the SOAP endpoints, which obviously we're not writing new SOAP APIs, but there's still quite a few that exist as we go through the transition to get to REST. But that's the public face, if you will, of the service. The job agents run background jobs. And these, of course, that functionality exists in TFS. They're just not deployed as separate machines on-prem. But that runs background jobs. It could be processing commits. It could be doing any number of things. It could be doing cleanup. But they're background jobs. And that's what it does. So our largest scale unit in TFS has about 11 D4ATs, 32 partition DBs, with about 40,000 accounts per DB. And so, yes, it's about 1.3 million accounts in SU1. These days, we don't let the scale units get quite so big. We tend to cut them off at 7,800,000 instead. And then we've got about 120 terabytes in blob storage in just that one scale unit. So there's a lot of data in that scale unit. But that gives you a sense of scale for at least the largest one. So the next piece, I'll give you some stats here to kind of give you a sense of the service overall. As I mentioned before, we have 31 services in VSTS today. We're in 15 regions total. And like I said, TFS is the one that has the most. It has 15 regions. Not all the rest do. We have 192 scale units total. If you add up all these 31 services, all the scale units associated with them, I guess I was wrong. I said 15 for TFS. It's actually 17. My bad. In terms of cores, we have about 7,000 cores, CPU cores, used in VSTS. If you kind of look at production all up. TFS itself adds up to around 1110. We have 659 SQL Azure databases. Of those, 426 are standard, 233 are premium to give us, again, a sense of how much we use SQL. We use it a lot. And that adds up to about 63 terabytes of databases, just metadata. That's not file content. There's a nice bill there. Yeah, it's not cheap. This is not inexpensive, which is why. And you'll hear about this also. I think somebody's going to talk about it. It's why we focus on the cost of running the service. Every account, you get five free users. We run a service that's mostly free. Therefore, cost matters a lot. Question? So are the PaaS databases scaled up automatically, or is this a manual process? So today it is a manual process. So we literally run a report that looks at the load on the databases. We have metrics to ensure they're healthy. If they trend above the line, then we go and scale them up. If for some reason they come down, they need to be smaller, we'll bring them down. Usually the ones that come down are, let's say, from a data import or something like that. Typically a database that, once the load grows, the load doesn't suddenly shrink. It would only be if we moved an account out of that database or something that would cause it to shrink. But today, it's still manual. It's something actually that hopefully the next several sprints will actually start to get automated. And of course you have to be a little careful, right? Going up is reasonably safe. Going down can be dangerous. So you need to make sure you've got good safeguards in place. Well, thank you. You're welcome. Question? Is there a dependency or a cost factor that keeps you on virtual machines rather than choosing ad services for those backend jobs? So for the backend jobs, you talking about the job agent? Right, why do you have to be on VMs? Can you get away from VMs? So good question. So today they are virtual machines. We're gonna move to containers. I don't think that really addresses what you're getting after, which could we use a different Azure technology for it? We could. One of the interesting challenges we have is we ship TFS and VSTS. So we ship an on-prem product and VSTS in the cloud. We try to keep the code base the same. And so if we run it very differently in the cloud, it makes it harder for us to test the on-prem product and know that we have the right quality when we ship the on-prem product. And which by the way, is becoming a bigger and bigger challenge because as you saw in Aaron's presentation, most Microsoft is on VSTS, right? And it's only getting more and more so. Another year, 18 months or whatever, all the instances of TFS on-prem, which at one point were 71, 76 instances of TFS internal to Microsoft, something like that, they had heavy use. They don't have so much heavy use anymore. Some of them like DevDiv's still there, but people only use it for patching the legacy products. So part of it is the constraint of shipping an on-prem product and wanting to keep the code the same. In an ideal world where we're simply cloud only, we would take advantage of be it Azure Functions or whatever. I'd love to take more advantage of that, but right now I've just got to keep a good balance between my ability to use the service to test the code and being able to take advantage of sort of cloud-native technologies. Yes? So how did you understand the relationship with the rings and the instances? Okay, so Ed Glass is gonna go through that in detail, but basically what we do is we take the instances and we map those to rings. So ring zero's got one instance, ring one has one instance, ring two has two instances in it, ring three has four I think, and then ring four has about five or six. That probably doesn't add up quite to the right number, but roughly speaking that's the way it works so that every time we go to a new ring we're actually getting a much bigger audience. So if there's a problem, we wanna find a course in an earlier ring. The fact is few people as we can limit the so-called blast radius of a problem. So that's the whole goal of the rings and he'll go through it in a lot of detail. And I already mentioned, we've got 1.3 million accounts in scale unit one. So I touched on this in answering the question earlier, but I call it 90% the same code base. It might be more than that. It might be 95 or 97%, but it's basically the same code. I mentioned earlier the server framework and I'm gonna talk a little bit more about that in detail, but the server framework is, it was originally part of TFS like so many other things. This is what allows us to write a bunch of different services and have them all work the same way and we'll talk about what that means. That enables though a key piece here, which is that we can write plugins that allow us to abstract away some of the differences. So for example, authentication and identity, completely different in the cloud, right? Microsoft accounts, AAD with org ID, these don't exist on prem. So we've got plugins for the identity system and if it's running in TFS, it's using one plugin. If it's running in the cloud, it's using a different one. And when it comes to shipping TFS, it's those differences where we have to focus most on testing to make sure that, hey, we're not getting mileage on this in the cloud. Do we have it right in TFS? Storage, I mentioned that before, we split out storage between SQL and blob storage in the cloud, it all goes into SQL on prem by having a common server framework with plugins. We can then, you can go write a service like search for example or whatever and you don't have to think about how to store your data. We take care of it. You specify what kind of data is it, is it metadata, is it file data? And then the underlying framework takes care of the details for you. So the server framework that I mentioned before, we call it VSSF, Visual Studio Server Framework or Visual Studio Shared Services Framework. And again, we extracted this from TFS. It's common to all the services that we've implemented. And it was interesting, last night I was having a conversation with Tom Moore, who you'll hear more from tomorrow on to live site and telemetry. And he said, you know, we really don't fully appreciate how valuable that framework is. He said, I used to work on, cause he runs a service delivery team. He said, I used to run another service at Microsoft. It was a set of services. And he said, every service was different. So when it came to managing secrets, they were all different. When it came to deployment, they each had their own special way to deploy. He said, everything was different. And we just spent so much energy and lost so much time on that diversity of ways of doing fundamentally the same conceptual thing. But in reality, of course, it was all done in a different way. And this allows us to get some economies to scale. We have a few teams that work on the framework and everybody else in the organization is able to build on that and not have to go reinvent that wheel. So key examples, well, I'll give you some key examples here in a minute, but it forms this abstraction layer that allows us to have this consistency between the two models. And again, across the whole set of services, 31 services, all running the same way. And from an engineering standpoint, I don't have to go fund developing the same thing over and over again. And this sort of operational consistency, not only does it save us money, cause we're not having to have the same, different engineers go do the same thing, but from an operational standpoint, it means there are fewer opportunities to get things wrong. It also means that different people can go work on different parts of the service. Tom told me, he said, and the other problem they had with this set of services is when somebody changed teams, they had to go relearn how to do stuff on that service. When his folks, his service delivery team, if they wanted to go work on or needed to support different services, let's say somebody's out on vacation or whatever, he said, it's much harder because again, it's different for each one. So this consistency has been extremely valuable to us. So what's in this framework? And I'm not gonna go through all these things, but it's a long list. And this is just scratching the service. But a couple of the key ones, I've already called SQL and Storage out as being key. Another key piece here that I'll talk about later is secrets, handling secrets. We'll talk a little bit about that in the security presentation. Tracing is common for all of these services, which means that everybody understands exactly how the telemetry is gonna flow through the system. And we get resiliency. Circuit breakers and throttling are built into the framework. Every service can go adopt those without having to rebuild them. And they're not simple. And you'll see with throttling, for example, surprisingly complex. So taking a brief moment here to talk about telemetry in particular, because this was a big mindset shift. We were an on-prem team. The notion of telemetry was a foreign concept to us, because we sell you the software, you go run it. We don't get to go grab telemetry from your server. So many of these servers, of course, they don't allow all that stuff to come back up into the cloud. So this was a different thing for the team. It was also different in terms of debugging.  Hey, there's a problem. Ah, can we go reproduce it locally? Well, when you run a cloud service, if your customers are suffering, nobody wants to wait for you to get a repro live in some debugging environment where you can step through breakpoints and figure it out. You really have to change to think about, can I debug the service from the output of the telemetry that the service produces? So it became this mantra of trace everything. And as Tom will tell you about, that's both in good and bad, because at some point you can drown in your telemetry. And he'll talk a bit about how we deal with that.  We wanna trace all those. We wanna also look at cache behavior. So I'll take a smaller side on caches. You probably all know what a cache is, but I have a different definition of a cache. A cache is a live site incident generator. So if you look back over the last six years, so we stood up the service reel in April 23rd, 2011. So in the last six and a half years, if you look back across all the live site incidents we've had, the single biggest thing in common is caches. And we've hit all manner of bugs. Inconsistency, strange behaviors, you name it, it's happened. And every time somebody says, hey, I got a problem, be it performance or whatever, typically performance, I'm gonna go out of cache. I'm like, great, you now have two problems. So having this cache behavior in telemetry is incredibly key. It's also, by the way, there's a cache class in the Visual Studio framework. We had so many problems with it, we said, hey, look, let's at least build a foundational cache component that has the core telemetry in it about eviction rates, about the hit success rates, et cetera, so that you can at least get some core basic information about every cache that we put in the system. But it's incredibly important. And caching is so, so subtle, so seductive, right? I'm gonna go solve the problem, I'm gonna add a cache, it'll be way faster. Cache fails, you turn it off, you got a different performance problem now because the system doesn't actually work anymore without the cache. Caches, I can't emphasize it enough, they're really dangerous. You need them, you can't live without them. They are super dangerous.  Inputs are really key. So this notion of trace everything really was a big switch for us. The next piece is you need to be able to control this, right? Cause you, some tracing's expensive. You wanna trace some set of things, but it's this large object or it's something you wanna compute cause you don't actually wanna trace the raw thing for whatever reason. Sometimes it's expensive, so you need to be able to control it. So we got four different levels, error through verbose that can be turned on individually, errors on all the time by default. And in order to control these things in tracing, we have this notion of trace points. And they're literally just lovely numbers like this. They don't have meaning, but you go, you're having a life-side incident. There's something going on, let's say, for identity. They go look up and go, I need this trace point cause I wanna see what's happened with this descriptor for security.  This one, of course, is at trace level info, so you may have multiple uses of this particular trace point with increasing levels of verbosity. And as you dig into the problem, you can decide how much data do you need in order to solve this problem. But this has been hugely valuable. We also have variants of this where we, in fact, conditionalize it so we don't do the extra work for tracing if the tracing's not turned on. But this is, again, a big shift in mindset for a team that's used to box product software, on-prem software. I mentioned we have a ton of logic in SQL. We have something on the order of over 1400 stored procedures. It's a lot of SQL. As a result, you need some way to explain to people how should you write SQL? How should you write SQL that works on-prem, in the cloud? How do you get consistency across the product for a variety of reasons? So here are some of the key principles in our SQL guidelines. And I won't go through all of them, but the first one is particularly interesting. The cloud and the on-prem product have different characteristics. There's no notion of an account on-prem. It's in the code, but it's effectively hidden from you. When you do an upgrade in the cloud, you're upgrading, I mentioned earlier, 40,000 tenets in a single database. That means 40,000 collections in a single database. You need to have your upgrade scale. So thinking about these things up front become very, very key. So in the SQL guidelines, it talks about all the sorts of stuff. It talks about even at the bottom of my list here, partition ID for partition for different tenets. There's a set of things that we want people to follow. There's a long list. It's actually something that I even asked, hey, do you think we could publish this? We may at some point publish it. Because I think there's some real value there. But so much of it comes back to the consistency. Doing things the same way so that every time somebody has to go look at, let's say, a life-side incident, they don't have to figure out, oh, well, this team does SQL completely differently than we do. What does that mean? It's not a good time to learn that in an emergency. Sorry, but just before you go on there, with so much logic in stored prox, how do you guys test that? So, good question. A lot of testing is, so we're trying to decide how deep to go into that answer. So, Manil Shah, this afternoon, is gonna go through quality and testing in general. We have different levels of testing. Everything from what you might call a pure unit test, though we give it a really boring name to avoid religious debates on what a unit test is. Call it L0s through L3. And so there's a level that he'll talk about called L2s where you can test through REST APIs. But since we have so much logic in SQL, we said, hey, we actually need the ability to test some of these SQL stored procedures as quote unit tests. I mean, and it's kind of a stretch, right, for some people to think of that as a unit test, but level one is like level zero, except it allows you to use SQL. So, we have SQL specific tests. We also have tests that drive the SQL because you're calling REST APIs and so forth. So, I'll leave that question really for his presentation, but it is an important thing for us. So, REST APIs, I mentioned earlier, when TFS began, and I was writing code on TFS back then, we were doing SOAP APIs, and SOAP was cool in 2003. It's 2017, SOAP is very uncool. So, we started the shift a few years back over to REST. One of the things we did with the SOAP APIs, which we can debate whether or not it was a good idea or not, but we said SOAP APIs are effectively an internal implementation detail. You're not meant to use them. Go use our .NET object model. Fast forward, the world's shifted. People want to call these things from, you know, Macs and Linux and everything else in the world. The best way to do that, of course, is with REST APIs. Everybody moved over to REST APIs. So, the REST APIs, unlike SOAP, are very much a part of our public face. We build a platform. You need to be able to call the REST APIs to be able to write extensions that do any number of things, other services that call into VSTS. Having been part of the problem with SOAP APIs, if you go look at our SOAP APIs, you can tell, looking at it, that each one was done by a different team. It's very clear that the version control team and the WIT team, the workout and tracking team, did not agree on how to do SOAP because they are completely different APIs and how they work, it's just crazy. And you look at this and go, did they ever talk to each other? Well, I helped create the problem, so I can poke at it. With REST, I said, and I don't do this often. I don't often put in review processes because in an agile world, in DevOps, if you own a service, why should you need to go to some manager to get something approved? I put in place a review process for REST APIs because the only way you get consistent APIs is that you force that consistency. Left to their own devices, every developer, quote, has a better way. And the problem is, it might be better, it might not, but if you as a developer have to go relearn a REST API every time you go crack it open, super frustrating. So, I'm not part of the REST API review process, I have people who know REST really well who do it, but this has been a key part to try to give you a set of APIs that look like they're from a single team and not from a bunch of competing teams or whatever. Now, you can certainly find places where we've not succeeded at that, but overall, it's been vastly better. We also didn't invent our own standards. There's a set of Microsoft REST API standards and the notes for the slide, you can find the link to it. You can Google it if you like. But the Microsoft REST API standards were derived from the Azure REST API standards and Office REST standards. They each had their own. So they got together and created one single standard. We use that, but there are parts in it that are optional or there might be two choices of how to do it, in part because it came together from Azure and Office. They didn't necessarily, let's say, fully agree on everything. So we get a little more concrete about some of it. So when I say it's our standard, it's the Microsoft standard with some concrete parts where it's optional. And we documented this and the whole process on our Wiki. And this is important. So these APIs can be reviewed through email if they're simple and there's no, I mean, the committee looks at it if there's no big discussion, great. Respond and email, you're kind of done. You might be breaking new ground. Maybe you're trying to do something totally different. You're struggling with resources and verbs and how to map things to your area. Great, have a meeting, go through it. But this process has been really valuable for us to generate an API, to create an API that's much more usable and more consistent.


Okay, hello everybody, this is SiliconANGLE, Wikibon's theCUBE, this is our flagship program. We go out to the advanced extract, they signal from the noise. I'm John Furrier, the founder of SiliconANGLE, join my co-host, Dave Vellante. Again here, he's the co-founder of Wikibon.org, free research. We are here live in Las Vegas for Amazon, web services, AWS re-invent conference. I'm super excited to be here, Dave, because this is really the beginning of a revolution. An extension of Amazon web services, cloud, public cloud efforts, which in the developer community is widely known and recognized as helping startups get off the ground. But what we're seeing now is a transfer to Amazon, to the enterprise, a hybrid cloud, a word that's not being used much here, and I have a story for that later on that, but hybrid IT, whatever you want to call it, Amazon is changing the game on infrastructure. Obviously, they're in the class of darlings of Google, Facebook, Amazon. I mean, you got a search engine that builds a data center, and you got a book retailer that builds one of the most impressive infrastructures of all time. If you went back to 1996 and said the future of computing was going to be a book retailer and a search engine, you probably would have said you're high as a kite, what are you smoking crack?  So let's kick this off with a quick analysis for the folks out there. Your take of the current state of the industry, Amazon's position in it, these are being compared to the other leaders like IBM who's been in the computing business for many decades, and kind of what's happening here in Las Vegas. Well John, as you know, this is our first year at Reinvent. We were watching last year, we did not have theCUBE here last year, we did the AWS summit in June in Moscone, and essentially what we've been talking about for the last six to nine months is Amazon has completely changed the game, they've turned the data center into an API, and last year at Reinvent was really Amazon's coming out party for the enterprise, they essentially really drove hard, focused on bringing in enterprise customers. Obviously Amazon has done a great job with developers, and if you think through the various phases of cloud, John, when Amazon launched AWS in 2006, obviously very developer friendly. In 2008 and 2009 we said the economic downturn accelerated the move to the cloud by at least 18, maybe 24 months. Coming out of the downturn, we saw huge amounts of shadow IT going on within marketing organizations and lines of business, and we're now seeing the CIO crowd really get on board, figuring it out that their future is really as cloud brokers, and they want to make Amazon another arrow in the quiver of their opportunities to offer services and transform their organizations. So I expect John this week to hear more about pushing into the enterprise, more case studies. You're going to hear the typical Netflix and NASDAQ and other main companies and customers of Amazon, but I think the other thing you're going to hear is new services that really appeal to the enterprise customer, and we're going to be here covering it wall to wall. Okay, one of the things that's really exciting is one, this show has only 8,000 people, some early tweets by some of the folks here at Amazon and customers, 8,000 people here. Let's compare that to say Dreamforce, an older cloud company, salesforce.com, really the pioneer of cloud computing, kind of this modern era, is the old shoe now. Salesforce, the Scuttlebot is that they're currently rewriting code, patch working their cloud together, some acquisitions that might have done well, not so well, but what Amazon represents is the future of one, application developers, two, extending this consumerization IT trend, meaning Amazon's success with developers is so big and so massive, I don't think it's going to be hard for anyone, I think it's going to be very hard for people to come up and catch up to them, and where this is going is the data center, in the enterprise, you're going to see a massive shift to computing where these quote substations of data centers will move into the cloud at large scale, where computing resource will be ultimately infinite, to power things like Google Glass, internet of things, mobile devices, applications. So what you're seeing is a total intersection and collision between the consumer world and enterprises. Now personally, I think Amazon's a little bit wet on this idea that the data center is going to be obsolete, I still think they're going to see data center, if anything, I think it's going to change the game and highlight the value of the data center, but one thing is for certain Dave, software is a hard of the value proposition and the guys that are driving the software bus are developers, and I believe that you're going to see a lot of moves by other big players, IBM, HP, EMC's new company, Pivotal launched some stuff today, again, they're way behind the game on the developer front. They being, they being IBM, HP and Pivotal, Pivotal specifically, because they're the youngest, kind of, I mean, right out of the womb, not sure they'll grow into the right player, but HP and IBM are also there, so they're way behind on Amazon on the developer front. Where Amazon's behind is what I would call the hybrid opportunity in the cloud. They're behind on software defined data center, vision, they're behind on essentially what people already have in their enterprises, so full agreements, power and cooling, these are still huge issues and the Amazon, I don't think is going to get there in the near term, however, they're moving very, very fast. What's your take? Well, first of all, you're right. I mean, Amazon's betting that very few companies in the future are going to run their own data centers. I mean, that's a fundamental assumption that this company's making. Now, the second point, 8,000 people here are much smaller than some of the other conferences, but it's actually much larger than some of the other conferences. It's about the same size as HP Discover, you know, a much more mature company, and it's probably about four times larger than it was last year. Here's the thing, Amazon AWS is going to do about, we estimate at Wikibon about $4 billion this year in revenue. Amazon doesn't break out their revenue, but if you squint through the numbers and you look at the other category, it's growing very, very fast. And we think that Amazon will do $4 billion this year. The bigger piece of this is Amazon is going after a $1 billion TAM. You and I heard that when we had our one-on-one with Andy Jassy, we went deep with him. $1 billion TAM, John, growing very, very fast. Amazon is the disruptor, and did the gorilla in the marketplace. We've seen that they've got three quarters of the space. You want to say something? Yeah, no, I want to interrupt you because I think the gorilla position is key, and I want to ask you, we were just in the analyst briefing. I want to get your take on this. They are the gorilla in the public cloud. No doubt about it. We had a debate on theCUBE. We had a debate on our crowd chat with Randy Bias of Cloud Scaling. OpenStack is fast coming up the track. We had a crowd chat this morning. Go to crowdchat.net slash reinvent, where the debate was simply centered around one premise. The iPhone model versus Android, they used a mobile metaphor. Is Amazon the iPhone of the cloud? And is OpenStack Android, meaning Amazon's success is so big with developers. If they can keep an open marketplace of applications, some will argue that that closed lock-in that everyone's throwing around, actually is what people want. They don't mind if it's open. So that means that Amazon would be the iPhone Apple model, and OpenStack, the open would be like Android. Both different approaches, different ecosystems. So that debate was out there. Yeah, so let's define open, right? So what does open mean? So you take OpenStack, right? The vision of OpenStack is all these clouds will be interoperable. Maybe so, although there's a lot of propriety built in to potentially some of those OpenStack clouds. But if OpenStack certifies various clouds, that interoperability could happen. My question is, John, does that matter, right? Now, Amazon, I think you're right, is essentially the iPhone of the enterprise. It's got an open interface, right? It's transparent about how to write to the API. I mean, it publishes that specification, right? And so, in a sense, it's open. You talk to developers, they absolutely love it. I mean, the openness is, to me, lock-in means one thing, no agility to move. Move your data, move, what happens if you want to move your workload out of the vendor? But to me, Apple is a lock-in. I mean, iTunes. That's so is Amazon, but so, yeah.  People like it. The product is good, it's functional, and the applications are open. Meaning, they're available on the platform. Let's talk about lock-in for a second. There's always been lock-in in this business. You have to have lock-in to make money. You know who doesn't have lock-in? It's canonical. That's why they're not making any money. But they're disrupting. So open source, you know, this whole lock-in discussion, you've got to have lock-in to make money, period. So does Amazon have a lock-in? Yes, does VMware have lock-in? Yes, Joe Tucci stands up and says, we will not lock you in. Well, the fact is, there's always got to be some degree of lock-in, some moat, as it's called. So here's the thing that I brought up in the analyst meeting that not many people would get, maybe some of the Amazon guys would. I asked a specific question to the customer panel that was the success stories. I asked a hard question. Are you mindful of the software stack that Amazon has? Meaning, if you're an app builder, the beautiful thing about DevOps is that you push code, it trickles down into the integrated stack and everything gets updated. But here's the issue. If Amazon is controlling the upgrades, let's use Node.js as an example. If you've got a Node.js implementation and you're running an Amazon application and you want to push that through the stack, you've got to assume that Amazon has updated the latest code of Node. So as a developer, you've got to have a real visibility into levels of version control, those kinds of things, at least from where the bugs are coming from. So if you're pushing the envelope on application developers, you've got to have the integrated stack. It is a benefit, but it also can be a double-edged sword. So one of the things that Enterprise has got to be careful of is that double-edged sword. Making sure that the software stack is integrated and Amazon is moving fast enough on the versions of the software, not the hardware. They got that nailed down. The infrastructure as a service is kick-ass. No doubt about it, Amazon's market share is about 36% in infrastructure as a service. That leaves about 64 to 70% give or take your argument of between 29 other players on the cloud. They're dominating the infrastructure as a service. It's the platform that becomes the question. In platform, you got to have software version control. That's what we're going to be watching very closely. And depending on how you find it, it could be a lot higher. If you just go pure infrastructure as a service, I would say its market share is closer to 70%. But again, it depends what you throw in there. Now again, as I said, the theme that we're talking about all week is Amazon and the Enterprise. The other thing we're going to talk about this week is the government cloud, the whole CIA deal that went down. On November 8th, Judge Wheeler published his opinion on the whole IBM, Amazon, CIA, GAO, Brujaha. So we're going to be unpacking that. We've read through that documentation. People at SiliconANGLE and Wikibon have parsed that. We got a lot of good information that we'll be talking about a week. The bottom line of that is essentially the judge ruled that Amazon had a superior offering. Now remember, this is pre-soft layer. This one all went down. So IBM has thrown down the gauntlet. They know how to play this game. So we're going to be talking about that all week amongst ourselves with customers, with partners, with analysts. We're here. So we're going to be back live. We're going to take a break, but we're going to have two days of wall-to-wall coverage. This is kickoff day one, and we're going to bring on some new guests. And we're going to break down tonight. Really talk about the analysis. We're going to bring on some key partners here. We're going to also talk to some other analysts. We're going to talk about some real success stories here early on. And then tomorrow it's all full day. Full day Wednesday and Thursday here live, SiliconANGLE.com. And remember, go to crowdchat.net. We're going to be having tomorrow all day crowd chats. That's a group chat on Twitter. New feature, great feature on top of Twitter and LinkedIn. Sign in, be part of the conversation. We are going to extend theCUBE to the social networks. Go to crowdchat.net slash reinvent. Go to SiliconANGLE.tv for coverage. SiliconANGLE.com for blogging. You can go to wikibon.org for the free research. We'll be right back with our first guest here at Amazon Reinvent live in Las Vegas after the short break.


So now we come to the implementation strategy of the 11th 5 year plan as far as the gender equality and women empowerment and development is concerned. As usual there are lots of nice words and intentions and targets but implementation as we will see later is rare. So if you look at this table it looks at gives us the policy intervention, it gives us the outcome or output, it gives us indicators, major institutions responsible and targets. The first target was education for all girls. The outcome was reduced gender gap, the indicators was number of girls and boys enrolled in primary and secondary schools. The major institution responsible was the ministry of education at the federal level and the provincial education department and the target was at the primary level 1 meaning thereby all the gender parity achieved and at the secondary level almost gender parity meaning thereby for every 100 boys there were 95 girls in the secondary school. The second was target or policy intervention was behavioral change and awareness about discrimination against women. The major institutions was the ministry of law, justice and human rights and provincial welfare and women departments, the indicators were the number of incidents of violence, abuse and discrimination against women. And the target was that more than 70% of the population will be sensitized on gender based issues. The next was education and research and gender studies. The major institutions responsible for this change was the ministry of education and training at the federal level, the higher education commission and the provincial education department. The target was 80 gender and women's studies departments and centers to be established both in private and public universities with the help of HEC. The next target was centers and institutions for survivors of violence and women in distress with 24 hours helpline. The major institutions dealing or responsible for achieving this target was the ministry of law, justice and human rights, provincial social welfare departments and provincial women departments. It was agreed that by the end of this 11th five year plan, 225 centers will be established at the district and at the sea level with NGOs and CSOs which will help the survivors of violence and women in distress. The next target was to bring IT or information management systems to the gender areas. The main problem or issue to be dealt with was to come up with gender disaggregated data. So we have data available with the government but we don't know how many men or women have benefit. So the idea is to establish data centers or data or MIS management information systems which give us separate data so we know how many men and how many women are benefiting from different development schemes and programs and other areas or objectives of the government. So the major implementing agency in this area was Ministry of Labor, Justice and Human Rights, provincial social welfare departments and women development departments. And the idea was that at the federal level and all the four promises MIS or management information systems will be established and fully functional by 2018. The next objective was gender impact assessment. So okay we have gender data but how it will be used. So it will be used to come up with gender sensitized public policies, plans and projects and planning commission and P&D departments in provinces will help that. In case of skill development programs more than 2,500 lady industrial homes and other centers were established at the union council level. And another area was the establishment of 225 daycare centers in the cities and towns all over Pakistan. The major area which looked at the major agency to implement this was the capital and development department and provincial welfare department. And lastly removal of discriminatory laws and the major implementing agency in this case was the labor justice and human rights agency, national commission of human social rights and provincial law and provincial women departments. And it had to look at all the existing laws and review whether they are discriminatory to women or not and then propose laws which are better or less discriminatory against women. So if you look at 20 VR in 2019 the program the plan has ended not much work is done most of the targets were not achieved so that is the solution now as far as gender equality is concerned.


Hi, Adam here from Spotlight English. Before today's program, I want to tell you about YouTube memberships. When you click that little Join button, you get extra programs, behind-the-scenes videos, you can request scripts of programs, and we will thank you in Spotlight Programs. So, click the button, join the community, and take your English practice to the next level. Now, let's get on to the program. Welcome to Spotlight. I'm Liz Wade. And I'm Colin Lover. Spotlight uses a special English method of broadcasting. It is easier for people to understand, no matter where in the world they live. Paris, France In April 2017, a man invaded the home of Sarah Halimi. He called her hateful names and attacked her. He threw her from a window. She died after this attack. The man wanted to hurt Halimi because she was Jewish. In January 2018, an eight-year-old boy was attacked while walking to tutoring. He was wearing a kind of Jewish hat. In recent years, many Jews like Sarah Halimi and this eight-year-old boy in France have been hurt because of who they are. French government officials say that anti-Jewish beliefs are spreading like poison there. More and more Jewish people in France are reporting experiencing crime or hateful speech because of who they are. Crimes done against people because of who they are are hate crimes. President Emmanuel Macron of France responded to these and other hate crimes. He said, every time a citizen is attacked because of their age, their appearance, or their religion, it is an attack on the whole country. Why do hate crimes like these happen? How can France and other countries deal with them? Today's Spotlight Program is the fifth in a series of ten programs. In this series of programs, we will look at ten ways to fight hate.  So the Southern Poverty Law Centre, SPLC, has made this list of ten ways to fight hate in your community. On today's Spotlight Program, we will look at the fifth way to fight hate in your community. Educate yourself. How can a community understand people who do hate crimes? How can they react to such violence and hate? The SPLC says that researching the facts about hate groups and hate crimes can be one answer. They call this educating yourself. When people have the facts about a hate group, they can fight hate. Communities must know about hate groups and hate crime before they can react to them and stop them. But knowledge can also help people stop hating. Hate usually comes from fear and understanding can defeat fear. A hate crime often starts with a bias. A bias is an opinion about someone who is different from you. A person often makes a bias because he does not understand people from another group. Often we do not know people who belong to different religious or racial groups than ourselves. If we have never met someone from that group, we can easily form wrong opinions about them. These biases might be negative. Sometimes they encourage prejudices and hate. Every person has biases. Often people do not even know their own biases. But they express biases in many forms. A person can express his bias in words or actions. The SPLC calls some incidents bias incidents. For example, a racial joke is a bias incident. Bias incidents do not involve criminal acts like beatings, starting fires or damaging property. Hate groups try to use and encourage the biases people already feel. In fact, hate groups are usually very skilled at spreading their biases. They use propaganda. Propaganda is bias information that people use to spread a particular message. These hateful messages can appear as a painting on the side of a building, on a paper hanging in a local store, or even sometimes on television or the radio. Hate propaganda influences how people think of each other. It tries to represent groups of people as less than human. Slowly, members of a community begin to think that a particular group of people is not important or is harmful. Angry, scared individuals may attack the minority group. These criminals believe that their actions are accepted. They may even believe that they are doing good work. The SPLC says that most hate crimes are not committed by hate groups. They are committed by individuals, alone or in small groups. These individuals have listened to hate propaganda. They let their biases influence bad actions.  Any criminal act done against someone because of a bias is a hate crime.  It is a hate crime. Many areas punish hate crimes severely. But how do we stop hate crimes from happening? First, it is important to try and understand your own biases. What do you know about people who are different to you? The first step is to learn about people who are different to you. Try to understand them. Learn about them. When we understand and listen to each other, we learn to accept our differences. Continue investigating your own biases. Second, if you observe or experience a hate crime, try to find out if a hate group was involved. You can also research facts about the particular hate group you are trying to stop. What does the group want? What signs or symbols represent the group? Experts say that members of hate groups often want to divide communities. They want to separate a community into racial, ethnic or religious groups. They may want to give particular groups in the community limited rights. Many do not respect or recognize the authority of the government. And they try to harm people who oppose them and their ideas. When you know about the hate groups in your area, you are more prepared to fight against the hate they represent. If you have children, talk to them about how they should react to hate. Share information you have learned with your community. Information and education are powerful. When people have the facts, they can make better decisions. When people learn about other cultures, they do not feel threatened by them. Education helps people to understand the world and other people better. Hate and hate crimes cannot continue. Whole communities must join the fight against hate. We can all encourage tolerance and acceptance in our communities. This is the fifth programme in a series of ten programmes on ten ways to fight hate. This list is from the Southern Poverty Law Centre. The Southern Poverty Law Centre is a website that tracks and reports on hate groups, especially in the Southern United States. Here are their ten ways to fight hate. Educate yourself. Create an alternative. Pressure leaders. Stay engaged. Teach acceptance. And dig deeper. Keep listening to Spotlight to hear the complete series. You can leave a comment on our website or email us at contact at spotlightenglish.com. You can also find us on YouTube, Facebook, Instagram and Twitter. The writers of this programme were Liz Wade and Amelia Bergland. The voices you heard were from the United States and the United Kingdom. All quotes were adapted for this programme and voiced by Spotlight. You can listen to this programme again and read it on the internet at www.spotlightenglish.com. This programme is called Ten Ways to Fight Hate, Educate Yourself. Visit our website to download our free official app for Android and Apple devices. We hope you can join us again for the next Spotlight programme. Goodbye.


So if you're hunting with a group of friends or possibly some new guys that you haven't hunted with, try to make one guy the captain. So he would be basically doing all the calling so you're not calling on top of each other. He's going to start first, and if you want to blow your duck call, you'd basically start basically in the middle of his cadence. Okay? So what you don't want is guys basically running right on top of each other. It doesn't sound very realistic. If you're having a problem with it, I would suggest kind of huddling everyone together and say, hey, we got to come up with a game plan or you call out a group of ducks, the next group comes, I'm going to call out a group of ducks. So you don't want everyone calling in the blind and scaring birds away from you.


Good morning everyone. My name is Nisha. I'm part of the MySQL team for over 7 years now. And today I'll be discussing about upgrading to A.dobe and how we have tried to make it an automated experience. A moment for the safe harbor statement. In this session I plan to complete, first discuss about the importance of upgrade and what are the upgrade options that is available for the users and how a straightforward upgrade to A.dobe would look like. And then get into the details of the process of upgrading to A.dobe and also I will discuss how we have tried to improve the upgrade experience overall in A.dobe. So why do we have to upgrade our MySQL installations? Generally the newer releases address some of the security concerns reported and also the major releases do come with a major performance improvement as well as the scalability. And yeah, the major releases again has a host of new functionality. And also it is important to reduce the technical debt that occurs with your MySQL installation. Consider you are on 5.6 now and you have to upgrade to A.dobe. The general guidelines is that you have to upgrade to 5.7 and then to A.dobe. Now you would have a lot of deprecated functionality within 5.7 which are then removed in A.dobe. This would mean complex upgrade procedure for you to get on to A.dobe. So why are the upgrades generally postponed? The users, the general apprehensions that the users have is do they have the sufficient knowledge in order to do the upgrade? Or do we have enough resources who can contribute to the upgrade? And of course the time taken and the cost incurred is in two cases. One is the cost incurred for the DBAs and consultants who will be doing the upgrade and as well as the cost for the lost business during the downtime when you do a switchover. At some point in time you do have to upgrade and the general input from the DBA is that they have to reduce the risk and the cost involved during the upgrade and also the total duration for the upgrade should be short. And for the customer application it is important to retain the older or my still behavior and then slowly go towards the newer behavior. And yeah, they do want to test the new version gradually and when switching the downtime it should be minimal. So what are the upgrade options available? There are two options. You can either do a dump upgrade or you can do an inflate upgrade. In case of dump upgrade the difficult thing would be to back up your data directory and then you dump the data from the existing MySQL dump using the MySQL dump utility and load the particular dump file using the newer instance of the MySQL and then subsequently run the MySQL upgrade. In case you do not want the system schema and you are interested only in the user schema you will back up your data directory. Dump only the user schema again using the MySQL dump utility and load this particular dump file using the newer MySQL instance and then run the MySQL upgrade. The other option available is the inflate upgrade where you again back up your data directory stop your old MySQL instance and then you change the binaries to the newer MySQL version you will have to adjust your config file to set the correct defaults and then you start your new MySQL server on the old data directory and run the MySQL upgrade. So inflate upgrade versus a dump upgrade what is recommended is the inflate upgrade. Why? Because inflate is generally faster than the dump upgrade and in case of dump upgrade as I mentioned previously you do have deputations and rules and there are chances there are certain syntaxes to turn on in case that you will have to go in and modify a dump file for you actually it will come to a newer MySQL instance in order to avoid that it is better to go ahead with the inflate upgrade. In the straightforward case you would have backed up your data directory and then started a newer MySQL instance on the old data directory you would run your MySQL upgrade and chase all your system tables and the user tables and generally it should be through the target issues and you restart your server, look at the messages and as you see there are no errors and then check if your apps and services are working fine. Prior to 5.7 the metadata was spread across in different formats that's your files, your system tables and as well as some amount of metadata was stored within the Unodb dictionary and the system tables use the MySQL storage engine and you might have come across these files like rm-driven and .opt in a.do it's all collated and it's stored in the dd tables which uses the Unodb storage engine and it's called the data dictionary so as I mentioned based on the inputs you need the upgrade to be faster and should be with lower risk so what we have done is try to eliminate the legacy issues with the metadata and we have transition from the legacy metadata handling to a transactional data dictionary and the upgrade process will produce a consistent data dictionary and also we have tried to help the TVAs who are applying to upgrade to a.do what we have done is we added a new utility file I mean as part of the shell we have a real checker called as the upgrade checker which helps you prepare for the upgrade to a.do and also during the upgrade we have enforced certain checks when the server comes up so that you don't have legacy issues getting into your new metadata store first there are a lot of course of new features you could look at the release notes, you could look at the blocks as well as the MySQL documentation to see what's gone in and couple of them being the transactional data dictionary, the atomic details the GIs, enhanced GIs support, roles persistent runtime configuration and much more as I said there are deputations and removals and the features that are removed are the credit cash and the support for non-native partitioning and the options in the variables that have been removed is related to error longer errors, longer earnings, it's replaced by a log error a verbosity which determines the kind of warnings or errors or loads that gets logged onto your L log and as well as the option related to secure all has been removed and so the list of remotes have been removed like create user or the brand in terms of the God management the password function has been removed previously you could create a user using the brand statement which is no longer supported and the syntaxes that are affected are extended and partitioned keywords it's been removed from the explain and slash n was used as a synonym for null then it's no longer supported we'll have to explicitly use null there has been a lot of changes in defaults and I'll highlight a few of them here the default character set and collation has changed to UTF-8.84 and UTF-8.84, 900, absent, insensitive and case insensitive the default preferred authentication is changed from native to the cache in shard and password and the ANO-DV ANU tablespaces has changed from zero to four so also it's no longer the MySQL system tablespace it's a separate system tablespace I'm sorry, a separate tablespace which helps in you could truncate your ANU or the log tablespace also like Narendra mentioned the log web has changed from off to on that's a new default as well as in order to work well when you upgrade from 5.7 you'll have to do a distance relation on EV master key this re-encrips your master key and stores it back to your tablespace I mentioned the most important has been the cassettes in the collation default changes so when you're upgrading your schemas from 5.7 to 8.2 what we do is we do have the log of 5 which does retain the the cache that was used and is persistent and when you upgrade you don't have to really do any additional step it still has the same character set now in terms of rolling upgrade with your if you have fun, I mean the difficult thing where you would upgrade your slave and then you would do your master's say your master is on 5.7 and you have a slave which is on 8.2 for the new schemas that get added on your master it would still follow the 5.7 defaults of Latin and you wouldn't really run an issue on the slave though it is on 8.2 and also the new tables which get added to the existing scheme up except the schemas character set so again you wouldn't really run into any issues when you get on to 8.2 on your slave then you have a rich checkup which is very useful what does it do? it actually checks whether your 5.7 installation it is ready for upgrade it is part of the 5.7 releases what you can do is you can run that particular tool on your 5.7 installation and look for what are the legacy issues that would cause an issue during the upgrade clean up all of that at your own pace and then proceed with the upgrade so as I mentioned it is part of 5.7 it is an active development and we are continuously adding more checks to it to improve the upgrade preparedness for your 5.7 and in the subsequent slides I have done a list of all possible issues that you might run into a great of course not all of your environments will run into these issues but it is just for the knowledge purpose that have listed all the issues so the usage of the old temporal amitypes we no longer supported on 8.2 so if you are 5.7 installation during your binary upgrade if at all it has been redeemed you need to clean up if you have conflicted in the object means and with the reserve keywords you need to rename all those and the usage of unit of 8 and unit of 3 this has been deprecated in 8.2 so we would throw their free checker catches these reserve table names in mysql schema we have the DD table names created and the DD table is created in the mysql schema if you have any user tables in the mysql schema which conflicts with these you would be getting errors when you run the tool and the foreign key names which are longer than 64 characters this is generally the table names which are 64 characters where each character utilizes say 3 bytes and then the foreign key name is not explicitly specified but is auto generated and you would run issues where those more than 64 characters which is all supported in 8.2 and the usage of obsolete SEO modes and if you have enough set call and definitions containing elements longer than 55 characters it's more supported in 8.2 usage of partition table and shared table spaces not supported in 8.2 usage of remote functions this is most likely like the GIS functions which are removed and usage of remote group by ascending and descending all the issues that are reported by a check table for a great command also gets listed when you run a great checker tool let's consider an example as I said if you have you do have user tables in the mysql schema which conflicts with your needy table names which are going to be created in 8.2 the checker would actually throw the warning so it can be detected with the mysql query by looking up with the mysql schema name and the list of the needy table names and what you'll have to do is rename the tables which have the conflicting names with respect to the needy table names I mentioned there are certain functions which have been removed for example point from text and you can look up from the information schema in order to figure out which are these functions what you'll have to do as part of the cleanup will be to use the ST or MVR alternative for the remote functions and that's the example during the binary upgrade it's possible that all the old data types retained in your system but you are no longer supporting it in 8.2 and it is essential that you clean up before you proceed upgrading to 8.2 what you can do is check table for a grid on 5.7 will be reported also the mysql shell upgrade checker would be both the same and what you need to do is to repair tables so that your tables get rebuilt and you no longer have the old data type but you'll have your new data type so once you run your upgrade checker on 5.7 installation and it runs clean you are all good to upgrade to 8.2 so what you do is pack up you are doing it directly you solve the version run mysql upgrade restart the server and you inspect the error log reconnect that and it should work fine and if at all as I mentioned we have enforced checks during the upgrade in 8.2 so if at all your upgrade checker does not run clean and you attempt to do an upgrade the upgrade is going to stop we revert back all the changes that's made so far and we revert back to the original 5.7 data directory you can still start your 5.7 data I mean server on it continue with your cleanup and then start with the upgrade else it will be refuse the upgrade our great plans are you want to continue improving the upgrade process you want to reduce the time and the risk that you can run it to when you are doing the upgrade by enforcing more checks ensuring no legs issues get into your new metadata store and the path of the time for increase of greed as I said we have the 5 base metadata which we have moved into transaction data dictionary so we do harvest the metadata for analysis then also store it in the duty to have the example in our stores all the metadata you need to be without changing with newer releases with the 8.2 server is self aware from which version it's upgrading so it handles the upgrade of your DD tables in itself so you don't have to worry about that yeah it's good for security reasons previously your mice can use the tables you can go ahead and actually do a couple of inserts on to your system tables and the integrity was just gone and we have hidden these certain system tables the DD tables are hidden so you can't do anything there and this enforces the integrity and remove the need for mice to upgrade client or work with progress and should be available soon and it's more to the mice to the server itself it's no longer an external tool that you'll have to run at the end of every upgrade it's part of the mice to the server and of course it's longer and will be an upgrade so the traditional I had explained the traditional way of doing an upgrade now what you do is stop the old mice to the server change binaries to the new version adjust your content files for the new server version and then start your mice to the server as I said it transitions from your old way of storing the metadata to the DD tables so it analyzes and does an automatic upgrade and this makes it faster and with the work in progress when we have this remote you no longer have to run the mice to upgrade explicitly you don't have to restart the server because you perform the upgrade and the server is up and running so what we've done lower risk in terms of lower risk we have introduced the upgrade checker which identifies all sort of issues that you could run into which you can run on your 5.7 installation itself and there's an active development where continuously adding more checks enforcing more checks to it of course the metadata integrity as I mentioned we have it in the system tables and some of the DD tables and you no longer can insert explicitly into it and that way we are enforce the integrity of the system tables faster upgrade process because we do the metadata analysis as well as the metadata upgrade and with the removal of the disk and upgrade you lose out on an additional step you don't have to do the additional step and let's take care of the server step the simplified upgrade process because it's fewer steps now and it does all the metadata upgrade as well so you prepare for the upgrade and the other resources in order to figure out what are the changes that's gone into the version and run the mask in the upgrade checkbook and fix all your issues and run it until it's clean fix it and then run until it's clean and test your applications on New York 8.2 and do the backup and upgrade to 8.2 these are the resources there's a documentation and also also you have the blocks that can be downloaded