Downloaded 17 times
More Related Content
Similar to Scaling Your DevOps with Chef (December 15th 2016)
Scaling Your DevOps with Chef (December 15th 2016)
- 1. DevOps with Chef. ant@chef.io @anthonyhodson AnthonyHodson – Solution Architect
- 2. About Me Solution Architect Enterprise Israel,Europe and UK
- 3. Our Talk Today: “Everybusiness needs to be able to deliver new products to market fast. Chef and Manageware will discuss how a combination of a change in culture along with collaborative tools, can enable your IT teams to deliver the changes your customers want consistently, faster and with more confidence.”
- 4. Our Talk Today: “Everybusiness needs to be able to deliver new products to market fast. Chef and Manageware will discuss how a combination of a change in culture along with collaborative tools, can enable your IT teams to deliver the changes your customers want consistently, faster and with more confidence.”
- 5. Our Talk Today: “Everybusiness needs to be able to deliver new products to market fast. Chef and Manageware will discuss how a combination of a change in culture along with collaborative tools, can enable your IT teams to deliver the changes your customers want consistently, faster and with more confidence.” Fast: Increased Release Frequency Decreased Lead Times Decreased Time to Recover from Issues Decreased number of Issues
- 6. Why Care? State ofDevOps Report 2016: 1. High-performing IT organizations deploy 200x more frequently than low performers, with 2,555x faster lead times. 2. They have 24x faster recovery times and 3x lower change failure rates. Source: Dr Nicole Forgren - state of DevOps report 2016
- 7. State of DevOpsReport 2016: 1. High-performing IT organizations deploy 200x more frequently than low performers, with 2,555x faster lead times. 2. They have 24x faster recovery times and three times lower change failure rates. 3. High-performing IT teams spend 50% less time remediating security issues. 4. They spend 22% less time on unplanned work and rework. Source: Dr Nicole Forgren - state of DevOps report 2016
- 8. State of DevOpsReport 2016: 1. High-performing IT organizations deploy 200x more frequently than low performers, with 2,555x faster lead times. 2. They have 24x faster recovery times and three times lower change failure rates. 3. High-performing IT teams spend 50% less time remediating security issues. 4. They spend 22% less time on unplanned work and rework. 5. Employees in high-performing teams were 2.2x more likely to recommend their organization as a great place to work. 6. Lean product development predicts higher IT performance and less deployment pain. Source: Dr Nicole Forgren - state of DevOps report 2016
- 9. State of DevOpsReport 2016: 1. High-performing IT organizations deploy 200x more frequently than low performers, with 2,555x faster lead times. 2. They have 24x faster recovery times and three times lower change failure rates. 3. High-performing IT teams spend 50% less time remediating security issues. 4. They spend 22% less time on unplanned work and rework. 5. Employees in high-performing teams were 2.2x more likely to recommend their organization as a great place to work. 6. Lean product development predicts higher IT performance and less deployment pain. Source: Dr Nicole Forgren - state of DevOps report 2016
- 10. Highlights of DevOpsResearch: When organisations employ DevOps Practices: 1. Throughput and stability improve together. 2. Firms with High-performing IT organisations were twice as likely to exceed their profitability, market share and productivity goals. 3. IT performance is predictive of organisational performance. Sources: “What I Learned From Four Years Scienc-ing the Crap Out of DevOps” – N. Forsgren 2016 “The Role of Continuous Delivery in IT and Organisation Performance” – N. Forsgren & J, Humble 2016
- 11. Our Talk Today: “Everybusiness needs to be able to deliver new products to market fast. Chef and Manageware will discuss how a combination of a change in culture along with collaborative tools, can enable your IT teams to deliver the changes your customers want consistently, faster and with more confidence.”
- 12. CULTURE Community is important Aplace for help A place to shine / show A place to communicate Permission to innovate / help / learn Positive enforcement A purpose: “will it get us nearer…” as a driving principal… More links and information here: goo.gl/UK6VSk
- 13. Tools Choose Tools that:Encourage Collaboration Make Innovation Safer
- 14. Findings for Toolingin DevOps Research: QUIZ: How do these correlate with IT performance? Third Party Scripts Home-grown Scripts Golden Images Manual Config Management Commercial Config Management Opensource Source: “What I Learned From Four Years Scienc-ing the Crap Out of DevOps” – N. Forsgren 2016 KEY: + Correlates with positive IT performance ~ No Correlation -- Correlates with poor IT Performance
- 15. Findings for Toolingin DevOps Research: How do these correlate with IT performance? ~ Third Party Scripts ~ Home-grown Scripts ~ Golden Images ~ Manual Config Management -- Commercial Config Management + Opensource Source: “What I Learned From Four Years Scienc-ing the Crap Out of DevOps” – N. Forsgren 2016 KEY: + Correlates with positive IT performance ~ No Correlation -- Correlates with poor IT Performance
- 16. Our Talk Today: “Everybusiness needs to be able to deliver new products to market fast. Chef and Manageware will discuss how a combination of a change in culture along with collaborative tools, can enable your IT teams to deliver the changes your customers want consistently, faster and with more confidence.”
- 17. Continuous Delivery is •Fast, reliable Tests along with Deployment Automation • Trunk-based dev and Continuous Integration • Application code, application config and system config all in Version control. • Effective Test Data Management* • Incorporating Security and Security teams into Delivery Process*
- 18. Continuous Delivery Research,Findings: • Benefits for your teams: Lower deployment pain Higher IT Performance (Throughput and Stability) Lower Change Fail Rates Decreased team burnout Identifying strongly with your team (as a team member) • For your Organization Higher Organisation Performance (productivity, market share, profitability). Source: “The Role of Continuous Delivery in IT and Organisation Performance” – N. Forsgren & J, Humble 2016
- 19. Recap: • What itis to move fast, • Why moving fast is important • What Chef see as culturally important when implementing DevOps • Why delivering ’The Goods' is important to your organisations.
- 20. Chef History 2008: + 2009:+ 2011:
- 21. 25,000+ Organizations 50% ofthe top 2000 organizations
- 22. Expansion of Chef’sTools • Application Portability • Oversight and Reporting • Continuous Delivery (Apps and Infrastructure) • Security and Testing
- 23.
- 25.
- 27.
- 29. Workflow Tests Applications Tests Infrastructure Worksw/ Chat-Ops Fires Jenkins Jobs
- 30. Workflow Pipeline Shape Thestages are fixed, and each stage has a fixed set of phases VERIFY BUILD ACCEPTANCE REHEARSA L DELIVEREDUNIONAPPROV E DELIVE R Lint Syntax Unit Security Quality Publish Lint Syntax Unit Provision Deploy Smoke Functional Provision Deploy Smoke Functional Provision Deploy Smoke Functional Provision Deploy Smoke Functional Submit Change Does this code change look good? Do we want to ship this?
- 31. Compliance • Agent orAgentless • Windows and Linux • On Demand • Scheduled • Test in Dev • Smart Profiles • Corporate Profiles
- 32. Available Compliance Policies •Basic Linux • Basic MySQL • Basic PostgreSQL • Basic SSH • Windows Server 2012 R2 Base Security • CIS AIX 5.3 and AIX 6.1 Benchmark Level 1/2 • CIS IBM AIX 7.1 Benchmark Level 1/2 • CIS Amazon Linux 2014.09-2015.03 Benchmark Level 1/2 • CIS Apple OSX 10.10 Benchmark Level 1/2 • CIS Apple OSX 10.11 Benchmark Level 1/2 • CIS CentOS Linux 6 Benchmark Level 1/2 • CIS CentOS Linux 7 Benchmark Level 1/2 • CIS HP-UX 11i v3 Update 2 Benchmark Level 1/2 • CIS Oracle Solaris 10 Benchmark Level 1/2 • CIS Oracle Solaris 11.2 Benchmark Level 1/2 • CIS Red Hat Enterprise Linux 6 Benchmark Level 1/2 • CIS Red Hat Enterprise Linux 7 Benchmark Level 1/2 • CIS SUSE Linux Enterprise Server 11 Benchmark Level 1/2 • CIS SUSE Linux Enterprise Server 12 Benchmark Level 1/2 • CIS Ubuntu 12.04 LTS Server Benchmark Level 1/2 • CIS Ubuntu 14.04 LTS Server Benchmark Level 1/2 • CIS Microsoft Windows 10 Enterprise (Release 1511) Benchmark Level 1/2 + BitLocker • CIS Microsoft Windows Server 2012 (non-R2/R2) Benchmark Level 1/2 - Domain Controller / Member Server • CIS Microsoft Windows 7 Benchmark Level 1/2 + (with/without BitLocker) • CIS Microsoft Windows 8/8.1 Benchmark Level 1/2 + (with/without BitLocker)
- 33.
- 34.
- 35. Questions Please &Thank You! Where to Learn More / Links: • http://chef.io/automate • Learn.chef.io <- Free training. • https://www.chef.io/customers/ stories from our Customers • Culture resources: https://goo.gl/UK6VSk • Nicole’s talk about statistics shown: https://goo.gl/N94W0p • Demonstration video of habitat: https://youtu.be/aKrEmadJMa4 habitat.io ant@chef.io @anthonyhodson
Editor's Notes
- #4 (slide3)I believe in delivering on my promises so let's break apart today's topic to show how this is worthwhile.
- #5 (slide 4) Let’s define Fast for ourselves… Questions (Ask audience): what Fast means to them and their business? What’s the problem with moving slow? What would fast be compared to how it is today? If you don’t have a destination, how will you know when you get there? Answers on next slide.
- #6 (slide 5) You're all here to talk about dev-ops (thanks for taking the time to listen to me today) so I believe you all agree that getting new products or features to your customers is worthwhile, but perhaps we can put some figures behind it.
- #7 (slide 6) 25,000 Professionals over 5 years contributed to these figures. Rigorous statistical analysis on these figures 1. High-performing … We're going to see a polarization of ability as time moves on between companies doing this and those not. 2. They have 24 times faster recovery… So let's say there's around 14.4h of production issues a year, averaged out to per month is 72 minutes due to change failures. When problems arise they occur 1/3rd of the normal rate (24min per month) and take 1/24th of the time to fix so averaged out that's 1/24th of 24 = 1min, This is the experience of companies employing DevOps practices.
- #8 (slide 7) 3. High-performing IT teams spend 50 ... I think this metric is impressive but I'll show you how this has moved on with Chef and we'll talk about how later. 4. They spend 22 percent less time on unplanned work and rework. Where could this time be spent where it's better valued?
- #9 (slide 8) 5. Employees in high-performing … Unhappy team members are not team members for long, especially in technology. 6. Taking a lean approach to product development (for example, splitting work into small batches and implementing customer feedback) predicts higher IT performance and less deployment pain. Predicts, this is an important word. I enjoy Nicole's work she's been working with Jezz Humble both really smart people who've worked at Chef. We're going to look a little deeper into their findings because it will either help you understand why DevOps is important to you, your organisation and your teams. But also a little about what's probably not going to help you get there.
- #11 (slide 10) Nicole's got a great talk “What I Learned From Four Years Scienc-ing the Crap Out of DevOps” 1. Throughput and stability… You can have them both, they're not at odds. 2. Firms with High-performing IT organisations …. Does when my company does well, it's good for me, I expect it's the same for you. 3. IT performance is predictive of organisational performance. If you go away remembering one thing remember this: How well your IT team performs predicts (not just correlation) your organisation’s performance
- #12 (slide 11) What we're talking about here is a culture of innovation. And allowing that innovation to operate in a system where others are also free to innovate. DevOps is seeking to remove the mundane, let the machines do the repetitive, let the systems manage the definable and let your teams work on the bigger problems, break those down define the solution and move on and up.
- #13 (slide 12) There is a lot written about culture in DevOps For good reason.
- #14 (slide 13) You can implement DevOps without buying a thing, Opensource, in house, bespoke; make a tool exactly in-line with your needs, put the hours in, pay your smart people and have them document it, train others in your organisation on how to use it; how to maintain it and how to interface it. Maybe you can sell it… But your probably better off taking advantage of your domain expertise, taking advantage of your position in the market and carefully selecting your tools and aligning your culture. And as much as I would love to say that tools will make up for shortcomings in culture, it's just not true. My advice is to choose tools that aid DevOps Encourage Collaboration Make Innovation Safer
- #15 (slide 14) Ask of these which do you think will correlate with high performing IT Which have no correlation Which if any correlate with poor performance? What do you think? (Pause)
- #16 (slide 15) What can we read from this? DIY does not usually work when trying to improve IT Performance (which predicts org performance) Commercial Config Management, those systems that are an overhead rather than a resource are not helping but hindering IT performance. Employing Opensource in your organisation is something those who perform well mostly do… Why do we think that is? Speed of development progression, community learning, community events, looking under the covers.
- #17 (slide 16) There may be other ways to get your changes to your customers with the quality you need… But for now, with what we know, if you want to move Fast with Consistency and have the confidence to put it into production (because it's been tested with it's dependencies, because its been unit tested, because you can put it back if it does go wrong) Continuous Delivery is your tool.
- #18 (slide 17) These are the future and early adopters are doing this to get further ahead.
- #19 (slide 18) These sound familiar right? Within DevOps Continuous Delivery is core to moving faster which explains that echoing of DevOps' typical success markers.
- #20 (slide 19) So we've all got an understanding of: What it is to move fast, Why moving fast is important What Chef see as culturally important when implementing DevOps And Why delivering 'the goods' is important to your organisations and teams and as you'll be bringing this to your organisation, it's going to reflect well on you too. Now we're X Minutes into my talk, I'm going to tell you a little about Chef, our OpenSource roots and how we marry that with our premium features to deliver value to your organisation.
- #21 (slide 20) Adam Jacob was a Vocal consultant for puppet leading up to 2009 when he decided that things were not as good as they could be: The language was restrictive (built with Ruby but no ability to use it) The order of execution was difficult to predict The scalability was floored … In 2009 Adam Jacob wrote Chef and today he’s our CTO. He’s still an outspoken member of the open source community and was speaking in open spaces this week giving technical advice to chef users. Imagine Bill Gates talking you through pivot tables in excell… that would be helpful right. In 2011 Chef introduced Windows Support and it’s a first class citizen, to our array of Unix based environments.
- #22 (slide 21) Our customers come from across verticals, from some of the largest enterprises, mid-market contenders to ambitious start-ups. Our software gives these organisations the sharpest tools, backed by a committed team of experts at Chef as well as a famously active and collaborative open-source community.
- #23 (slide 22) Since our initial Infrastructure “Infrastructure Automation” was released, Chef has continued to look at the most significant technology challenges organisations face; and we have applied that same ethos of Flexibility and control to these new areas. These are not areas any other Company has gone into combined, this is where Chef differs from Ansible, Saltstack, Puppet. Application portability (Habitat) Large system oversight and reporting (visibility) Continuous Continuous Delivery with Integration for applications along with their infrastructure code (chef Workflow) and Security and Testing - through Chef Compliance, which is what we're discussing today. All of this lets your teams work together to build great things.
- #24 (slide 23) Chef Automate is built on our opensource base of Chef, Inspec and Habitat Chef- Open-source Infrastructure Management - Define your system in code, start with a part of it and expand or define a whole system and deploy it in moments. Windows and Linux. Deploys to nearly anywhere: Dedicated, Docker, Cloud, Openstack Private Cloud, VMWare… it uses a real and friendly programming language and is supported by enterprise partners (VMWare, Microsoft, AWS, F5, Oracle….)and cherished by the thriving open source community. There's no lock in. Inspec – means: Infrastructure-Specification - Opensource testing language, easy to read (even for non techs) easy to write. Ask it to test what you want to know, don’t write down how to do it. Habitat - Application portability tool. Package up your application and all of its dependencies and launch them from a single executable. Using a supervisor have these 'nodes' work together as one. An exciting technology learn more at habitat.sh
- #25 (slide 24) 25,000+ Organizations 50% of the top 2000 organizations Server Client Ruby Based Very popular Learn.chef.io Mature local testing environments Huge resources written by community and Chef (don’t re-invent the wheel) Windows and Linux / Unix Provisioning only Ongoing control Works with most things!
- #26 (slide 25) Habitat is an application automation too which is made up of two components: A packing tool which pulls in all the dependencies for an application, that could be some web scale applications or legacy non-web specific products. The output is a single binary which runs on a node, without worrying about the underlying infrastructure (currently Linux only) It is also a supervisor which allows you to control deployments of multiple ‘instances’ and have them working together in synergy. It is made to be used in ephemeral infrastructure As opposed to being a competitor to Docker it works nicely when put with Docker.
- #27 (slide 26) Local / development integration testing and compliance consistency Automates tests in a pipeline Production system auditing
- #28 (slide 27) Describing the what rather than the how, It’s easy to read it’s easy to write and it’s using the same code as Chef (Ruby).
- #29 (slide 28) Building on this open source base is a suite of premium tools which have been designed to solve the problems you'll encounter when using these open-source tools at scale in production: How do we see what everything was doing last Tuesday. Which of these Systems are not compliant with corporate policy Which Systems are not in their desired state, when did this happen How can I show management how much change has been through our system in the past week and how does that compare to the previous month? How can we test our applications with the infrastructure in a mature collaborative way? Workflow is a Continuous Delivery Pipeline Visibility is a dashboard Compliance is a security testing suite
- #30 (slide 29) Workflow is a Continuous Deployment pipeline It will test and ship your application code (we use it to ship our application code) It will test and ship your infrastructure code It will integrate with your chat-ops It will work with your existing pipeline if you've got existing investments like Jenkins. Show pipeline shape. Pipelines are made of Phases and Stages, activates are defined in chef code. Test environments can become ephemeral so you're only paying for your testing when you're doing testing. The pipeline is tried, tested, used by Chef ourselves and come to through our work with all of our customers moving faster.
- #31 (slide 30) Overview: Six fixed stages, each with phases which can be configured. Verify Stages are ‘Fast Fail’ tests which don’t provision anything, they’re run before bothering anyone this also enforces company / industry standards you set for lint / syntax checks. Changes are currently on a ‘feature branch’ in the repository. Approve? a human gate to check that this look like it solves a problem? Could be a team manager or peer review. Build checks your changes once the merged with with trunk, does it still pass those previous tests? What about other Security and Quality tests you’ve written. Acceptance, this is when we Provision infrastructure (if needed), Deploy the code onto infrastructure and run your Smoke (is it working) and Functional tests (is it doing what we wanted) Deliver? A second human gate, If all goes well beyond this stage it will progress to delivered which is whatever you want it to be, a release candidate through to being pushed into production automatically. Union the system is now to be tested with the dependencies it has. A bigger broader test suite is run against the whole system now to check it works (smoke test) and is doing what it set out to do (functional tests). Rehearsal Typically your most production like system, this may have production like data in it, perhaps simulated load perhaps a team of human testers. Delivered, this could be your production environment along with some production validation tests or a repository or anything else you want it to be.
- #32 (slide 31) From the compliance section you’re able to see where your nodes are and are not compliant with policies Compliance is a Security testing tool. Windows and Linux, Agent or agentless. On Demand and/or scheduled scanning Smart profiles which know when they're relevant to the platform. Corporate profiles which can define all of your infrastructure security needs Tooling allows the security testing to happen earlier and easier so a small change is required when the initial work is done rather than big changes when it's found to be a problem later in the process or even production. Industry profiles like CIS L1/L2 and we're closing in on PCI modules in the next quarter.
- #34 (slide 33) You can see here an overview of all of your chef estate. The aim is to give you a meaningful dashboard of everything chef is managing for you. TOP LEFT We've got an overview of last 8 hours of our chef controlled systems, successes, failures and cookbook changes, workflow changes. This graphic could represent all of your infrastructure and it's shows what is and what is not in your desired state. TOP RIGHT we have an overview of automated testing nodes and how much testing they've handled in the past two weeks. Lower Centre We have an overview of how much change is being put through your Workflow Pipeline over the last two weeks. We are using this very tool (automate/workflow) to develop the product you see here, and we'll be delivering more functionality for Compliance overviews and habitat in the coming months.
- #35 (slide 34) Chef sell one product and you get everything with it to help you succeed. Pricing is based on the number of nodes so starting small comes with little to no investment (free trials). Further demonstrations available on any of these systems and features. Consulting, training and DevOps Journey Assessments are also available from Chef. Subscriptions all come with SLA'd support from our dedicated team. .
- #36 (slide 35) Where do I Learn more? Come speak to myself or Toby about how this could help your organisation when aligned with your goals and company culture. Links to research, links to Toby and Ant's details, Habitat - Habitat.sh Inspec - Inspec.io Chef - chef.io