2023
Integration Patterns for Distributed Architecture - Intro to dionysus-rb
In the previous blog post, I promised we would introduce something special this time. So here we go - meet almighty Dionysus, who knows how to make the most of Kafka.
Read on →Integration Patterns for Distributed Architecture - Kafka at Smily
In the last blog post, we covered some fundamental concepts about Kafka. This time, let’s discuss how we use Kafka in Smily, how we got where we are now, what the decision drivers were, and how the overall architecture has evolved over time.
Read on →Integration Patterns for Distributed Architecture - Intro to Kafka
In the last blog post, we covered a general overview of integration patterns for distributed architecture, and now it’s time to get into further details.
Read on →Integration patterns for distributed architecture
Distributed architectures have been growing in popularity for quite a while for some good reasons. The rise of cloud services making the deployments simpler, as well as the ever-growing complexity of the applications, resulted in a shift away from monolithic architecture for many technical ecosystems. Microservices have emerged as an alternative solution offering greater modularity, scalability, reliability, agility, and ease of collaboration between multiple teams. Nevertheless, these benefits don’t come for free. The price to pay could be significant due to many factors, and one of them is dealing with some challenges that don’t necessarily happen when working on a monolith. One of such challenges is establishing the best way of integration and communication between services.
Read on →2019
Messages on Rails Part 3: RabbitMQ
In the first part of this series, we were exploring some potential options for communication between services - what their advantages and disadvantages are, why HTTP API is not necessarily the best possible choice and suggesting that asynchronous messaging might be a better solution, using, e.g. RabbitMQ and Kafka. We’ve already covered Kafka in the part 2, now it’s the time for RabbitMQ.
Read on →Messages on Rails Part 2: Kafka
In the first part of this series, we were exploring some potential options for communication between services - what their advantages and disadvantages are, why HTTP API is not necessarily the best possible choice and suggesting that asynchronous messaging might be a better solution, using, e.g. RabbitMQ and Kafka. Let’s focus this time entirely on the latter.
Read on →Messages on Rails Part 1 - Introduction to Kafka and RabbitMQ
Microservices, Service-Oriented Architecture (SOA) and in general, distributed ecosystems, have been on hype in the last several years. And that’s for a good reason! At certain point, The Majestic Monolith “pattern” might start causing issues, both from the purely technical reasons like scalability, tight coupling of the code if you don’t follow Domain-Driven Design or some other practices improving modularity, maintenance overhead, and also from organizational perspective since working in smaller teams on smaller apps is more efficient than working with huge team on an even bigger monolith which suffers from tight coupling and low cohesion. However, this is only true if the overall architecture addresses the potential problems that are common in the micro/macro-services world. One of these problems I would like to focus on is communication between apps and how the data flows between them.
Read on →