Loosely Coupled Environment for Microservices

In a system working with mircoservis architecture, we can list some of the situations where software developers have the most difficulty while developing in the local environment; realizing all scenarios of the developed works in the local environment, access to dependencies and stability of backing services in the environments.

If a software developer asks the following sample questions while developing, the system is missing something.
Is Kafka up?
Should I run all dependencies locally?
I do not have permission to access redis in the test environment, what should I do?
How can I implement the timeout scenarios?

Microservices architecture is very popular these days and it solves many problems. So what to do in such situations? Could other software developers have experienced such problems? The answer is yes. One of the 5 main goals in the 12factorapp manifesto is to solve such problems and while solving this problem, we should prepare the installations in the form of setup automation.

“Minimize divergence between development and production, enabling continuous deployment for maximum agility”

It is possible to run a service as standalone, yes

Let’s implement this problem with a simple scenario. Here’s our scenario: Let us have an order service, this order system will take information from product and seller services during create order. After the creation process, it sends an event saying that the order has been created. (This scenario is for example purposes. I tried to keep the architecture as simple as possible.)

According to this architecture, accessing all dependencies and backing services and all of them being stable can make development difficult.
Solution: We can solve all dependencies (mocking) and backing services in our local by simply run and up with docker.

Now, let’s examine the problems that may occur in the environments one by one;

Message queue:
We can configure the message queue integration as follows and perform our tests in our local environment. All we have to do is replace the kafka address with the address in our locale

RDMS (postgres):
In order to easily see database changes in our project, and especially if we use tools such as liquibase or flyway, we should not send them to any environment without trying them in the local environment. To make this process easier, we can make an integration as follows.

You can access sample liquibase scripts on github.

Nosql (redis):
As an example of various nosql solutions that have become widespread with microservices architecture and solve our problems in many subjects, redis integration will be as follows. So we can see if our integration is working properly.

Dependencies (other services used):
Sometimes it is inevitable that we get information from another services in microservices architecture. In such cases, we can mock all the requests and responses of the services we depend on.
According to our example project, we can run and up our dependencies in our local environment as follows.

Scenarios:
A healthy request scenario would be as follows.

http://localhost:8086/products/123

with timeout:
http://localhost:8086/products/25

You can access sample mock data on github

The final version of our Docker compose file will be as follows.
Now all we have to do is run the following command and then we can run and up our project.

docker-compose up

You can access the sample project codes on github

I hope it was useful.

Have fun..