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?
Asked
Active
Viewed 386 times
1 Answers
0
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.
Milan Velebit
- 507