Top 5 Scenarios for Blue/Green Deployments

In the first blog post, I explained the Blue/Green Deployments feature of Hazelcast IMDG Enterprise in general. Now, it is time to go through the top 5 scenarios where you can benefit this feature from.

When using these features, it may be necessary to copy data or synchronize data from one cluster to the other. The following Hazelcast Enterprise features can be employed.

• WAN Replication: Hazelcast WAN Replication keeps multiple geographically dispersed Hazelcast clusters in sync by replicating their state over wide area networks. Please see WAN Replication sections in the IMDG Reference Manual and Deployment and Operations Guide. 
• Hot Backup: Provides the ability to take a snapshot of cluster state to the Hot Restart Store at a certain point in time. This is useful when the goal is to bring up a new cluster with the same data or parts of the data. Please see the Hot Backup section in the IMDG Reference Manual.

Use Case 1: Low-Risk Patching

There might be cases where you might want to apply an important patch to either your application or Hazelcast IMDG itself. The Blue/Green deployment feature allows you to ensure that the bug is fixed and the patch does not cause any other problem. 

1. Start the new cluster with the patch.
2. Using Management Center’s Cluster Client Filtering screen, introduce filters via client labels, instance names, or IPs so that which clients should start connecting to the new cluster can be chosen. It might be useful to connect only a small subset of clients to the new cluster.
3. Monitor the new cluster to make sure that the bug-fix has been applied successfully.
4. Using Management Center’s Cluster Client Filtering screen, redirect remaining clients to the new cluster.
5. Shutdown the old cluster which has no connections coming from the IMDG clients.

Use Case 2: Upgrading Multiple IMDG Versions

Instead of an iteratively rolling upgrade for multiple version updates, you can use the Blue/Green Deployments feature to upgrade Hazelcast IMDG Enterprise at once.

Rolling Upgrade is an Enterprise feature of Hazelcast IMDG. It can upgrade Hazelcast versions of cluster members without service interruption. Each minor version is compatible with the previous one (back until Hazelcast IMDG 3.8). For example, it is possible to perform a rolling upgrade on a cluster running Hazelcast IMDG Enterprise 3.11 to Hazelcast IMDG Enterprise 3.12. However, you cannot upgrade from v3.10 to v3.12 as they are not consecutive.

Upgrading to a non-consecutive minor version requires applying the rolling upgrade procedure multiple times (i.e. as many as the version difference). For example, you need to apply the rolling upgrade procedure two times to upgrade version 4.0 cluster members to version 4.2. In short, you can benefit from the Blue/Green Deployments feature to upgrade your cluster members in a one-shot.

Use Case 3: A/B Testing

A/B testing is a method of comparing two versions of an application (i.e. control and variation) to determine which one performs better for a given conversion goal. You can also use A/B testing to provide the same functionality with two different methods so that you can test, compare, and analyze the two approaches.

You can use Blue/Green deployments to make A/B testing where your new application logic is served only for a specific set of users. In this use case, the blue cluster is the current version and the green one acts as the new one which includes the new features or the new application logic. Step by step, you can migrate the remaining clients into the new cluster until all is done.

Also, feature toggling and canary deployment might be another variation of this use case.

Use Case 4: Disaster Recovery

This use case corresponds exactly to the Automatic Disaster Recovery feature which is actually a specialized version of the Blue/Green Deployment feature. 

When one of the clusters is unavailable due to a site-wide failure, the connection between the clients and the owner member in that cluster is gone, too. When a client is disconnected because of a failure in the cluster, it first tries to connect to another member of the cluster. If no connection can be established to any members in the cluster, the next cluster is tried. The client’s behavior after this disconnection depends on its reconnect-mode, and it has the same options that are described in the “Features worth mentioning” section of our previous blog post.

The client tries to connect to those alternative clusters depending on the reconnect-mode if alternative clusters for the clients have been provided.

When failover starts, i.e., the client is disconnected and was configured to connect to alternative clusters, the current member list is not considered; the client cuts all the connections before attempting to connect to a new cluster and tries the clusters as configured. 

The prioritization of clusters is also supported. Clients are going to try connecting in the given order as shown below.

<try-count>4</try-count>

<clients>

    <client>client-config1.xml</client>

    <client>client-config2.xml</client>

    <client>client-config3.xml</client>

</clients>

Use Case 5: Resource Allocation During Peak Times

Hazelcast is an in-memory technology for scaling e-commerce and inventory management systems to handle burst behavior from different types of special days. The world’s largest e-commerce sites rely on Hazelcast for sub-millisecond response times during massive volume spikes commonly experienced during Black Friday, Cyber Monday, Singles’ Day or product launches.

During these events, you might want to make the main cluster serving as a sales-only point. In this case, you need to blacklist any process other than sales, such as DW (DataWarehouse), marketing, etc. A smaller cluster can serve these blacklisted processes. 

More Use Cases!

This was the second blog post for our Blue/Green Deployments feature. Please download the whitepaper below which introduces many other use cases and includes a more comprehensive introduction to the feature:

• Whitepaper: Blue/Green & Auto DR Failover Scenarios

Documentation:

• Hazelcast IMDG
• Management Center

Free Training:

• https://training.hazelcast.com

Join the Discussion:

• Google Group: https://groups.google.com/forum/#!forum/hazelcast
• Stack Overflow: http://stackoverflow.com/questions/tagged/hazelcast
• Gitter: https://gitter.im/hazelcast/hazelcast