Tech Summit Paris DevOps Best Practices for Azure and VSTS

Editor's Notes

• #10: DevOps Then and Now
• #11: One comment pointed out that there are many more people in the second pit stop than in the first. I would argue that there are a lot more people involved in delivering software now than even a decade ago. Software delivery has become a team sport involving many more people than ever before. Which I feel is very clear in the video.
• #12: What I also found interesting is when I saw all the additional people I saw them as automated tasks in my head. Specialized tools used to achieve a common goal. They are like micro-services. One service to remove the tire, another to replace it and one service to just jack up the vehicle. I saw and incredibly orchestrated pipeline. I also noticed redundancy built in to the process.  If you watch the back of the vehicle there are two people with jacks. One jacks up the back of the vehicle and the other appears to be there just in case. There are also people near the front on the far side that never touch the vehicle but are monitoring the process, so they can learn and improve.
• #13: Another comment points out that in the second pit stop the team does not refuel the vehicle.  I believe you should fix what hurts most first. Watch the first pit stop again. Refueling the vehicle is done long before the second tire is changed. Reviewing the first pit stop what hurt most was the tire changing. The first pit stop took over 60 seconds the second less than 2.  Even if they had refueled the vehicle at the same rat as the 1950’s pit stop that would have been an enormous gain. Not to mention in the second pit stop they changed all four tires and not just two. I also think it is important to realize that the second team was not required to refuel the vehicle. This means work has already been done to remove the need for the bottle neck by making the vehicles more efficient. We do this in software. Historically manual testing has been the bottle neck, so many teams are leveraging automated tests to reduce the need for manual testing. Applications are being re-architected so the majority of the functionally can be tested and verified in a much more efficient way. This does not remove the bottle neck entirely because at some point manual test might still be run. However, the number of tests should be reduced and therefore the time to execute is reduced as well. Just as in the F1 race eventually the vehicle will need to be refueled but less frequently and quicker because they require less fuel. The more I watch the video the more I think it is the perfect visualization of a digital transformation.
• #14: I also think it is important to realize that the second team was not required to refuel the vehicle. This means work has already been done to remove the need for the bottle neck by making the vehicles more efficient. We do this in software. Historically manual testing has been the bottle neck, so many teams are leveraging automated tests to reduce the need for manual testing. Applications are being re-architected so the majority of the functionally can be tested and verified in a much more efficient way. This does not remove the bottle neck entirely because at some point manual test might still be run. However, the number of tests should be reduced and therefore the time to execute is reduced as well. Just as in the F1 race eventually the vehicle will need to be refueled but less frequently and quicker because they require less fuel. The more I watch the video the more I think it is the perfect visualization of a digital transformation.
• #15: Why is this transformation important? Let’s take a look at the next few years before us… In 2020, 1 million new devices are expected to come online every hour. The connectivity between people and data is creating billions of new relationships that are driven not only by data but by algorithms that keep customers engaged and buying.* In 2020, the average age of a S&P 500 corporation is expected to be 12 years old. Compare that to the S&P 500 in 1960 when the average age was 60 years old.** By the year 2025, at least 60 percent of computing will be cloud-based, due to “everything-as-a-service” shifting fundamental changes in the IT industry.*** For digital transformation, mobility is the universal catalyst and cloud is the great enabler. How are you planning for digital transformation? Do you have the right people and the right technology in place to build your digital vision? How can you use technology to shape your future? *http://www.gartner.com/newsroom/id/3142917 **http://upstart.bizjournals.com/resources/author/2015/06/04/fortune-500-must-disrupt-or-die-writes-r-ray-wang.html?page=all ***http://www.emersonnetworkpower.com/en-US/Latest-Thinking/Data-Center-2025/Documents/002401_DataCenter2025Report_HR_INTERACTIVE.PDF
• #17: Traditional model - Empathize, land the case for change based on change in business context Take empathizing tone (don’t want to make this sound negative). We want them to realize that what customers have done may have worked in the past but they need to recognize the need for change as the business is changing rapidly. Most companies are running custom apps that are stitched together, they have purpose-built hardware to think about, and have specialized teams, and everything has been carefully customized (over many years in some cases!). Now as an enterprise, you did all this for all the right reasons, but you might consider that it might be holding our customers (and their business) back in many ways given that the business context has changed fundamentally. In this new age of apps, the old way of doing this is causing friction because IT isn’t moving as fast as business wants it to. This is manifested in developers not getting the speed and freedom they need to create the best end-user experiences. That leads to lost productivity on their side, which results in ‘Shadow IT’. In 2015, 42% of the technology budget resides outside IT; this will grow to 50% by 2020 (Gartner). So this is real.   And we all know that while Shadow IT behaviors provide immediate gratification, it comes with risk. Slide 8: Cloud model (Mark) – Empathize, ask customers to be change agents, land cloud principles. Now let’s look at the cloud. Everyone knows that the cloud offers agility and innovation. It’s proving itself to be the way forward for the modern enterprise and we’ll talk more about that in a bit. But for some of our IT customers, the cloud might seem a little daunting. They might be asking, “Is this something I want to lead the charge on? How does it help my career?” The tension some of them experience is because you’re not sure if things are consistent with what you’re doing on-premises and it seems like it will be hard to manage. There’s also a tension between developers who want speed and freedom (represented by business demands), and the IT folks who have to worry about things like security and compliance.   Bridge to our POV while bringing them along. Implore them to be change agents in their orgs. But make no mistake about it – the cloud is the natural way forward for the rapidly evolving enterprise. Let’s all embrace it. In this context, we’re already seeing some leading indicators around “bi-modal“ IT among you: 45% of CIOs have a second, fast, mode of service delivery that complements their rock solid operations” (Gartner Symposium, Oct 2014). So there’s already some great progress that a lot of you seem to be driving. This is do-able. And we want our customers to be change agents in driving cloud adoption in your orgs.   Our POV We believe that cloud is a model/architecture, not a location. (Cloud-first principles as in the slide) Turns out that Microsoft has been on its own cloud-first journey for many years and we have fully operationalized cloud-first in our hyper-scale datacenters. We’d like to share some of that next to help customers shortcut their journey.
• #18: It was – and still is - the time of Agile and DevOps. We had to formulate a DevOps strategy for our entire organization. But what is DevOps? It can mean radically different things for different people!
• #21: 2014 Report collected in December 2013 had over 9,200 survey respondents across 110 countries with companies of ALL sizes and verticals. 2015 Report had 4,976 respondents with companies of ALL sizes and verticals.
• #25: [Slide goal] Highlight the fact that Microsoft owns the entire ecosystem and therefore it can provide deeper integration across the platform and tooling, while still allowing for third party extension and augmentation when and where desired [Talk track] Microsoft is in a unique position to support an organization’s adoption of DevOps practices – Microsoft provides collaboration solutions, development tools, testing tools, release management tools, monitoring tools and services, as well as an infrastructure platform – both on-premises and in the cloud. There is no competitor that can match this breadth of solutions, tools, services and infrastructure offerings. By owning all components of the DevOps ecosystem Microsoft can provide better integration between the tools and the platform and between the tools themselves, allowing organizations to spend less time configuring and managing tools and more time focusing on delivering value. By keeping the tools flexible and open, Microsoft still allows organizations to leverage existing investments in other tools. Microsoft continues to invest in all areas of this ecosystem, which is a key asset to its own engineering organizations too. This is another unique differentiating point – Microsoft is ideally positioned to learn first hand what works, what needs to be improved and what is lacking and make good investments. This first hand experience combined with things like User Voice, input from customers, and usage analytics gives Microsoft great insight and the ability to focus on what is needed most by its customer. Microsoft is in the best position in the industry to provide end to end tooling to support a strong DevOps practice.
• #28: Essential DevOps practices include CLICK agile planning, CLICK continuous integration, CLICK continuous delivery, CLICK and monitoring of applications. CLICK DevOps becomes reality with powerful tools that help development teams move through the different phases of the DevOps lifecycle quickly and efficiently. There are many powerful best-of-breed point solutions – both OSS and commercial – available today. These tools cover individual DevOps tasks or entire phases, and teams choose and integrate their preferred tools in order to get an end-to-end toolchain that works for them. CLICK Visual Studio Team Services (TS) is our Azure OSS DevOps solution and it is an easy and flexible offering. It’s enterprise class, integrated from end to end, extensible, and works with other tools. It ties everything together – program in any language, develop on any operating system, and deploy to any platform. It’s best with Azure, but it integrates with other cloud providers, giving users the flexibility to explore and gradually move to Azure. We do not ask you to stop promoting your favorite OSS DevOps tools – quite the opposite, we want your customers move the tools they are using to Azure. However, we do want you to keep in mind that TS is a great integration platform that can work with your OSS tool of choice and also brings additional value if you include it as part of an existing OSS DevOps setup. How? Let’s take Jenkins as an example. Jenkins is a great tool and best-of-breed OSS solution. Jenkins runs on Azure, in fact you can provision a fully functional Jenkins instance in just a few minutes from the Azure portal. That’s a great start and will create some consumption. But Jenkins also has some drawbacks from past experience: Managing Jenkins infrastructure can be cumbersome. It requires a master/slave relationship between all build nodes. As a team grows, they will require more builds which in turns requires more build nodes. From an infrastructure perspective, you need a dedicated team to manage that whole setup to ensure it runs smoothly. Security within Jenkins is enforced via plugins and highly complex to setup (when compared to TS). The plugin ecosystem is wide but there a lot of plugins that cause stability issues within Jenkins. Upgrading Jenkins is very painful which results in more teams using outdated version of Jenkins which can cause security risks. Integrating Jenkins with other tools like Jira or Github is cumbersome (while TS provides features from all tools within one product). If a Jenkins setup is mission-critical then setting up Jenkins in HA is extremely hard considering its backend is a filesystem rather than a database. Consequently, teams will tend to scale the Jenkins master vertically instead of horizontally as the number of jobs increases. The on-premises team is responsible to provide a decent SLA to the dev/ops teams. This is not to say that teams should stop using Jenkins – but they should be aware how TS can help mitigate some of the drawbacks. This was just an example of one tool in an end-to-end DevOps toolchain. If your customer is using multiple different tools, similar issues will crop up.
• #34: Optional others depending on time: - [first] Planning (Kanban/scrum board demo) - [before monitoring] Infrastructure changes (adding ARM templates to the release definition)
• #35: How do we use VSTS to build a pipeline to Azure – using the product to enable a process for our people to continuously deliver value to our customers. - new DevOps Project in Azure (Node to Linux App Service… let it run) - new Web App (full framework .NET), show: - FTP publish (with credentials, etc) - Git sync (connect and let deploy) - configure Continuous Delivery (disconnect git and make a change first) - show the DevOps Project result
• #46: globally distributed , database as a service. It allows you to