You are being normally realistic. What is the dev-ops benefit ? I think you ONLY split services when: 1. they have different workloads (say kv + search). search is (cpu+memory)-bound while k-v is (only memory ? cpu too with nvme) and they have different access patterns. 2. you keep state in the client (like above) and have different access patterns between services. 3. it becomes too big and you want to serve it as a "service" (note: not micro) and really share it across an organization (facebook scale, think "search, file upload, real-time notifications, feed-system"). 4. different access pattern (say fast-path / slow/async-path), and you don't want slow/async path to interfere with fast-path SLA.
If all your stuff can be in memory in 1 server (say adserver keeping all ads in-memory) then you can just replicate servers tldr: Avi Kivity on that thread is really good (kernel + db stuff) so his words stand. On Tuesday, February 12, 2019 at 4:27:47 PM UTC+1, Margaret Figura wrote: > > 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.
