Ultra Messaging Knowledge Base

UM in the Cloud Notes

• UM in the Cloud Notes
    • Disclaimer
    • Bottom Line
    • Multicast
        • Unicast Transports
    • Porting Existing Applications to Cloud
    • IP Addresses
    • Connectivity to Your Data Center
    • Latency
    • Containers
    • Next Steps

Disclaimer

The Informatica Ultra Messaging group does not have high expertise in Cloud computing. To the degree that Cloud provide a Windows or Linux execution environment, Ultra Messaging code will run fine on them. But we cannot help you properly configure your cloud instances.

Bottom Line

UM is fully supported in the Cloud. We have customers using a variety of different UM versions in the Cloud. Most of them are running in AWS, but we have at least one that I know of using Azure. In most cases, they are able to migrate to the cloud without any changes to their source code.

Porting to any kind of different environment brings with it the possibility of some kind of incompatibility, so naturally you will need to test your system before going live. But based on our experience, there should be no incompatibilities with UM.

Here are the high-level topics that need to be considered when migrating to the Cloud.

Multicast

Most cloud infrastructures do not support true multicast networking. AWS offers a multicast-like service, called the Transit Gateway, that allows applications to invoke standard multicast functionality (socket calls) and simulates the operation of multicast. However, some of our customers have expressed dissatisfaction with the Transit Gateway and have instead chosen to rely on UM's unicast protocols.

There are other potential multicast solutions; for more information, Multicast in the Cloud Notes.

For the purposes of this article, let's assume that you are not making use of a cloud-based multicast solution.

Unicast Transports

You should use either transport type LBT-RU or TCP. LBT-RU generally provides more predictable latency, but in the cloud the difference is minor, and the added simplicity of TCP might be preferred. See TCP vs RU for more discussion.

If migrating from multicast to unicast, you should enable source-side filtering. This can improve latency and throughput.

Note also that unicast transports can generate "connect" and "disconnect" source events. Your publisher code may need to be modified to handle these events.

Note that transport sessions are defined differently than with multicast. If you mapping topics to transport sessions explicitly, you will need to modify that mapping.

Porting Existing Applications to Cloud

In a majority of cases, applications can be ported to the Cloud by only making changes to configuration, not source code.

However, there can use cases where changes to your source code will be needed.

If you make use of the "MIM" functionality (Multicast Immediate Messages), you will have to migrate to a different method. Contact UM Support.
If your publisher is written to respond to what are called “source events”, switching to a unicast transport will introduce two new source events: “connect” and “disconnect”. Most of our customers can handle these new events without code change. But there is a possibility (low) that your code will treat the new events as an error and will malfunction as a result. We can help you analyze your software to determine if you are at risk of this. Contact UM Support.
Some customers map topics to transport sessions using application code. If you are changing your transport protocol from multicast to either TCP or LBT-RU, you will have to change how you map topics to transport sessions. Contact UM Support.

IP Addresses

There are different ways to deploy an application system in the cloud. Unfortunately, we Ultra Messaging engineers are not experienced with the different methods, so we can only rely on reports from our successful customers. In particular, I believe there are some deployment methods where you do not have any control over the IP addresses of the hosts that your services run on. Today it might be one IP address; tomorrow it might be a different IP address. In fact, I believe that in some cases, a given application could have a different IP address every time it is invoked, so it could be changing continuously during the day.

UM was not written with this kind of non-deterministic addressing in mind. UM normally expects applications to be long-running with a stable IP address. It is possible to configure your cloud deployment to have stable IP addresses; contact your cloud provider for details.

Connectivity to Your Data Center

If you need Ultra Messaging connectivity between your cloud and your own data center, you will probably need our DRO component. This component bridges across networks and provides transparent messaging connectivity. I.e. no source code changes are needed in your applications.

The most common way of configuring DROs to bridge between your data center and the cloud is two DRO instances connected by peer link. The UDP Peer Link feature (requires UM version 6.16 or beyond) can avoid the large latency outliers and throughput interruptions that can plague TCP-only peer links.

Latency

Due to the nature of the cloud environment, we cannot guarantee the same low latencies that you have today. Cloud can increase latencies for a number of reasons. And they tend to also increase variation of latency (jitter), so your latency deviations from the average will be higher.

There are some third-party products that claim to mitigate this somewhat. But we have not tested these products so we cannot give any advice concerning their use.

Containers

Some customers decide to containerize their applications at the same time they move to the cloud. We recommend that this be done as two separate steps. First containerize your applications in your own data center, and once that is working to your satisfaction, migrate to the cloud.

See UM-in-Containers-Notes.

Next Steps

To effectively support you, UM Support would like to have a meeting where you describe the architecture of the system, as it exists today and as you envision it existing in the Cloud. Your primary publishers and subscribers would be good to know. Approximate data rates would also be good to know.

We would also want to see your configuration.

Application configuration for UM. This is typically supplied using configuration files.
UM Service configuration. Do you use our Persistence functionality? If so, then you have “Store” processes running. We’ll want to see those configurations too.
Are you running the “lbmrd” service today? If so, when we’ll want that configuration file too (although sometimes the process can be run without a configuration file, with all operating parameter supplied on the command line).

KB Home | Index

UM Home

See Notices for important information.