Comparing to Alternatives

There is no alternative to Jina. Let me explain it with two example applications.

Multi-user video streaming

Imagine your goal is to build a video streaming service, which allows multiple users to join and share their webcam. In the end, everybody can see each other’s video in real-time. How would you implement it?

Think about it for few minutes. Think about the tech stack, the library, and the architecture. How much time do you need for the first working POC?

Expand to see Jina’s solution in 30 lines of code

Source code can be found here.

Server

import numpy as np
from jina import Executor, requests, Flow


class VideoChatExecutor(Executor):
    last_user_frames = {}

    @requests
    def foo(self, docs, **kwargs):
        for d in docs:
            self.last_user_frames[d.tags['user']] = d.tensor
            if len(self.last_user_frames) > 1:
                d.tensor = np.concatenate(list(self.last_user_frames.values()), axis=0)


f = Flow().add(uses=VideoChatExecutor)

with f:
    f.block()

Client

#!pip install opencv-python
import cv2


def render_recv(resp):
    for d in resp.docs:
        cv2.imshow('output', d.tensor)


from jina import Client, Document

c = Client(host=server_address)
c.post(
    '/',
    Document.generator_from_webcam(
        tags={'user': 'han'}, show_window=False, height_width=(200, 300)
    ),
    on_done=render_recv,
    request_size=1,
)

That’s it.

Index and query with sharding

Imagine your goal is to build a semantic search system for sentences. User inputs a sentence and the system searches over the index and returns the top 10 sentences that are semantically similar to the input. How would you implement it?

Now let’s spice up a bit. Let’s add sharding to the index. Sharding is the process of splitting up a database or a table across multiple instances to improve the manageability, performance, and availability of a database. Introducing sharding means at the index time you have to split up the data into multiple shards and store them separately. At the query time, you can query from every shard and merge the results. How would you implement it?

Think about it for few minutes. Think about the tech stack, the library and the architecture. Think about how to maintain the index/query time data consistency with sharding. How much time do you need for the first working POC?

Expand to see Jina’s solution in 45 lines of code

The code below can be copy-pasted and run as-is.

from pprint import pprint

from jina import Flow, requests, DocumentArray, Document, Executor


class MyFeature(Executor):
    @requests
    async def foo(self, docs, **kwargs):
        docs.apply(Document.embed_feature_hashing)


class MyDB(Executor):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.db = DocumentArray()

    @requests(on='/index')
    def index(self, docs, **kwargs):
        self.db.extend(docs)

    @requests(on='/query')
    def query(self, docs, **kwargs):
        return self.db.find(docs, metric='jaccard', use_scipy=True)[0][:3]


class MyRanker(Executor):
    @requests(on='/query')
    async def foo(self, docs, **kwargs):
        return DocumentArray(sorted(docs, key=lambda x: x.scores['jaccard'].value))


d = Document(uri='https://www.gutenberg.org/files/1342/1342-0.txt').load_uri_to_text()
da = DocumentArray(Document(text=s.strip()) for s in d.text.split('\n') if s.strip())

if __name__ == '__main__':
    f = (
        Flow()
        .add(uses=MyFeature)
        .add(uses=MyDB, shards=3, polling={'/query': 'ALL', '/index': 'ANY'})
        .add(uses=MyRanker)
    )
    with f:
        f.post('/index', da, show_progress=True)
        pprint(
            f.post('/query', Document(text='she smiled too much'))[
                :, ('text', 'scores__jaccard__value')
            ]
        )

You don’t have to dig into implementation at the moment, just get a taste of a Jina application, you will get to know the details later.

What was your solution, is it easier than Jina’s? I bet not. From the two examples above, one can at least conclude that Jina

• is easy to read and understand;

• is versatile on data modalities: it is capable of building both NLP and video service;

• has a straightforward design pattern for either a singleton service or a complex workflow;

• provides out of the box client-server architecture;

• is fast enough for realtime application;

• easily scales.

• self-contained, no context switching between different tech stacks.

Comparisons

Jina is unique, but it doesn’t mean you can’t achieve certain task without Jina; you just take a detour but still can make it. In this section, let’s compare Jina with other frameworks and tech stacks that you may want to use for building a solution.

On local machine

When using Jina on a local machine, most of the functionalities are realized by DocArray. The comparison hence becomes DocArray vs. alternatives. You can find the comparison here. In conclusion, there is no alternative that offers such expressive data structure for cross-modal and multimodal applications.

As a singleton or monolith service

When a Jina Flow contains only one Executor, serving this Flow is basically serving a monolith or a singleton service. One may compare it to other web framework such as FastAPI, Tensorflow Serving and NVIDIA Triton Inference Server.

Feature	Jina	FastAPI	Tensorflow Serving	Nvidia Triton
Latency	Low	Moderate	Low	Low
Easy-to-use	Easy	Easy	Moderate	Moderate
Supported deep learning frameworks	Any	Any	TensorFlow	TensorFlow, PyTorch, MXNet, ONNX
Supported devices	CPU, GPU	CPU	CPU, GPU, TPU	CPU, GPU
Web protocol	gRPC, HTTP, Websocket, GraphQL	HTTP, Websocket	gRPC	gRPC
Prometheus support	Yes	No	No	Yes

As a workflow on the cloud

When using Jina on cloud, it makes sense to compare Jina with other MLOps platforms. Note that MLOps is an especially confusing landscape with hundreds of tools available. Platforms have their own specializations and there is no clear line between a tool (with a narrow focus) and a platform (which supports many ML lifecycle activities). Even platforms that have a similar scope have different concepts and strategies, making them hard to compare directly.

Based on “Guide to Evaluating MLOps Platforms”

The figures below illustrate how platforms specialize in particular areas (bottom) and others aim to cover the whole lifecycle with equal focus (top). The original figures are from the Thoughtworks Guide to MLOps Platforms. We add Jina as a new entry to it.

Based on “MLOps Platforms”

Below we adopt the methodology from MLOps Platforms and add Jina as an entry. The chart and tabular data are credited to MLOps Platforms.

	Product Focus	Pricing - OSS, per-model etc.	Data Preparation - Exploration, cleaning, feature engineering	Model Training - Managed training. Or AutoML.	Model Deployment - Batch, real-time, streaming	Scaling Predictions - Parallelisation, low-latency/grpc, A/B tests, multi-model	Model Performance and Basic Monitoring - Accuracy, metrics etc.	Model Governance - model registry/catalogue	Continuous Delivery - Auto-retraining, promotions, environments	Collaboration Features - “workspaces”, permissions	Self-install Support - Bare Metal/VMs/containers	Cloud/SaaS Support - Self-managed, SaaS etc.
Jina	Build cross-modal and multimodal services on the cloud, ease the building of neural search and creative AI cloud-native services in production.	Opensouce, free cloud hosting via JCloud, free finetuning via Finetuner.	Reusable building blocks for preprocessing, cleaning, feature engineering are “Executors” in Jina’s terminology. They are contributed by Jina AI and the community via Jina Hub	Model finetuning is managed by Finetuner, and freely available to Jina users.	Deployment as optimized REST/gRPC/Websockets/GraphQL services. Can be deployed via JCloud, Kubernetes, DockerSwarm. Support real-time and stream processing.	Async data flow all the way. autoscaled, serveless executor on JCloud	Monitoring for latency and resource built-in. Integrated Prometheus, and dashboard for Grafana which can be customized to monitor model performance.	Jina Hub provides a marketplace for share, explore, and try models, executors. They can be directly used as a microservice in any Flow, without download or pulling.	Connect to CI/CD tool (e.g. Github) to automate Executor and Flow release via jina-hubble-sdk and jcloud	Basic private & public permission on data, Executor and Flow. “public” means everybody can view/check/use/listing for all 3 concepts “private” means only user itself can view/check/use/listing for all 3 concepts. Will introduce more access levels in the near future	Can be run locally, self-hosted, and via JCloud. Flow can be deployed on any K8s, Docker swarm cluster.	Managed via JCloud or self-managed on own infrastructure or any cloud provider.
Dataiku DSS	Data exploration, model building and excel-style interaction with big data. Visual or code-based pipelines for building and deploying models.	Enterprise. Not stated.	Lots of data sources, application of schemas, highlighting and fixing of outliers and missing values, interactive stats, built-in filtering and transformations and sampling. Assisted labelling plugin.	Flows/Pipelines for training/retraining. Lab for assisted building of models/AutoML. Models can also be custom or Spark.	Real-time deploy to API Node. Batch Prediction via Flows. Support for Spark and Spark Streaming.	Model versioning, rollbacks and traffic splitting. HA and loadbalancing. Export for prediction in other runtines or offline, inc onnx export.	Real-time scoring. Metrics.	Models built in flow saved as versions. Active and inactive versions and concept of rollbacks.	CI/CD pipelines	Projects with permissions. Also history and rollbacks. Configurable user isolation across integrations.	Linux or AWS	Dataiku Online is a new offering
H2O	Platform with a core Java compute engine. Lots of integrations and add-ons, includuing AutoML.	Enterprise. Not stated. Open source core platform.	h2o-3 supports range of input formats and manipulations. Driverless AI supports even more inputs, has visualization and also automatic and tailored feature engineering.	Training features in Driverless AI are AutoML. Training features in h2o-3 are for pre-defined algorithms.	Predictions can be made in h2o-3 and it can integrate to Spark. Models can be deployed within Driverless. But centerpiece deployment tool in the suite is MLOps for its features and integrations.	In MLOps there’s champion/challenger and A/B traffic splitting. Different run-time options for latency optimization. Export to other runtimes inc Java and C++.	Latency, alerts, custom metrics.	AppStore is like a catalog of apps built from models and has permissions. Integration at project level between model building and hybrid cloud appstore is like registry - called Shared Model Repository.	Automatic retraining for driverless AI models. Dev-test-prod envs	Projects and sharing in MLOps. Maps to other hybrid cloud products.	k8s for MLOps. h2o-3 part of stack can be run locally	only for trials
Databricks	Spark and mlflow as open source offerings. SaaS platform with added features and DeltaLake as enterprise. ‘Customer-managed’ SaaS option on AWS, Azure or Google.	Open Core. Platform can be pay-per-use (DBUs)	Notebooks. Spark. Cloud provider integrations. Feature store. Data Catalog.	Mlflow, Spark MLLib and AutoML. Distributed training including using GPUs. AutoML.	MLFlow serving for real-time. Spark for batch or streaming.	Versions and stages for models with MLFlow. Relatively new feature and in preview. For traffic splitting and inference pipelines there are integrations	Logs and resource monitoring built-in.	mlflow model registry with permissions and deployment history	CICD templates, stages	for notebooks, models and spark	Typical installation is on your cloud account via integration with cloud providers. Allows for levels of control over cloud infra. Open source parts of the platform (e.g. spark, mlflow) can be installed by the user but that’s a subset.	Option for ‘customer-managed’ SaaS as well as SaaS options on AWS, Azure or Google.
AWS SageMaker	MLOps platform on AWS	metered	Ground truth for labelling, wrangler for feature engineering and feature store, studio IDE, notebooks	Pipelines brings together different training options. Lots of support for different languages and distributed vs not distributed. Spot instance option interesting. Pipelines for SageMaker have less prominence in docs than Pipelines for Vertex - less emphasis on orchestration.	Deployment with pre-built or custom containers. Inference pipelines supported. Unified batch and real-time.	Autoscaling. Multi-model. GPU inference and elastic inference for low-latency. Async for large payloads. Traffic splitting.	Invocation metrics to CloudWatch. Payload capture/logging. Custom monitoring schedules to check constraints.	Model registry with versions, groups and associations to training metadata. Can enable cross-account deployment.	Payload capture/logging. Templates for CI/CD.	Has projects idea - has to be configured as is not used by default. Has templates for using with git and CI/CD.	Can train models in k8s with kubeflow. Could do this with other tools too but AWS are trying to support it. Only training though.	SaaS
Azure Machine Learning	MLOps platform on Azure	metered	Data labelling service. Ingestion pipelines. Azure Synapse for prep/wrangling.	Container-based training in an Environment or can use a training Pipeline for distributed. Visual editor for assisted pipeline creation or there’s also full AutoML.	Deployment with pre-built or custom containers as managed endpoints. Real-time or batch.	GPUs and traffic splitting available.	Monitoring for latency and hardware resource built-in.	Per-workspace registry and shareable across workspaces.	Pipeline, CI and git integration. Payload logging to blob.	Workspaces with permissions and security.		SaaS
Google AI Platform (Vertex)	Vertex AI Platform on Google	metered	Vertex feature store, data labelling service, managed/unmanaged datasets, BigQuery, notebooks.	Integrated metadata for pipelines. Distributed training for custom training jobs where frameworks supports. GPU-based training for custom training. AutoML fits alongside.	Deployment with pre-built or custom containers. AutoML similar but easier. Batch support.	Traffic splits available. Private endpoints for low-latency.	Built-in monitoring of latency etc.	Not an explicit concept of registry in docs but there is a models page in a vertex project, which is like a registry.	Prediction logging and continuous evaluation possible but not yet well integrated under Vertex. Pipeline is a bit like CI	Uses concept of projects and assigning permissions		SaaS
Kubeflow	Open source MLOps for kubernetes	Open source. There are also tailored distros and fully managed in google vertex and from Arrikto	Jupyter notebooks	Pipelines as orchestrator and training platform. Training operators for specific frameworks. Katib for hyperparameter tuning (AutoML).	KFServing as core component with Seldon and other integrations. KFServing has batching integration and a streaming example. Preprocess and postprocess inference steps available.	KFServing has autoscaling through knative, traffic splitting, multi-model serving and GPU integration.	Resource and high-level request metrics integration. Can be added to UI.	No native model registry. Can log model details (artifacts) with metadata. Listing of running models available.	Kubeflow Pipelines for workflow orchestration - needs to be invoked from CI. Als flexible request logging via kfserving or seldon.	Namespaces and sharing permissions between namespaces	Self-install on kubernetes is the default route, with some per-provider distribution customization.	Google Vertex has managed kubeflow pipelines but that is not the same as a managed kubeflow. There are distributions which hook into some managed platform features.
Mlflow	Open source flexible approach to MLops	Open source. Also available integrated into the databricks managed service.	Projects and entry points provide a way to package data operations.	MLflow does tracking during the training process. Provides structure with projects and entry points and multi-step workflows. Can execute locally or on a hosted backend e.g. kubernetes. Provides tools that put structure around training rather than hosted platform like many others do.	MLflow Models provides structure for packaging and deploying models. Local basic serving is out of the box. Built-in and extensible integrations for specialist hosting with plugins available. Can do batch straight from projects without serving step. Batch or streaming also possible with spark integration.	Depends on the chosen deployment option. The functionality of mlflow serve is basic but mlflow is designed for integrations with more features such as sagemaker	Depends on the chosen deployment option as it is the deployment which is monitored. There are integrations but the deployment itself is outside of mlflow open source.	Model registry which provides model lineage, versioning, stage transtions and annotations.	mlflow projects can be git repos so can hook CI into git to call an entry point. Promotions can be recorded in registry	Mlflow projects can be git repos so there’s separaton and collaboration there. At server level there’s not a concept of permissions in the open source	Can run on local machine or install server to run hosted	Managed version from databricks
KNIME	Open core low-code visual Data Science and Data Analytics platform with MLOps capabilities.	KNIME Analytics Platform is free and open source. KNIME Server requires an annual license.	Inspection of tabular data and generation of plots within Analytics Platform workbench. Various data manipulation nodes available.	Workflows can be used to manipulate data and train models. These can be scheduled to run on KNIME Server to leverage elastic infra.	Captured subsets of workflows, which can contain models, can be deployed to KNIME Server. Can be for REST calls or as scheduled jobs. Some nodes support streaming. Workflows containing javascript-enabled interactive nodes can also be deployed with KNIME Server’s Web Portal.	Challenger rollout modes like A/B testing using Model Process Factory templates. Validation can be performed on model during deployment to KNIME Server.	Model monitoring component for classfication or can be done more generally using Model Process Factory. For scheduled jobs there’s notifications. Status of running workflows can be inspected in the admin UI.	Versioning and comparison of workflows. Workflows are the key unit rather than models in KNIME, though models can be exported to PMML if you want to deal with them outside KNIME.	Triggered retraining for classifiers with model monitoring component. KNIME server has a REST API so deployments can be invoked from CI.	Workflows can be parts of workflow groups. Permissions on workflows and groups with owners and delegation.	Server can run on cloud or on-prem. Analytics Platform is a desktop app.	Marketplace versions available of Server for Azure and AWS.
DataRobot	End-to-end Data Science and MLOps Platform. Model building for Data Scientists and Citizen Data Scientists (AutoML). MLOps for deploying and monitoring models.	Enterprise. Three-year licence with metered pricing plans.	Many data sources such as jdbc databases, databricks and salesforce. Spark SQL support. Visual wrangling operations. Automated transformation flows.	AutoML for building models with feature detection/exploration and customizable model search. Monitoring for model building jobs. Leaderboard for choosing a model from the AutoML search. Training dashboard for insights into the model training process.	Real-time and batch prediction options, including high volume batch. Post-processing of prediction data.	Challenger rollouts and monitoring to compare the challenger in detail. Can take stored predictions that went to the main model and replay against the challenger.	Accuracy and availability monitoring for individual models and as a summary. Specialist monitoring for time series.	Deployment actions restricted by role. Deployment approvals. Deployment notifications and reports. Model registry with generation of compliance docs.	Automated retraining. Write-back integrations to log predictions and responses to Snowflake, Tableau and BigQuery as well as native storage.	Deployment permissions. Platform-wide roles and RBAC. Projects for building models.	Can be installed on-prem as a supported option	Installation on preferred cloud platform or as managed service.
Pachyderm	Data Foundation for Machine Learning. Pipelines with automated data versioning, lineage and monitoring.	Enterprise Edition is self-deploy and Hub is a managed service. Contact pachyderm for pricing of these. Community Edition is open source and free.	Notebook integration for exploration. Main focus is pipelines and lineage rather than exploration. Data transformation within pipelines is recorded and monitored. Could be used with any exploration or wrangling tool. Integration examples available for data labeling and experimentation.	Data Versioning and Lineage for Pipelines which automates reproducibility for data transformation and model training. Console adds visibility/monitoring. Approach is agnostic to choices of code libraries. Especially well suited to large volumes of unstructured data as well as structured data.	Can be used with deployment tools to track data at the prediction stage as well as training. Integration examples are available. Can also serve a model API directly using Service concept.	Can be used with deployment tools to track data at the prediction stage as well as training. Integration examples are available. Can also serve a model API directly using Service concept.	Can be used with deployment/monitoring tools to track data at the prediction stage as well as training. Integration examples are available.	Trained models and their artifacts can be versioned in Pachyderm and hosted with Pachyderm’s S3 gateway to be integrated with deployment systems	CI integration, which can be setup to retrain. An end-to-end CD example is provided. Spout for streaming data.	Access controls with identity provider integration. Console to facilitate collaboration on DAGs/pipelines and for debugging. Notebooks for collaboration on pipeline creation. Contexts for switching between clusters.	Pachyderm Enterprise and Community editions both provide a self deployed option for local or kubernetes	Pachyderm Hub provides a managed Cloud version
Seldon	With an open source core and other popular open source libraries, Seldon focuses on model management, deployment, monitoring and explainability.	Open source core + libraries. Enterprise platform priced per model.	Works well in tandem with data preparation/versioning tools	Agnostic about model training and frameworks used. Integrations with MLFlow, Kubeflow, Pachyderm etc.	Deployment as optimised REST/gRPC microservices. Can be deployed using pre-packaged inference servers or using custom python components. Support for real-time inference, batch predictions and stream processing.	Autoscaling, multi-model inference graphs, A/B tests and progressive rollouts.	Collects metrics by default on your deployed models. Custom metrics can also be defined and there is support for distributed tracing and payload logging	Seldon supports a variety of model stores with integration in to cloud stoarge providers. The enterprise offering comes with a model catalog together with supporting metadata.	Enterprise offering includes gitops capability, allowing model deployments to be automated, versioned and reproduced. Also examples for upgrades and rollbacks, intelligent rollouts with iter8 and alerts based on monitoring	Seldon Core uses Kubernetes namespaces for separation of workspaces. Seldon Deploy also comes with project based authorisation	Self-install on Kubernetes with installers provided for enterprise offerings	Self-managed on own infrastructure or any cloud provider.
PrimeHub	End-to-end ML orchestration platform for Kubernetes. Focuses on model management/deployment with cutomizable notebook environment, 3rd-party app integration and admistrative features.	Community Edition (OSS) and Enterprise Edition priced per nodes/deployments; License Comparison.	Notebook, group shared-files, multi-dataset management, and Label Studio (Integrated by PHApps). End-to-end tutorial to show this.	PrimeHub SDK (guide), job scheduling, model management integrated with MLflow.	Via Deployments, models can be deployed with pre-built/custom pre-packaged servers as services over Kubernetes with the specified resources and access-control. Streamlit(integrated by PHapps) to create interactive web apps.	Deploy different versions of a models in parallel for the purpose of A/B testing. Deploy models with multiple replicas for scaling predictions.	Integrated Prometheus, and dashboard for Grafana to monitor model metrics. Integration with MLflow to track training metrics.	Through MLflow integration, experiments/models can be tracked and versioned with access-scope per group. Deployments are also restricted by their own private/public access.	Schedules can be used to deploy and upgrade model versions.	Groups can collaborate and share data, notebook files, artifacts and models through their own User Portal.	Self-install on Kubernetes: Both Community Edition (single-/multi-node)and Enterprise Edition (single-/multi-node) with Trial License available.	Self-managed on own private Kubernetes, Google GKE, or Amazon AWS
Prevision.io	AI management capabilities for production data science.	Pay-as-you-go	Connectors to data systems. Dataset exploration module and automated features engineering. Notebooks integration.	AutoML.Experiment tracking capabilities (versioning, external model import). Pipelines to automate model creation or more complex tasks.	Models are deployed on a custom URL. Rest APIs allow the model to be requested in real-time. Pipeline for batch prediction.	Autoscaling for deployed models with champion/challenger rollouts.	Monitoring for deployed models in the default UI, including predictions, inputs, CPU, response time and memory.	Deployed models are listed and versioned. Depending on permission level, they can be added to a marketplace.	Pipelines (scheduled or triggered) & git integration for automated retraining.	Projects with permissions. Deployments with permissions.		SaaS
Iguazio	MLOps platfom with a built-in feature store running on AWS, Azure, GCP & on-prem	OSS & Enterprise	Feature engineering with an online feature store, support for various data types (structured & unstructured) and sources (including streaming), built-in Jupyter service & support for 3rd party IDEs (eg. Pycharm)	Pipelines for training. Option to leverage 3rd party training platfoms such as SageMaker & Azure ML or run training in Iguazio using Kubeflow pipelines.	Deployment/serving supporting batch & real time using Nuclio serverless functions.	Built-in API gateway for rolling upgrades, scale with serverless nuclio-based functions running on Kubernetes	Real-time monitoring for performance and operational statistics	Built-in experiment tracking with model and artifact versioning including model management & cataloging	Integration with common CI/CD tools including Gitlab, Jenkins, Github	Users work in the context of a project with workspaces and permissions. They can share and collaborate on features, models, artifacts etc. per project. Built-in security layer with RBAC	Self install on multi-cloud (AWS, Azure, GCP), on-prem or hybrid, including on-prem VMs	Installation on preferred cloud platform or as managed service. Self service running on customer’s VPC
Neptune.ai	Metadata store for MLOps, built for teams that run a lot of experiments. Neptune.ai logs, stores, organizes and displays metadata, so that you can query and compare on metadata generated during training and experimentation.	Free individual and paid team/enterprise plans available.	Data versioning and artifacts (possibility to log and query metadata at a project level, including dataset and model versions, text notes, images, notebook files, and anything else that can be logged to a single Run). Integrated with Jupyter Notebook and Deepnote.	Tracking model training (data, code, parameters, and model binary versioned for every model training run). Ability to re-run a training job. Integrated with PyTorch, PyTorch Lightning, TensorFlow/ Keras and more.	All model artifacts are stored in a central model registry. Guide provided for integration with CI/CD pipelines.	N/A	Training can be monitored as it happens. Neptune is for monitoring training and experimentation and recording metadata for later reference. It is not a production monitoring/observability tool and can be used alongside one.	Neptune.ai can be used as a model registry (all model-building metadata can be logged, queried and downloaded).	Integrates with CI/CD pipelines. Can be used with GitHub Actions and Docker.	User groups and ACL (only for Teams and Enterprise customers), users can share UI links with project members/external people as well as add notes and comments.	Can be deployed on-prem (installation manual provided).	Managed cloud service (SaaS)
Verta	Platform for model management & operations including experiment tracking, production registry, deployment, and monitoring.	Enterprise pricing delivered as SaaS, on-prem, or VPC.	Works with data preparation, exploration, cleaning, and featuring engineering tools	Works with model training tools	Verta Deployment - Serve inference in batch, real-time and streaming (kafka). Verta Model Registry - package and deploy to external ecosystem (e.g. Spark)	Manage model release versions and stages. Supports autoscaling, HA, canary rollouts	Operation metrics available in the system & exported to other systems. Ingest GT and monitor model performance metrics. Supports creation of custom metrics	Package & publish release ready models in Verta Model Registry. Transition model stages with approval workflows & activity logs. Capture model metadata, ensure model immutabilty and add CI/CD automation	Connect to CI/CD tool (e.g. Jenkins) to automate model release. Approval workflows and stage/environment promotion	Support for workspaces, granual user permissions, admin controls and collaborators. RBAC, user management, SSO support with variety of identity providers.	Self-install of ModelDB on kubernetes	SaaS, on-prem, and VPC

Conclusion

Deep learning applications are quite diverse, and one may consider Jina as MLOps framework for neural search and creative AI. Having one MLOps platform that can deal with all of these different settings and requirements is quite difficult. Most MLOps products promise everything but actually pick a specific subset of these possibilities. It might not even be a good idea to build a platform that works for everything. Jina focuses on cross-modal and multimodal applications, optimizes for their system designs and requirements, and provides an end-to-end development experience that can be used to build in production applications.