Cloud design patterns in microservices architectures — Part 2
This is the second part of a serie of articles speaking about cloud design patterns in microservices architectures. Here is the link to go to the Part 1:
Compensating transaction
Also known as “Saga pattern”. This is a pattern more related to software development. The idea is that for any call to a transaction (transactions in core banking are a good example), there is a compensating transaction that is invoked in case the first one fails.
With Neflix Hystrix, you can specify to Java which method must be invoked when the main method fails. This is really useful because with Hystrix we can follow the circuit breaker pattern and do not call the transaction failing in a period of time.
Compensating consumers
Several consumers subscribe to a same topic or queue, and the dispatcher takes care of distributing the call to the consumer in some kind of queue task distributor, like for example Round Robin, broadcast, or others... This is a very importan pattern if you want to achieve an architecture completely orientated to events. A good example of a product using this pattern is the distributed streaming platform Kafka.
Netflix: Netflix OSS provides Eureka, the service discovery of Netflix. Eureka stores and maintains the relationship of microservices registered to a service name and the ip and port that identifies this services. Eureka and Ribbon will be responsible of propagate the calls to the microservices through Zuul (External gateway) and Ribbon (reverse gateway).
Kubernetes: provides the element Service, which stores the private ip`s of all the pods registered to the service. Later, the service and its kubectl-proxy is responsible of redirect the call to the final pod.
Compute resource consolidation
Place resources that are needed each other close together like for example in the same server. With this aproximation, the latency of the calls between services will be minimum.
Netflix:it does not provide any library for this pattern. It is the duty of the devops people to know in which server the services will be placed and executed.
Kubernetes: you can choose in which server, inside the cluster of machines, the pods will be located and executed. If you do not specify the server, Kubernetes will take the decision for you.
Command and query responsibility segregation
One of the most important patterns if you want to achieve a good lambda architecture. Separate the code and the algorithms responsible of reading data from the code responsible of writing data. Reading data is much more faster than writing data, so, in order to minimize the time that a client is waiting for his call to be returned by the server, we send an event of writing some data to an event bus like for example Kafka or RabbitMQ. With this decision, the writing of data will be processed in a different way. In other words, the CRUD pattern is not recommended in Lambda architectures.
This pattern is software development oriented, so Netflix and Kubernetes do not provide any special quality for this pattern.
Event Sourcing
This pattern is related to the previous pattern: Command and query responsibility segregation. This pattern covers specially the writing path, enabling the possibility to write data through an event bus like Kafka or RabbitMQ. Following this pattern, we can achieve lambda architectures, completely oriented to data processing, in which data is processed in a massive way. For the same reason as explained in the previous pattern, Netflix and Kubernetes does not provide any solution for this pattern.
External Configuration Store
This pattern suggests us to locale all the configuration files outside our packages or FATJARS, with the scope of enabling the possibility to change the properties configurations of the applications without the neccesity of re-packaging again one artifact. This is not a new pattern, since in old web servers you already could locale the config files outside of the EARs.
Netfix: You can achieve this pattern in two ways:
- Netflix Archaius: the solution of netflix of the external configuration files. Netflix provides its own library in Java to get the props in the way of Archaius. You must get the files with Archaius if you want to refresh the config props if the files are updated.
- Spring Cloud Config Server: locate all the config files outside the fatjar, specially in a remote git server, where you can leave your properties. In this way, you have all the props files located in the same store, outside the packages.
Kubernetes: The cluster manager provides the tools security maps and config maps.You must associate this files to the deployment file, and automatically kubernetes puts this files in the pods as vm args. They are conceived for two scopes:
- Config maps: To store config properties in a file. They will be supplied to the pods when they are lauched as vm args.
- Security maps: The same than config maps, but designed to store users and params. In fact, you must store the passwords in BASE64.
Important: If you want to see all the config properties associated to a pod, just read the log of the pod, the first lines show the properties.
Runtime reconfiguration pattern
This pattern is related with the previous one: external configuration store, but specifies that an application must refresh its config properties when the properties change automatically. Unless in Java applications, this pattern behaves:
Netflix: Following the same argument of the previous pattern:
- Archaius: lets you schedule the time when the props are updated automatically. This must be configured with classes of Archaius.
- Spring Cloud Config Server: you must call the endpoint POST /refresh, provided by Spring Cloud, in order to refresh the beans located in @RefreshScope. This beans will take the new properties config.
Kubernetes: when you update the files: config maps and security maps, the new properties will be pushed to the pods using this files, but you must specify the pods to get the new files, delegating this act of refresh to the language of the pod.
Thanks for reading the second part of this series of articles. I hope that these lectures help you to understand better the microservices and cloud architectures and why they are designed in the way we know them.
