DOC-4674 condense two faq pages

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[]

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.

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]