My only skepticism about using microservices over REST /HTTP is that there could be a performance drop. Using too many microservices over REST, with a REST connection, the data would always first need to pass through an HTTP server and things like latency would be an issue. Imagine a data process which needs to pass-through 100's of microservices which are connected via REST to each other. Is there a better way to achieve this without REST?
closed as too broad by gnat, Arseni Mourzenko, BobDalgleish, Robert Harvey Jul 25 at 0:11
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Yes. Streaming architecture (where the interaction is done through a streaming platform (Kafka, AWS Kinesis etc)), RPC so on and so forth. You'll need orchestration software, dedicated databases for each microservice etc. In all honesty, if you don't see the benefits and have no clue as of yet how to put it all in place and no performance benchmarks prognosis, don't do it, read more, research and then consider migrating. This way you'll inevitably end with microliths which are dysfunctional attempts at creating decoupled, true microservices (even though the term microservice (d)evolves, its core values stood over time). At the end of the day, your bills will probably skyrocket as microservice architecture isn't cheap to maintain but you might not gain any performance and stability overall.
I've personally witnessed CTOs (no joke) opting for migrating to microservice architecture and outvoting engineers just because they read a few articles by some hyped folks and ending up nowhere.