devopsy.kinsta.cloud

Tag: MLOps

  • Navigating the MLOps Revolution: Three Missteps to Avoid

    Navigating the MLOps Revolution: Three Missteps to Avoid

    With nearly 60% of businesses set to adopt MLOps by 2024, this function has quickly established itself as an indispensable part of the enterprise technology world. And with computing needs rapidly expanding as digital transformation efforts continue, the growth of the MLOps market is unlikely to stop anytime soon.

    That said, as with any emerging technology–particularly something as powerful as MLOps–there is no shortage of potential pitfalls that businesses and their tech teams can fall into if they move too quickly. More importantly, these missteps can have significant impacts on a company’s ability to generate revenue and optimize performance.

    With that in mind, below are three of the biggest mistakes that companies tend to make when adopting MLOps.

    Jumping in Without Testing the Waters

    If you doubt your MLOps maturity, you should probably wait. One of the biggest factors that undermine MLOps adoption and long-term success is that companies jump in before they are actually ready to adopt the technology. This not only leads to MLOps feeling like a burden but also often devolves the customer-vendor relationship into a transactional sales relationship rather than what it should be: a partnership. Onboarding technology needs to be a give-and-take process with ongoing dialogue between the customer and the vendor. If not, vendors – even the most ethical ones – have to rely on partial situational intelligence and guesswork to offer solutions that may or may not address the problems and deliver results. The best way to overcome this is for companies to map out exactly what MLOps challenges they are up against, what barriers are present, and also the outcomes they are looking for. With these key components understood and agreed to in advance, not only can companies make sure they are getting the best vendor partner, but the vendor can then provide much more tailored guidance.

    Misunderstanding What MLOps Actually Is

    There is a tendency among new adopters to distill MLOps down to the idea that it is made up of two components: Storage and compute. Yes, these are two significant elements of the MLOps equation, but this view is a massive oversimplification. Also, if it is not clarified at the outset, this misperception can lead organizations to feel overwhelmed by MLOps and make adoption less “sticky” as a result.

    The fact is, MLOps is composed of numerous pieces–from experimentation to deployment–that each come with their own specific nuances. Each of these parts is interconnected to the next and can derail MLOps results if not properly planned for and maintained. In addition, making sure that every necessary component is functioning the way it should in order to meet the needs and expectations of each client takes time. So businesses and their broader DevOps teams need to be prepared to exercise patience if they have any hopes of successfully adopting MLOps in a way that is geared towards long-term sustainable results.

    Not Realizing the Amount of Iteration MLOps Takes

    When looking at projects from a traditional DevOps perspective, there is a common belief that if a project is stable enough to get it to DevOps, it is ready for production. With MLOps projects, however, this simply isn’t the case. In comparison to DevOps, MLOps is prone to evolution – meaning that iteration and reiteration are incredibly common. For example, in the midst of the MLOps process, companies will want to iterate over the existing process, sometimes at a much more frequent cadence than their software release cadence. This means that there is greater ongoing contact and collaboration between MLOps teams and other teams. This interaction stands in stark contrast to traditional DevOps projects where once production is complete, developers hand over the keys and are essentially hands-off. Businesses and their traditional DevOps teams need to become comfortable with this new way of doing business and build in the flexibility and leeway to make sure that while their MLOps is able to function correctly and grow, that it does so in a way that works for them.

    Businesses are right to be excited about the prospect of adopting MLOps. However, to hit the ground running and deliver impact over the short, medium, and long term, it is essential that companies deploy a comprehensive strategy to ease onboarding headaches and make the process as seamless as possible. And by keeping these key missteps in mind, businesses can do just that.

  • Zilliz Unfurls Managed Vector Database Service

    Zilliz Unfurls Managed Vector Database Service

    Zilliz this week made generally available a managed cloud service that can now be spun up in less than five minutes. The service is based on the company’s open source Milvus vector database.

    Frank Liu, director of operations for Zilliz, said the managed Zilliz Cloud service running on the Amazon Web Services (AWS) cloud will make vector databases much more accessible to a wider range of application developers.

    Vector databases are gaining traction because they provide artificial intelligence (AI) application developers with a more efficient method for managing the unstructured data need to train AI models. Currently, many of those teams are relying on labels and tags to classify and manage data. The Milvus vector database employs deep learning algorithms and its own AI model to create and store, index and manage vectors to more efficiently classify data, said Liu.

    Based on a cloud-native architecture that, for example, employs Kubernetes to scale consumption of cloud resources more efficiently, Zilliz Cloud can also scale to process tens of billions of high-dimensional vector data for data-intensive applications, he added. The company claims Zilliz Cloud delivers up to 10 times greater throughput and five times lower latency for read and write operations for data-intensive workloads.

    Other attributes of the managed Zilliz Cloud include support for multi-language software development kits (SDKs), a web-based graphical user interface to search and explore data, SOC 2 compliance, network isolation using IP whitelists and full data encryption in transit (TLS).

    In the future, Zilliz also plans to add support for Microsoft Azure Cloud and Google Cloud Platform in addition to graphical processor units (GPUs) to optimize the performance of its deep learning algorithms.

    Potential use cases for a vector database span everything from image retrieval and video analysis to fraud detection to drug discovery. Organizations that already use Milvus, which is being advanced under the auspices of the LF AI & Data Foundation, include eBay, Shopee and SmartNews.

    In general, the rise of data-intensive workloads is driving more organizations to embrace DataOps best practices to optimize the management of massive amounts of data. Organizations that build AI models are typically at the forefront of those efforts given the massive amounts of data typically required to train AI models. The challenge organizations have historically faced is not many have the internal expertise required to manage a vector database. The Zilliz Cloud eliminates the requirement by relying on the expertise of a team of database administrators trained by Zilliz to operate a managed service.

    It’s not clear at what rate organizations are embracing vector databases to build AI models. As the next era of applications are constructed, it’s only a matter of time before the machine learning operations (MLOps) practices used to build AI models converge with DevOps practices used to build the applications in which those models will be embedded. The challenge is the data science teams that build AI models tend to also have a distinct DataOps culture all their own; DevOps teams will need to find a way to embrace and extend that.

    In the meantime, the number of types of databases being used to build applications will only continue to expand so it will be up to each DevOps team to know when to manage each one themselves versus relying on a managed service.

  • Where DataOps and Opportunities Converge

    Where DataOps and Opportunities Converge

    In today’s data age, getting data analytics right is more essential than ever. A robust data analytics implementation enables businesses to hit key performance metrics, build data and AI-driven customer experiences (think ‘personalize my feed’) and capture operational issues before they spiral out of control. The list of competitive advantages goes on, but the bottom line is that many organizations successfully compete based on how effectively their data-driven insights inform their decision-making.

    Unfortunately, implementing an effective data analytics platform is challenging due to orchestration (DAG alert!), modeling (more DAGs!), cost control (Who left this instance running all weekend?!) and fast-moving data landscapes (data mesh, data fabric, data lakehouses …). Enter DataOps. Recognizing modern data challenges, organizations are adopting DataOps to help them handle enterprise-level datasets, improve data quality, build more trust in their data and exercise greater control over their data storage processes.

    What is DataOps?

    DataOps is an integrated and agile process-oriented methodology that helps businesses develop and deliver effective analytics deployments. It aims to improve the management of data throughout the organization. 

    While there are multiple definitions of DataOps, below are common attributes that encompass the concept while going beyond data engineering. Here’s how we define it:

    We broadly define DataOps as a culmination of processes (e.g., data ingestion), practices (e.g., automation of data processes), frameworks (e.g., enabling technologies like AI) and technologies (e.g., a data pipeline tool) that help organizations to plan, build and manage distributed and complex data architectures. DataOps includes management, communication, integration and development of data analytics solutions, such as dashboards, reports, machine learning models and self-service analytics.

    Why DataOps?

    DataOps is attractive because it eliminates the silos between data, software development and DevOps teams. The very promise of DataOps encourages line-of-business stakeholders to coordinate with data analysts, data scientists and data engineers. Via traditional agile and DevOps methodologies, DataOps ensures that data management aligns with business goals. Consider an organization endeavoring to increase the conversion rate of their sales leads. In this example, DataOps can make a difference by creating an infrastructure that provides real-time insights to the marketing team, which can help the team to convert more leads. Additionally, an Agile methodology can be employed for data governance, where you can use iterative development to develop a data warehouse. Lastly, it can help data science teams use continuous integration and continuous delivery (CI/CD) to build environments for the analysis and deployment of models.

    DataOps can Handle High Data Volume and Flexibility

    The amount of data created today is mind-boggling and will only increase. It is reported that 79 zettabytes of data were generated in 2021 and that number is estimated to reach 180 zettabytes by 2025. In addition to the increasing volume of data, organizations today need to be able to process it in a wide range of formats (e.g., graphs, tables, images) and with varying frequencies. For example, some reports might be required daily, while others are needed weekly, monthly or on demand. DataOps can handle these different types of data and tackle varying big data challenges. Add in the internet of things (IoT), such as wearable health monitors, connected appliances and smart home security systems, and that introduces another variable for organizations that also have to tackle the complexities of heterogeneous data as well. 

    OK, so, how can we make this a reality? First, to manage the incoming data from different sources, DataOps can use data analytics pipelines to consolidate data into a data warehouse or any other storage medium and perform complex data transformations to provide analytics via graphs and charts.

    Second, DataOps can use statistical process control (SPC)—a lean manufacturing method—to improve data quality. This includes testing data coming from data pipelines, verifying its status as valid and complete, and meeting the defined statistical limits. This enforces the continuous testing of data from sources to users by running tests to monitor inputs and outputs and ensure business logic remains consistent. In case something goes wrong, SPC notifies data teams with automated alerts. This saves them time as they don’t have to manually check data throughout the data life cycle.

    DataOps can Automate Repetitive and Menial Tasks

    Around 18% of a data engineer’s time is spent on troubleshooting. DataOps enables automation to help data professionals save time and focus on more valuable high-priority tasks.

    Consider one of the most common tasks in the data management life cycle: Data cleaning. Some data professionals have to manually modify and remove data that is incomplete, duplicate, incorrect or flawed in any number of ways. This process is repetitive and doesn’t require any critical thinking. You can automate it by either setting customized scripts or installing a built-in data cleaning software tool.

    Additional processes that can be automated via DataOps include:

    • Simplifying data maintenance tasks like tuning a data warehouse
    • Streamlining data preparation tasks with a tool like KNIME
    • Improving data validation to identify flags and typos, such as types and range

    Building Your Own DataOps Architecture 

    To develop your own DataOps architecture, you need a reliable set of tools that can help you improve your data flows, especially when it comes to crucial aspects of DataOps, like data ingestion, data pipelines, data integration and the use of AI in analytics. There are a number of companies that provide a DataOps platform for real-time data integration and streaming that ensures the continuous flow of data with intelligent data pipelines that span public and private clouds. Looking to increase the likelihood of success of data and analytics initiatives? Take a closer look at DataOps and harness the power of your data.

  • MLOps Vs. DevOps: What’s the Difference?

    MLOps Vs. DevOps: What’s the Difference?

    Machine learning operations, or MLOps for short, is a key aspect of machine learning (ML) engineering that focuses on simplifying and accelerating the process of delivering ML models to production and maintaining and monitoring them. MLOps involves collaboration between different teams including data scientists, DevOps engineers, IT specialists and others.

    MLOps can help organizations create and improve the quality of their AI and machine learning solutions. Adopting MLOps allows machine learning engineers and data scientists to collaborate to improve model performance by implementing continuous integration and continuous deployment (CI/CD) practices. It accelerates the ML model development process by incorporating the appropriate monitoring, governance, and validation of ML models.

    What Is DevOps?

    DevOps combines the concepts of development and operations to describe a collaborative approach to performing the tasks usually associated with separate application development and IT operations teams. DevOps, in its broadest sense, is a philosophy that encourages improved communication and cooperation between these (and other) teams within an organization. 

    In its narrowest sense, DevOps refers to adopting practices that enable the deployment and maintenance of iterative application development, automation, and programmable infrastructure. It also includes changes in the workplace culture, like trust-building and bonding between developers, system administrators and other team members. DevOps aligns technology with business objectives and can transform the software delivery chain, job functions, services, tools and best practices.

    MLOps Vs. DevOps: Key Differences

    Here are some of the main differences between MLOps and traditional DevOps.

    Development

    The concept of development refers to different things in each model, with a slightly different CI/CD pipeline.

    DevOps:

    • Usually, the code creates an interface or application. 
    • The code is wrapped into an executable or artifact before being deployed and tested with a set of checks. 
    • Ideally, this automated cycle will continue until the final product is ready.

    MLOps:

    • The code enables the team to build or train machine learning models. 
    • The output artifacts include serialized files that can receive data inputs to generate inferences. 
    • Validation involves checking the trained model’s performance based on the test data.
    • This cycle should also continue until the model reaches a specified performance threshold.

    Version Control

    DevOps:

    • Version control typically only tracks changes to code and artifacts.
    • There are few metrics to track.

    MLOps: 

    • MLOps pipelines usually have more factors to track. Building and training an ML model involves an iterative experimentation cycle, requiring tracking of various metrics and components for each experiment (essential for later audits). 
    • Additional components to track include training datasets, model building code and model artifacts. 
    • Metrics include hyperparameters and model performance indicators, such as error rates.

    Reusability

    DevOps:

    • DevOps pipelines focus on repeatable processes.
    • Teams can mix and match processes without following a specific workflow.

    MLOps: 

    • MLOps pipelines repeatedly apply the same workflows. The common framework across projects helps improve consistency and allows teams to progress faster because they start with familiar processes. 
    • Project templates offer structure, enabling customization to address the unique requirements of each use case.
    • Uses centralized data management to consolidate the organization’s data to accelerate the discovery and training processes. Common approaches to centralization include a single source of truth and data warehouses.  

    Continuous Monitoring

    Monitoring is essential for both DevOps and MLOps, but for slightly different reasons.

    DevOps:

    • Site reliability engineering (SRE) has been trending over the past few years, emphasizing the need for monitoring software from development through to production deployment. 
    • The software does not degrade in the way an ML model does. 

    MLOps:

    • Machine learning models can degrade quickly, requiring constant monitoring and updating.
    • Conditions in the production environment affect the model’s accuracy. After deployment to production, the model starts generating predictions based on new data from the real world. This data is constantly changing and adapting, reducing model performance. 
    • MLOps ensures that algorithms remain production-ready by incorporating procedures to facilitate continuous monitoring and model retraining.

    Infrastructure

    DevOps and MLOps both rely heavily on cloud technology, but have different operational requirements.

    DevOps relies on infrastructure such as:

    • Infrastructure-as-code (IaC)
    • Build servers
    • CI/CD automation tools

    MLOps relies on infrastructure such as:

    • Deep learning and machine learning frameworks
    • Cloud storage for large datasets
    • GPUs for deep learning and computationally-intensive ML models

    DevOps and MLOps Trends

    Here are some of the major trends driving the development of DevOps and MLOps.

    GitOps

    A new evolution of the DevOps workflow, GitOps is a new paradigm for controlling and automating infrastructure. A Kubernetes-oriented paradigm enables developers and operations teams to manage Kubernetes clusters and deliver containerized applications using Git. Implementing Git workflows for operations and development teams allows developers to leverage Git pull requests to manage software deployments and infrastructure.

    GitOps incorporates existing development tools to manage cloud-native and cluster-based applications with CI/CD. It automatically deploys, monitors, and maintains cloud-native applications using a Git repository as the single source of truth.

    GitOps is a way to implement and maintain clusters in Kubernetes. Continuous delivery and deployment allow developers to build, test, and deploy software faster through incremental releases. Kubernetes continuous integration and runtime pipelines must be able to read and write files, update container repositories, and load containers from Git. GitOps helps businesses manage their infrastructure with version control, real-time monitoring, and alerting of configuration changes.

    Synthetic Data

    Synthetic data is any information generated artificially instead of collected from real events. Algorithms generate synthetic data for use as a replacement for operational and production test datasets. Synthetic datasets are also useful for validating mathematical models and training machine learning models.

    Benefits of synthetic data include:

    • Minimizing the constraints associated with using sensitive and regulated data.
    • Customizing data to specific requirements and conditions not available in real-world data.
    • Generating data for testing software quality and performance for DevOps teams.

    Codeless Machine Learning and AI

    Machine learning often involves computer code to set up and process model training, but this is not always the case. Codeless machine learning is a programming approach that eliminates the need for ML applications to go through time-consuming processes.

    Codeless ML eliminates the need for experts to develop system software. It is also simpler and cheaper to deploy and implement. Using drag-and-drop input during machine learning processes can simplify training efforts in the following ways:

    • Evaluating results.
    • Dragging and dropping training data.
    • Creating predictive reports.
    • Using plain-text queries.

    Codeless ML gives developers easy access to machine learning applications, but it is no substitute for an advanced, nuanced project. This approach is suitable for small businesses that lack the capital to maintain an in-house data science team.

    TinyML 

    TinyML is a new approach to machine learning and AI model development. It involves running models on devices with hardware restraints, such as microcontrollers powering smart vehicles, refrigerators and electric meters. This strategy is the best fit for these use cases because it speeds up the algorithm—there is no need for the data to go back and forth to a server. It is especially important on large servers and can speed up the entire ML development process.

    Running TinyML programs on an IoT edge device has many benefits:

    • Lower energy consumption.
    • Reduced latency.
    • User privacy guarantees.
    • Reduced bandwidth requirements.

    Using TinyML offers greater privacy because the computation process is entirely local. It consumes less power and bandwidth, resulting in lower latency because it doesn’t require sending data to a central location for processing. Industries that are taking advantage of this innovation include agriculture and healthcare. They typically use IoT devices embedded with a TinyML algorithm to monitor and predict real-world events using collected data.

    Conclusion

    In this article I covered the key differences between MLOps and DevOps:

    • Development—DevOps pipelines focus on developing a new version of a software product, while MLOps focuses on delivering a working machine learning model.
    • Version control—DevOps is mainly concerned with tracking binaries and software artifacts, while MLOps tracks additional factors like hyperparameters and model performance.
    • Reusability—DevOps and MLOps both strive to create reusable processes and pipelines, but use different strategies to achieve repeatability. 
    • Continuous monitoring—Monitoring is important to DevOps, but even more important in MLOps because models degrade in performance due to model and data drift.

    Finally, I covered a few key trends that will transform DevOps and MLOps in the near future. I hope this will be useful as you discover your place in the new and exciting development ecosystem.

  • Top 3 Requirements for Next-Gen ML Tools

    Top 3 Requirements for Next-Gen ML Tools

    As the machine learning market matures, new tools are evolving that better match data science and machine learning teams’ needs. Vendors, both open source and private, have been quick to introduce new products that better meet requirements making it easier and faster to develop models and enable collaboration.

    These new offerings range from cloud-based platforms that make it easy to build and deploy models to specialized software that can speed up the training process. As an example, the existing field of ML experiment tracking is a multi-billion dollar market with a crowded amount of vendors: Comet ML, Weights & Biases, Neptune AI, Databricks’ MLflow and more. These tools will need to evolve to move beyond meeting only the basic requirements of ML teams like experiment tracking, visualizations and model training to address collaboration and technical requirements so these teams can get models to market faster.

    The types of teams that are driving modern requirements for data science are the bet-the-farm types, where it’s all about finding new technology and solutions to drive efficiencies and get models to market faster for their organizations to maintain a competitive edge. Going forward, we’re seeing the following as requirements for ML teams as they evaluate tools to add to their MLOps stack.

     An Open, Modular Approach

    Data scientists and ML engineers use multiple tools to do their jobs, from Jupyter notebooks for model coding to DVC for experiment and data versioning, to automation tools like AirFlow to model visualization tools. Solutions will need to be open to integration with other tools instead of a walled garden that many ML tools, like those offered by cloud vendors (e.g. Amazon SageMaker, etc.) are now.

    Familiar Developer Experience

    ML developers and engineers are familiar with standard DevOps tools and workflows like GitOps (think GitHub or GitLab) and live in CLI-oriented solutions. ML tools should integrate tightly with these existing tools instead of complicating the developer experience with a separate ecosystem. And as a part of the developer experience, workflow is also important. Data scientists can run hundreds of experiments using their preferred CLI-based solutions but, often, all those experiments are streamed and posted into existing ML tools. A more optimal approach would be to offer data scientists the experience of running experiments locally and letting them commit only the most important experiments for further discussion and collaboration so the team isn’t overwhelmed.

    Strong Connection to Source Code

    This approach makes a stronger foundation for something like tracking ML experiments. As ML teams race to get models to market and continually improve them, being in lockstep with DevOps teams to deploy those ML models into production is critical. An example would be a developer tracking five experiments with changing hyperparameters. For these experiments, they may have a link to a Git repo for a particular version of source code. But what if the source code changes or data set changes are not committed or reported in their existing ML solution? Then, the connection is lost and existing metrics would be based on a previous version of source code or data that’s no longer accurate. That lost connection slows down time-to-market and makes it harder to optimize models.

    As seen with the above examples, ML teams juggle myriad tools and workflows as they develop models for various applications and services. The requirements discussed will help these teams to collaborate better and build models faster in an increasingly heterogeneous MLOps landscape.

  • Positioning ML Devs and Teams for Success

    Positioning ML Devs and Teams for Success

    Intelligent applications are (by their very nature) complex. While conventional software basically consists of one thing (code), intelligent software involves code, models and data. As previously discussed, three distinct fields—DevOps, MLOps and DataOps—have evolved to govern each of these interconnected disciplines. 

    Moving through the ML life cycle quickly and efficiently requires collaboration between teams in each of the above disciplines. Organizations should strive to make this collaboration as frictionless as possible to position their ML efforts for success. What follows are four places where we believe organizations should focus: 

    • Infrastructure
    • Team structure
    • Tools 
    • Project ownership and KPIs

    Build Dedicated Infrastructure for Each Pillar

    Infrastructure software is not one-size-fits-all across the three pillars of code, model and data. For example, DevOps teams have historically played the infrastructure role in software development, supporting application or product services. Think of regular software engineering teams who are supported by DevOps, producing different kinds of application services. App infrastructure is so baked-in to software development that most of us take it for granted.

    Just as regular software services require DevOps, data and model services require corresponding infrastructure. Data infrastructure is typically concerned with managing tools (such as Airflow installations, Spark clusters and feature stores), building data pipelines and ensuring that data services remain smooth and operational for data consumers. 

    On the other hand, model services are chiefly concerned with creating, running and organizing models in such a way that others can use them efficiently. Since the AI/ML life cycle is incredibly complex, a host of factors need to be considered (e.g., hardware, parallelization libraries, model packaging formats, etc.) to help data scientists and engineers do their jobs efficiently. Robust ML infrastructure along with a dedicated ML infrastructure team goes a long way in helping organizations scale their AI.

    Optimize Team Structure

    Best practices for ML and AI are continuously evolving, and organizations have tried a host of team structures over the years. We have noticed two popular structures for intelligent application development teams emerged in recent years:

    • Pods

    Pod structures involve smaller teams—usually a data scientist, a data engineer and an application software engineer—working together closely to deliver an intelligent feature or product. Due to their tight-knit nature, these teams are positioned to iterate extremely quickly, which often leads to better products and features. However, the closely-knit nature of pods also comes with a downside, as knowledge sharing between pods with different objectives can be difficult.

     

    • Center of Excellence

    In a center of excellence (or COE) structure, all data scientists or data engineers are “pooled” and then assigned to different products or features depending on project requirements and circumstances. In contrast to pods, COE structures tend to share knowledge very easily. However, this arrangement can lead to slower iteration cycles because team members are not dedicated to particular products or features. 

    In our opinion, both pod and COE arrangements can be effective depending on the realities of an organization. Choosing an optimal team structure depends on how the rest of the organization is structured and how reporting relationships are set up. 

    Select Appropriate Tools

    To select the best possible tools for your organization, choose those that foster collaboration and uphold safety across code, model and data teams. 

    The right tools help teams work quickly and efficiently. Teams should be able to discover pertinent information for themselves without having to pull others off of whatever they are working on. For example, a data science team should be able to discover what data access or learn what features exist. Similarly, application teams should be able to discover what models exist, what versions are the latest or how and when to use models. The more that you can make your code, model and data self-serve, the faster teams will be able to build products that are ready to be put into production. 

    Furthermore, proper tools make debugging faster and easier. If you’ve been around ML-enabled features or products for any length of time, you’ve probably been bitten by undeclared dependencies and apps breaking due to upstream changes. In an intelligent app, finding the root of a problem can be extremely difficult because the root cause can exist in any of the three pillars or any combination of the three. Robust tools provide logs and information to help discover what went wrong more easily.

    Finally, governance should play a key role in tool selection, as safety should be a chief concern for ML teams. For example, consider a model that predicts the demographics of a user based on their app usage. While these predictions might be considered acceptable in certain applications, if a model is being used to make financial recommendations or approve credit applications, use of certain demographics may violate various consumer protection laws. Since a software engineer using this model might not be aware of the nuances related to its use, baking in safety checks on model and data use becomes vitally important. 

    Establish Ownership and Determine Appropriate KPIs

    Whether we are working at a company or in an academic lab, our goal always remains the same: build the best product. 

    But “best product” can mean a lot of different things depending on the use case. For example, sometimes teams may be willing to trade a bit of accuracy if a model fails in predictable ways (e.g., in health care applications.) By contrast, an e-commerce recommendation system can optimize for overall model accuracy even if a model isn’t quite as stable. As a result, choosing the appropriate KPIs for model optimization requires careful attention.  

    Similarly, choosing appropriate metrics that make sense for the product and business usually requires a high-level view of a number of factors — user expectations, revenues, user complaints, etc. In our experience, product owners are usually in the best position to make these decisions. KPIs for each of the pillars supporting the intelligent app should be based on key metrics determined by product owners. While these can range, we’ve seen the following KPIs work well:

    • Code — Number of releases, number of bug fixes, number of features that have shipped, mean time to resolution
    • Model — number of model iterations shipped, model quality in production, model performance SLAs 
    • Data — frequency of data refreshes (e.g., every day or every month?), number of data quality issues, speed of access to data

    The key point here is to drive all of these based on the product KPIs and to focus on the agile principle, which is how quickly are you moving and how many deploys are happening. 

    Know what metrics your team is looking to optimize so that you can invest your resources in the right spot. 

  • What is MLOps? DataOps? And Why do They Matter?

    What is MLOps? DataOps? And Why do They Matter?

    Let’s look at three distinct disciplines—DevOps, MLOps and DataOps. In 2011, Marc Andreessen famously proclaimed that software was “eating the world.” A little more than a decade later, it’s all but impossible to argue with his premonition as software has embedded itself into virtually every industry. 

    But now another shift is underway and AI is gobbling up software as we know it. Our emails can finish our sentences for us, connected cars are helping us stay safer on the road and predictive technology is helping minimize supply chain disruptions caused by COVID-19. In the near future, almost every piece of software we interact with will have intelligence built-in, and as AI gains acceptance and new use cases are rolled out, applications will only continue to become more intelligent. The widespread move toward ML-enabled software has the potential to be as transformative and far-reaching as what Andreessen predicted. 

    But innovation is rarely easy or simple—and intelligent applications are no exception. While conventional software involves one thing—code—and not much else, intelligent software relies on a complex relationship between three interconnected variables or legs of a three-legged stool.

    A Three-Legged Stool: DevOps, MLOps and DataOps

    Model:  The one or more AI/ML models (e.g., linear regressions, rules, deep neural networks, etc.) trained to recognize patterns in data and make decisions are what makes an application “intelligent.” 

    Data: Most often, a model is trained on historical data and programmed to emulate it. As a result, an application’s behavior depends heavily on the data—the raw input data, labels and features, as well as the new data to which the model is applied and ground-truth for this data.

    Code: Code is the language an application uses to function. When used in the context of intelligent applications, the code pillar might refer to business logic, calls to models, receiving outputs, decision making and calls to other data systems. 

    A Real-World Example

    To see how these pillars play out in real life, consider the example of a perception system for a self-driving car. Such systems use data (provided by offline sources and real-time cameras and sensors), models and code to determine myriad ever-changing variables (for example, if there are obstacles on the road, what lane markings look like, how fast a car can safely travel, etc.) While the following illustration is greatly simplified, it outlines the basic steps needed to build and deploy such a system and indicates which pillar each step belongs to. 

    Regardless of application type, the legs that intelligent applications stand on are always the same: Model, data and code. And if you try to remove any one of them, the application will topple over.

    With the three distinct pillars that make up intelligent applications, three distinct disciplines have emerged to keep each individual pillar functioning as efficiently as possible: DataOps, MLOps and DevOps. The rest of this post examines the details that make each discipline distinct and necessary to the model life cycle.

    DevOps

    Once upon a time, companies used waterfall processes to develop software. The process often moved so slowly that products didn’t realize their potential before they died or were replaced. In 2000, Agile was introduced, allowing developers to work quickly and iteratively in tight sprints where they were constantly delivering. By 2009, Flickr, for example, was the envy of the industry, routinely performing 10+ deploys per day. Companies seeking to increase their own productivity combined software development with established operations principles—and the term “DevOps” was coined. 

    As the familiar loop graphic below illustrates, the DevOps cycle goes from the planning stages to the creation, testing/verification, packaging, release, configuration, monitoring and then starts over again with planning. Over the past two decades, a host of unique tools have emerged to support individual steps in the DevOps life cycle—helping developers ensure quality by building in continuous integration and continuous testing from the start and helping speed up time-to-market with workflow automation. The DevOps ecosystem is robust, well-thought-out and always iteratively improving.

    MLOps

    MLOps helps teams move more quickly and efficiently through the model life cycle—a loop that involves six distinct steps, each of which contains unique considerations. 

    Since MLOps is related to DevOps, businesses sometimes try to adapt the processes used to write conventional software to execute the unfamiliar task of machine learning operationalization. But the approach doesn’t work, as the two disciplines are actually quite different.

    MLOps primarily deals with models, not code—and models are quite different from code. For example, model training and testing look very different from code building and testing. (What does “test case” even mean for a model?) And monitoring model performance is completely different than monitoring traditional software. (DevOps looks at things like CPU utilization, latency and throughput, while MLOps looks at model quality, drift and data quality.)

    Furthermore, the people that MLOps engineers are building for are quite different than their DevOps counterparts. As one might expect, the primary users of models are data scientists while DevOps generally serves software developers. Most often, MLOps engineers come from a background in ML and data science or software engineers who picked up ML. 

    As with DevOps, no single all-inclusive MLOps platform exists. Rather, different tools support different individual steps in the model life cycle and provide some amount of workflow automation to speed up processes. Different tools support specific pieces of the ML life cycle—but the ecosystem is still somewhat fragmented. Ideally, MLOps will evolve to offer more DevOps-like tools that work well together and offer more automation. For companies looking to build an MLOps platform, build a suite of supporting tools with speed, safety and automation in mind.

    DataOps

    We’ve seen very well-defined life cycles for the other two pillars discussed above; however, when it comes to DataOps, the life cycle is still being defined. But the overall objective of DataOps should sound familiar: DataOps involves processes and tools to ship high-quality data frequently—which requires a combination of data engineering, data quality, data security and data integration. 

    As with DevOps and MLOps, what the DataOps platform or DataOps engineer is doing is supporting the tools that help perform one of these activities and help build workflows. For example, a workflow may take data from a database, apply some transformation to it and then make it available for a business intelligence (BI) tool. That’s the kind of automation that is involved in DataOps. 

    As you might imagine, the skillset and the tools required for DataOps are quite different from the ones needed in MLOps and DevOps—so expecting a DevOps engineer to also be an expert in DataOps seems a bit unrealistic. While MLOps requires a much tighter integration with data than DevOps historically has required, MLOps is not the same thing as DataOps. More so than the other pillars that support intelligent applications, DataOps tends to be quite separate and distinct. 

    Conclusion

    From perception systems to enterprise-scale fintech software, every intelligent application depends on three distinct disciplines: DevOps, MLOps and DataOps. And therein lies the complexity of developing intelligent products. Each of these fields is distinct, dealing with a different set of questions and objectives within the ML life cycle and requiring different kinds of people and tools. However, they are all fundamentally united by a common goal: Optimizing quality and speed of iteration of the ML life cycle. The tools, practices and organizations that will rise to the top are the ones that will enable more seamless collaboration between different ML teams, helping them move through the ML life cycle quickly and efficiently. 

  • Iterative Adds Experiment Versioning to MLOps Platform

    Iterative Adds Experiment Versioning to MLOps Platform

    Iterative today added an experiment versioning capability to an open source platform for managing machine learning operations (MLOps) using GitOps workflows.

    Dmitry Petrov, Iterative CEO, said the latest version of the Data Versioning Control (DVC) platform makes it simpler to save, compare and reproduce machine learning (ML) experiments at scale without requiring organizations to set up an additional repository to track them. Instead, organizations can store those experiments alongside other software artifacts in a Git repository, he said.

    As a result, IT teams will no longer need to try to keep track of experiments using spreadsheets or notebook tools such as Jupyter, he noted. Organizations that are building AI models for applications constructed using DevOps workflows will also find it easier to comply with a wide range of existing and forthcoming compliance mandates, added Petrov.

    The DVC platform makes use of a Git-like interface to enable organizations to track multiple versions of data sets, models and pipelines across an MLOps workflow. That capability is being extended to make it easier to manage the experiments data science teams create during the construction of an AI model.

    Iterative is at the forefront of an emerging debate over how best to infuse AI models into applications. Providers of platforms used by data science teams are making a case for separate repositories for tracking the artifacts used to construct an AI model. Iterative, on the other hand, is arguing for the use of an AI model build framework that uses the same Git repositories where any other type of software artifact is stored and shared. Iterative’s argument is that, in effect, AI models are just another type of software artifact, noted Petrov.

    In addition to reducing the total cost of building AI models by reducing the number of platforms required, a Git-based approach also makes it simpler for DevOps and data science teams to collaborate because the DevOps team will have more visibility into what AI models will eventually need to be incorporated into an application.

    It may be a while before the development of AI models and applications fully converges. Data science teams today typically have defined their own workflow processes using a wide range of graphical tools. However, as it becomes obvious that almost every application is going to be infused with machine learning and deep learning algorithms to some degree, the need to bridge the current divide between DevOps and data science teams will become more acute.

    In the meantime, DevOps teams should assume that many more AI models are not only on the way but that those models will need to be continuously updated. Each AI model is constructed based on a set of assumptions; however, as more data becomes available, AI models are subject to drift that results in less accuracy over time. Organizations may even determine that an entire AI model needs to be replaced because the business conditions on which assumptions were made are no longer valid. One way or another, the updating and tuning of AI models is likely to soon become just another continuous process being managed via a DevOps workflow.

  • Oracle Adds AI Services to Cloud Portfolio

    Oracle Adds AI Services to Cloud Portfolio

    Oracle today unfurled Oracle Cloud Infrastructure (OCI) AI services, a collection of services that make it easier for developers to use application programming interfaces (APIs) to invoke a wide range of services based on algorithms trained by Oracle on their behalf.

    Elad Ziklik, vice president of product management for AI services and data science at Oracle, said the primary goal is to offload the data engineering tasks associated with machine learning operations (MLOps) from organizations that simply want their developers to include AI capabilities within their applications without having to necessarily hire and then retain a dedicated data science team.

    However, organizations also have the option of uploading their own data into OCI AI services to retrain the models provided by Oracle, he noted.

    Ultimate, the goal is to make OCI AI services a simple extension of DevOps workflows by making it simpler to employ AI models; these models become just another software artifact that can be stored and updated in a Git repository alongside all the other artifacts managed by a DevOps team, said Ziklik. In effect, Oracle wants to make AI ‘boring’ in the sense that these capabilities can now be readily invoked by any development team, he added.

    The OCA AI services include OCI Language, a text analysis capability that enables developers to add sentiment analysis, key-phrase extraction, text classification, named entity recognition and other similar capabilities to their applications, and OCI Speech, which converts file-based audio data containing human speech into text transcriptions.

    Oracle has also included OCI Vision for image recognition and document analysis tasks, OCI Anomaly Detection to create models that flag irregularities in processes, OCI Forecasting for tracking business metrics over time and OCI Data Labeling for creating datasets to train AI models.

    These services are designed to address the most critical AI requirements of the average enterprise rather than attempting to outperform on a set of AI benchmarks that don’t reflect the requirements of business development teams, said Ziklik.

    In addition, Ziklik noted Oracle has also made it easier to address AI compliance requirements that will eventually require organizations to document precisely how their AI models work.

    At some point soon, just about every application will be invoking AI capabilities to one degree or another. That shift creates a major workflow challenge for DevOps teams. AI models are typically created by data science teams that typically don’t successfully deploy an AI model in a production environment more than a handful of times a year. Those AI models, however, need to be integrated with applications that, in many cases, are being continuously updated via DevOps workflows.

    Oracle said that goal becomes easier to achieve using models it creates versus allowing data science teams to build out a set of custom MLOps workflows on platforms that then need to be maintained by IT professionals. Instead of having to set up, for example, a feature store to track and manage AI models, the models created using OCI AI can be stored in an existing Git repository.

    Naturally, each organization will need to determine the degree to which they will converge MLOps and DevOps best practices. Oracle, however, is betting that the simplest way to achieve that goal is via AI models surfaced via a cloud service that developers can readily invoke whenever required.

  • Mona Allies with New Relic to Converge MLOps and DevOps

    Mona Allies with New Relic to Converge MLOps and DevOps

    New Relic and Mona, a provider of a platform for monitoring the models used to provide artificial intelligence (AI), announced today they have formed an alliance to help bridge the divide between DevOps teams and data scientists.

    Most data science teams today build models based on machine learning algorithms using operations platforms that enable them to manage the life cycle of those models, otherwise known as MLOps. Mona provides a set of monitoring tools that are employed to detect drift that can occur as some of the underlying assumptions that were made when building the model are discovered to be less accurate or when new data sources become available.

    New Relic, meanwhile, provides an observability platform that is widely employed by DevOps teams to monitor and observe an IT environment. IT teams that have access to New Relic One can now also view dashboards provided by Mona that detect anomalies involving data integrity issues and model performance issues.

    The integration also enables users to create custom Mona alerts that are shared via the New Relic Alerts and Applied Intelligence service. That capability reduced the volume of alerts generated by correlating anomaly detection to specific IT events.

    Yotam Oren, CEO of Mona, said that level of integration provides a bridge between DevOps and data science teams that typically have widely divergent cultures.

    Incorporating AI models within applications is the next major DevOps challenge. There is almost no application being built today that won’t incorporate some level of AI. The challenge is AI models are built by data scientists that employ a wide range of machine learning operations (MLOps) platforms to construct those models. The pace at which those AI models are developed, deployed and updated varies widely. However, all organizations will eventually need to confront the problem of how to insert AI models within applications both before and after they are deployed in a production environment.

    There are two schools of thought about how best to achieve that goal. The first is to assume an AI model is just another type of software artifact that can be managed as part of an existing DevOps process. In that context, there may be no need for a separate MLOps platform. Conversely, proponents of MLOps contend AI models are built using pipelines created by data engineering teams working in collaboration with data scientists. Developers only become part of the process when an AI model needs to be inserted into an application environment. AI models may ultimately need to be incorporated within an application, but the proponents of MLOps platforms maintain building models requires a unique platform to manage a software artifact that is built by training algorithms.

    It’s only a matter of time before compliance issues force some form of convergence between DevOps and MLOps teams, noted Oren. The longer it takes to address both the cultural and technical issues that are required to meld DevOps and data science teams, the more challenging it will become as both teams are set in their respective ways.