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.

  • 3
    If you have a request chain of 100s of microservices you have something horribly wrong. There's a lot of information out there on how to deal with microservices interactions, including synchronous and asynchronous communication. Start there. If you have a specific question to ask, please restructure your post to make it clear what that question really is. – Berin Loritsch Jul 24 at 20:00
  • 3
    If you need to chain 100 times (or even 50 times), have you really managed to build a micro service architecture? Or have you actually just split your monolith into 100 different servers, effectively creating one giant headache for yourself? – Noceo Jul 24 at 20:14
  • 1
    If you do not yet see the advantages of microservices then you most probably don't need it. Microservices are designed to help when your server is dying because you need to handle thousands of requests per second (not per hour) by enabling you to simply run more servers for the service that is bottlenecked. To be honest, microservices do nothing to most regular websites. Even stackoverflow is not run on microservices – slebetman Jul 24 at 20:52

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.