4 helpful Cloud Design Patterns in 4 minutes.

Moving to the cloud is not a straightforward task. You have to take care of decomposing old services into new microservices, communication between services, security, logging, and so on.

Cloud Design Patterns help you to tackle those problems. They provide a blueprint to the most common challenges developers may encounter. Read more about four interesting patterns in this article.

Strangler Fig

Migrating your application to the cloud in one big bang will fail. It is no secret that small, incremental steps remove risk and complexity. The Strangler Fig Pattern applies this principle to cloud migration.

Create a facade that mirrors the old application's API. Find a coherent part of the system which you can isolate. The facade will decide whether to call the new, isolated system or the old system. Clients do not need to know that two systems exist. You can migrate parts of your old application without the need for any client to change.

Repeat the process until you old system is gone. This will literally strangle your old application until nothing is left.

Strangler-Fig enables you to grow new systems in small chunks.There are some challenges. The facade will increase the latency and add mental load as it increases the size of the overall system. As you do not want to implement the old API in your new service, consider adding an Anti-Corruption Layer.

Anti-Corruption Layer

You want to create new applications in the green countryside. Avoid old API methods or data structures if they do not fit the new application. You do not want to use SOAP in 2021, don't you?

The Anti Corruption Layer solves this problem. It hides obsolete APIs from your new application.

Create a new, thin service that translates old API calls to new ones. To hide file-based APIs, create a service that accepts file uploads. It will take the file and transform it into your new data structures. Those can be send via REST or gRPC.

You can remove the layer if it is no longer needed without any changes to your new service.

Anti-Corruption layer hides obsolete APIs.Again, this extra layer increased network latency and mental load. Yet, it keeps your new system clean.

Compare this to the Gang-Of-Four Pattern "Adapter" or the Ambassador Pattern.

Ambassador

Microservice architectures involve a lot of communication between services. As networks may fail, you need to add a layer of resilience to this communication. Take the Retry Pattern as an example. Yet, it can be hard up to impossible to do deal with this in old applications.

The Ambassador Pattern comes to the rescue. It acts as a Proxy between your old applications and cloud microservices. Old applications call the Ambassador which takes responsibility for retry, logging, security, and more.

That encapsulates cross-cutting concerns and reduces the changes in old systems. Also, it frees resources. An independent team can develop the Ambassador as a service for other teams.

On the downside are, as always, higher latency and a more complex system.

See also: Proxy, Anti-Corruption Layer.

Retry

The Retry Pattern handles temporary network failures and short service outages. If a request fails, your services try it again. It is as simple as that. Yet, there are multiple strategies for when and how often to retry.

You must limit the number of retries. Retrying 100 times will not help if the network or the other service is completely broken. On the other hand, retrying only once is also not helpful.

For example, the default in Spring Retry is three. That is a good rule of thumb.

But how long should you wait before you retry? A common strategy is an exponential back-off. Simply put, you wait 2^(n-1) seconds before you retry, where n is equal to the try.

So after the first failure, you wait 2⁰ = 1 seconds. If it fails again, you wait 2¹ = 2 seconds, then 2² = 4 seconds and so on. You give the problem enough time to solve itself.

Keep in mind that you should not (and cannot) repeat every request. Think twice if a request is expensive!