#4 - DevOps par un évangeliste Microsoft Corp
•Download as PPTX, PDF•
2 likes•275 views
Nous vous proposons un talk qui n'était pas prévu, mais qui est exceptionnel ! Nous profitons de la venue en France de Julien Stroheker, Montpelliérain qui est parti s'installer au Canada il y a plusieurs années et qui a rejoint depuis 2 ans Microsoft. Sa présence en France est rare, venez nombreux pour discuter avec Julien, de DevOps et de plein d'autres sujets. Julien est spécialiste DevOps, Open Source et anime des conférences et Hackathons dans le monde entier. Vidéo de la session : https://www.youtube.com/watch?v=MEoNH4cUvtU&t=507s Son blog : http://blog.jstroheker.com/ Son twitter : @Ju_Stroh Son linkedin : https://www.linkedin.com/in/julienstr... Sa chaîne channel 9 : https://channel9.msdn.com/Niners/Juli...
Recommended
More Related Content
Similar to #4 - DevOps par un évangeliste Microsoft Corp
Similar to #4 - DevOps par un évangeliste Microsoft Corp (20)
Recently uploaded
Recently uploaded (20)
#4 - DevOps par un évangeliste Microsoft Corp
- 1. DevOps Overview Senior Software Eng. Julien Stroheker – twitter.com/Ju_stroh
- 2. Julien Stroheker | @ju_stroh Senior Software Eng. Jstroheker.com MSFT Code….code….code…. Studies in development Basket-Ball fan #TalkDevOps
- 3. Agenda
- 6. It’s tough out there…
- 7. Outperforming teams are 54% more likely to Developers 26.7% No executive support 56.7% Cultural inhibitors 43.3% Fragmentedprocesses Collaboration blockers DevOps was being initiated by more development teams than IT Ops teams by about a 40% to 33% margin Agile methodologieshave adopted 3/4 of teams BusinessIT Ops The average hourly cost of infrastructure failure is $100,000 per hour It takes on average 200 minutes to diagnose and repair a production issue A bug caught in production ends up costing than if the same bug was found earlier in the development cycle 100x more IT decision makers is still unfamiliar with the term DevOps 61 in 40% … of implementations end up getting reworked because they don’t meet the users’ original requirements … of development budgets for software, IT staff and external professional services will be consumed by poor requirements 41% IT drives business success! High IT performance correlates with strong business performance, helps boost productivity, market share and profit. Responding to ongoing needs for efficiency and growth Always keeping all systems safe and secure dual goals … for companies that try to adapttheir existing toolsfor DevOps practices 80% failure rate … CIOs 70 % to reduce IT costs Would increase risk and accelerate business agility of
- 10. DevOps is not…
- 11. …separate new DevOps team
- 12. … a reason to have no operations
- 13. DevOps “project”
- 14. … tool fixing culture
- 15. … “one-time DevOps workshop”
- 19. Applications Infrastructure Management Databases & Middleware App Frameworks Linux Proven Hybrid Hyper-scale Open cloud
- 21. Plan 1 Monitor + Learn ReleaseDevelop + Test 2 Development Production 4 3
- 22. cspkg
- 23. cspkg
- 24. cspkgcspkg
- 35. Thanks you / Questions / Happy DevOps twitter.com/ju_stroh DEV OPS Production
- 37. Lean History -> VSM -> DevOps CALMS
- 38. Types of Waster in Software Delivery 無駄
- 39. Lean Software Development practice “Tools”1. Value Stream Mapping
- 41. Why Value Stream Mapping (VSM) ?
Editor's Notes
- Cover Option 2
- Taken from: http://dev2ops.org/2010/02/what-is-devops/ Development kicks things off by “tossing” a software release “over the wall” to Operations. Operations picks up the release artifacts and begins preparing for their deployment. Operations manually hacks the deployment scripts provided by the developers or creates their own scripts. They also hand edit configuration files to reflect the production environment, which is significantly different than the Development or QA environments. At best they are duplicating work that was already done in previous environments, at worst they are about to introduce or uncover new bugs. Operations then embarks on what they understand to be the currently correct deployment process, which at this point is essentially being performed for the first time due to the script, configuration, process, and environment differences between Development and Operations. Of course, somewhere along the way a problem occurs and the developers are called in to help troubleshoot. Operations claims that Development gave them faulty artifacts. Developers respond by pointing out that it worked just fine in their environments, so it must be the case that Operations did something wrong. Developers are having a difficult time even diagnosing the problem because the configuration, file locations, and procedure used to get into this state is different then what they expect (if security policies even allow them to access the production servers!). Time is running out on the change window and, of course, there isn’t a reliable way to roll the environment back to a previously known good state. So what should have been an eventless deployment ended up being an all-hands-on-deck fire drill where a lot of trial and error finally hacked the production environment into a usable state.
- There’s no question, doing business is tough nowadays We have worked with a lot of different companies in different industries and we’ve found that 3 main challenges come up again and again: Business is getting faster every day … markets can turn and change at a moment’s notice Competition is getting stronger … today’s edge is tomorrow’s mainstream The need to go from idea to reality in a radically shortened timeframe is putting huge pressures on an organization’s ability to deliver Since every company is a software company today, those that can deliver value faster are the ones that will survive and win
- In the real world, there are real consequences if you are unable to deliver high-quality software quickly or build the wrong thing to begin with: 40% of implementations end up getting reworked because they don’t meet the users’ original requirements The average cost of one hour downtime of a customer-facing app is calculated at 100.000 dollars per hour – and this does not take into account the damage to reputation, which can be even greater. Fixing such production issues takes on average 200 minutes per incident Three quarters of development teams have adopted Agile methodologies today, enabling them to develop faster. While this is a great number, it does not help if a development team is Agile but deployment still takes weeks or months because IT Ops is perceived as not being Agile These are just 3 very high-level examples but all the data we have today points toward the same conclusion – this is about more than just frustration or minor delays. Lack of collaboration between dev and ops can have substantial impact on a company’s bottom line and success
- 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.
- People = Culture Fundamental attributes of successful cultures: Shared mission and incentives: infrastructure as code, apps as services, DevOps/all as teams You need to consider your hardware as a commodity, (don't give your servers names) , servers are like farm animals, it is just harder if you let theids name them Build deep instrumentation into services, push complexity up the stack Rally around agile, shared metrics, CI, service owners on call, etc. Changing the culture: any change takes time, changing culture is no exception and you can't do it alone, exploit compelling events to change culture: downtimes, cloud adoption, devops buzz PROCESS Definition and design, compliance, and continuous improvement PEOPLE Responsibilities, management, skills development, and discipline Products Tools and infrastructure
- SLA ? Response Time CPU / RAM
- Cloud Based / OnPremises Feedbacks – Application Insight / Relic / etc…
- Multiple configuration Cloud Cloud Cloud
- This is the framework for which you could connect the 300 level technology demos back to DevOps for any of your presentations. Do not present this slide to customers. Sample DevOps practices might include: Continuous Integration Infrastructure/Configuration as code Self Service Environments Continuous Deployment Test automation Release Management Performance Monitoring Alerting Production Diagnostics Availability Monitoring Feature Flags Automated Environment De-Provisioning Automated Recovery (Rollback & Roll-Forward) Hypothesis Driven Development TiP Fault Injection Usage Monitoring / User Telemetry Load Testing
- Azure is open and flexible – you bring what you know and simply continue to use it – there are no second class citizens in the Microsoft cloud Whether it’s platforms, languages, tools or apps – we support an ever-growing set of OSS and proprietary technologies, tools and standards With Azure, you have choices - choices that help you maximize your existing investments You bring the tools you love and skills you already have, and run virtually any application, using your data sources, with your operating system, on your devices Or - complement what you’ve already built by using Azure to add additional value to your app Augment your iOS or Android mobile application with identity and access management through Azure Active Directory, or cloud-powered insights through Azure Data Lake Analytics Run Linux batch processes to support your .NET applications And tap a growing ecosystem of open source solutions available from Azure Marketplace that enable rapid deployment in the cloud At Microsoft, open source is a part of our day-to-day approach to cloud innovation We are also constantly looking for ways to improve developer and user experiences with SDKs for open source languages and an open API Plus, we are committed to sharing our cloud learnings with you and for your datacenters, thanks to Linux and open source support in Azure Resource Manager and Azure Stack
- Release Management in the Visual Studio Online Service (or on-prem product which not easy to access for hackathon) Deployment Slots + CI/CD solution with VSO + Azure Websites
- David Note: Make sure to highlight customer pain points, “bullet train”, Poll??
- Roll-forward means making a fix to the code Check-in fix, quickly test, “roll-forward” by pushing a new release
- IMPORTANT NOTES: TechReady24 will utilize Windows 10 and the new PowerPoint 2016, as well as PowerPoint 2013 on all event machines. Please build your slides utilizing the appropriate TR24 Template and utilize the version of PowerPoint that works best. Windows 10 devices now connect remotely through VPN using the PIN with Passport for Work. Speakers needing to use VPN in a demo, will need to have registered for Phone Authentication at https://phoneregistration.microsoft.com. Additional details are also available here: https://microsoft.sharepoint.com/sites/itweb/securelogon/Pages/FAQ.aspx
- JIT = Just in time Say Toyota started on concept of JIT all the way back in 1934. 1936 “Kaizen” improvement teams. 1988 – term first coined by John Krafcik in article “Triumph of the Lean Production System”. Two key principles in Lean – Just in Time (JIT) and “Autonomation” (Smart Automation) http://itrevolution.com/devops-culture-part-1/ The concept of CALMS was introduced at DevOpsDays Mountain View (San Francisco area) in 2010. John Willis started with CAMS initially then Jez Humble added the concept of Lean. The lean principle for development are the following: Eliminate waste Amplify learnings Decide as late as possible Deliver as fast as possible Empower the team See the whole
- 1. Value Stream Mapping Will be the core of the presentation in the future. It gives a view of the full process with times spend on each activity. 2. Theory of Constraints Methodology to identify the most limiting factor that stands in the way of software development. By identifying the bottleneck in the process, the most efficient use of the current can be achieved. 3. Pull Systems Each step in the process pulls the work from the previous steps. This leads to the Kanban methodology. 4. Queuing Theory 5. Motivation 6. Measurements 7. Test Driven Development (TDD)
- Executives have a very high level view, however the coders and operations have a small view of the process. The VSM brings an intermediate point of view best suited for understanding the process.
- Value Stream Mapping aids visualization by allowing persons to see the entire VSM on a single (11”X17” or A3) piece of paper. A “rich picture” is a metaphor to explain that as well as the process steps, each aspect of the process is given depth and clarity through the structure of the VSM
- This guide will give additional background information on how to implement the VSM and bring a practical way to design and bring improvements. https://www.amazon.com/Value-Stream-Mapping-Organizational-Transformation/dp/0071828915/ref=sr_1_1?ie=UTF8&qid=1474332193&sr=8-1&keywords=value+stream+mapping The first three chapters of the VSM book are very helpful to read before you start doing one VSM with a customer.
- Around 50m