DevOps is nothing but the combination of process and philosophies which contains four basic component culture, collaboration, tools, and practices. In return, this gives a good automated system and infrastructure which helps an organisation to deliver a quality and reliable build. The beauty of this culture is it enables a quality for organizations to better serve their customers and compete more effectively in the market and also add some promised benefits which include confidence and trust, faster software releases, ability to solve critical issues quickly, and better manage unplanned work.
“DevOps is not a goal, but a never-ending process of continual improvement.”
Jez Humble
Here are the key DevOps best practices that can help you for successful implementation of DevOps.
1. Understand Your Infrastructure need: Before building the infrastructure, spend some good time to understand the application and then align your goals to design your Infrastructure and this implementation of DevOps should be business-driven. While understanding infra, make sure you are capturing below components:
2. Don’t jump start: There is any need to automate the complete cycle in one shot, always take a small entity and apply your philosophy and get this validated. Once you feel your POC is justified, start scaling up now and create a complete pipeline and define a process so anytime you can go back and check what all need to improve and where. All these small success will help you to get confidence internally in your team and builds a trust to stakeholder and your customers.
“DevOps isn’t magic, and transformations never happen overnight”
3. Continuous Integration and Continuous Deployment: If your team is not planning to implement this continuous integration and continuous delivery, then it is not fair with DevOps. Even I’ll say the beauty of DevOps is how frequently your team can deliver without disturbance and how much you are automated in this process. Let’s take a use case: You and your team members are working in an Agile team. In fact, there are multiple teams and multiple modules which are tightly coupled in which you are also involved. Every day you work on your stories and at the end of the day, you push your ‘private build’ of your work to verify if it builds and ‘deliver’ it to a team build server and same applies to other individuals. Which indicates you all ‘integrate’ your work in the common build area and do an ‘Integration Build’. Doing these integrations and builds to verify them on a regular, preferably daily basis, is what is known as Continuous Integration.
Continuous Deployment doesn’t mean every change is deployed to production as soon as possible. It means every change is proven to be deployable at any time. What it takes is your all validated feature and build from CI and deploys them into the production environment. And here we can follow some of the practices. a) Maintain a Staging Environment that Emulates Production b) Always deploy in staging then move to production c) Automate Testing of Features and Nonfunctional Requirements d) Automatically fetch version-controlled development artifacts.
4. Define Performance and do benchmarking: Always do some performance testing and get a collective benchmarking report for the latest build shared by your team because this will only justify the quality of your build and the required infra as well.
For example: We have done one performance testing a few days back and got good results, explaining in details. So we did some benchmarking for our CFM machines because we are having a global footprint and at the same time, for us, latency matters and we need CFM in the nearest region. We have verified with our current build how many requests we can handle and we found we are firing more than 200 RPS (request per second). So we planned to check our build capability and fired a good number of requests and noted the number where our build got crashed and noted the RPS and then we did autoscaling of CFM. We might have upgraded our CFM but we planned for auto scaling because the number of requests is an assumption and we don’t want to spend amount for that but at the same time we are ready to consume the experimented traffic. And then we found 7 out 2 CFM are only consuming exact or little less number configuration and request (181 to 191 RPS). So we shared a report to the business team to focus on other regions where we were having very less traffic because we were paying the same amount.
Conclusion: We verified our build which has given good confidence to our dev team and we shared the report to the business team which helped them to plan their marketing strategies, meanwhile we completed auto scaling the process as well.
5. Communicate and Collaborate: Collaboration and communication are the X-factors to help organisation grow and assess for DevOps. Collaboration with business and development team helps DevOps team to understand to design & define a culture. This helps to speed up the development, operations, and even other teams like marketing or sales, allowing all parts of the organization to align more closely with goals and projects.
6. Start Documenting: Document everything (All your work done) which you are spreading across the process and infrastructure and specially the reports, RCA’s (Root cause Analysis), change management. This helps you to go back and see if all issues we faced can be automated in the next cycle or other ways to handle them smoothly without interrupting your production environment.
7. Keep your eyes on cost burning: It has been experienced many a time that if we don’t keep an eye on cloud bills it will keep increasing and will tend to be proportional to the growth of your business till the time you don’t look for optimization. Always do an audit in 2 months and evaluate your cloud computation to optimize. Do some experiment with infra because you should not spend not more than 5 to 10 % of cost for cloud infra if you are completely dependent. Tools you can try : Reoptimize, Cloudyn, Orbitera etc.
“If you are DevOps you should account the no’s.”
8. Secure your infra : If your team follows certain compliances from day 1 then there is very less chance to compromise with your data and this can be easily enabled by providing a setup where you can verify your vulnerabilities. Before moving your build to the production team you may need to follow the standard at an early stage of development by using configured tools like: SonarQube, VeraCode, Codacy, CodeClimate etc.
9. Tool Selection: Always select tools which all are compatible with rest of the toolchain you are planning to use. Why you should have to be so careful is because you have to capture each and every request capture. Once you are done with the tool selection, draft a tools metrics you are willing to capture or will be going to help you to debug. Start logging and monitoring them and have some clear definition for those logs so you can justify and determine that your processes are working as expected. Tools you can have a look: Nagios, Grafana, Pingdom, Monit, OpsGenie, Observium, Logstash etc.
Tool chain for DevOps process:
“If you are not monitoring, you are not in the production”
Conclusion:
An organization that follows all the above best practices creates the right culture, which finally gets the ending it deserves i.e DevOps organization. "A good DevOps organization will free up developers to focus on doing what they do best: write software," says Rob Steward, Vice President of product development at Progress Software. "DevOps should take away the work and worry involved in deploying, securing and running the software once it is written."
| Name | Date | Fee | Know more |
|---|
