Being involved in a project where Quarkus is intensively used, I’ve started to work on some integration tests and system tests where I’ve involved the persistent storages as well.
I’ve said persistent storages, yes, we have two: Microsoft SQL Server and Amazon S3. I will try to show next how both of them can be integrated for real into the testing part by using Testcontainers, without creating mock objects, like usually.
I found this article useful because the integration of Quarkus and Testcontainers is a different story (see this and this), compared with the integration between Spring Boot and Testcontainers. I’m not trying to say that Spring Boot has better integration with Testcontainers, but if you are coming from the Spring Boot world, then Quarkus has some minor(major) differences in certain aspects of how it is working. I’ve worked for a few days until I’ve finally finished integrating them into the project (thanks mainly to Sergei Egorov) and I want to share the knowledge that I have with others who are trying to achieve this goal. …
Today’s article will be oriented to a very specific concept, which is the In-Memory Data Grid or IMDG, discussing all the ideas introduced by this one.
IMDG is a general or abstract concept, which describes a way to leverage some kind of distributed system for storing data and performing in-memory computations on stored data.
Being an abstract construction, we will dive into a concrete implementation of the concept, looking specifically at Hazelcast In-Memory Data Grid.
What is an In-Memory Data Grid (IMDG)?
First of all, let’s introduce the concept of Data Grid. A Data Grid is a system of multiple servers that work together to manage information and related operations in a distributed environment. …
Modern distributed systems, especially microservices, are hard to be designed, developed, and maintained, as we’ve already seen in one of the previous posts, where were discussed more some key principles that should be followed when working on a microservice-based architecture.
We have seen that at this moment the most complete idea about building this kind of system is given by the Reactive Manifesto. In this set of principles, the most important one is the responsiveness of our system. This is achieved by building an elastic and resilient system on top of message-driven integrations between components of the system.
In a previous post, we have also discussed some message-driven integration patterns between microservices. …
In the previous blog post, I’ve shown what was the lessons that I’ve learned when I’ve worked in building reactive microservices. In the current article, I want to show you what are the methods that I’ve seen that allowed for gaining proper isolation and decoupling between microservices.
First of all, I will start by assuming that most of the software engineers are thinking that if two whatever software components (eg: two functions, two classes, two microservices, two systems, etc.) do not share anything and are not integrated in any way, then the perfect construction was achieved. Scaling the number of components from this statement from two up to let’s say tens, hundreds, or even thousands of them will make us think that a properly designed system is one in which the building blocks are not coupled in any way one of each other. …
I think that this will be the first blog post from a series in which my purpose is to share with you my experience when working with distributed systems.
For some time microservices are the most used architectural style and also the point that every software engineer wants to reach. During time microservices have undergone some changes and in this way, we have reached out at concepts such as miniservices, self-contained systems or reactive microservices and, reactive microsystems as defined by Jonas Bonér.
My point of view is that all these concepts share some fundamental to-be followed ideas, let’s called them patterns, and those are really important when building modern distributed systems. For me, personally, there is not about microservices or miniservices or other buzzy terminology, but about building responsive, scalable, and fault-tolerant distributed systems. …