Opinionated DevOops

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

Transcript

1. DevOps
2. WHO AM I ? Naren Senior Software Consultant Tarka Labs
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
4. Philosophies Practices Tools WHAT IS DEVOPS ?
5. HOW WAS IT BORN ?
6. PRE-2000’S Business Dev QA Ops Friction Friction Friction Customer Release Cycles:
 Months or Years Idea
7. 2000’S Business Dev QA Ops Friction Customer Release Cycles:
 Weeks or Months Agile Idea
8. DEV (VS) OPS
9. NOT MY PROBLEM Dev Prod Issue
10. IT’S EVERYONE’S PROBLEM Dev Prod Issue
11. 2009’S Velocity Conf 10 Deploys Per Day, Dev & Ops cooperation at Flickr John Allspaw & Paul Hammond
12. 2010’S
13. 2010’S Business Dev Ops Customer Release Cycles:
 Hours or Days Lean Idea DevOps
14. THE DEVOPS MOVEMENT STARTED
15. PHILOSOPHIES Work together to optimize both the productivity of developers and the reliability of operations Increased communication Full ownership
16. PRACTICES Continuous Integration Continuous Delivery Microservices Infrastructure as Code Monitoring and Logging Communication and Collaboration
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.
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
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
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
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
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
23. TOOLS
24. DEVELOPMENT Git Docker JIRA
25. CI/CD Concurse Jenkins GoCD Gitlab CI Circle CI Travis CI Complex/Enterprise Simple
26. DEPLOYMENT Chef Puppet Terraform SaltStack Ansible
27. SERVICE DISCOVERY Zookeeper Consul EtcD Complex/Enterprise Simple
28. ORCHESTRATION Kubernetes Apache Mesos with Marathon AWS ECS/Fargate Complex/Enterprise Simple
29. MONITORING Nagios Prometheus Icinga New Relic AWS Cloud Watch
31. BRINGING IN THE DEVOPS CULTURES AND PRACTICES
32. To Be Continued…
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
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
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
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/
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
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

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
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.
42. Naren @DudeWhocode