malaskowski
commented
4 years ago Microservices
Approach 1 - Remote Nodes
There is an idea on "Remote Nodes" (just working name) that are actually a Microservices. They can be grouped into tasks as standard (local) nodes now (also combining both in a single task should be possible). There will be a contract defined exactly the same as for normal nodes (input: Fragment, output: modified Fragment + Transition). For now, 2 ways to communicate with Remote Nodes were identified:
- via Vert.x Event Bus
- via HTTP e.g. using RestAPI exposed by the microservice
The internals of Remote Node is not known to a task, only the contract matters. Of course, the Remote Node can also use Fragment processing and have its actions. But what is also very important, any service can be used (e.g. written in Spring, PHP or Go) as a Remote Node, when communicating via HTTP.
Pros
- any technology can be selected to write a microservice (the only requirement is keeping the Fragment contract)
- microservices communicating via Event Bus does not have to worry about having its own HTTP Server
- complicated scenarios can be designed as a graph OOTB, which makes them easier to understand
- some of the behaviours are available OOTB (like Circuit Breaker) and can wrap "Remote Nodes"
Cons
- there is a Fragments contract, that each microservice need to follow (
Fragment->Fragment'+Transition)
Approach 2 - pure Rest API
Communication between microservices takes place via HTTP (Rest APIs). Each microservice, have its own HTTP Server with simple RestAPI exposed and additionally it may use Fragments processing to produce the output. Each microservice defines its own API, there are no restrictions on working on Fragment. Also, there might be other technologies used to create a microservice (e.g. Spring, PHP or Go), the only contract is their API.
Pros
- any technology can be selected to write a microservice
- microservices are not bound to any specific Rest API contract, they define it themselves
Cons
- each microservice needs an HTTP Server to expose Rest API
- stability patterns such as Circuit Breaker must be implemented independently, when communicating with each microservice via Rest API
Context Let's discuss on how Knot.x impacts application architecture choice. Being more specific, which architecture approach does Knot.x promote:
MonolithicvsMicroservice.Describe the solution you'd like A solid comparison of two architecture approaches when using Knot.x as part of the application. Differences between using Knot.x in monolithic vs microservice architectures with simple examples. Also, basic recommendation when use one or another approach and finally, what are advantages of using Knot.x in any of them.
Additional context If Knot.x enables it, describe (in form of blog post or documentation) how to switch one architecture to another (preferably monolithic to microservice, which will be the most common). How Knot.x supports such transitions, what are prerequisites, when to do that.