Cloud design patterns in microservices architectures — Part 1
In this article I would like to write a study of the most important cloud design patterns and how, without you knowing it, you are applying many of them in your microservices oriented architectures. I think that it is really interesting to know this patterns in order to understand why cloud architectures are designed in the way we know them.
I will focus this series of articles mainly in two of the technologies that are currently in the state of the art in this architectures: Netflix OSS and Kubernetes. Consider that almost all of the cloud providers like AWS, AZURE , Google Cloud and IBM CLOUD are offering their own Kubernetes cluster, whether customized or from scratch.
I have obtained all this patterns reading this book written by the people of Microsoft, that althouth they adapt them to Azure, you can extract a good agnostic study from them: https://www.microsoft.com/en-us/download/details.aspx?id=42026
I will separate the patterns in several articles so that the reading is more enjoyable.
Cache aside pattern
Save data on demand in the cache to increase the performance of the microservices. You can also use this pattern when you want to share cached data among several microservices.
Netflix: The Netflix stack does not offer any propietary solution, but in an easy way it integrates with spring-boot-starter-cache to connect to many different cache engines like REDIS, Caffeine and others. In the case of Caffeine, you will not be able to share the cache among different microservices since this cache lives inside the classpath of the jre.
Kubernetes: Since this pattern is a programming oriented pattern, Kubernetes does not offer any solution. Nevertheless, it could manage REDIS like a pod inside the the kubernetes cluster with persistence or volatile storage volumes.
Circuit breaker pattern
Thanks to this pattern, a platform or a service may become resilient against failures, specially in points where you know that may appear system or integration failures. We can switch the circuit in this points in case of failure, and change the normal execution flow waiting for the failure to disappear, or kill the microservice an create a new one.
Netflix stack offers Hystrix to enable resiliency in critical points. In this points, Hystrix creates a new thread pool, different than the caller one, and a second optional execution in case the first one fails. You can also configure former dashboards to see more info. https://github.com/Netflix/Hystrix
Kubernetes: kubeflix is a java library that integrates Kubernetes and Netflix. It comes with Hystrix, Turbine and Ribbon. The main disadvantaje, it vinculates with Java.
Leader election pattern
Pattern oriented to manage machines in a cluster or instances of microservices. In an automatic way, the manager chooses a leader instance to work with the tasks. In case the leader fails or goes down, automatically another leader will be chosen.
Netflix: we can choose this pattern to avoid unique breaking points, like for example Zuul, thanks to Zookeper.
Kubernetes: Following this pattern, Kubernetes always have one master server and other one or more backup servers chosen as leader in case that the current leader fails. The tasks of this leader is to manage the cluster, manage the services, ingress controllers, deployments…
Pipes and filters pattern
This pattern decompose a complex task in more easier and smaller tasks, with the purpose of increase the scalability, performance and reuse of the service. In my point of view, this is the pattern that best describes one microservices architecture. Split a big task, or application, in several tasks, or microservices.
Netflix: microservices what communicate among then with http protocol or through an event bus (Event sourcing pattern) thanks to Zuul, Ribbon, Eureka, Spring Cloud…
Kubernetes: Pods executing microservices. The pods can communicate one to each other through services of kubernetes or through an event bus.
I hope this article is interesting for you. If you want to continue reading, go to the next part:
