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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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
asyncmethods. 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!
I am interested to learn more about asynchronous communication between services. Any recommendations of references on this topic?
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.
Great question.
Dont remember any particular resource on the topic, but you might want to look at Messaging systems like RabbitMQ or Apache Kafka.
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.
"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?
Might consider a state machine library. Here's one I created for similar projects github.com/scottctr/NStateManager.
Yes, a library would be probably be the path I would take now.
Thanks for sharing.
Nice article Bruno, I look forward to more from you soon!
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.