Hi everyone, I've found a thread from 2015 about micro-services in the context of HFT: https://groups.google.com/forum/#!topic/mechanical-sympathy/pw0X8tgElsA/discussion
I was interested if anyone had any changes of opinion, now that it's 2019 and somehow the world hasn't yet ended? My use-case isn't HFT, but it's similar in a lot of ways -- we take-in lots of streaming data 24/7, make some associations between events, do some aggregations, output lots of streaming data. Low-ish latency is important, but not as critical to existence as in HFT. There is a desire (from management) to break down our existing platform into micro-services. There are some obvious benefits from a testability/dev-ops kind of perspective, but I'm worried about the added costs (we're also expected to maintain or improve performance). Adding extra hops means extra serialization/deserialization. The JVM/code and some amount of auxiliary data would be duplicated in memory. I'm not sure what effect -- positive or negative -- it would have on CPU usage by GC when we have many small JVMs rather than a handful of large ones. Even thinking about thread affinity / context-switches / cache-friendliness probably becomes an exercise in futility. Micro-services seem to be at conflict with mechanical sympathy in a lot of ways. Maybe I've being overly pessimistic? Thank you in advance! Meg -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
