Limitations

Initial thoughts

Doing DevOps, I never thought anything was missing or it has any limitation in the way we do it. Rather in today's world I realized what we want to achieve is limited by our thoughts not limited by technology. If we talk about the application development, other than coding, we can automate everything else. The most daunting tasks of the previous generation, like zero downtime deployments are now default approach without putting any significant extra effort - Kubernetes or Spinnaker can do it for you in various ways. On top of that you can use Spinnaker with Kubernetes. What else you can ask for!!

Above given was just one example. You take any scenario, there is some or other tools or technology available to do what you want. So one thing was sure that "What" was sorted. We could do anything, any automation. But eventually, the realization started popping up, that its not about the "What" only. Its is equally about the "How".

The truth is that this realization didn't motivate me to do DFD. It's actually reverse. When I did DFD, I realized that doing DFD changes the "How" so majorly and positively, that it actually brings all the power of DevOps and hands it over to the team. By implementing DFD, you can see intents of DevOps actually getting addressed well.

Limitations on How

Centralized control

This can be one of the biggest anti-patterns of DevOps. If you have a build and deployment team, who does all the builds and deployments, then we are again creating silos, instead of breaking silos. If your team can't build and deploy hundreds of applications without DevOps team doing it for them, then the DevOps is not done right.

Generally, the DevOps pipelines are so geeky, that only a set of people can understand it right and use it without making any error. They are not team friendly.

Incomplete

Who didn't hear about CI/CD? If your project has DevOps, you must have heard the word CI/CD a zillion time. Didn't you? I am assuming you would have state of art CI/CD pipelines, capable of doing amazing things. Question is - What else did you do other than CI/CD? If the answer is "Nothing", then here is the second question for you, just food for thought - Did you do DevOps or just CI/CD?

May be this way - Is CI/CD is whole of DevOps? Why don't we just call it CI/CD instead of DevOps? Is something missing? Is it really incomplete as DevOps? What is missing? What can make it complete?

Let's understand the situation. You did an awesome CI/CD. Let's be clear - build and deployment work perfectly. Also include some infra provisioning using Infrastructure as code; that is also done well. If you think you can't do anything more, then for you DevOps ends with CI/CD.

Let's revisit, what is DevOps:

1. Increased speed - Done using CI/CD. Really? Can nothing else be improved from speed perspective?
2. Improved quality - CI/CD did that as well. Sure? Does quality is bound to code quality only?
3. Cut overhead - Did CI/CD do that? Or you created 10000 rules which team needs to take care of?

Let's extend the list a bit here.

4. Breaking the silos - Did you solve this? But this is covered in last point..
5. DevOps culture - Is your team (Dev and QA both, may be Perf and Sec as well) can do everything they want using your pipelines?
6. Security - Are right people able to do what they should be able to do and they are forbidden for what can't be done by them?

If all these are confusing, ask a simple question - Does your team depend on you? Exclude the case of infra/network issues, Jenkins crash, or such edge cases. If the answer is Yes, then just try to turn the answer to No and you would be Complete instead of Incomplete.

Tracking

As we know DevOps is a lot about the whole team, you made their task easier by doing a lot of automation. But are they clear about the Current Status of the running system in various environment? Can they:

1. Rightly tell which version of what is deployed where?
2. Who deployed, when?
3. Can we track it back till the code in case of debugging?
4. Which version can be moved for release?

Additionally:

5. How many build/deployments failed or passed?
6. How are the various trends: build duration, MTTR, commit, build failure, etc.

Conclusion

The way we do DevOps today in most of the cases, it is not at its full potential functionally. Technically, certainly we are in best of the days. We might need to stop for sometime, step back and relook on what else can be done.

DFD is the answer to these limitations. Knowing what DFD can do, I think it can do more if needed. By experience, it solved almost all the request almost instantly when we did it in DFD way.