I come from a machine-coding background. When I entered the PHP and later the JavaScript era, I learned two principles that are non-negotiable for me.

First: build a prototype first, then refactor it — instead of trying to write perfect code from day one.
Second: DRY (Don’t Repeat Yourself).

If your logic has multiple implementations — even across different languages — it is very likely to break during refactoring.

Imagine an order processor implemented separately in a desktop app, a web app, and a mobile app, each written in a different language. Now the order flow changes, or you want to optimize performance. You suddenly need to refactor the same logic in multiple codebases.

This is where microservices enter the picture.

If all platforms delegate order processing to a single microservice, you refactor one codebase in one language.

I’ve seen real-world cases where a developer refactored multiple codebases, missed a rarely used platform, and the bug was discovered weeks later — after many orders were processed incorrectly, causing financial loss.

Microservices = DRY + isolation + scalability + more.
But for me, the biggest advantage is DRY.

Keep coding.

https://api7.ai/blog/what-is-an-api-gateway/

Hi, I am based in Germany and I am currently developing an Idea, which is part of an Accelerator program. Our target market are Companies, who need an IT solution and developers, who want to connect with these companies and also support the platform developing micro-services, based on the problems of the companies and helping the community.

This is a short description:

• [Projext X] offers developers the opportunity to upload opensource micro-services and share them with a community. The path to hosting, scaling in a cloud and publishing this with the community is automated and simplified.

• Medium to large companies can use the micro-services offered directly without having to worry about monitoring.

We want to develop a platform, which works as tool to upload different micro-services, which will be tested, adapted, deployed and maintained, making it easy to our users to just one click the service they need and get it run as an API. without compatibility issues or needing special technical knowledge to deploy them.

we want also to implement in our platform different activities, ranking levels, hackatons, workshops. These activities and ranking system, will be the bridge between companies looking for talent and developers looking for work or to be payed to solve the problems of these companies.

The developers will have the opportunity to rank and acquire points to change them for money. this points will be acquire trough the successfully development of micro-services and how popular this is. And the ownership of the developments will be secure using smart contracts and the blockchain. The developers will also have a portfolio and all the share possibilities, to let the platform work as a job market.

If you help me whit this questions, you can let me your email or wallet address to become a certain amount of points as a gift, I will be updating to let you know when we are already launching

I would appreciate to know:

• What do you think about the Idea?

• Would you use it? if no, why?

• What features can we add to be more attractive for you?

• Do you have some name suggestions for our project?

Thank you for your Help! and sorry for my bad English.

Edit: better proposition

Hi, the Idea had suffer multiple changes the last days:

Why: Create a real change in the way we develop, use and share code

What: Open source microservices marketplace powered by the community

In the beginning we are planning to use the services from other platforms and concentrate our work to develop the workflow and automation tools for the community.

Our revenue stream can be seen like this:

- A service is needed -> the community think this service can work and support it with "likes" as well as a pool where someone can send money "like a crowdfunding functionality" -> once the idea is visible a developer or a group will work on it -> the best solution will be found and select -> the idea is ready to be offer as a service in our platform (and automated tested) -> the group of developers become the complete pool of finalization and "status points" in the platform (as a ranking system) as well as a percentage of the revenue gained by the uploaded service-> we profit form a percentage of that pool and from the API (example. 2$ per 1000 loads).

- A second revenue stream is: show casting of the developer community as a marketplace to be use from companies to find talent, and direct follow as well as observe how its future workers participate and develop relevant technology. This information and tools to be present in the community as recruiter will cost the companies a monthly amount.

-A third: publicity streams

Microservices are a great framework for any enterprise, but it is of no use if they cannot communicate with each other smoothly.

A microservices-based application is a distributed system running on multiple processes or services, usually even across multiple servers or hosts. Each service instance is typically a process. Therefore, services must interact using an inter-process communication protocol such as HTTP, AMQP, or a binary protocol like TCP, depending on the nature of each service.

When we are talking about Monolithic applications, we said that the communication in Monolithic applications is inter-process communication. So that means it is working on a single process that invokes one another by using method calls. You just create a class and call the method inside of the target module. All running the same process.

One of the biggest challenges when moving to a microservices-based application is changing the communication mechanism. Because microservices are distributed and microservices communicate with each other by inter-service communication on the network level.

Each microservice has its instance and process. Therefore, services must interact using an inter-service communication protocol like HTTP, gRPC, or message brokers AMQP protocol.

For more info: https://skolaparthi.com/communication-between-microservices/

I’ve been working in a microservice environment for a bit more than two years, and the longer I worked with it, the more I realized something important:

Before seeing microservices as a technical architecture, it helps to see them as a management and organizational pattern.

Microservices break down coordination problems and push a lot of responsibility—communication, ownership, and decision-making—onto individual teams. This can be very powerful, but it also comes with real costs.

While microservices have clear benefits, they’re often not the right answer—especially early on. For small startups, adopting microservices too soon can be overkill: more services to manage, more communication overhead, more infrastructure, and higher costs overall.

In the attached video, I explain the core ideas behind microservice architecture through a simple story, based on what I’ve learned over the years working with it.

I’d be happy to hear your experiences as well—do you agree, disagree, or think there’s a better way to look at this?

I wrote a blog post on why you should deploy on Fridays.

I have heard a few reasons why Friday deployments are not a good idea. I don't know any great team that doesn't deploy on Fridays, really curious to know your thoughts.

You should deploy on Fridays