diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 44d3e9e..d6c4381 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -1,6 +1,5 @@ .Frequently asked questions * xref:ROOT:astream-faq.adoc[] -* xref:operations:onboarding-faq.adoc[] .Release notes * xref:operations:astream-release-notes.adoc[] diff --git a/modules/ROOT/pages/astream-faq.adoc b/modules/ROOT/pages/astream-faq.adoc index 2c66007..398011d 100644 --- a/modules/ROOT/pages/astream-faq.adoc +++ b/modules/ROOT/pages/astream-faq.adoc @@ -1,6 +1,10 @@ = {product} FAQs :navtitle: FAQs :page-tag: astra-streaming,dev,admin,planner,plan,pulsar +:page-aliases: operations:onboarding-faq.adoc + +When considering {product} for your production workloads, you might have questions about what options are available for connecting and consuming your serverless clusters. +This page answers some common questions about getting started with and using {product}. == How do I get started with {product}? @@ -28,6 +32,15 @@ The pricing model also makes {product} accessible to mid market and small/medium And finally {product} offers a user-friendly interface and free tier to satisfy the needs of individual developers and technologists who want to learn more about {pulsar} and data streaming in general. +== Why does {company} call {product} "serverless"? + +Running a {pulsar-reg} cluster that can handle at-scale workloads is not a trivial task. +It requires many (virtual) machines to be configured in a very particular way. + +In traditional cloud environments, you would pay hourly for every machine whether they are being used for workloads or not, and you would carry the burden of maintaining the server infrastructure. + +A serverless environment removes those operational burdens, and you pay only for the resources you actually use. + == What is CDC for {astra-db}? Change Data Capture (CDC) for {astra-db} uses a {pulsar-short} IO source connector that processes changes from the {cass-short} Change Agent through a {pulsar-short} topic. @@ -40,7 +53,115 @@ Each tenant can have multiple *namespaces*, a logical container for creating and A *topic* is a named channel for transmitting messages from producers to consumers. A *sink* feeds data from {product} to an external system, such as {cass-reg} or Elasticsearch. -== See also +== Shared clusters and Streaming Capacity Units (dedicated clusters) + +The following questions address differences between shared clusters and Streaming Capacity Units. + +=== What is the difference between shared clusters and Streaming Capacity Units for {product}? + +See xref:operations:astream-pricing.adoc[]. + +=== What happened to dedicated clusters? + +{product} dedicated clusters are now called Streaming Capacity Units. + +=== Are connections to shared clusters less secure than Streaming Capacity Units? + +Connections to both cluster types are secure. +However, Streaming Capacity Units offer the option for private connectivity. + +For Streaming Capacity Units, all connections in {product} are guarded by authentication, authorization, and secure (TLS) communications. +You can connect over the public internet or xref:operations:private-connectivity.adoc[establish a private connection]. + +Shared clusters also use a secure connection over the public internet. +However, shared clusters don't support private links. + +For more information, see xref:operations:astream-pricing.adoc[]. + +=== What are the differences in geo-replication for shared clusters and Streaming Capacity Units? + +Geo-replication is available for both shared clusters and Streaming Capacity Units. +Both cluster types can replicate to other clusters, but there are some differences: + +Connections:: +For shared clusters, traffic between clusters is secured over the public internet. ++ +Streaming Capacity Units can use either the default secure public internet connection or enable private links. + +Regions:: +Shared clusters can replicate between any xref:operations:astream-regions.adoc[supported region] of the same cloud provider. ++ +Streaming Capacity Units can use almost any region supported by your cloud provider, as well as across cloud providers. + +For more on geo-replication, see xref:operations:astream-georeplication.adoc[]. + +== Security and access control + +The following questions address security and access control in {product}. + +=== Does {product} support single-sign on? + +If your {product-short} organization is on the *Pay As You Go* or *Enterprise* {product-short} subscription plan, your users can use SSO to sign in to the {astra-ui}. +For more information, see xref:astra-db-serverless:administration:configure-sso.adoc[]. + +=== How do {product-short} roles and permissions map to {pulsar-short} roles and permissions? + +See xref:ROOT:astream-org-permissions.adoc[]. + +=== What is the difference between {product-short} application tokens and the {pulsar-short} tokens? + +See xref:operations:astream-token-gen.adoc[]. + +== Application development + +The following questions are related to application development with {product}. + +=== What APIs are available? + +See xref:apis:index.adoc[]. + +=== Can I migrate data from my existing {pulsar-short} cluster to {product}? + +Unless you are starting a project from scratch, you likely have message data that needs to be brought over to your {product} tenants. +For migration assistance, contact {support_url}[{company} Support]. + +Every tenant in {product} comes with custom ports for Kafka and RabbitMQ workloads. +{company} also offers a fully-compatible JMS implementation for your Java workloads. +For more information, see xref:streaming-learning:use-cases-architectures:starlight/index.adoc[]. + +=== How do I separate messaging traffic? + +It is common to have a hierarchy of development environments through which you promote app changes before they reach production. +The configurations of middleware and platforms supporting the app should be kept in parity to promote stability and fast iterations with low volatility. + +By Tenant:: +To support the hierarchy of development environments, {company} recommends creating separate tenants for each development environment. +This gives you the greatest flexibility to balance the separation of roles with consistent service configuration. ++ +All tokens created within a tenant are limited to that tenant. ++ +For example, start with a tenant named `Dev` that your development teams can access and create tokens for, and then create other tenants named `Staging` and `Production`. +At each level of the hierarchy, there are fewer users with access to the environment's tenant, which means fewer opportunities to create tokens that can programmatically access that tenant. +Yet, you still maintain parity across the three environments. + +By Namespace:: +Alternatively, you might choose to separate development environments by namespace within your {product} tenant. +While this doesn't offer as much flexibility as separation by tenant, it does offer a much simpler model to manage. +Also, note that in this scheme you cannot limit access by namespace. +All tokens would have access to all namespaces. + +=== Can I develop applications on open source {pulsar-short} and then move to {product}? + +{product} is actively maintained to keep parity with the official https://pulsar.apache.org[{pulsar} project]. +The notable differences arise from accessibility and security. +Naturally, you have less control in a managed, serverless cluster than you do in a cluster running in your own environment. +Beyond those differences, the effort to develop locally and then move to {product} should not be significant, but {company} recommends that you develop directly in {product}. +If you are trying to reduce costs, use the free tier of {product} and then switch when you are ready to stage your production services. + +=== Can I use {product} with my existing Kafka or RabbitMQ applications? + +Yes, {product} offers a fully compatible Kafka and RabbitMQ implementation. This means you can use your existing Kafka or RabbitMQ applications with {product}. You can also use the {product} Kafka or RabbitMQ implementation with your existing {pulsar-short} applications. {product} comes with custom ports for Kafka and RabbitMQ workloads. xref:streaming-learning:use-cases-architectures:starlight/index.adoc[Learn more] about the Starlight suite of APIs. + +=== Can I use {product} with my existing Java applications? -* xref:getting-started:index.adoc[] -* xref:apis:index.adoc[] +Yes, {product} offers a fully compatible JMS implementation. This means you can use your existing JMS applications with {product}. You can also use the {product} JMS implementation with your existing {pulsar-short} applications. xref:streaming-learning:use-cases-architectures:starlight/index.adoc[Learn more] about the Starlight suite of APIs. \ No newline at end of file diff --git a/modules/operations/pages/astream-pricing.adoc b/modules/operations/pages/astream-pricing.adoc index d2d7a20..a16bddf 100644 --- a/modules/operations/pages/astream-pricing.adoc +++ b/modules/operations/pages/astream-pricing.adoc @@ -74,6 +74,6 @@ If your preferred region isn't already available, you can contact your {company} == See also -* xref:operations:onboarding-faq.adoc[] +* xref:ROOT:astream-faq.adoc[] * xref:ROOT:astream-org-permissions.adoc[] * xref:operations:monitoring/index.adoc#aggregate-astra-streaming-metrics[Aggregate {product} metrics] \ No newline at end of file diff --git a/modules/operations/pages/onboarding-faq.adoc b/modules/operations/pages/onboarding-faq.adoc deleted file mode 100644 index 262e09a..0000000 --- a/modules/operations/pages/onboarding-faq.adoc +++ /dev/null @@ -1,111 +0,0 @@ -= {product} enrollment FAQ -:navtitle: Enrollment FAQ -:description: Common questions about getting started with {product}. -:page-tag: astra-streaming,onboarding,Orientation - -When considering {product} for your production workloads, you might have questions about what options are available for connecting and consuming your serverless clusters. -This page answers some common questions about getting started with {product}. - -== Why does {company} call {product} "serverless"? - -Running a {pulsar-reg} cluster that can handle at-scale workloads is not a trivial task. -It requires many (virtual) machines to be configured in a very particular way. - -In traditional cloud environments, you would pay hourly for every machine whether they are being used for workloads or not, and you would carry the burden of maintaining the server infrastructure. - -A serverless environment removes those operational burdens, and you pay only for the resources you actually use. - -== What is the difference between shared clusters and Streaming Capacity Units for {product}? - -See xref:operations:astream-pricing.adoc[]. - -== Are connections to shared clusters less secure than Streaming Capacity Units? - -Connections to both cluster types are secure. -However, Streaming Capacity Units offer the option for private connectivity. - -For Streaming Capacity Units, all connections in {product} are guarded by authentication, authorization, and secure (TLS) communications. -You can connect over the public internet or xref:operations:private-connectivity.adoc[establish a private connection]. - -Shared clusters also use a secure connection over the public internet. -However, shared clusters don't support private links. - -For more information, see xref:operations:astream-pricing.adoc[]. - -== Does {product} support single-sign on? - -If your {product-short} organization is on the *Pay As You Go* or *Enterprise* {product-short} subscription plan, your users can use SSO to sign in to the {astra-ui}. -For more information, see xref:astra-db-serverless:administration:configure-sso.adoc[]. - -== How do {product-short} roles and permissions map to {pulsar-short} roles and permissions? - -See xref:ROOT:astream-org-permissions.adoc[]. - -== What is the difference between {product-short} application tokens and the {pulsar-short} tokens? - -See xref:operations:astream-token-gen.adoc[]. - -== What are the differences in geo-replication for shared clusters and Streaming Capacity Units? - -Geo-replication is available for both shared clusters and Streaming Capacity Units. -Both cluster types can replicate to other clusters, but there are some differences: - -Connections:: -For shared clusters, traffic between clusters is secured over the public internet. -+ -Streaming Capacity Units can use either the default secure public internet connection or enable private links. - -Regions:: -Shared clusters can replicate between any xref:astream-regions.adoc[supported region] of the same cloud provider. -+ -Streaming Capacity Units can use almost any region supported by your cloud provider, as well as across cloud providers. - -For more on geo-replication, see xref:astream-georeplication.adoc[]. - -== Application development - -=== Can I migrate data from my existing {pulsar-short} cluster to {product}? - -Unless you are starting a project from scratch, you likely have message data that needs to be brought over to your {product} tenants. -For migration assistance, contact {support_url}[{company} Support]. - -Every tenant in {product} comes with custom ports for Kafka and RabbitMQ workloads. -{company} also offers a fully-compatible JMS implementation for your Java workloads. -For more information, see xref:streaming-learning:use-cases-architectures:starlight/index.adoc[]. - -=== How do I separate messaging traffic? - -It is common to have a hierarchy of development environments through which you promote app changes before they reach production. -The configurations of middleware and platforms supporting the app should be kept in parity to promote stability and fast iterations with low volatility. - -By Tenant:: -To support the hierarchy of development environments, {company} recommends creating separate tenants for each development environment. -This gives you the greatest flexibility to balance the separation of roles with consistent service configuration. -+ -All tokens created within a tenant are limited to that tenant. -+ -For example, start with a tenant named `Dev` that your development teams can access and create tokens for, and then create other tenants named `Staging` and `Production`. -At each level of the hierarchy, there are fewer users with access to the environment's tenant, which means fewer opportunities to create tokens that can programmatically access that tenant. -Yet, you still maintain parity across the three environments. - -By Namespace:: -Alternatively, you might choose to separate development environments by namespace within your {product} tenant. -While this doesn't offer as much flexibility as separation by tenant, it does offer a much simpler model to manage. -Also, note that in this scheme you cannot limit access by namespace. -All tokens would have access to all namespaces. - -=== Can I develop applications on open source {pulsar-short} and then move to {product}? - -{product} is actively maintained to keep parity with the official https://pulsar.apache.org[{pulsar} project]. -The notable differences arise from accessibility and security. -Naturally, you have less control in a managed, serverless cluster than you do in a cluster running in your own environment. -Beyond those differences, the effort to develop locally and then move to {product} should not be significant, but {company} recommends that you develop directly in {product}. -If you are trying to reduce costs, use the free tier of {product} and then switch when you are ready to stage your production services. - -=== Can I use {product} with my existing Kafka or RabbitMQ applications? - -Yes, {product} offers a fully compatible Kafka and RabbitMQ implementation. This means you can use your existing Kafka or RabbitMQ applications with {product}. You can also use the {product} Kafka or RabbitMQ implementation with your existing {pulsar-short} applications. {product} comes with custom ports for Kafka and RabbitMQ workloads. xref:streaming-learning:use-cases-architectures:starlight/index.adoc[Learn more] about the Starlight suite of APIs. - -=== Can I use {product} with my existing Java applications? - -Yes, {product} offers a fully compatible JMS implementation. This means you can use your existing JMS applications with {product}. You can also use the {product} JMS implementation with your existing {pulsar-short} applications. xref:streaming-learning:use-cases-architectures:starlight/index.adoc[Learn more] about the Starlight suite of APIs. \ No newline at end of file