DEV Community

My experience and learnings from working in a microservices oriented project

Bruno Paz on December 01, 2018

In the past few years, Microservices have become a very hot topic in our industry and seen as the recommended way to build more decoupled, scalable...
Collapse
 
meysamsalehi profile image
Meysam Salehi

I'm in first steps of designing a migration plan from a big spaghetti monolith web app to microservices. In our architecture state machine play a key role and in the first thoughts like yours, we thinking about a generic state machine. but I agree with you about the costs of generalization. Thank you for sharing your experiences.

Collapse
 
nverinaud profile image
Nicolas Verinaud

I advise against going from spaghetti monolith to microservices. It will be less risky to move toward a modular monolith first, best if you can refactor your current monolith instead of starting from scratch.

Collapse
 
mamhaidly profile image
mamhaidly

I am interested to learn more about asynchronous communication between services. Any recommendations of references on this topic?

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

I'm also interested in this topic. Next year I might be able to write an article about a software system whose components use ActiveMQ for communication. However this system was not designed as a microservices system, so I'm eager myself to see if it works well.

I guess RabbitMQ might be a good decision in general, maybe even IBM MQ if you want to spend money on it. Kafka on the other hand is a bit special, but probably the messaging system of choice when you really have massive amounts of (small) messages and the publish-subscribe pattern matches your architecture.

Collapse
 
brpaz profile image
Bruno Paz

Great question.

Dont remember any particular resource on the topic, but you might want to look at Messaging systems like RabbitMQ or Apache Kafka.

Collapse
 
tyrotoxin profile image
Serge Semenov • Edited

You are not the only one, Bruno. Thanks for sharing - you just re-assured everyone in one of the most common problems developers solve over and over again.

For that very reason, I started the D-ASYNC open-source project, where your hierarchical state machines are represented merely by async methods. I.e. the programming language is the abstraction without a need for any special library or syntax.

I'm really curious about some details where your generic state machine library failed and what features were missing. And I totally understand how this complexity can derail developers from focusing on business logic (domain modeling). Even if you use an Actor Model framework, your code can blow up 5x in size. This is explained in details of Conquest of Distributed Systems series.

Share more, Bruno!

Collapse
 
daveclarke profile image
daveclarke

As a dotnet developer my reference for building myhonestybox.co.nz was Microservices in .NET Core by Christian Gammelgaard. It’s a really useful practical reference for developing a microservice system. It’s not the only way to build a microservice in .NET but it’s worth reading to get a perspective on one approach.

Collapse
 
cheetah100 profile image
Peter Harrison

"Think about your Domain Model and the relationship between your Domain entities...
This is really important. If the service boundaries are not well defined, you might end up with services that are too coupled with each other." - perhaps the problem is basing services on the domain at all? Perhaps design services around what they can do and expel the domain into configuration/data. Why couple an application to the domain at all if can help it?

Collapse
 
scottctr profile image
Scott C.

Might consider a state machine library. Here's one I created for similar projects github.com/scottctr/NStateManager.

Collapse
 
brpaz profile image
Bruno Paz

Yes, a library would be probably be the path I would take now.

Thanks for sharing.

Collapse
 
david_j_eddy profile image
David J Eddy

Nice article Bruno, I look forward to more from you soon!

Collapse
 
jordybaylac profile image
Jordy Baylac

Man this is epic!

...nothing stops you from having a monolith that is modular, have a great separation of concerns, low coupling and high cohesion

Great article.