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

Opinionated DevOops

Naren
August 08, 2018

Opinionated DevOops

An opinionated talk I gave to my client team about devops practices.

Naren

August 08, 2018
Tweet

More Decks by Naren

Other Decks in Programming

Transcript

  1. DevOps

    View Slide

  2. WHO AM I ?
    Naren
    Senior Software Consultant
    Tarka Labs

    View Slide

  3. WHAT IS DEVOPS ?
    DevOps is the combination of cultural philosophies, practices, and
    tools that increases an organization’s ability to deliver applications
    and services at high velocity: evolving and improving products at a
    faster pace than organizations using traditional software development and
    infrastructure management processes. This speed enables organizations to
    better serve their customers and compete more effectively in the market.

    - AWS

    View Slide

  4. Philosophies
    Practices
    Tools
    WHAT IS DEVOPS ?

    View Slide

  5. HOW WAS IT BORN ?

    View Slide

  6. PRE-2000’S
    Business
    Dev
    QA
    Ops



    Friction
    Friction
    Friction
    Customer
    Release Cycles:

    Months or Years
    Idea

    View Slide

  7. 2000’S
    Business
    Dev
    QA
    Ops
    Friction
    Customer
    Release Cycles:

    Weeks or Months
    Agile
    Idea

    View Slide

  8. DEV (VS) OPS

    View Slide

  9. NOT MY PROBLEM
    Dev
    Prod Issue

    View Slide

  10. IT’S EVERYONE’S PROBLEM
    Dev
    Prod Issue

    View Slide

  11. 2009’S
    Velocity Conf
    10 Deploys Per Day, Dev & Ops cooperation at Flickr
    John Allspaw & Paul Hammond

    View Slide

  12. 2010’S

    View Slide

  13. 2010’S
    Business
    Dev
    Ops
    Customer
    Release Cycles:

    Hours or Days
    Lean
    Idea
    DevOps

    View Slide

  14. THE DEVOPS MOVEMENT STARTED

    View Slide

  15. PHILOSOPHIES
    Work together to optimize both the productivity of developers and
    the reliability of operations
    Increased communication
    Full ownership

    View Slide

  16. PRACTICES
    Continuous Integration
    Continuous Delivery
    Microservices
    Infrastructure as Code
    Monitoring and Logging
    Communication and Collaboration

    View Slide

  17. CONTINUOUS INTEGRATION
    Regularly merge their code changes into a central repository
    Find and address bugs quicker and improve software quality
    Reduce the time it takes to validate and release new software updates.

    View Slide

  18. CONTINUOUS DELIVERY
    Code changes are automatically built, tested, and prepared for a release
    to production
    Deploy changes to testing or staging or production environment
    Developers will always have a deployment-ready build artifact that has
    passed through all testing process

    View Slide

  19. MICROSERVICES
    Each service is scoped to a single purpose
    Runs in its own process and communicates with other services through
    a well-defined interface (HTTP, GRPC, Queues)
    Deployed independently or grouped with similar services

    View Slide

  20. INFRA AS CODE
    Infrastructure is provisioned and managed using code and software
    development techniques
    Treat infrastructures like application code
    Since it’s like code, it can be deployed with standard patterns, updated
    with latest versions and patches

    View Slide

  21. MONITORING AND LOGGING
    Monitor metrics and logs to see how application and infrastructure
    performance impacts end user experience
    Alerts and continuous monitoring helps to respond to incidents
    effectively
    Gives a continuous feedback to evolve business logic

    View Slide

  22. COMMUNICATION AND COLLABORATION
    The tooling and workflows brings the team together to deliver features
    Use of chat, issue tracker and wikis speeds up the communication
    among devs
    Makes other teams like sales and marketing to align more closely on
    goals and projects

    View Slide

  23. TOOLS

    View Slide

  24. DEVELOPMENT
    Git
    Docker
    JIRA

    View Slide

  25. CI/CD
    Concurse
    Jenkins
    GoCD
    Gitlab CI
    Circle CI
    Travis CI
    Complex/Enterprise
    Simple

    View Slide

  26. DEPLOYMENT
    Chef
    Puppet
    Terraform
    SaltStack
    Ansible

    View Slide

  27. SERVICE DISCOVERY
    Zookeeper
    Consul
    EtcD
    Complex/Enterprise
    Simple

    View Slide

  28. ORCHESTRATION
    Kubernetes
    Apache Mesos with Marathon
    AWS ECS/Fargate
    Complex/Enterprise
    Simple

    View Slide

  29. MONITORING
    Nagios
    Prometheus
    Icinga
    New Relic
    AWS Cloud Watch

    View Slide

  30. View Slide

  31. BRINGING IN THE DEVOPS CULTURES AND
    PRACTICES

    View Slide

  32. To Be Continued…

    View Slide

  33. View Slide

  34. FEATURE PLANNING
    5 days or 10 days sprints in JIRA
    Break down the features into achievable chunks
    End of every sprint cycle release a version of the software

    View Slide

  35. GUIDELINES
    Git should always have two branches: master and dev
    Develop in master branch until initial PoC is done (Where the idea is
    not an hypothesis anymore)
    Lock the ‘master' branch. Start a ‘dev’ branch

    View Slide

  36. GUIDELINES (CONTD.)
    Pick a feature from current sprint (JIRA), branch out a ‘feature’ branch from ‘dev’ branch.
    After implementing one of the feature, write unit test cases and merge it back to ‘dev’
    branch. Then, delete the ‘feature’ branch. Our CI system kicks off as code is pushed to ‘dev',
    runs tests and deploys it in the dev server(?)
    Once all the features for the currents sprint are done, After a quick code review we merge
    dev to master.
    The CI system will kick off, builds and deploys the code pushed to master in prod machines
    Repeat the steps for every sprint in JIRA

    View Slide

  37. GUIDELINES (CONTD.)
    After initial development, note that the master branch will always be
    locked, one cannot directly work on master branch. You can work by only
    branching out. The tip of the master will always be the latest, stable,
    production release.
    Refer Semantic Versioning for versioning your releases: 

    https://semver.org/

    View Slide

  38. GUIDELINES (CONTD.)
    Tagging the releases helps us to quickly rollback prod systems. If an
    unknown bug makes v0.2 unstable, we can quickly rollback to v0.1while
    fixing bug in v0.2. 

    When rolled back client may lose the new features of v0.2 but they
    won’t experience total downtime as it’s rolled back to working version
    v0.1.

    Once bug in v0.2 is fixed, it's deployed again

    View Slide

  39. Time
    master
    dev
    feature
    branches
    New feature in
    computer vision
    Tag
    v0.2.0
    New feature
    in API and
    DB Tag
    v0.0.1
    (Lock Master branch)
    Tag
    v0.1.1
    Tag
    v0.2.1
    Work on master
    branch until a very
    basic MVP is done


    View Slide

  40. TESTING
    Write unit test cases for the code before merging to ‘dev’ from ‘feature'
    branch
    Unit test cases helps us to check the sanity of every function in the code. So,
    any function in the code should have only one responsibility.
    Unit test cases are important while setting up CI/CD. Since every feature is
    continuously deployed by the system, code should be well tested before
    pushing to master branch

    View Slide

  41. LOGGING
    When a piece of code is written, it should provide some way to give the
    insights while running
    A very simple way to do it is having a basic logging system dumping logs
    to files.
    In future we will see how we can create a dedicated logging
    mircorservice that collects logs from other services and provide
    application and business insights.

    View Slide

  42. Naren

    @DudeWhocode

    View Slide