Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Year of Talking about DevOps

kellobri
November 09, 2019

A Year of Talking about DevOps

kellobri

November 09, 2019
Tweet

More Decks by kellobri

Other Decks in Technology

Transcript

  1. Reflections on a year spent
    talking to Data Scientists
    about DevOps

    View Slide

  2. Solutions Engineering isn’t Dev and it isn’t Ops...
    Industrial Research
    Business Management
    Human Resources
    Government Work
    Regulated Environments
    Big Data Applications
    Cloud Infrastructure
    R in Production
    What is there to learn?
    What are the needs?
    What are the problems?
    Solutions Engineers!

    View Slide

  3. What are the problems?
    1. Legitimacy
    How do you get R recognized as
    an analytic standard?
    How do you make R a legitimate
    part of your organization and get
    the resources you need to
    support it?
    In many organizations, R enters through the back
    door when analysts download the free software
    and install it on their local workstations…
    Some organizations struggle to standardize on R
    due to a lack of management and governance
    around open source software.
    At the same time, organizations may neglect R
    on user workstations, thereby increasing
    security, legal, and operational risks.
    - Nathan Stephens, R Views 2016

    View Slide

  4. What are the problems?
    1. Legitimacy

    View Slide

  5. (super-quick)
    Introduction to DevOps

    View Slide

  6. View Slide

  7. 1. DevOps is a philosophy / set of practices
    2. Which create new processes for
    collaboration between Dev and Ops teams
    3. There’s nothing new in DevOps
    A framework for making sense out of common sense

    View Slide

  8. Vicious cycle of mutual resentment and distrust
    Dev Silo IT/Ops Silo
    THE FEAR
    “Hey - could you just put this thing in
    production real quick?”
    “Uh.. I just deployed this little change, and
    something might be broken”

    View Slide

  9. Strategies for Managing
    Code Handoffs
    Steal Existing
    & Define Shared Goals

    View Slide

  10. SUPER-vicious cycle of mutual resentment and distrust
    Data Science Silo IT/Ops Silo
    THE FEAR
    “Hey - I wrote this code using a bunch of
    open source packages some random person
    from the internet created …
    Also, I built a Web App - is that cool?”

    View Slide

  11. Challenges for the R User
    Organizational
    ● Legitimizing R
    ● Working with IT
    Technical
    ● Experience
    ● Education
    ● Exposure

    View Slide

  12. Shiny in Production Journey
    Code Profiling
    Version Control
    Testing
    Deployment/Release
    Access/Security
    Performance Tuning
    Shared Goal:
    Shorten the distance between
    development and production
    Shared Goal:
    The improvement of daily work
    Shared Goal:
    Reduce the risk of deploying a
    breaking change

    View Slide

  13. Code Quality and Performance
    The “Hour-Long-Talk” of
    Data Products
    - Rambling, Cluttered
    - Parts that work well
    - Parts that work not-so well
    Local Development
    EDA, Prototyping, Iteration
    The “Lightning-Talk”
    of Data Products
    - Targeted
    - Elegant
    - Streamlined
    - Optimized
    Production
    Development

    View Slide

  14. Turn a Prototype into a Production Application
    Performance Workflow
    1. Use shinyloadtest to see if app is fast enough
    2. If not, use profvis to see what’s making it slow
    3. Optimize
    a. Move work out of shiny (very often)
    b. Make code faster (very often)
    c. Use caching (sometimes)
    d. Use async (occasionally)
    4. Repeat!

    View Slide

  15. Testing: Why Test Shiny Apps?
    ● You’ve developed a nice app
    ● You want to be confident that it will keep running in the future
    Things that can change/break a Shiny application
    ● Modifying code
    ● Upgrading the shiny package
    ● Upgrading other packages
    ● Upgrading R
    ● External data source changes or fails
    Shared Goal:
    Reduce the risk of deploying a
    breaking change

    View Slide

  16. Automation!
    ● I don’t want to remember to run this testing procedure
    ● I don’t want to have to assure someone from IT that I ran it
    ● I certainly don’t want to hand the job off to them
    GIVE IT TO THE MACHINES
    Shared Goal:
    The improvement of daily work

    View Slide

  17. Shared Goal:
    Shorten the distance between
    development and production
    ADVOCATE FOR A
    SANDBOX PUBLISHING
    ENVIRONMENT
    B. User Acceptance Testing
    A. Automated
    Snapshot Testing

    View Slide

  18. ● Deployment is any push of code to an environment (test, prod)
    ● Release is when that code (feature) is made available to users
    Application-based release patterns vs. Environment-based release patterns
    DevOps Learning: Decouple deployment from release

    View Slide

  19. The DevOps Handbook
    1. Accelerate Flow
    - Make work visible
    - Limit Work in Progress (WIP)
    - Reduce Batch Sizes
    - Reduce the number of handoffs
    - Continually identify and elevate
    constraints
    - Eliminate hardships and waste
    2. Utilize Feedback
    - See problems as they occur
    - Swarm to solve problems and
    build new knowledge
    - Keep pushing quality closer to
    the source
    - Enable optimizing for
    downstream work centers
    3. Learn and Experiment
    - Enable organizational learning
    and a safety culture
    - Institutionalize the improvement
    of daily work
    - Transform local discoveries into
    global improvements
    - Inject resilience patterns into daily
    work
    Three principles form the
    underpinnings of DevOps:

    View Slide

  20. Start by answering some questions…
    - What is a Shiny Application?
    - Who is the audience?
    - What is your service level agreement definition? (SLA)
    - What does your analytic architecture look like today?
    - What are your goals for evolving this architecture?
    - How will monitoring be handled?
    - Who is responsible for maintenance?
    Make work visible, Define shared goals, Build a checklist, Iterate
    Empathetic Communication is Challenging

    View Slide

  21. Production is...
    CUSTOMER/USER FACING
    - Ready to use
    - Software that end users are using
    - An app that is live and available to the
    end user
    - Apps on our production server are
    available to our clients
    - Client facing
    Credibility
    AT SCALE
    - Scaled to a larger audience
    - Bulletproof, scalable, fails predictably
    - Live to 1000 of users with production
    vehicle data
    SERVICE LEVEL AGREEMENTS
    - Required for mission-critical operations;
    downtime affects the ability to serve customers
    - Deployed for end users to have continual
    access without performance issues
    ENVIRONMENTAL REQUIREMENTS
    - An area where validated applications are deployed in a locked down
    environment
    - The main part of a company that handles all process
    - Application or system operates effectively without much maintaining effects
    - A server or environment that runs the “final” applications that your ultimate
    end-users (often external customers) use to get stuff down
    DOCUMENTATION - TESTING &
    MONITORING
    - Creating apps that can reach a wider
    audience and are deployed/tested in a
    consistent manner
    - Running in a way that is stable to use,
    documented and monitored

    View Slide

  22. January
    1. Shiny in Production Workshop
    2. Configuration Management Tools for the R Admin
    April
    3. Championing Analytic Infrastructure
    July
    4. Art of the Feature Toggle
    5. Environmental Release Patterns
    August
    6. Shiny in Production: Building bridges from data science
    to IT
    September
    7. Data Product Delivery: The R user’s journey toward
    improving daily work
    8. The R in Production Handoff: Building bridges from data
    science to IT
    October
    9. Interactivity in Production
    10. Is there a Future for DevOps?
    speakerdeck.com/kellobri
    solutions.rstudio.com
    community.rstudio.com
    #radmins

    View Slide