DevOps

WHO AM I ? Naren Senior Software Consultant Tarka Labs

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

Philosophies Practices Tools WHAT IS DEVOPS ?

HOW WAS IT BORN ?

PRE-2000’S Business Dev QA Ops Friction Friction Friction Customer Release Cycles:
 Months or Years Idea

2000’S Business Dev QA Ops Friction Customer Release Cycles:
 Weeks or Months Agile Idea

DEV (VS) OPS

NOT MY PROBLEM Dev Prod Issue

IT’S EVERYONE’S PROBLEM Dev Prod Issue

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

2010’S

2010’S Business Dev Ops Customer Release Cycles:
 Hours or Days Lean Idea DevOps

THE DEVOPS MOVEMENT STARTED

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

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

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.

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

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

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

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

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

TOOLS

DEVELOPMENT Git Docker JIRA

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

DEPLOYMENT Chef Puppet Terraform SaltStack Ansible

SERVICE DISCOVERY Zookeeper Consul EtcD Complex/Enterprise Simple

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

MONITORING Nagios Prometheus Icinga New Relic AWS Cloud Watch

No content

BRINGING IN THE DEVOPS CULTURES AND PRACTICES

To Be Continued…

No content

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

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

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

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/

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

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


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

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.

Naren @DudeWhocode