 Hello. Oh, wonderful. Good evening, folks. I think it's been a long day. Good evening, folks. All right, wonderful. So it's always a challenge being the last session of the day because pretty much you stand between, or rather, we stand between you guys and a lovely dinner that's to follow. But we will try and make this interesting. I believe we have about 45 minutes. We're going to try and keep this interesting. So to start with, I'm Nahas Mohamed. I'm from Microsoft. And this is... Do you want to say that again? All the way through? Yeah. Wonderful. So my name is Anand. I'm also from Microsoft. So we've got a chance to see a couple of sessions while we were waiting for our chance. And a couple of things that came out quite evident is DevOps. I believe the definition is still not very clear. And trust me, wow, the slides are bright. It's a definition that's kind of evolving over a period of time. The way we see, or rather the way, at least we are here to talk about DevOps is how traditionally... If you think about your dev teams over a period of time or traditionally DevOps or development team has been restricted to just what the dev team does. What we, as from Microsoft, are trying to do is kind of expanding that scope, so to speak, to involve other stakeholders. When I see other stakeholders, it involves getting your customers and other business stakeholders into your development scenario, so to speak, as well as extending it beyond your development teams to your IT operations, which is your production servers and monitoring your applications in that environment. So basically what we are trying to do is kind of expanding the scope to go beyond just the dev team. If you think about how... So predominantly that's what we would like to cover today, of how DevOps plays throughout the lifecycle of the application lifecycle management, as well as how Microsoft is bringing what we have to offer in the DevOps space. And obviously with the cloud infrastructure and the cloud offerings growing over a period of time, how you can actually leverage that also. So if you think about how things... I wouldn't say today's world, but maybe in the last couple of years how typically we come across problems is either the customer reports a problem or there are problems which you never are aware of. Am I too loud? I tend to do that. No? Is it okay? Be good? All right. So typically how issues used to be reported is either the customer actually reports a problem to you through a feedback mechanism or in many times reports, I mean, you never even get to know that there was a problem because you just lose a customer or if it's like a, let's say it's an e-commerce site and somebody faced a problem, there are times you actually don't even get to know of it because there is no feedback mechanism actually involved or implemented in the system. And okay, how many of you know what that device is? I see very young faces here, but this is used to be called a pager before the mobile phone came in. So this is typically how people used to get reports that something is wrong on the server and of course I know Anand has spent quite a lot of nights out trying to sort that out. And when we actually get to a problem, the first thing, and I'm quite sure you must have come across this situation, okay, whenever a customer reports a problem and you go to the dev guy saying that the customer is reported so it's a problem, the first response you get is that it works fine on my machine. Right? It happens all the time. The reason is because your dev environment is always configured for the best case scenario. Production servers are never configured for that. Production servers always assumes worst case scenario. They shut down all the ports. I don't know, in SQL, you want to do, you know, you want to connect to the SQL server? SA blank password. Easiest thing. Why for dev, you need to get things done faster. In production, it's always shut down. You have the, it's only open what is required. And typically when you come to meetings of reporting issues, this is what typically happens. The infrastructure guy comes and says, everything is fine on my end. There's something wrong with your code. The dev guy says, no, everything's fine with my code. There's something wrong in your, in your infrastructure. This is typically what happens today. I don't see in all cases, but typically what happens today. So if you think about what DevOps is all about, it involves three primary elements. One is people. People are an important aspect of the DevOps cycle. Unless you all of us, when I say us, I mean all of us, unless we are conscious or consciously participate in thinking that we need to take care of not, that's it. Got it. All right. So we need to participate in ensuring a well running production site. DevOps has to be part of your thinking process. It's not enough where you think that, okay, my dev environment works fine. My code works absolutely fine on my, on my dev server. Everything's good. It has to be beyond that. Similarly for the people in the operation site, they have to start getting involved in the dev, in the development cycle much earlier in the, in the, in the game. We'll talk about that in a little more. And obviously the process. You can have people who want to do a good, but if you don't have any kind of stringent process in place, it's not going to help. When I say process, it's not, it's not about tools. It's about how do you do a release? How do you actually incorporate feedback into your, into your applications? There is, there is the process is separate. And of course you have tools to enable the process, but get the process right first. And obviously you need the tools that actually get to, get to, get to have to help with the process. Quick question here. Wild guess, right? What do you think is the biggest aspect for failures in production? Take a wild guess. Is it people, process or? Tools. Tools. People. People. Okay. Okay. Let me put the stack right there. People, process or tools? What would be the mix? Do you think the, it's the products that fail? Is it the processes that are faulty? Or is it, is it people mistake that cost most of the failure? Process. Process. Okay. So here what I have is a, is a gardener report. This is not us. Microsoft saying this is a gardener report which says 80% of the failures that happen is because of either application failure or an operation failure. It is because of operations. It's because of people and the processor part and not the tools. You often tend to blame the hardware, blame the code, blame software. That only accounts to 20% of the failures. And this is not us saying this. This is study done independently by gardener. It could be a wrong change management process. It could be a wrong overlorded person sitting and not overlooking a process. Or it could be a weak problem detection in your process chain. Simple things like, you know, if I call it a bug fix or a, or a change management change request came in a kind of QA process that you had implemented to ensure that, that fix is not, you know, affecting something else. Those are the things that actually causes applications to fail. It's not typically never the hardware and the OS. So how do you, how do you, how do you fix that? How do you try and address some of these challenges? How do I fix? Obviously you have the right set of tools. You have tools and products which can fix it. But how do you fix the process and people part of it? Now at least from an operation standpoint, the, some of the challenges, some of the things that we're trying to fix is one, obviously help dev accelerate the delivery process. Optimize the resources which are available. That's obviously something which is, which is IT or ops mandate. Do more with less, right? Whatever you have, do, improve the availability. Again, availability is not something which the dev will much focus on. He'll say add a little code. It's up to you to deploy and make sure that it is available. And finally increase application quality. Though there is, there is good amount of, good amount of dev as well as ops mix which is needed for increasing the application quality. It's, it's more responsibility for, it's equally, both of us are equally responsible. But the idea here being, operations have to be there involved earlier in the picture. When you get the infrastructure guys in earlier in the planning process, DevOps, they enter DevOps cycle, or you are better off in getting a quality product than getting them involved later stage, right? So that's, that's the whole idea of getting. In fact, if you think about when you guys, I know obviously you guys are, you know, building world-class software. We don't feel, typically, again, we don't think production. We never think about what is this application going to be, what environment will this application be running in? Mostly we focus on the business scenarios, not really the deployment scenarios. Fair, fair assumption. Yeah, yeah. So, see these are things which we need to change. These are things which we can actually help us reduce failure in production. Now, this is, again, another report that is actually presented saying that what are the kind of different initiatives and tools that support, that support a good DevOps initiative is version control system. Obviously, safe to assume that a lot of us are using some kind of a version control system or something. This is all to ensure that there are lesser failures in, obviously, you know, change source history, change history, all that is taken care of. These are the bunch of, again, so again, a public available report, but the kind of tools that are actually available to ensure a good DevOps initiative, as well as a bunch of benefits that has been yielded by implementing these kind of initiatives. This again, just to give you a quick, obviously, it's publicly available. This is another comment which you think that how many of you are actually thinking this? Nobody? Nobody? But trust me, it works. All right? It's a matter of changing the way we should be approaching when you're trying to build a solution, change the way you think a bit, and trust me, it will give you a bunch of benefits later on. So to quickly talk about how we bring the development team and the operations team together to work well, Microsoft ALM offering is primarily, I would say, four different buckets. There's something called the planning phase, which is basically gathering requirements, prototyping, scheduling, excuse me, so on and so forth. Dev and Test, obviously, is Dev and Test. Release is a release management mechanism where you can actually set up a complete workflow of how you want to promote your code from one stage to the other, be it from Dev to test to UA if you have any, or maybe from staging and then again to production, basically a complete release management portfolio of release management cycle, and finally is when you actually release it to the production where the operation team takes over and starts monitoring your application and then continuously keeps giving feedback to the Dev team as and when things go wrong so that it becomes a cycle, it's every application evolves. Every code that you've written today, at some point you're going to go and write that again, or rewrite it, or refactor it, or something of that sort, constantly learning. Why? Because for whatever reasons, it could be because you're trying to make it better, or the business scenario has changed, or anything of that sort. Now, for Microsoft, from the ALM stack, what we have done is we've actually provided one single solution or one single product that pretty much covers the entire ALM offering, so to speak. So right from capturing requirements to source code control, to source code control, to agile planning, to test case management, to requirements capturing, integration, and the good thing is because this is one single product that gives you everything, I would say traceability is intrinsic. So let me give you an example. If I have a requirement saying that I need to create a login page, and I write a bunch of test cases saying that test the login page and I have a bunch of test cases, I can link this test case to this requirement. Every time a bug is reported, I report a bug against a test case which is again linked to this particular requirement. Automatically you get complete end-to-end traceability and obviously you have the code that is written against that particular requirement. So because we are one single stack that offers everything end-to-end, traceability is available right out of the box. Obviously we kind of integrate with other offerings, other servers, be it project server if you want full-fledged project planning. I hate to ask this question. I know this might be inappropriate, but how many of your .NET developers here? I pretty much assumed. How many of you are surprised to see Microsoft here? So fair question, right? Fair question, all right. Okay, so I'll give you a shot. So we have an ALM stack offering on-premise which you can install on your physical box. We have the same thing available in the cloud which we call Visual Studio Online. For those of you who are uninitiated, Visual Studio is our development stack. What is used to build .NET applications and so on and so forth. But one point I would definitely like to make. Team Foundation Server is platform agnostic. So you could be using an Eclipse on a Mac writing Java code using Maven or Ant as your build engine and it will just work well with Team Foundation Server because we integrate with all of these really well. So you want to give it a run please? I would encourage you to do that. So that's about the ALM stack. So we provide everything right from end to end right out of the box on one single box. We can just go to the next slide. So if you think about what are the various components for, you know, like a source control for build, what do we have, what do we have for test case management, what do we have for deploy and so on and so forth. So these are typically our offerings in each of these buckets of ALM. For tests we have a complete SKU used for test case management and test execution. And once we give it to the operation side, systems and it takes over. Right. So what I see on the right hand side is what we use for the deploy and off side and what do you use on the left hand side be it Visual Studio or Eclipse or Java or Windows Server as a platform, Linux Server be it on-premise, be it Amazon, be it open stack. What we can do is we can deploy and monitor monitor your stack like no one else's business. So one of some of the things which we keep in mind when you go through the entire development process from Microsoft, so couple of things like when does the application exact development start, so when do you actually start the deployment does it, is it where is this app going to live eventually, is it going to in each phase change environments because accordingly we need to plan. I mean these are questions that we would ask more from the off side of things when you do the planning and that's exactly why it's very important for you to get into the process, the ops team to get into the process early on in the development cycle. Other questions? Yeah, so this is areas where you would want forcing you to think about production environments like sensitive information is everything going to be secure communication, what kind of ports do you want to open on the server these kind of conversations is important to have up front in the cycles rather than having this conversation once you're ready and good to go because by then you probably are too late. What kind of SLA, what kind of performance are you looking at, is it an app which you're looking for targeting for 5000 users, 50,000 users I mean as a developer you may think doesn't really matter, I mean do I need to plan for that. But these are kind of questions that we need from an ops side of things because is your code going to scale or is it something that you're leaving up to my infrastructure to take care of it right, if I need to do that planning I need to get that involved. So the bottom line being start to be involved get to be involved, get the ops team early on in the development life cycle. See one additional point on that the scalability thing, you might be building an application that has a tendency or that has a nature that it gets spikes of usage, like for whatever let's say it's going to keep going up every weekend, that's an important information you need to be telling the ops guy because he knows that he needs to schedule his infra in such a way that every weekend he spikes up a bunch of additional VMs and then brings down the scale once a weekend is over. However small that information might be very important for the infra guy to know because he knows that when he deploys his infra he schedules the VMs getting fired up every weekend or every Friday night. So the planning phase that's what we gather from the dev teams. What happens in the develop phase, once you start developing then you start looking at creating the dev test environment in the first place looking at infrastructure as a code looking at the client images, building the client images and handing it out to the dev teams not just one but multiple environments depending on you're doing a test separately, build separately, dev environment separately. See with the power of the cloud today you have the complete flexibility of setting up your entire dev environment on the cloud and everybody could just get along with a bunch of dumb machines but very hard to find those kind of machines these days but even then you could use just dumb terminals and you could actually have a complete environment set up in the cloud and these are something which at least we are seeing very, very I don't know if you guys do this very often but something which is very popular in the kind of people companies that you're working with a lot of the people are just pushing their entire dev environment to the cloud on site but everything is on the cloud at the same time taking in mind, keeping in mind the back and connectivity stuff like VPN how do I make sure that my on-premise teams are able to seamlessly work on the cloud just the way they did it on-prem, things like VPN how do I do a site-to-site VPN if a bunch of developers are working on the same set of code or if it is an individual developer how do I make an individual connectivity from his or her machine back to the cloud advanced infrastructure consideration things like how do I have a service gateway how do I have a traffic manager something which will load balancing or redirecting traffic which is coming from a particular geography to a particular back-end infrastructure these are stuff which you can deliver out of the cloud now when you talk about cloud let me quickly show you how Windows Azure Microsoft Azure looks like when it comes to how many of you have heard of Windows Azure please raise hands, thank you how many of you actually have an Azure account wonderful perfect so this is a new management portal for Microsoft Azure so as you can see when you open up the portal on your gallery you have a bunch of let me zoom it so that so I do see in my gallery there are so I can go ahead and create a virtual machine but then I can also go ahead and create a website if you don't want a full-fledged virtual machine to host your database as well as your IA's or appashay you can just say fire up a web server for me now what kind of web server I can go ahead and say fire up a combination of web server which is which is just a particular combination like appashay plus MySQL so I can do that so that's the first thing now specifically around virtual machines when I go ahead and create a virtual machine I can open up a gallery which tells me what is it that you're planning to host again if I zoom in you get to see that there are not only window servers not only applications from Microsoft but also open source things like Ubuntu things like CentOS, Suzy, Oracle, Puppet Labs which means there are pre-built images and if these are not sufficient we do have a VM depot which is like an open source community like a code flex community where the community maintains a bunch of images and you can pick and choose from those or you can go ahead and upload your own images so that I have a copyrighted image of my environment that needs to be uploaded so that when somebody asks for a test and dev environment I can go ahead and fire before without doing much of job I can do that as well so let me quickly walk you through just 2-3 steps on showing you how easy is it to create a virtual machine from scratch so I'm going to create a virtual machine for rootconf so that all of you users can log in rootconf I'm going to give a strong password for that now here is how I as a developer go ahead and create an individual virtual machine from scratch so I go ahead enter in a bunch of details ask what are the end points that needs to be opened which means that if you're hosting a website I want to probably have HTTP port open so those are the kind of things which you would mention on this wizard and finally you would go ahead and tell what is it that you want to you want to go and deploy a plane vanilla virtual machine or do you want to go ahead and integrate with a back-end back-end Chef or a puppet server so I can go ahead and say I do have built-in extensions for Chef puppet or you can write your own custom script so that let's say I want to connect to a back-end Chef or I can take it from a local repository and I can go ahead and fire that VM so in a sense what I wanted to show you is how easy or how straightforward using a wizard is for you to create a virtual machine from scratch or create a resource on the cloud from scratch you can obviously do that with the code of your choice I mean you can go ahead and write a script you can go ahead and do it in partial you can fire the same thing from I mentioned on a Mac and go and fire that as well but that was a quick demo of how you do it do it in the dev and recently in addition to allowing to provision Windows Server environments we also now allow you to provision Windows client environments like you could set up a Windows 7 and Windows 8.1 Windows 8.1 and Windows 7 we allow you to set up client machines on the cloud and so if you think about it I could be traveling and I can actually set up a VM anywhere in the world I will be able to continue with my dev because my entire source code and everything is maintained in the cloud so this gives you the it's a complete IAS play here so in the dev machines you can set up a dev server your configuration server completely from an IAS perspective the other option like I mentioned earlier is you had team foundation server on-prem as well as you have something called the visual studio online basically your ALM offering on the cloud so you could actually have your dev machines sitting in Azure in the form of VMs connecting to a team foundation service which is basically your ALM service in the cloud so that is also another option that you can you can actually explore release management as you all know it's about how you the process is important how you actually promote your build from your dev to the phases of your development and it could be and typically what the phase is what you would typically again this is not what everybody should be following but in your sample environment something like this where you promote your stuff from your dev to your test and you always should have an approver at every stage to ensure that somebody is actually certifying that this this build is good to go so there are two parts to it there is a process saying that every build should be authorized by somebody and there are tools to do that so we have a tool from our side also it's called in release which is a company which we recently acquired and we are actually incorporated in release as our release management offering along with team foundation server and yeah that's it okay in the operation phase which is finally where you give back everything to the IT guy that's where Anand would come in so which means that once they handle the code and you're good to go for production you go ahead and deploy your code in production that's where the ops team's majority of the work starts that's where I'm constantly required to monitor the health of the application not just from a standpoint of looking at CPU memory discretization which are given having something like a Nagios in place and look at the vital statistics of the server but then it would be more important for the business to see to give them intelligent reports something that tells back business saying that even kind of infrastructure this is all that you can handle can you do like 5,000 concurrent users can you do 50,000 unless you give that kind of intelligence back as a report or some mechanism back to business those reports are really not very meaningful that's what we mean when you say do a monitor in the development or deployment phase the second thing which I would be concerned about as an ops guy is the scale business comes back and says I know that this was actually built for 5,000 users but then this is holiday season I want you now to take this app and scale it out for 10,000 users now do I go back to the developer and ask him is your code ready for 10,000 users he may say yes then it is again my headache to make sure that how do I how do I scale I'll always say yes you'll always say yes I know and finally it's about security how do I secure the entire thing right from the code platform to the code to auditing and logging so that in case something happens and I don't stop there I need to constantly pass back the learning to the dev team so that we can have a very healthy cycle so that in the next sprint of their relays they have a better improvement in terms of scalability in terms of security in terms of deployment unless I give this intelligence back to the dev teams they would have no clue that's where it is in the entire DevOps cycle at least the mics are working no it is it is so so that's where you pass on the learnings back and in the entire developments life cycle it becomes very critical for the dev teams to get these kind of insights so what we can do is in the interest of time we can take any questions that you have because I have a small demo where I can show you this entire process and then we are good to go so till the slide comes up or rather the project it comes up we are happy to take any questions other than stuff like what are you guys doing here so does this make sense no at all not at all okay I'm sorry say it again when you say images as in virtual images yeah okay you don't have as many I mean to choose from okay is there a reason behind that we are getting there that's right so this is something which we in first service from Microsoft Azure is something which we release in the month of July of 2013 right so it's less than a year now it's not that we've been here for like 10 years and a lot of images that you see are recent additions things like Oracle Linux things like our tie up with Mentos and Suzy are all additions which we made in the recent past in fact the puppet and chef integration happened only in the build right in the build two months back that's right so it's it's we are catching up wrong word now we're getting there again one of the things you have to keep in mind is what does it mean that if I don't see an image there what does it mean does it mean that it doesn't run or it is not supported so the difference between an image being there and image not being there is that an image that is there is fully tested and certified by Microsoft unlike unlike someone else who says that yeah it runs so you can bring your image it may run but don't call us for support that's the only difference you can bring in whatever you want as long as it runs on x64 as a platform it should work upon the cloud the only difference being we are not tested it so it's it's like we have a buffet so you can pick from the buffet you can bring your own food outside food is an analogy outside food is allowed yeah outside food is allowed other providers no so if you check the prices recently if you check the prices recently we are more competitive but when we quoted for one of the automation thing Azure was three times higher than what Amazon was giving unless you're done very wrong calculation that can never be the case and trust me this this battle will not end anytime now this will continue to happen I mean that's how this business is so because the price of like a tiny instance or a medium instance of Ubuntu is totally different with the price of what with Amazon is giving with Azure we would love to have the discussion we will have that later let's stick to technology I know for sure that the prices are comparative as any competitor out there in the market that's our foundation because we are the late runners late entrants in the market we cannot afford to be at least in this this platform to be costlier right okay very quickly when you look at the ops this is an example of dashboard that we have from an ops side right so jazzy dashboards and meters running green red now this green dashboard here tells me how is my app performing now that is critical that is different from the kind of dashboards that you see dashboards that you would probably see from an IT standpoint are these blinking lights which say disk utilization memory utilization this is different this is what I call as a SLA dashboard service level agreement dashboard directly impacts your business if this is directly something which you can take to your business and say give me more money because with what you've given me this is all that I can run this for example is telling me that I'm giving back business a target of 90% uptime of my infrastructure since I'm running on-prem and I'm a lean team but I'm on the contrary maintaining a SLA of 98% however there is another aspect that I'm measuring my data center of which is what is a target time that it takes for your shopping cart to load for example so here this dashboard is telling me that the target time was 50 seconds versus currently it is taking 97 seconds for you to load now here is where the traditional fight starts or the finger pointing starts that's probably because the code is wrong that's probably because the networking guy did not do his job probably that's probably because sand cannot take that kind of that kind of IOPS now there is where you need to look at a monitoring tool which can go beyond just telling you what are the vital statistics so for example this in this case I'm able to look at the look at an incident and break down that incident into pieces in this case I have a dotnet code but it doesn't matter if I have a java code as well I can tell you did it have a score flow which line in the code gave you that particular problem in this case I'm telling there's a WCF code that ran that pulled up a SQL query as giving you a breakdown of each component by component each query by query how long did it take so that I can try and figure out is this database probably not indexed properly not partitioned properly I need to do something at the database level versus a WCF call or I can do some something like this which tells me where did again is it is it because of browser is it because the Ajax call that is being made is it because the image is it because so I set myself a threshold of 500 milliseconds and look at what is the current utilization so these are examples of how a proper monitoring system if once deployed can deliver value not only to the ops guys but also to the dev guys how because I clearly know that there looks like an extent there looks like a client performance exception happening which needs which is relevant which is related to a client Ajax call that the developer has built definitely not an offensive problem so what I can do is I can set the resolution state as assigned to engineering and what then happens is of the data that I was looking into my dashboard those valuable information goes back to the developer so that he can start now building or re-looking at the code and try and fix the problem so this is where I mentioned earlier about how you're actually extending development just beyond the development team and bringing the IT IT guy inside if you remember I mentioned that we have something called our ALM stack team foundation server so once let's assume that we went through the build and we went through our QHX and we went through the release management and we finally deployed the application on the production server and Anand here has set some thresholds let's say for the sake of example that the threshold one of the thresholds he said that is a page response time should be sub second just say for the sake of example every time that threshold fails he gets an alert saying that it failed at this point what Anand can do is that he can actually drill down to those alerts figure out what exactly went wrong there to that level as to what are the SQL statements that ran there and by simple right click he can post to engineering what happens now is because I don't know if you mentioned this is system center by the way which is our product to monitor data centers and so on and so forth we have an integration when I say we team foundation server has an integration with system center so what effectively happened is when Anand says right click can say post it to engineering the system center actually posts a work item in team foundation server along with all the information that he needs including what is he always that's running on it what's the service pack that's running on it all that stuff which you typically are the questions you ask the guy when a bug is reported what is the environment you're running in what is the search query that you're what is this product that you're searching for questions you ask whenever whenever a bug is reported in this case all that information is handed over to you in a platter right from and real world real world real data as to right from the production server all the way back to your your development server which is which is your ALM server which is team foundation server so this is our or our interpretation of what DevOps should be wherein you're actually bridging the gap between the development team and the IT team which is by you know kind of continuously delivering value to the team if you think about it whenever a bug for those of you who have fixed bugs in your life fixing the bug is never the largest amount of time that you spend the maximum amount of time trying to figure out where the bug is or why the bug is happening fix is typically not that much of a problem the moment you find that this is a reason it's a much easier it's a much easier conversation the objective here is to reduce that the moment you know that this is a scenario that this is the environment that the application was running in this is the sequel query that it ran and this is the reason why it you know it was showing 1700 milliseconds of runtime that's that's gives you a focus area to go back and you know try and fix the bug so this is DevOps for us so you're continuously improving the application which means with the kind of SLAs what I'm able to achieve is is better control on MTTD the meantime taken for recovery mean time between failures mean time to failures and continuous delivery mechanism right I now have the kind of insights where I am not in a situation where I'm pointing fingers is it a code issue is a network issue with the right kind of tools what I'm able to deliver is to try and pinpoint if not to find the root cause try and pinpoint where the problem is headed is it a storage problem is it a code problem is a network problem is it something related to infrastructure is it related to cloud and effectively what what we can deliver is better value to business right so that's pretty much what we had for our little talk today what we can now do is open it up to questions so I see you have a question during your one of your slides you mention about increase application quality and there was a role that operations played right and then the series of stages for an application go into dev and a test and a stage in a life unfortunately between the time it goes into stage and life there are like two days three days you know where exactly are you talking about applying this increase application quality and ops involvement because stage is the full blown environment quality is never an afterthought quality is always right from the design dev everything when the quality is typically it's like once let's do all the dev and then let's get into test that is no longer especially when if you guys are following agile and stuff you go hand in hand right quality is always in there in every phase if you ask me where is where exactly are you suggesting use quality it is it's a it's a it's a horizontal it's got to be through and through through every single phase and you mentioned staging production is a two day pre-proud right unfortunately in most of the cases we try to go early on stage but by the time the cycles are done and you go into pre-part it's more around oh let's have a full blown data test and then with the load balancers in the picture and active active structure or whatever it is and oh that's the small test that needs to be run and then you go live right there had been a lot of instances where we have got problems in stage and it's like completely a dba sitting there the whole day trying to get a sequel optimized right so I understand the quality needs to happen all the way and hand in hand is something that we talk a lot about right but I was wondering if there's something specific that an ops person is doing an ops standpoint yeah that's right so if I have my plug in from an ops standpoint in each of those cycles in your development life cycle I can take those inputs and not just keep it with me but give it back to their team some example so I'm in a dev stage before moving to pre-proud one of the challenges that you mentioned was scale right how do I do scale testing in pre-proud and make sure that stuff runs properly I can do a mini scale testing in the dev cycle itself right and I don't want to overload the dev guy with testing roles or thanks to the function that you need to anything on the infrastructure side if I'm writing a line of code and if that code was written not written properly as a result of which I know for sure when it reaches stress testing it may fail can be an obvious thing that an ops guy can take and give it back as an info to the dev team those are some of the examples where the ops team can get involved in catching out some of the performance bottlenecks and can help in constant improvement in the life cycle and you also have that swap thing right the option where you could have a production and you could set up a staging environment and what you do is that you first deploy to staging and once everything is do you just do a flip and so the people are coming from the outside world they see absolutely no difference so you can switch between a prod and pre-proud a test and prod environments with a flip of switch thank you yeah couple of questions regarding the offerings of Azure these days AWS has been very proactive in offering new services like EMR Redshift, ELB etc. so what kind of managed services you provide and what kind of security if you compare with AWS they are banking heavily on VPNs what kind of security aspects are so security comes at multiple angles so VPN is definitely there VPN is one of the mechanisms for security but for a security is there in each layer be it the infrastructure layer be it a pass because if you look at Azure as such as an offering we started off as a pass player right we came into infrastructure as service late we started off as a pass layer which means that security is first and foremost when you look at a pass standpoint because it is a totally shared kind of infrastructure right you run a piece of code it is running on not just an individual virtual machine probably which is isolated for you but it may be running as a website in an IAS server which may be sharing code with some other vendor so for a security was first and foremost in our platform built at each and every layer be it the storage layer be it the compute layer be it the virtual machine layer be it the networking layer then came in infrastructure as a service and for us it became easier because we built a foundation that way now if you look at the platform innovation that we are looking at I know where you are getting at so managed API is something which we announced just this week yesterday day before day before so the kind of innovation that we are bringing on the cloud we are bringing at a rate at which we never seen before and we are able to do that because it is not product release it is just release to the web right so every month you will see a lot of announcements that are happening and that is how it has been happening over the last one year and if you look at the last one year every month every single month we had at least 5 to 10 announcements that we had to make improvements on our platform that is a constant thing that is happening and like an SP1 that will release on the on the on prem part of things right we have 8 and then 8.1 and we have constant cycle that is not the case in the cloud yeah any other yes ma'am two questions do you have an API for all the UI things that you are doing or APS partial or REST ok and do you have a trial like account absolutely yeah it provides everything that so do you have an MSDN account sorry do you have an MSDN subscription you have an MSDN account you already have azure oh really so you can go to your MSDN subscription activate your azure every MSDN so for all of your MSDN subscribers in the room if you are not aware you already own certain hours of azure as part of your subscription depending on what level of subscription you are in platinum premium MSDN comes in 3, primarily 3 editions pro premium and ultimate if you have ultimate you get about 150 dollars worth of computer hours on azure every month so it gets reset every month from the time you activate that's your day 1 then every 30 days it just keeps resetting back to as you consume and then it resets back to 150 dollars so that is a great thing to leverage and again for those of you who have MSDN subscriptions you also have load testing capability available on azure so what you could actually do is that if you are using visual studio you could actually run a load test on windows azure so it's about 15,000 i forgot the number but yeah if you don't have an MSDN subscription you can always go ahead and sign up for a free trial so we give you 30 days free trial where you get 200 dollars worth of computer so that's your first question what is yours so is there a way to integrate it with other providers like open stack or cloud stack when you say integrate what exactly suppose i want to use open stack frontend api to apis to fire environments on demand in azure cloud so that's what today the way you can do that is either use rest apis or partial, partial i don't know how you will integrate with the open stack frontend but rest yes for sure you can make rest calls to windows azure and we do have in MSDN enough and more code snippets that you can copy and paste on to various different frontends okay thank you yes sir last question so the monitoring tool that you mentioned was system server system center is there a open source version of that a commodity version or something like that i mean open source version when you said free let's put it your question is do you have a commercial version of system center free version of system center or free version of system center is that what your question was so yes we do have free version obviously there is a difference between what is possible in the free version and what is not possible in the free version so there is a free version which is called the system center advisor so if you can go to systemcenteradvisor.com you can go ahead and sign up for free you can point that to your windows servers windows servers and it will give you all the statistics like operational performance all of that not the kind of dashboards that you saw it will give you built in dashboards you cannot obviously customize those dashboards what can be monitored are minimal but yes we do have a free version as such i don't know if you missed it but like Anand mentioned system center is not to monitor just windows boxes you could even monitor non-windows boxes unix linux unix linux and stuff like that you can monitor those boxes and java apps non-microsoft apps great i think thank you so much for being such a wonderful audience i hope this was good