4 ms·

"Using so-called microservices to break complicated problems into easy-to-solve ones" I would love to see microservices which actually solve problems and reduc

"Using so-called microservices to break complicated problems into easy-to-solve ones" I would love to see microservices which actually solve problems and reduce complexity! :(

winrid 7y ago
I am curious how that will help latency here. It must be pretty bad if refactoring and adding more network connections is an improvement.
- vijaybritto 7y ago
  Yeah I know people preferring microservices for its horizontal scalability advantage but never for reducing latency. Maybe something was lost in the translation to the author.
- koffiezet 7y ago
  Only thing that I can think of is that it would make it easier to detect the bottlenecks. Other than that, certainly in high-frequency trading - I only see it adding latency.
- DrBazza 7y ago
  They were likely running old Tibco/RV systems (network) distributed across the network (common for 1990s to early 2000 trading systems), and replaced the system (and hardware) with multi-core boxes, and use shared memory for message passing. Reduces internal latency from milliseconds to sub-microsecond.
  - winrid 7y ago
    Makes sense in this case. I guess you can just deploy the microservices as containers on the same machine or what have you.
koffiezet 7y ago
Complexity is never reduced, but made more manageable. Microservices make a good architecture a lot harder, certainly if you have to start with a blank slate and don't really have an idea what you're up against. However, things that are virtually impossible to enforce or even very hard to implement in a monolith, are made manageable if you have the proper setup. That includes central standardised logging, tracing, metrics and monitoring. If you have these in place and can enforce them, you're off to a good start. These things rarely happen in a v1 though - which usually is a POC that ends up in production, and if you have a full-blown microservice architecture from the start, this will probably grow into something a lot worse than huge PHP monolith. With microservices you need to design a 'platform', and ad-hoc POC development never results in a good design, but just something that functionally works.
- vijaybritto 7y ago
  Agreed. You missed db syncing, container orchestration, deployments, sharding, DEBUGGING and some sweet sweet anxiety attacks!

"Using so-called microservices to break complicated problems into easy-to-solve ones" I would love to see microservices which actually solve problems and reduce complexity! :(

winrid 7y ago

I am curious how that will help latency here. It must be pretty bad if refactoring and adding more network connections is an improvement.

vijaybritto 7y ago
Yeah I know people preferring microservices for its horizontal scalability advantage but never for reducing latency. Maybe something was lost in the translation to the author.
koffiezet 7y ago
Only thing that I can think of is that it would make it easier to detect the bottlenecks. Other than that, certainly in high-frequency trading - I only see it adding latency.
DrBazza 7y ago
They were likely running old Tibco/RV systems (network) distributed across the network (common for 1990s to early 2000 trading systems), and replaced the system (and hardware) with multi-core boxes, and use shared memory for message passing. Reduces internal latency from milliseconds to sub-microsecond.
- winrid 7y ago
  Makes sense in this case. I guess you can just deploy the microservices as containers on the same machine or what have you.

koffiezet 7y ago

Complexity is never reduced, but made more manageable. Microservices make a good architecture a lot harder, certainly if you have to start with a blank slate and don't really have an idea what you're up against. However, things that are virtually impossible to enforce or even very hard to implement in a monolith, are made manageable if you have the proper setup. That includes central standardised logging, tracing, metrics and monitoring. If you have these in place and can enforce them, you're off to a good start. These things rarely happen in a v1 though - which usually is a POC that ends up in production, and if you have a full-blown microservice architecture from the start, this will probably grow into something a lot worse than huge PHP monolith. With microservices you need to design a 'platform', and ad-hoc POC development never results in a good design, but just something that functionally works.

vijaybritto 7y ago
Agreed. You missed db syncing, container orchestration, deployments, sharding, DEBUGGING and some sweet sweet anxiety attacks!