You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/cosmos-db/cassandra/choose-service.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ In this article, you will learn the differences between [Azure Managed Instance
16
16
17
17
## Key differences
18
18
19
-
Azure Managed Instance for Apache Cassandra provides automated deployment, scaling, and operations to maintain the node health for open-source Apache Cassandra instances in Azure. It also provides the capability to scale out the capacity of existing on-premises or cloud self-hosted Apache Cassandra clusters. It scales out by adding managed Cassandra datacenters to the existing cluster ring.
19
+
Azure Managed Instance for Apache Cassandra is a fully managed service for pure open-source Apache Cassandra clusters. The service also allows configurations to be overridden, depending on the specific needs of each workload, allowing maximum flexibility and control where needed. It also provides the capability to scale out the capacity of existing on-premises or cloud self-hosted Apache Cassandra clusters. It scales out by adding managed Cassandra datacenters to the existing cluster ring.
20
20
21
21
The RU-based [Azure Cosmos DB for Apache Cassandra](introduction.md) in Azure Cosmos DB is a compatibility layer over Microsoft's globally distributed cloud-native database service [Azure Cosmos DB](../index.yml).
22
22
@@ -27,10 +27,10 @@ The following table shows the common scenarios, workload requirements, and aspir
27
27
||Self-hosted Apache Cassandra on-premises or in Azure | Azure Managed Instance for Apache Cassandra | Azure Cosmos DB for Apache Cassandra |
28
28
|---------|---------|---------|---------|
29
29
|**Deployment type**| You have a highly customized Apache Cassandra deployment with custom patches or snitches. | You have a standard open-source Apache Cassandra deployment without any custom code. | You are content with a platform that is not Apache Cassandra underneath but is compliant with all open-source client drivers at a [wire protocol](../cassandra-support.md) level. |
30
-
|**Operational overhead**| You have existing Cassandra experts who can deploy, configure, and maintain your clusters. | You want to lower the operational overhead for your Apache Cassandra node health, but still maintain control over the platform level configurations such as replication and consistency. | You want to eliminate the operational overhead by using a fully managed Platform-as-as-service database in the cloud. |
30
+
|**Operational overhead**| You have existing Cassandra experts who can deploy, configure, and maintain your clusters. | You want to eliminate the operational overhead by using a fully managed Database-as-as-Service for open-source Apache Cassandra, but have the option of controling Cassandra-specific configurations such as replication and consistency when required. | You want to eliminate the operational overhead by using a fully managed Platform-as-as-service database in the cloud. |
31
31
|**Production Support**| You handle live incidents and outages yourself, including contacting relevant infrastructure teams for compute, networking, storage, etc. | You want a first-party managed service experience that will act as a one-stop shop for supporting live incidents and outages. | You want a first-party managed service experience that will act as a one-stop shop for live incidents and outages. |
32
-
|**Software Support**| You handle all patches, and ensure that software is upgraded before end of life.| You want a first-party managed service experience that will offer Cassandra software level support beyond end of live| You want a first-party managed service experience where software level support is completely abstracted.|
33
-
|**Operating system requirements**| You have a requirement to maintain custom or golden Virtual Machine operating system images. | You can use vanilla images but want to have control over SKUs, memory, disks, and IOPS. | You want capacity provisioning to be simplified and expressed as a single normalized metric, with a one-to-one relationship to throughput, such as [request units](../request-units.md) in Azure Cosmos DB. |
32
+
|**Software Support**| You handle all patches, and ensure that software is upgraded before end of life.| You want a first-party managed service experience that will offer Cassandra software level support beyond end of live, automated patching, and turnkey upgrades for major versions | You want a first-party managed service experience where software level support is completely abstracted.|
33
+
|**Operating system requirements**| You have a requirement to maintain custom or golden Virtual Machine operating system images. | You can use vanilla images but want to have control over the selection of SKUs, memory, disks, and IOPS. | You want capacity provisioning to be simplified and expressed as a single normalized metric, with a one-to-one relationship to throughput, such as [request units](../request-units.md) in Azure Cosmos DB. |
34
34
|**Pricing model**| You want to use management software such as Datastax tooling and are happy with licensing costs. | You prefer pure open-source licensing and VM instance-based pricing. | You want to use cloud-native pricing, which includes [autoscale](scale-account-throughput.md#use-autoscale) and [serverless](../serverless.md) offers. |
35
35
|**Analytics**| You want full control over the provisioning of analytical pipelines regardless of the overhead to build and maintain them. | You want to use cloud-based analytical services like Azure Databricks. | You want near real-time hybrid transactional analytics built into the platform with [Azure Synapse Link for Azure Cosmos DB](../synapse-link.md). |
36
36
|**Workload pattern**| Your workload is fairly steady-state and you don't require scaling nodes in the cluster frequently. | Your workload is volatile and you need to be able to scale up or scale down nodes in a data center or add/remove data centers easily. | Your workload is often volatile and you need to be able to scale up or scale down quickly and at a significant volume. |
0 commit comments