DevSecOps vs DataOps vs MLOps
Choosing the Right Workflow for Your Project
Since the inception of the agile manifesto in 2001, many software development methodologies emerged, each trying to improve processes. While the basic agile manifesto still guides workflows, today major efforts are extended mainly towards breaking silos across a wide range of fields. This is achieved by unifying siloed departments into collaborative teams.
At first, development and operations teams were unified into DevOps teams. Today, it is becoming increasingly clear that DevOps is not enough. Security is also a critical aspect that needs to be addressed throughout the process, rather than in the end. Hence, the inception of DevSecOps, which adds security to the development cycle. To ensure database operations and machine learning operations run smoothly, as well, DataOps and MLOps were created.
This article examines these four main methodologies — DevOps, DevSecOps, DataOps, and MLOps — providing guiding principles for when and how to use each workflow.
What Is DevSecOps?
DevSecOps is the combination of DevOps with security teams. It is designed to ensure that responsibility for security is shared across development and operations tasks and to implement the management of “security as code”. Implementing DevSecOps is typically taken on by teams that are already comfortable working with a DevOps strategy.
DevSecOps teams enable security members to bridge the gap between development and deployment operations and security concerns. By breaking down the silos between teams, they can help integrate security practices into existing workflows, reducing friction and ensuring more secure products from the start.
The ways that DevSecOps specifically differs from DevOps is both in tooling and mindset. These implementations shift testing to the left in development processes and focus on teaching security best practices. The idea is to prevent vulnerabilities from entering projects in the first place.
For example, DevSecOps teams often incorporate static application security testing (SAST) tools in integrated development environments (IDEs). This means security audits and testing begin before code is even submitted for traditional testing. Similarly, teams' focus may include cloud security posture management (CSPM) or compliance auditing tools into environment deployment steps. This helps catch misconfigurations before environments go live.
DataOps: Leveraging DevSecOps Principles for Secure Data Analytics
As DevSecOps evolved from DevOps, other business units have also begun incorporating DevOps principles, branching off from the strategy and evolving. One example is DataOps, which has a base of data analytics.
DataOps takes the practices and values of DevOps and extends it to data analytics workflows and goals. It applies the focus on collaboration and shared responsibility and shifts it to the engineers and admins that collect, store, analyze, secure, and deliver data.
DataOps is designed to streamline existing big data processes, increasing workload value and security simultaneously. It does this by integrating security into the encoding, retention, and delivery of data while keeping in mind the dependencies between analytics and storage workflows. This helps ensure more reliable access and can improve time-to-value.
DataOps Infrastructure
Implementing DataOps requires more than a change in mindset or workflow; it also requires infrastructure modifications. For example, new architecture patterns that focus on agile feedback loops and automation.
DataOps also often requires teams to implement next-generation technologies designed for analytics and storage. For example, teams typically need to adopt redundant, cluster-based storage to ensure that data processing pipelines are highly available and scalable. Environments may also need to be configured and deployed to ensure isolation and compliance with data privacy regulations. This is true for both production and test or dev environments.
Another change that DataOps teams may need to address is the diversity of workload that is supported. For pipelines to offer agility, solutions need to be integrated into a single infrastructure, not distributed by task or team. This means incorporating big data analytics tools, like Spark and Hadoop, log aggregators, like Sumo Logic and Splunk, and oversight tools, like Prometheus and Jira.
DevOps vs MLOps
MLOps is another offshoot of DevOps. In it, DevOps principles and workflows are applied to machine learning operations, such as model training and deployment. It implements pipelines and automation to enable the smooth flow of training operations and the integration of finished models into software products.
In many ways, MLOps also overlaps with DataOps since it also requires the handling, maintenance, and security of datasets. However, there are some aspects of machine learning workloads that require different focus or implementation. Some of these differences include:
- Team skills — in MLOps, teams need to incorporate ML researchers and data scientists who are often not experienced software engineers. These members focus on experimentation, model development, and data analysis and may not have the skills needed to perform application development, operations, or security tasks.
- Development — unlike traditional development which is more linear, ML is often highly experimental. Teams need to be able to manipulate parameters and features and retrain models frequently. This requires more complex feedback loops. Additionally, teams need to be able to track operations for reproducibility without impeding workflow reusability.
- Testing — testing in MLOps requires additional methods on top of what is normally done in DevOps or DevSecOps. For example, MLOps requires tests for data validation, model validation, and testing of model quality.
- Deployment — depending on the type of ML model you are deploying, you may need to set up pipelines for ongoing data handling and training. This requires multi-step pipelines, which can handle the retraining steps as well as the verification and redeployment processes. Without MLOps this is done manually but with it, steps should be automated.
- Production — models in production can face challenges that aren’t faced by standard application deployments, such as issues related to evolving data profiles. This can cause models to decay and reliability to decrease. MLOps implementations need to incorporate continuous monitoring and auditing to confirm that models are both available and accurate. If accuracy decreases, models need to be called back and corrected.
Another important area that MLOps deviates from DevOps is in how continuous integration/continuous development (CI/CD) pipelines are constructed. In MLOps, CI components need to extend to testing and validating data schemas, data, and models. CD components need to support the deployment of the training pipeline as well as the final model prediction service or application. Additionally, there is another component, continuous testing (CT) that needs to be accounted for to enable automatic model retraining and refinement.
Conclusion
DevSecOps unifies development, security, and operations roles into one unified team. The workflow is often automated and the feedback loop should be continuous. This ensures team members spend their time on critical tasks and continuously improve and secure the code.
DataOps workflows leverage DevOps principles, such as collaboration and automation, for data administration workflows. This workflow can help eliminate silos originating at the data level. MLOps workflows also leverage DevOps principles, but here the application is in machine learning operations.
Choosing a workflow is a critical component, and it requires cooperation between all involved parties. Before implementing a workflow, you should make sure all team members possess the necessary skills, the workflow is suitable for your project, and you have all necessary tools for testing, deployment, and production.
