I may add that use of microservices makes deployment and maintenance much more complicated than it needs to be. And makes local deployment for testing/debugging at least very inconvenient (usually just impractical, often even impossible).
Possibly I know better solution than microservices, I've described it in my blog here, at dev.to recently.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
I read your article. Looks good, if only because I have adopted something very similar. With Gravity there is dynamic runtime configuration which can create new data structures and related API. Business rules, views, filters and integrations are all defined at runtime through the API. It is a clustered system so that all the services run on each node, so regardless of the API called it is capable of servicing it without doing another hop. It uses JMS queues to manage workload across the cluster. Because each node of the cluster is identical you will never get resource bound on a specific service because any node can do anything. There are three clusters involved, the API, JMS and Persistence.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I may add that use of microservices makes deployment and maintenance much more complicated than it needs to be. And makes local deployment for testing/debugging at least very inconvenient (usually just impractical, often even impossible).
Possibly I know better solution than microservices, I've described it in my blog here, at dev.to recently.
I read your article. Looks good, if only because I have adopted something very similar. With Gravity there is dynamic runtime configuration which can create new data structures and related API. Business rules, views, filters and integrations are all defined at runtime through the API. It is a clustered system so that all the services run on each node, so regardless of the API called it is capable of servicing it without doing another hop. It uses JMS queues to manage workload across the cluster. Because each node of the cluster is identical you will never get resource bound on a specific service because any node can do anything. There are three clusters involved, the API, JMS and Persistence.