MLOps Essentials: Doing Machine Learning Operations right with design patterns

When designing Machine Learning Operations (MLOps) processes, coding is more than just writing functional scripts or notebooks. It's about architecting resilient, adaptable, scalable, and time-durable systems. Despite the intrinsic differences between writing ML systems and traditional software development, the good practices crafted over decades in the latter could help design your MLOps strategy.??

In particular, programming principles like (SOLID) and the proper use of design patterns would benefit your MLOps practice. In essence, programming principles could guide your team to identify potential design problems on their system, "code smells," and design patterns would bring proven solutions to repetitive situations. Adopting design patterns helps your system be functional, maintainable, extendable, and efficient.?

It is worth noting that the MLOps tooling landscape is fragmented and full of powerful tools/libraries; correctly using design patterns makes it easier to glue these systems. Creating an MLOps practice would feel like a continuous cherry-picking of modules (e.g., Feature Factory, Model Registry, API framework, Orchestrator, Database technology, among others.) that must be connected to work seamlessly with the final purpose of having rock-solid models running 24x7. On top of this, Machine Learning quickly becomes a repetitive process full of standard steps and concepts that, properly abstracted, would help your team move considerably faster than writing every application from scratch.

Adopting Design Patterns in your MLOps coding practices is an excellent way to materialize these characteristics. This could initially feel overwhelming for data practitioners but could become your team's strategic weapon in the long term. Literature is full of design patterns, but this article summarizes the most relevant for MLOps. The patterns are divided by type (Creational, Structural, and Behavioural). Each item in the list contains a brief explanation and some applied examples of MLOps development.

Creational Patterns deal with object creation mechanisms, optimizing object instantiation to be executed functionally. Creational patterns are very relevant to maintaining the system extendable, ordered, and modular. In MLOps, processes need to instantiate objects all around; creational practices will help do this elegantly.

• Factory Pattern:?This pattern centralizes the creation of your instance. For instance, the factory pattern allows you to instantiate all your features or models without interacting directly with the class definitions. Adding new features or models (for example) becomes a matter of adding a couple of standardized modules and registering them in the factory. Rapidly, your "Feature Factory" and "Model Factory" will become the rockstars of your MLOps system.
• Abstract Factory Pattern:?The Abstract Factory Pattern produces families of related objects without pinning down their concrete classes (or factories). Some people reference this pattern as the factory of factories. Factory patterns will become broadly adopted in your framework, and suddenly, too many factories become cumbersome to handle and remember. Using this pattern, you will build a centralized instance creator to considerably facilitate your code writing.?
• Builder Pattern:?It's about constructing intricate objects step by step. Consider the task of building a dataset in MLOps. Instead of manually combining various features, a builder pattern can streamline the process, ensuring that datasets are constructed systematically, reducing errors, and enhancing reusability. This pattern will make building datasets for different models and applications a matter of defining a list of features (already registered in the feature factory). With the builder pattern, all the complexity of maintaining dataset signatures and per feature merge is written once and forgotten for a long time.
• Singleton Pattern:?This pattern ensures a class has just one instance and provides a way to access it. Think of a configuration manager in MLOps. Implementing it as a singleton ensures that system-wide settings are consistent and controlled, enhancing stability and predictability. I advise delegating all the interactions with secret managers and database handling to singleton objects. It will centralize and maintain your open connections under control.

Structural Patterns focus on assembling objects and classes into larger structures while ensuring flexibility and efficiency. I found these helpful when integrating more extensive modules/libraries into your framework or creating complex features.?

• Facade Pattern:?It offers a simplified interface to decouple a complex (usually external) system from your own. For instance, I am convinced that your system will benefit from using a Model Registry, and building it from scratch does not make sense given the capabilities of existing ones like MLflow . It is okay to use the external tool, but build the integration as decoupled as possible because the field is quickly evolving, and you may decide to change it for a more robust future. Using the Facade Pattern, all your interactions with the external tool will be in a single location with well-defined dependencies.
• Composite Pattern:?This pattern allows treating individual objects and compositions uniformly. In feature engineering, features, whether standalone or combinations, can be managed uniformly using a composite design, promoting flexibility and ease of management. With the composite pattern, your more complex and straightforward features will behave the same even when built differently.

Behavioral Patterns revolve around defining strategies to solve a complex task. The Behavioural patterns try to define well-defined responsibilities to different class instances and mechanisms to change the behavior dynamically.

• Chain of Responsibility Pattern:?It allows multiple objects to handle a task in a sequence of actions, where an independent object instance performs each step. Picture a batch processing scenario in MLOps. To start making predictions, the system must first select what entities are valid for prediction and which don't. To handle this effectively, the developer may split the complete task into small sequential steps, where each stage uses a well-contained handler and sends the result to the next handler. The chain of responsibility pattern allows developers to quickly introduce new criteria by only adding an extra handler to the process.??

Design patterns are practical strategies to keep your MLOps practice efficient. They are a way to reuse proven solutions to standard problems. These patterns are invaluable in the diverse MLOps landscape, where integration of various tools is the norm. They guide the development of systems that are both robust and flexible. But, a word of caution: over-relying on patterns can lead to overcomplicated frameworks and hard-to-decipher code.

Join the conversation! Share insights on design patterns, principles, and architectural patterns in MLOps. Indeed, I am leaving several design patterns out of the list, but tell me if you have some worth mentioning or exploring!

If you are interested in these and other Design Patterns, look at the exceptional work of Alexander Shvets in their Refactoring And Design patterns.