cloud-lock - distributed locking via cloud storage in Java

What’s cloud-lock?

#

cloud-lock provides a means of distributed locking via cloud storage in Java. This let’s you do leader election to run certain workloads only once when your service is scaled out horizontally. Doing it via cloud has the benefit of not needing to provision a database for that purpose if your service is stateless in the first place.

How does it work?

#

Being the lazy P.O.S. that I am, cloud-lock exploits the nature of most cloud storage solutions of blocking concurrent modification of data stored there. So, what cloud-lock goes on to do is try to write to the same file from all instances of your service. The first one will succeed, gain the lock and update the file with time of getting the lock to point out that currently a lock is active. During concurrent access attempts, all other service instances will fail to write to the file and instances trying later will find that there is already a lock in place. After being done with its workload, the instance with the lock will delete the lock. That’s it! Easy-peasy lemon potato <3

Which cloud providers are supported?

#

At the moment, cloud-lock works with 3 different cloud storage solutions by the following providers:

• Google Cloud Storage (GCS) powered by Google Cloud Platform
• Azure Blob Storage powered by Microsoft Azure
• Object Storage Service powered by Alibaba Cloud

When to use?

#

Let’s go over the use case(s) of cloud-lock with a nice lil’ (and purely hypothetical) example:

Let’s say you are working on a stateless service, be it a serverless function or whatever and have periodic workloads you need to do with it. Extracting the periodic part would be too much effort, because the logic is tightly coupled or simply equals the service’s main purpose. Since we in a stateless context, we have no database and our go-to solutions for that are off the table. You might be working in the context of a landing zone, where you are not allowed to draw on certain infrastructural alternatives such as Leader Election with Kubernetes. And voila, cloud-lock is there to bail ya out. What can I say except “You’re Welcome”!

How to use cloud-lock?

#

Requirements

#

• Java 11+
• SLF4J
• Dependency of cloud provider’s storage solution that you actually use

Installation

#

Add the following dependency to your project:

• Maven

  <dependency>
      <groupId>com.originalflipster</groupId>
      <artifactId>cloud-lock</artifactId>
      <version>0.0.8</version>
  </dependency>
  

• Gradle

  implementation 'com.originalflipster:cloud-lock:0.0.8'
  

also provider dependencies

Setting up the storage

#

Before using cloud storage for distributed locking, you will have to enable the respective API in the cloud console of your choice and create a bucket and set up authorization for your service to be able to reach the bucket.

Refer to each doc of your cloud provider to learn how to do that.

Handling

#

There’s 2 ways of configuring cloud-lock on instantiation. Either create a new instance of CloudLock by passing it a Vendor and Config parameter

CloudLock cloudlock = new CloudLock(Vendor.GCP, new Config("tyler-lockett", "leader.txt"));

… or use the empty constructor. In this case, cloud-lock will look for a configuration file named cloud-lock.properties in the root of your classpath expecting all necessary configuration values.

vendor=AZURE
bucketName=tyler-lockett
lockFile=leader.txt
endpoint=https://tylerlockett.blob.core.windows.net/

To use, simply pass the workload you want locked to the doLocked method as a Runnable:

cloudlock.doLocked(() -> {
	System.out.println("My bajingo's on fire!");
});

Configuration

#

Check the following matrix to see which config values are required for which cloud storage provider:

In case you like to get crafty aside from the keyboard as well, peep this pattern to crochet your very own Java Duke of mine!