-2

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?

1201ProgramAlarm
  • 1,529
  • 2
  • 14
  • 21
Tobi Owolawi
  • 133
  • 4
  • 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 '19 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? – Jakob Busk Sørensen Jul 24 '19 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 '19 at 20:52
  • Possible duplicate of [How do microservice system architectures avoid network bottlenecks?](https://softwareengineering.stackexchange.com/questions/275734/how-do-microservice-system-architectures-avoid-network-bottlenecks) – Arseni Mourzenko Jul 24 '19 at 21:46

1 Answers1

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
  • 3
  • 13