If you are a connoisseur of trade shows and new product innovations like me, then undoubtedly you have heard that every known product in existence has a new feature that is driven by artificial intelligence (AI) and fueled by machine learning (ML). There’s so much artificial intelligence touted, that natural intelligence seems to be out of vogue. After countless Terminator movies and other prophetic visions of AI run amok, you would think that we would cool it on the machine learning apocalypse, but alas, no.
There are even articles describing how DevSecOps is being accelerated by AI & ML, which is undeniable. But this is not one of those articles. Instead, I want to explore how AI can benefit from DevSecOps, which is also known as DataOps, and thereby more efficiently hasten the sudden but inevitable robot betrayal.
“Most AI applications today are considered Narrow AI, and involve some form of identification…or recommendation…In these cases, results are based on analyzing data…versus explicit instructional programming.”
First, I need to lay down some basic understanding of AI & ML. Skynet and other machine overlords are examples of General AI, meaning artificial intelligence aimed at mimicking the adaptable intellect of humans with the flexibility to accomplish many goals in changing environments. Rest assured that your latest application advancements do NOT do this! Your toaster is not going to attack you…yet. Even applications like Alexa, Siri, and Watson only mimic this kind of advanced interaction.
Most AI applications today are considered Narrow AI, and involve some form of identification … “Hey Shazam, what song is this?” … or recommendation … “Since you’re buying these nails, would you like to buy a hammer?” In these cases, results are based on analyzing data, of song waves or past purchases, versus explicit instructional programming.
Certainly, a developer using natural intelligence could write code recommending a hammer to someone buying nails, but with every product being sold in Amazon, manually coding each product’s recommendations would be a slow, brittle, and inevitably futile endeavor. Instead, by analyzing the data, hidden connections can be revealed, and hopefully, better recommendations are made, such as lumber, safety goggles – and given enough of my personal history with DIY – splints, pain meds, and the number for the nearest emergency care.
Machine learning, specifically, references the data analysis used to make these narrow AI applications possible. Data scientists “train” the dataset by adjusting the calculations, the types of information included, and by incorporating new data as it is being generated. The end goal is a simple algorithm that can be used in a production environment without the need for millions of calculations each time it’s invoked.
As new information becomes available, this algorithm is updated, so the process is one of continual improvement. And this is where modern DevSecOps concepts and practices come into play.
A data scientist may not be hand-coding an algorithm with a programming language, but as the data sets and the derived algorithms have different versions, it would be helpful to track who made each change and why. Well, that sounds like a job for source control.
“Data scientists may not be programming in the traditional sense, but their process certainly mimics and can benefit from a DevSecOps approach. And luckily…developers have spent decades skinning their knees on good practices to take code from thought to production, which is directly relatable to AI algorithms.”
Part of the data analysis requires repeating complex calculations thousands to millions of times and then pulling the results together. Well, that’s a parallel processing job suited for containers and elastic cloud resources.
Data scientists also want to run automated tests on the new algorithm to ensure that its accuracy is improving and that it doesn’t take significantly longer to evaluate in production. Which sounds like an automated CI/CD process with unit and performance testing.
And for the algorithm to be useful, it needs to be launched into a production environment, where marketing can tout their new AI-driven, ML-fueled features. Well, that takes release and deployment management.
Check and mate! Data scientists may not be programming in the traditional sense, but their process certainly mimics and can benefit from a DevSecOps approach. And luckily … for data scientists … developers have spent decades skinning their knees on good practices to take code from thought to production, which is directly relatable to AI algorithms.
Unfortunately, just like I don’t know why my sister’s router isn’t working and I’m expected to because “I use a computer at my job,” data scientists are expected to know everything about software development because “they’re smart and good with numbers.” I’m here to tell you that being good at statistical analysis does not make you good at software release management in a hybrid, multi-cloud infrastructure. Particularly, because my sister has a PhD in Physics and her dissertation involved statical analysis. It was a network outage Michelle; you shouldn’t need me to tell you that!
But that’s okay. Mainly, because new DevSecOps platforms, like the Open Data Hub, IBM Cloud Pak for Data, and Amazon’s SageMaker services, etc., can let data scientists focus on the “numbers” while providing tools that they may not even know they need. These platforms incorporate all the benefits of a modern, hybrid-cloud infrastructure without the need to get a degree in Kubernetes workflow management. For the truly uninterested, there are “As-a-Service” versions to let the data scientists just focus on the numbers, which may work for you.
“…new DevSecOps platforms, like the Open Data Hub, IBM Cloud Pak for Data, and Amazon’s SageMaker services…can let data scientists focus on the “numbers” while providing tools that they may not even know they need.”
But I’m more of a control freak and I’m already working on my degree. So given an AI project, I would pair my data scientists with seasoned DevSecOps practitioners, and not force my data scientists to reinvent wheels. Yes, they are smart, and yes, you should cross-train. But as with any specialized resources on a DevSecOps team, you want to focus on T-shaped skills at the team level and not necessarily with every individual member.
I mean, don’t make your graphics artist tune the database while your DBA handles the ransomware attack, because security specialists are busy deciding between shades of green. That way I would give my scientists the best tools and the most time to get back to their real job, ushering in the android Armageddon.
