NavigationContentFooter
Jump toSuggest an edit

Understanding Messaging and Queuing GA and migration

Reviewed on 01 February 2024Published on 25 September 2023

Overview

A new version of Messaging and Queuing was released towards the end of 2023. In the new version, the concept of namespaces has been removed, to streamline your workflows, offer you a better developer experience, and simplify the management of your Messaging and Queuing resources.

The release of this new version in the Scaleway console coincided with the NATS and SQS protocols leaving Public Beta and going into General Availability (GA). This means that the Messaging and Queuing product, when used with these protocols, is now billable. SNS remains in Public Beta for now while we continue testing and improving the product as you use it.

Your NATS resources were automatically migrated to the new version of the product. However, for SQS and SNS you were prompted to migrate, by recreating your resources in the new version. In December 2023, as warned, the old product version was retired and any remaining resources were deleted.

For all protocols, the endpoints of your brokers changed in the new version, and you were prompted to update these endpoints in any code, applications or architectures using your message brokers.

Read on to find out more about the new no-namespace version of the product.

The previous situation: v1alpha1 and namespaces

Whether you create and manage your NATS or SQS/SNS namespaces and credentials via our API or our console, they both pointed towards the same underlying version of the product: v1alpha1, which held your resources.

In this previous version of the product, you created namespaces, setting the protocol for each namespace as either NATS or SQS/SNS. Each namespace gave you a URL (or endpoint) representing a Messaging and Queuing broker, and also allowed you to create credentials to access that particular namespace. When you created messages, queues, streams, topics and other resources, they were scoped to that namespace.

What’s changed: v1beta1 and no more namespaces

v1alpha1 is now deprecated, and v1beta1 is in production, representing the new and improved Messaging and Queuing product.

In this new version of the product, the concept of namespaces has been removed:

  • For NATS namespaces have been replaced by accounts. You can create one or multiple NATS accounts, and credentials for each account. Each account will have its own URL/endpoint.
  • SQS and SNS have been separated into two distinct protocols. Instead of creating a namespace, you simply activate each protocol. You can then create credentials for each protocol. If you previously used multiple SQS or SNS namespaces to separate resources, you should now use Scaleway Projects to separate your resources.

From Public Beta to General Availability: impact on billing

The change to the new “no-namespace” version of Messaging and Queuing coincides with the NATS and SQS protocols moving into General Availability. This means that the beta testing phase is over, and you are now billed for your use of Messaging and Queuing with NATS and SQS protocols.

Billing is based on:

  • For NATS: Stream volume (the number of messages sent * the message size) and stream persistence (the total amount of data stored * duration)
  • For SQS: Queue volume (the number of messages sent * the message size)

Full details of price points and how the billing model works are displayed in the console when you create a NATS account or an SQS queue, or can be viewed on our website.

Important

The precise start of the billing period for NATS and SQS was defined as the time of General Availability, not as the time of the migration to the new v1beta1 “no-namespace” version of the product. This means that messages sent using both the old and new versions were billed from GA onwards.

Note that SNS has not yet moved into General Availability, but will instead stay in Public Beta while we continue to work on testing and improving this product. This means that you will not yet be billed for using Messaging and Queuing with the SNS protocol, even though the v1beta1 version is also now used for SNS.

Migration: timescales and action to take

NATS

Scaleway automatically migrated all NATS namespaces and their credentials from the old version of Messaging and Queuing to the new one. In the new version, each NATS namespace became a NATS account (each with its corresponding credentials).

The migration should have been seamless: if you logged into the Scaleway console before migration/GA you saw the “old” version of Messaging and Queuing with your existing resources showing as namespaces. After migration/GA, you now see the “new” version with your newly migrated resources now showing as accounts.

The old v1alpha1 API was available until the 1st of December 2023, after which it was retired in favour of v1beta1 version.

Note that the URL/endpoint by which you access your NATS resources is not the same in the two versions. Endpoints from the previous version are no longer functional. You must use the new URL/endpoints, visible in the console from your Messaging > NATS > NATS Account dashboard, and also from the new API.

If you are a Serverless Functions/Containers user, and have created NATS triggers with the v1alpha1 version of the Messaging and Queuing API, you must recreate these triggers for the new version of the API.

Summary: NATS

✅ Migration from the old to new API has been automatically performed for you
✅ Billing of NATS resources began at the time of General Availability
✅ You must update your code, applications and architectures so they use the new endpoint
✅ You should have recreated your Serverless Functions/Containers NATS triggers if you had any

SQS

From the moment Messaging and Queuing with SQS went into General Availability, a 30 day period began, by the end of which you had to migrate your SQS resources from the old to the new version. This period ended in December 2023. You should now have recreated your resources (credentials and queues) in the new version, as all resources in the old version have now been deleted. The old v1alpha1 version of the API has now been deprecated.

Remember that the new version of the API has no namespaces: now, you simply activate the SQS protocol and then directly create your credentials and queues. SQS and SNS have been separated, so if you want to use both you need to activate both separately and create separate credentials for both.

Tip

If you previously had multiple namespaces to separate your SQS resources, we recommend that you use Scaleway Projects with the new version to handle this. By creating multiple Projects, activating SQS in each one, and then creating SQS credentials in each Project, you will be able to achieve separation of resources, and credentials scoped to the SQS broker of each Project.

Console documentation:

  • How to activate SQS
  • How to create credentials
  • How to create queues

API documentation:

  • SQS v1beta1 documentation

Migration timescale:

Before GA

  • Only the v1alpha1 API was available. All your resources existed in this API.
  • The console was based on this API, so when you viewed your resources in the console, you were viewing resources in the v1alpha1 API.

At the time of GA

  • The v1alpha1 API was still available. Your resources continued to exist in this API until you delete them.
  • The v1beta1 API also became available. You were prompted to recreate your resources (credentials and queues) in this API.
  • The console switched to using the v1beta1 API. You were no longer able to see or manage your old resources from the v1alpha1 API via the console. Any resources created via the console from this point forward exist in the v1beta1 API.
  • Messaging and Queuing with SQS became billable. Whether you were using the old version or the new one, via the API or other devtools or the console, you started to be billed for the messages you send.

December 2023

  • The v1alpha1 API was decommissioned. Any resources still existing on this API were deleted.

The URL/endpoints for your Messaging and Queuing SQS service and for your queues are not the same in the two versions. By now, you should have updated to the new endpoint in any code, scripts, applications and architectures that were using the old endpoint. The new URLs/endpoints are visible in the console from your Messaging > SQS dashboard, and also from the new API.

If you are a Serverless Functions/Containers user, and had created SQS triggers with the v1alpha1 version of the Messaging and Queuing API, you should have recreated these triggers.

Summary: SQS

✅ You should have migrated from the old version to the new by recreating your resources and credentials
✅ You should have updated your code, applications and architectures so they use the endpoints of the new version
✅ Billing of SQS resources began at the time of General Availability
✅ All resources still existing on the old version have been deleted
✅ You must recreate your Serverless Functions/Containers SQS triggers if you have any

SNS

SNS with Messaging and Queuing has not gone into General Availability with NATS and SQS, and is not yet billable. However, it has still moved from the existing old version (v1alpha1) to the new version (v1beta1) without namespaces.

At the time of the release of the new version (which coincided with SQS and NATS going into General Availability) a 30 day period began. You were prompted to migrate your SNS resources from the old to the new version within this time period, which ended in December 2023. You should now have recreated your resources (credentials and queues) in the new version, as all resources in the old version have now been deleted. The old v1alpha1 version of the API has now been deprecated.

Tip

If you previously had multiple namespaces to separate your SNS resources, we recommend that you use Scaleway Projects with the new version to handle this. By creating multiple Projects, activating SNS in each one, and then creating SNS credentials in each Project, you will be able to achieve separation of resources, and credentials scoped to the SNS broker of each Project.

Console documentation:

  • How to activate SNS
  • How to create credentials

API documentation:

  • SNS v1beta1 documentation

Migration timescale:

Before release of new version

  • Only the v1alpha1 API was available. All your resources existed in this API.
  • The console was based on this API, so when you viewed your resources in the console, you were viewing resources in the v1alpha1 API.

At the time that SQS and NATS went into GA

  • The v1alpha1 API was still available. Your resources continued to exist in this API until you delete them.
  • The v1beta1 API also became available. You were prompted to recreate your resources in this API.
  • The console switched to using the v1beta1 API. You were no longer able to see or manage your old resources from the v1alpha1 API via the console. Any resources created via the console from this point forward exist in the v1beta1 API.

December 2023

  • The v1alpha1 API was decommissioned. Any resources still existing on this API were deleted.

The URL/endpoints for your Messaging and Queuing SNS service are not the same in the two versions. By now, you should have updated to the new endpoint in any code, scripts, applications and architectures that were using the old endpoint. The new URLs/endpoints are visible in the console from your Messaging > SNS dashboard, and also from the new API.

Summary: SNS

✅ You should have migrated from the old version to the new by recreating your resources and credentials
✅ You should have updated your code, applications and architectures so they use the endpoints of the new version
✅ SNS remains in Public Beta (in both old and new versions) and is not yet billed
✅ All resources still existing on the old version were deleted in December 2023

Terraform

There is a new Terraform provider for the new version of Messaging and Queuing.

If you manage Messaging and Queuing using the old Terraform provider, you should have updated your Terraform files to use the new provider, in line with the migration timelines laid out above.

Further support and next steps

Do not hesitate to join us on the Scaleway Community Slack where we will keep you up to date and answer any questions on the #messaging-queuing channel.

  • Messaging and Queuing documentation
  • Messaging and Queuing developers documentation
Docs APIScaleway consoleDedibox consoleScaleway LearningScaleway.comPricingBlogCarreer
© 2023-2024 – Scaleway