If you have read my other articles, I hope you can sense my passion for enabling continuous software engineering practices. This should be no surprise coming from a co-host of the ContinuousX Podcast series. I believe that if a process is important enough to be automated, it should be run in a continuous fashion to gain the fullest benefits.
Do I just like spending computer cycles needlessly? No!
Why would you even ask that?! How dare you!
Operational programs need to be run continuously because the system is always changing. Sometimes that change is intentional, sometimes it’s a mistake, and sometimes it’s a rogue element. Other times hardware just fails, or weird things happen, like 9 ÷ 3 = 2.999999999?
But only once every other week or so!
The continual running of operational tasks helps to identify “drift away” from the original intention as close to the point of drift as possible. Changes can then be addressed at a time when it’s clear that whatever just changed was wrong and not whatever changed over the last month. Alerts can be generated, and the problem is isolated. And in the best of cases, it can be automatically rolled back or self-repaired.
DevOps initiated my passion for Continuous Integration and Continuous Deployment.
CI/CD not just I and D. The continuousness is so important it gets a double billing.
Security got into the mix with DevSecOps to shift security issues left. But the talk on the street today is “shift-everywhere” all the time. Turns out that dumping everything in the developers’ laps is not a stable solution. And everyone in the process needs to be aware of security concerns and take appropriate actions, not just developers.
Wacky! Who would have thought that?
The same goes for testing, monitoring, and all the stages in the DevSecOps infinity loop. They all gain benefits from automation and full organizational focus. And it expands beyond the development realm into business needs with continuous planning, continuous finances with FinOps, and continuous ATO. It goes on and on…one might even say continuously!
But throwing a three-letter truncation in front of an “Ops” isn’t just a trendy re-brand of the needed functionality (or at least it shouldn’t be). For me to call it an “…Ops” it needs to be automated and it needs to be run very, very frequently. There is no good in automating a process for it to tell you that a problem has occurred in the distant past.
“Hey, this security report shows a lot of spikes in activity a couple of days ago…that’s unusual.”
“Yeah, we were hacked! I was up all night. Thank Buddha we have your report now though.”
I have a lot of old wounds.
That’s why I was happy to discover some like-minded people in the Software Engineering Research Lab at Blekinge Institute of Technology (BTH). And I only had to go to Sweden to find them. It’s researched, data-driven, and evidence-based, which makes it more scientific than my life ramblings. Yet, it documents the same insights my life has already shown me. So, of course, I love it.
Namely, all stages of the software engineering process benefit from automation which is continuously implemented. Plus, you don’t have to do it all at once, so you can focus on areas when they are needed. Because everything has a cost, and everything has a benefit, it’s up to you and your team’s situation.
Most modern software developers understand the internally focused goals of CI/CD to increase the delivery of software features. Automate the changes each developer makes to the application and run the whole process right when it is fresh in the developer’s mind and the change is isolated. Automating every step reduces mindlessly repetitive tasks which are prone to mindless human errors.
Breaking the application into domain-driven modules so that smaller teams can work on them independently might be an initially challenging cost, but it makes it easier to change and test in the long run. Yes, you should still test! A solid automated testing harness around your modules builds developer and stakeholder confidence for rapid changes.
This is where most organizations start yet unfortunately end.
But there are benefits in extending this focus externally to control boards and your user community. Ensuring continuous delivery processes that run smoothly with small changes and easier deliveries can build trust for a Continuous ATO approval stamp. Constantly focusing on user feedback and satisfaction enhances that trust, but it needs an investment in automation and monitoring.
Continuous monitoring of the now hundreds of microservices and functions each with its own APIs produces a steady stream of data. Mountains of data need to be collected, stored, analyzed, and refined into actionable information. This investment can be steep, but it is the only way to make truly agile planning decisions based on facts versus opinions. Directing development to implement relevant new software features at their new faster pace.
All while maintaining cross-cutting issues of consistent security, governance, compliance, and responsible budgeting. I am exhausted just writing this! Which just shows that you can’t do it alone. You need your entire organization to focus on these goals together. And you need automation to scale beyond that.
But it can be done! So, where do you want to invest? Let me know.
Jag har lärt mig så mycket tack vare dig (I have learned so much thanks to you), BTH SERL Sweden.
