 So what I'm going to do is actually tell you why it is so difficult for enterprises to actually use clouds in any interesting way. So let me actually start by, oh, animation is not working. Interesting. So it's a very nice slide, actually. So if you really start looking at an enterprise today and ask, where are we? Unfortunately, the answer is pretty bad. Most enterprises today have become enormously complex and large. Let me actually show you just some data to, hopefully, this will work. Ah. This is actually data from a top tier bank in the US. And actually, this is actually only part of the data. So they run an environment with more than 30,000 servers, more than 20,000 databases, 2,500 application server instances, 35 different programming languages in their environment, and so on and so forth. If you start looking at the applications, they run on top of that. It's pretty amazing, also. More than 4,000 business applications, anywhere from six months old to 20 years old. Every programming environment and language imaginable is present in their environment. In fact, when I saw the bottom part of the slide, it was I was actually a bit surprised. Why did they have 25 account opening applications? That's because they have gone through lots of mergers and acquisitions and different parts of the world has actually grown differently, and so on and so forth. So if you start drawing even a simple diagram of who is talking to who and who is dependent on who, you get something like this. This is actually a simplified version of an IT environment operated by a top tier bank in Europe. This is actually AB and AMRO. The first one was Bank of America. So as you can see, you have a mess. So this is my favorite picture. We don't know what we're dealing with. Well, we clearly do. Well, so you won't see the elephant that I was going to show you. So it's actually the standard story of six blind men and an elephant that we really don't know. Different teams within the enterprise have a very different perspective on what they are dealing with. At application development teams, things of the enterprise very differently than the team that actually manages the infrastructure, the team that manages security and compliance usually comes at the end. That's the guy doing compliance. He comes to clean it up. So that's reality. I mean, that's actually where we are. So actually, it's an interesting question to ask, why are we in this state? Why are we in such a messy state? In fact, I used to be a professor of computer science at UT Austin in the US for almost 15 years. And when I came to TCS and started looking at, if you will, real world, I was quite surprised. I didn't obviously realize that the real world was so much more complicated than my nicely cordoned world that I used to deal with. So I started asking myself a very simple question. Why is it the case that when Boeing builds 777, it can ship it with, it does not ship it with an army of people that debug the plane on the fly, right? Thank God. But when we build data centers, computer scientists, and run the kind of stuff that NSDL runs or whatever, we have an army of people that debug the data center on the fly. Why are these things so fundamentally different from each other? So it took me quite a while actually to understand what is the difference between these two very large engineering artifacts. In retrospect, the observation is actually very simple. I concluded that a big difference between traditional engineering artifacts and our kinds of systems is that unlike traditional engineering artifacts, our systems evolve continuously. So if you, so our underlying technology keeps changing, operating systems, middleware, all of that keeps changing, application functionality keeps changing, workload keeps changing, composition of workload, volume of workload, all of that sort of changes all the time, expectations of users change all the time, right? Till yesterday I was providing best effort service, now I'm providing you platinum gold, silver tiers of service with different SLAs. You go through mergers and acquisition, another form of evolution, right? So my favorite example that I often give when I explain this problem is that I mean you buy a Tata Indigo, right? It remains Tata Indigo for the lifetime of the car, but in the case of an IT system, you buy an Indigo and over time you try to transform your Indigo into a Toyota Corolla, Lexus or BMW or Ferrari. Sometimes you want to fly your car and sometimes you want to take it under water, right? Now you don't have the luxury of actually selling the car and buying a new car. You have to morph your car from its current state to the new state. Moreover, this morphing has to happen while the car is running, right? So just imagine changing the oil of your car while driving at 60 miles an hour. That's exactly the problem that most enterprises are actually facing, you ask NSDL, that is exactly their problem in life. They cannot say, well, I want to go to cloud, so I'm going to shut down for next one month, I'm going to retool my entire thing and come back alive. That is just fundamentally not possible, right? So if you really think about it, in computer science, we don't quite know how to do this. We don't know how to build evolving systems. We don't know how to reason about systems that are continuously evolving. We don't know actually how to build very large systems out of lots of little components and reason about the property of the large system when each component changes, property of the component changes. There's some fundamental problems, I mean, limitations of where, if you will, computer science is a huge number of opportunities for research, by the way. So this is actually the reason why we have a problem. So what happens today is that another animation is not working. Okay, so it's actually completely out of order. Instead of the print job, animation is completely out of order. So actually if you think about this, if you start drawing a simple diagram of complexity of an IT environment people run, here I've tried to depict it in three dimensions. Number of entities that you run, these could be hardware entities, software entities, applications, business processes, whatever you have. Number of interconnections, you saw this messy picture that I showed you where all these lines are basically saying who is dependent on who, who is communicating with who and amount of heterogeneity that you have, meaning how many different versions of an operating system you run or how many different versions of a database server you run and so on and so forth. So what you actually see is that over time we are actually only increasing this complexity. In fact, because of the fact, because of most enterprises actually operate in a very what I would call reactive firefighting mode. We go from problem to problem patch to patch. We have very less understanding of exactly what we are dealing with. The implications are obvious, right? How you have high total cost of ownership, very brittle environment, you try changing something here, something else somewhere else breaks so nobody wants to change anything. This is actually going back to the agility issue that you were talking about. So if you now start looking at this and ask the question, well, so the cause, so what I have actually told you is that real world, real enterprises are very complex, right? And I've told you evolution is actually a key contributor to the complexity. What is the implication? What that evolution is the cause, what is the effect? Well, there are many effects. I'll actually point out only two effects and then we'll talk about solutions. So one major effect that you see is that in an enterprise what you actually find is that you have a large number of what I would call vertically integrated or highly tightly coupled vertically integrated silos. Why do these things happen? Because if you really look at how an enterprise works and how IT projects get actually launched, they usually start with a business problem. I want to solve a particular problem. I want to launch a new service. And to launch that new service, I'm going to actually develop some application. It is going to run on some operating system, some middleware. It is going to run on Hadoop. And it is actually going to be mapped on some physical hardware and so on. So there is some vertical stack that you will create. And then you will actually put that in production. So now this is a very tightly integrated vertical stack that has been created. There are many such vertical stacks. Remember, you realize a 4,000 business application example that I just gave you. Now that is one fact. The second fact is that if you actually then look at how enterprise IT is managed, it's actually managed in horizontal layers. You have the infrastructure management team that works very differently from application or application support, business process automation, business process outsourcing. All of these are horizontal layers. So although on one hand, we have vertically integrated stacks. On the other hand, we have horizontally distributed capabilities as well as teams. As a result, there is actually very little understanding that crosses these layers. So people who run infrastructure often don't ask the question, why am I doing what I'm doing? They say, well, somebody told me to do this, so I'll do it. Nobody really actually understand why, and application owner does not really think in terms of infrastructure at all. He designs the functionality and says, now run it, that's your problem. I mean scale it, your problem, right? So we have fundamental issues here. That is actually the reason why we are in such a mess. So that is observation number one. Second observation or characteristic is that if you really look at most enterprise IT today, we have a large number of manual processes that actually dictate how we actually design and operate our entire IT environments. Because of this, so basically what I'm trying to say is that the world is not so beautifully automated as you heard about this cloud bursting. I mean there are obviously example instances, like how do certainly we'll do a very good job for what it is good at. But it is good at some things, it is not good at everything that you would want, right? So basically there are a large number of manual tasks that actually get done, which means that we inherently rely on a lot of experience and intuition to actually run our IT. So that's also another fundamental observation. So given these two basic problems that I've identified, what can you do? How can you actually fix these? So there are two basic problems. So the problem number one is highly coupled, vertically integrated silos. Problem number two is too many manual processes. What are the solution techniques that are actually becoming available? So on one hand the solution technique is virtualization. What virtualization does is basically allows you to decouple these vertical integrated things. Now the advantage of virtualization really is that now I can change something underneath without really affecting the higher layer. And there are many levels at which you can virtualize. So your VMware Zen is actually doing hardware platform virtualization by using a hypervisor. Then you can have operating systems that will hide the hypervisor. Then you'll have other layers that will hide, databases and so on, so on, so on. So there is many layers of virtualization that you can add to actually decouple. So that is one major trend that is actually making life slightly easier. The second major thing that needs to happen is what I would call enterprise modeling. This is really not something that is happening in any extensive way today because it's actually quite hard to do. But essentially what enterprise modeling says is that you want to have the ability to actually correlate a business process to an application, application to infrastructure, the interdependencies between these interdependencies across various layers of your software architecture, hardware architecture and so on. So that you want to have the ability to answer what-if questions. What happens if I change this? Fundamentally something that doesn't exist today. But these are the two key technologies, if you will, that are actually required to start even making, making any significant progress in actually taking real world enterprises and migrating them to this cloud nine world. So the natural question one would ask is this doable at all? Is this just something that I will dream about and it will never happen until I retire or there is some chance? Well, and that's where actually all of the discussion that we have had so far actually is a good evidence. And if you look at how what cloud providers or internet service providers have been able to do, they have in fact leveraged these concepts to develop an architecture that is fundamentally agile, adaptive and efficient. So we talked about agility being their key objective. That's actually a key objective for all most enterprises. They're looking for adaptivity. I should be able to adapt to rapidly changing requirements. It should be agile. I should meet those requirements very quickly. And while I become adaptive and agile, I want to be efficient, meaning essentially achieve that at low cost. And so you have already seen some data, so I won't actually talk about this. I think the only point I wanted to make here was the server admin. It's actually an interesting point also. If you look at most enterprises today, they actually use one server, one administrator for every 100 to 200 servers. Compare that to Google or what Yahoo or others or Microsoft are using. I mean, there are two orders of magnitude apart. And part of the reason is it's been designed from ground up as opposed to living with the legacy issues and problems that we are actually dealing with, right? So the question now is, how can actually enterprise IT really benefit from the evidence? So what this is actually saying is that there is an existential evidence that something can be done. The natural question is, how do you actually achieve that? I mean, so how do you actually realize the potential that exists here? So there are many challenges that actually one has to deal with in actually deriving, in realizing this potential. Some of these are, I mean, the first, actually I would say the second bullet first, the scale and complexity. I already showed you data that actually demonstrates that this thing is extremely large complex, very few people understand it, right? That combined with the fact that there are actually dime a dozen mechanisms available for actually, for you to use to actually simplify and transform your environment, right? You can use Hadoop, you can use basic virtualization. I mean, we talked about several levels of cloud or several levels of, if you just look at server virtualization, there are actually several different flavors of server virtualization available. If you are using Windows or Linux, you'll probably use VMware or Zen. If you have, if you're using some ultra sparks, you'll probably use Solaris containers or logical domains. If you're using AIX, you will use L-Pars, right? So there are so many different implementations of the same idea. Each one has cost benefits, it is side effects. Each one has constraints on when it is applicable, when it is not, right? So that just simply means that if you just combine these two points, what it essentially says is that it's extremely difficult for an enterprise to actually decide what should they do, right? I'm in a candy store, lots of different kinds of candies. There are different price and size and taste and so on. And I have limited budget, limited time. I have an enormously complicated environment. Tell me what should I do? And unfortunately, the answer that an enterprise will derive will actually be very different from some, and answer some other enterprise will derive. In fact, even within an enterprise, if it's a bank, an investment bank and retail bank may come up with completely different answers to the same question, right? Within investment bank, the front office, which is actually a transactional system, and back office, which is a batch system, will come up with a completely different answer to this question. So essentially, it is extremely critical that one has to derive a custom strategy for every environment. It is impossible to actually have one size fit all. Now, given the size and scale and the complexity of the number of diversity of techniques that are out there, it is very difficult to answer what to do, which is basically driving a custom strategy when to do this. So in what order will you actually migrate from your current environment to this new environment that you're proposing? And if I do so, what are my benefits? Am I going to gain anything? Is there a financial gain? Is there an agility gain? Is there an adaptivity gain? What gain and do I have? I have to be able to predict this. Unless I do this, nobody is going to spend their next one and a half year and lots of money to try and transform from their current state to the new state. Forget public, crowd, private cloud, it doesn't really matter, right? So that's actually our challenge. Now, there are a few more challenges. So even if I tell you, okay, wonderful, I can give you this nicely designed transformation strategy on a paper, how will you implement it? Can you implement this? I mean, you just imagine the Bank of America example, right? 30,000 servers. If you really go and ask almost anyone, including VMware, how many servers, realistically, they are able to actually virtualize from a current environment to a virtual environment. You'll get numbers like maybe 1000 servers a month and that's probably an upper bound. I mean, usually it's way lower than that. So just imagine, 30,000 servers will take you 30 months, even at the upper bound, right? So you're talking about a two and a half year program. That is actually going to be required to do this. Two and a half year is essentially infinity for almost all of the industry, right? So there are some very interesting challenges. How do you actually implement a plan that I have come up with? Such that you can do it without really impacting your business, so low risk to the business, high reward and so on, so forth. And then the last one is, well, when you do this, it's very nice to actually talk about all these things like VMotion and Bursting and things of that sort, but the fundamental thing is that this is actually changing the way people operate their IT environment, right? How do you actually do change management? How do you govern your environment? What is the governance structure you'll put in? Who will you blame when something doesn't work? These are all fundamental problems that are completely unanswered when actually most enterprises try to do this. And that's exactly why most enterprises actually are way away from actually embracing anything like this. So in fact, when you look at public clouds in particular, most people who use it are startups because they have nothing to lose, right? I mean, there are no customers, so if they get customers wonderful, if they don't get customers wonderful, they pay nothing, right? So that's a nice equation. And then enterprises use it for completely things that are completely non-critical. So maybe I'll do some development work on the cloud and then I mean, I need 10 server for next three months, I go to use it and then get out, right? For enterprises today, that's what the state of the art is and it's likely to stay there because of all of these problems, at least in the near future, okay? So let me actually just take, what I'm gonna do is actually, I have no answers to the bottom two questions, by the way. I don't know what to do about them. The first three, we have some ideas. So I'm gonna actually just take maybe in the next five minutes, a little bit more drill down on the first three bullets with only one technology in mind, namely server virtualization because that is actually the foundation of going to any sort of cloud environment. So if you look at server virtualization, as I said, I mean, what is the pain in an enterprise? Well, the pain in an enterprise today is the fact that you have a very large number of servers that are highly underutilized and most enterprises you run, most servers are running less than 10% of utilization, right? And there is static allocation between applications and server. So the question is, well, can I actually just dramatically reduce my footprint and thereby reduce the cost by actually multiplexing a server across a large number of applications? In most of these cases actually in an enterprise, the workload is actually somewhat predictable unlike a startup example where you don't know whether you're gonna get three customers or three million customers. It's not so unpredictable. It is changing. It is not that it is constant, but the patterns are actually fairly well understood. I mean, you actually, you see certainly obviously the workload changing in terms of volume, but the patterns actually don't change very frequently. It is not so dynamic that it is completely unpredictable. So in that environment, people are essentially looking at right sizing as the biggest benefit out of virtualization as opposed to all of these fancy features like VMotion. VMotion is very rarely used in most enterprises today. Although it's the most fancy thing that you can do, nobody actually uses it. Because if you just imagine, just think about it, right? Today, people don't know how to actually debug a performance problem when it arises, even when nothing is moving, right? Imagine with VMotion. Suddenly your application is not working well. You have no idea where your virtual machine is. What are you going to debug, right? So I mean, there are some practical problems. Fancy technology, I used to love all that, but I mean, now I'm actually on the other side of the fence realizing that these fancy things actually don't quite really solve your problem. It probably hurts you more than it helps you. So anyway, so there are many strategy derivation questions. What is the target server platform and configuration would you select? How many servers you need? What is the right sizing of the environment will you do? What will be the target server utilization when you do all this, right? What is the implication if any on the application performance? How would you decide a consolidation plan? I mean, Varsha talked about this bin packing. Well, you have to do bin packing, but it's actually temporal bin packing. Because if you look at the utilization of a server, it's a time series, it's not a single value, right? How do you actually compact all this in a manner such that their peaks don't line up? And by the way, if it's 10 things, I can do it by hand, 30,000 servers, completely different ball game, right? So there are a vast number of challenges. What are the benefits if I do this? What is actually my cost benefit that I will actually derive? There are many choices and many constraints. So I'll just spend maybe a minute on the constraints. This is actually very interesting and important for you to understand. It's not as if you can walk into an enterprise and say, you know, you have 1000 servers. They're all 10% utilized. So I should be, without doing anything, if you just allow me to get to 50, 60%, I should be able to reduce the server count to 400. They'll laugh at you and throw you out of the room where you're in no time. Why? Because there are so many constraints that actually prevent you from doing what you just suggested. These constraints usually fall in three categories. Business constraints, technology constraints, and usage constraints. So you may not be allowed to actually mix this business unit with that business unit for compliance reasons, right? Technology constraints. Well, you cannot mix your x86 with some Solaris or whatever sparks, ultra sparks, unless you're willing to also do technology stack consolidation. So you want to move from Solaris to Linux and then you apply Zen with it. Otherwise it'll not work, right? So these are technology constraints. Usage constraints, right? I want to make sure that my development environment and my production environment are kept separate, right? Because I mean, if I goof up something in development environment and production environment shouldn't go down. So you start adding up these constraints. You'll actually, for a typical enterprise that I have dealt with, they have hundreds of such constraints. So you actually apply all those constraints, you get nothing. No consolidation whatsoever, because these constraints are so, they'll divide the entire thing into such little islands that you will actually get nothing out of it, right? So the challenge isn't actually identifying the right set of constraints that matter and then instantiate, derive a transformation plan that actually honors these constraints and produces good results. Once again, announce reveal things to do. So, which as you can imagine requires really a very systematic exploration of the entire design space. So 30,000 servers, lots of different technologies, lots of cost-benefit options. Should I do it internally? Should I get it on the Hadoop cloud or the Amazon cloud? All these are options, right? Each one has cost-benefits risks inside effects, right? I have my own constraints on what I can allow, cannot allow. Now, by the way, you Mr. Designer, explore this entire space and come back to me with a recommendation of what should I do that is custom for my environment. Extremely hard to do. Takes months to actually derive a strategy like this today because it's actually done by hand. And so that is where there is huge innovation opportunity. In terms of can we take this currently what I would call an art form where somebody, a few highly paid consultants come together, they actually look at all of this. They have lots and lots of Excel sheets. They'll actually some crunch data and come back with a plan. First of all, it's not clear whether the plan is any good. Other than the fact that you can't tell the difference between good and bad, right? So anything that somebody says that this is a plan you trust saying, oh, must be this guy, I have no hair, so I must be saying something that is meaningful, right? So unfortunately, that's not true. In fact, it's sort of very funny because most of these consultants actually are never responsible for implementation. So they make lots of money and walk away. And then somebody tries to implement it and it doesn't work, right? So all those consulting dollars are total waste, right? So anyway, that's a different story. So what is really needed? Unfortunately, I'm going to run out of time in three minutes, so five minutes, okay. So a huge scientific challenge is really to say, can I take this whole exercise today, which is very much an art form, which says how do I go about actually deriving a custom transformation strategy for an enterprise? Convert that from a very intuition-centric art form to a very scientific exercise, where I can actually systematically derive a plan and ideally automate the process of deriving the plan. So can I change what take today? It takes months to do, two minutes, right? If I can do that, I can truly transform enterprise IT. So that's sort of a challenge that we have taken on. Of course, we are nowhere close to solving that, but we have certain evidence that this is actually solvable, although very, very hard, but certainly solvable. So we built a bunch of tools and I was planning to show a demo, but unfortunately, we have no time for that. But essentially a tool that takes, so our entire philosophy is analytics-driven automation, which basically says we will actually collect a lot of data from your actual operational environment, all your 30,000 servers, right? So your servers, your application, your business process, business process to application mapping, application to infrastructure mapping, utilization levels of servers, application level performance. By the way, most organizations actually collect a lot of this data. They just don't use it in a very interesting way today. So we take all this data, including cost data. How much are you spending on managing your environment? We take all of this information and analyze it. So we basically build a graph model, a time series model, every server, every application, and we analyze the heck out of all this to try and identify what are the opportunities of actually consolidation transformation. This combined with our understanding of emerging technologies, their cost benefits, risks, and side effects, we basically build a bunch of algorithms that essentially allow us to derive this transformation strategy automatically, right? So in effect, answer the three questions, what to do, when to do, and why to do. In fact, our tool produces a complete business case automatically, right? So today, what takes you maybe months to do, I can do it in minutes, assuming I can get a hold of data, right? So that's actually what is needed to really, completely transform the way people actually look at this. So let me conclude with this last slide. That, I mean, whatever we have done, if you remember nothing out of this presentation, I think I would say take one thing away, which is that the problems are way more complicated than you imagine, number one. Anything that you do with intuition and experience is just not going to work because of the scale and complexity, right? Number two, number three, analytics and automation are key to actually future generation of, basically all these fancy technologies that all the product companies come up with, to actually use them in practice is actually very hard to do precisely because we don't have any automated way of actually figuring out what to do, when to do, why to do, right? Huge opportunity, whatever I have shown and talked to you about actually the tool that we have built is actually only looking at servers, but that's only a small piece of the larger island, right? I mean, you have applications, you have desktops, you have mainframes, you have network storage and name it. All of them have exactly the same sort of problems, perhaps even more complicated than the server because the server is a relatively easier thing for us to handle and understand. So huge opportunity, how do you actually take a large environment and understand what's going on? How do you formalize the cost, benefits, risks and side effects of different types of transformation techniques? How do you take your knowledge that you have derived about as a state, combine it with the knowledge of these cost-benefit side effects of different technologies and actually automate the process of deriving a transformation plan? If you can do that, you have actually solved 50% of the problem. The remaining 50% is how do you execute that plan in a rapid manner while minimizing risk, maximizing reward? So huge, huge opportunities for doing very interesting work in this area. So with that, I'll stop.