Transform your Ops team with Extreme programming

The purpose of this talk is to dive into what does extreme programming(XP) mean to Operations.  It will be a deep dive on the lessons learned from operating an large scale public facing web service using the various practices like test driven development, continuous integration, pair programming, collective ownership and refactoring. It will attempt to outline how these practices are similar and different. 

 

We currently run about 5000 web applications in our production environment which continuously deploys distributed software.

 
1 favorite thumb_down thumb_up 8 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

1. Brief overview of extreme programming and the values it delivers to software development

2. Overview of the role of a Devops/Operator/SysAdmin for running various services

3. How we have adopted XP in our DevOps process at Pivotal

4. How to achieve the value of XP(extreme programming) by tailoring your Devops practices.

 

Learning Outcome

Anyone attending this session will learn about how your operations team will benefit by applying XP and develop capabilities to operate large scale cloud applications

Target Audience

DevOps/Operators

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Joel Tosi
    By Joel Tosi  ~  2 years ago
    reply Reply

    Hi Tushar,

        I enjoy the topic idea - bringing XP back and how it relates to DevOps.  Your learning outcomes seem awfully ambitious - after attending your session people will know how to do agile operations at scale?  Do you really mean that?  If so, I need to see that reflected in your submission.  Right now I just see a correlation between XP practices and DevOps.

     

    Best,

    Joel

    • Tushar Dadlani
      By Tushar Dadlani  ~  2 years ago
      reply Reply

      Hey Joel, 


      Thanks for your feedback. My intention wasn't very clear in the learning outcomes. The scale I was referring to was scale of operations (ie. Apps + Infrastructure) and not that of people in the operations team. One of the key take aways will be how can a member of an Ops team leverage XP practices to realize the goals of the Agile manifesto in operations. This individual transformation will lead to better processes which in turn will help them reach their desired operational scale. Hope that answers your question. 

       

      Thanks, 
      Tushar

       

      • Joel Tosi
        By Joel Tosi  ~  2 years ago
        reply Reply

        Thanks for updating the submission Tushar.  Could you give me an example or two of an XP practice and how you used it in Operations - along with why and what happened by doing it?  I'm ok with you not having presented before, I just want to understand how you are making the connection and if you will be able to get the audience to make that connection.

        Best,

        Joel

        • Tushar Dadlani
          By Tushar Dadlani  ~  2 years ago
          reply Reply

          Let's take test driven development for example from XP. The main purpose of TDD is to provide faster feedback to the developer and have a low cost of refactoring. In operations it looks like a stoplights dashboard, which is documented here (https://docs.pivotal.io/pivotalcf/opsguide/metrics.html) . This dashboard provides immediate feedback to the operator about the state of the system. Also since the configuration of the dashboard is all code, the cost of changing the dashboard is very low. Ex: we have started migrating our runtime backend to completely change and adding monitoring and metrics for the new components took us 2 days of pairing to set up. 

          Let me know if you need any further clarification or another example.

          Best,
          Tushar

           

          • Joel Tosi
            By Joel Tosi  ~  2 years ago
            reply Reply

            Thanks for that Tushar.  To me, TDD and your example are not the same.  TDD is a tool to drive out design.  It helps you decouple systems and dependencies.  A dashboard, while providing feedback to ops, is after the fact and I am missing the connection to how that would drive a design or help decouple systems.

            Am I way off?

            • Tushar Dadlani
              By Tushar Dadlani  ~  2 years ago
              reply Reply

              Hi, 

              Some points of clarification: 
              We use TDD for development of our tools and applications. The value proposition of that is exactly as you have stated above, drive design decisions about how to manage DevOps apps and tools and potentially derive patterns for developing applications. 

              Example: We depend a lot of external APIs to query information about the platform that we are operating. We get very slow feedback on our code, if say for example, we need to run an async request through the AWS cli every time we need to test code that runs describe-instances. We stub responses and use tests to drive out our code for the application. We also evolved in understanding patterns about data transformations that occur in our operational environment. Example: Transforming 'count' of log search results to dashboard metrics. Initially we wrote on app to transform just ssh abuse logs, but over time we ended up writing an application that can transform 'count' of any log query results to a metric.

              What I was referring to in the above comment was from an operators standpoint, establishing an easy to update dashboard is critical to the success of an Ops team. This dashboard needs continuous refactoring to have metrics that are currently critical to a running system. Example: A bug in a web application code that opens 10 times the number of ports that it is supposed to, would entail monitoring the number of open ephemeral ports on the system till a point of time the bug is fixed in the code. . This would require a dashboard that can be easily changed. (all our dashboard configs are stored in code). 

              Let me know if this helps answer your questions. 

  • Shiv Sivaguru
    By Shiv Sivaguru  ~  2 years ago
    reply Reply

    Tushar,

    will you be sharing the results of this approach in terms of improvements or benefits seen?

    Are they quantifiable?

    • Tushar Dadlani
      By Tushar Dadlani  ~  2 years ago
      reply Reply

      Hey, 

      I will be primarily be sharing the benefits of using XP on a day to day basis. Also, how it enables our team to operate large scale distributed software with ease. To be honest, they aren't easily quantifiable as the only metric we track is velocity based on user stories. I could present about what our backlog looks, how we point stories, etc, but I don't want the talk to tie into a particular tool. 

       

      Thanks, 

      Tushar