Previously on the blog: in my previous post I spoke about the first three talk, two of them about chaos engineering.

The fourth talk was “Stop Bashing Orchestration! And Long Live Choreography!” by Martin Schimak (blog – twitter – linkedin) started with a description about how to design microservices (CRUD entities, use synchronous request and response, forget idempotent) to then discussing about decoupling microservices and their communication. If there is a microservice that controls the flow of the communications, we speak about orchestration. Events, on the other hand, decouples much more the different microservices: one service just signal the end of a computation by putting an event in a queue. Other services may be interested in such events, and they subscribe to it. This READ-WRITE paradigm is called choreography. The advantage of choreography is related to the lack of an orchestrator: if the order of events processing changes we don’t have to recreate the full sequence, and this means that there is more decoupling.
Events have no intent, they are outcome of a processing, while commands (messages sent for requesting an action) are all about intent. Events and choreography, and commands and orchestration are like yin and yang: they can be used together.

The fifth talk was “How Monzo replaced a critical service” by Irina Bednova (twitter – linkedin). Monzo is a company that develops microservices since the beginning, and nowadays has around 760 services. In the talk Irina spoke about the Faster Payment service. Basically for having an inter-bank transaction, Bank1 has to have a bank account in Bank2 and vice versa, so that Bank1 can move money in terms of its bank account. This is quite complicated if you think about how many banks exist (every bank should have an account in any other bank and vice versa). With Faster Payments, Monzo can send a request to Faster Payments that sends a message to the other Bank. Each message has to be processed based on its context.
The old processor was stateful. It has been split into different services, and at the end the core was rewritten in a stateless services based on a service that, based on an enriched input message, generates the appropriate message and its destination. To migrate from one to the other, they put in place a several steps migration: initially they duplicated the messages to the two services and they compared the results. Then, when the service was mature, they redirected only individual user ids, for then extending it to all the staff users, then to 20% of the customers and finally 100%

The sixth talk was “Scaling Microservices with Message Queues, Spring Boot and Kubernetes” by Daniele Polencic (twitter – linkedin) was one of the few talks with a bit of coding. There was an introduction to scalability and robustness, speaking about how to deal with big traffic. He reported a case in which Amazon itself was unable to scale enough. Speaking about 1. Autoscaling, 2. decoupling services and 3. decoupling failures he ended up speaking about message brokers (ActiveMQ) and minikube for testing kubernetes in local as a cluster, and the Spring endpoints /metrics.

We had then a couple of lightning talks of 15 minutes. They were a bit too fast to understand something. The 7th talk was “Bulding Event-Sourcing Microservices With Kafka” by Pegerto Fernandez Torres (twitter) in which he underlined how hard distributed systems are by speaking about the Chandy–Lamport algorithm, a snapshot algorithm that is used in distributed systems for recording a consistent global state of an asynchronous system, how complex distributed systems are in terms of observability and veracity (how much do you trust your data) and the operational complexity, and finally he spoke about scaling as an organisational growth process. He then spoke briefly about DDD (Data Driven Design) and how this brings to Event Driven Architecture, and he sugegsted the use of Kafka as a streaming system.

Another lightning talk was the 8th, “Microservices and Dependency Mapping – How to Obtain and Leverage the Graph of the System Component Interactions” by Mikael Wozniak (twitter) in which he spoke about how to map a microservices platform for 1. bug investigation, 2. testing, 3. creating siloed teams and 4. avoiding duplicated code. The possible ways for him are three: 1. using embedded libraries, 2. using monitoring tools like AppDynamics or 3. using distributed traces (spring-sleuth). Eventually the data can be put in a NEO4J database, that is a graph DB.

Last lightning talk was “Microservice Or Micromonolth” by Andy Czerwinski (twitter). The interesting thing I got from it is some interesting tools like Monalisa built on top of sleuth, Mappamonde on NEO4j and JSONAPI for the communication.

One last talk for the end of this first day. But I leave it for the next post.
Stay tuned!

Share