The idea
DevOps today
Talking about DevOps brings few things in our mind immediately. Let's list few of them:
- Jenkins
- Ansible
- Terraform
- SonarQube
- Fortify
- Azure DevOps (May be)
- Code Build and Code Deploy (AWS)
- GitOps
- CircleCI
- TravisCI
Let's re-read them in a different way:
| Tool | Purpose |
|---|---|
| Jenkins | Integration Engine |
| Ansible | Infra as code |
| Terraform | Infra as code |
| SonarQube | Quality Monitoring |
| Fortify | Security scan |
| Azure DevOps (May be) | Over all CI/CD |
| Code Build and Code Deploy (AWS) | Build and Deploy |
| GitOps | Deployment and Configuration |
| CircleCI | Integration Engine |
| TravisCI | Integration Engine |
What can we notice in the above given table? The answer is very simple.
Automation Tool --------> Task to be automated
An expert DevOps engineer is the one who knows more and more such tools and have the skill to link all these things together and make the magic happen. With the advent of words like Data Driven DevOps, we are now capturing the metrics of these activities and by looking into the trend of these activities, we are trying to improve the process and at places we call this a Continuous Improvement i.e. the new CI.
Unlearn
Unlearning is very important to learn new things. For now, what is to be unlearnt is how we do DevOps, not what tools we use to do DevOps. Without those tools we won't be able to do DevOps. So, when we say 'Unlearn the way DevOps is done', we mean stop thinking the DevOps just as mindless and disconnected automation of the tasks using tools.
Unlearn that tools for DevOps are limited and you need to play only using those tools. You think it like that because to you the DevOps is still a side activity, basically automate things. Add a tool and get things automated, is not the only thing. DevOps is not only about doing build, deployments and infra creation automatically, it can be about more things and that's why Data Driven DevOps (though it is not DFD) came in existence.
Adapt
The tile could be "Learn" instead of "Adapt", but in that case it would be wrong because there is nothing new you need to learn to do DFD. You just need to adapt.
Now take and deep breath and adapt that DevOps is about:
- designing a system which helps the release process better in quality and faster.
- making that system work in favor of the team for today's and tomorrow's requirement.
- making that system helpful to take decisions based on the trends and available information.
- making that system helpful in case of versioning mismatch and helpful in debugging the problem.
- designing a system, as we design any other system to help the business or any process.
- designing a system just like any other application.
- designing a system, based on data.
Designing a system, based on data - repeat it 10 times and let it sink in!!
Learn
Now you need to learn the skill of translating the DevOps into a full-fledged application development, which might have a lot of:
- technical component other than the tools
- might talk to other systems outside
- entities i.e. data to create, update, retrieve or delete
- notifications to send to various people
- ways for people to register for those notifications
All in all, think as if you are going to design and implement a new system and be open to whatsoever may come and is relevant to that solution. If it looks difficult for you, start with entities and data points which are important and think about their structure and relationship with each other. Start with the good old ER diagram for the entities.
Decide
You might now have a lot of data entities and now you need to decide where to store what, just like how a polyglot data store system comes up. Follow the principles explained to take these decision and you would be good to go. Remember the most important thing:
As long as it makes sense, nothing is strange or awkward to use.
You might feel like using a MQ system to do a particular activity, go for it. Don't hesitate as long as MQ is the right solution and has no other alternative.
Pitfall
Do not over engineer !!!