5 ms·

Shipping forgettable microservices with Rust

81 points by wofo 10y ago

gue5t 10y ago
I don't think I have enough context to understand this article. What exactly does "response time" measure, here? The diagram of the system makes it look like this program is essentially just a scan over a data stream, so each iteration should be minimally computationally intensive--certainly not in the tens of milliseconds. Is this counting time to query the left-hand-side? Or is it time from receiving a message from the LHS to forwarding it rightward? I don't know what a "HTTP log drain front-end" is: is this software an HTTP client, or an HTTP server? If making HTTP requests across some network is costing you up to 10ms, what network is that, and why not simply run this code on the host that generates the data you're currently sending over HTTP?
- ukyrgf 10y ago
  I got an eery vibe that this was the equivalent of an /r/SubredditSimulator post for Hacker News.
- throwanem 10y ago
  "Log drain" appears to be a Heroku term of art for something that can receive shipped log data from their infrastructure, so an "HTTP log drain front-end" would be a client; if that or something like it is in play here, it would explain why they don't host the aggregator in the same place as whatever's generating the log entries it ingests. 40 requests/second does sound somewhat low, but that may just be the average rate at which whatever they're aggregating generates log entries, rather than a limit enforced by resource exhaustion.
cm3 10y ago
I may be getting this wrong, but I was under the impression that microservices are about having many small services as in a service bus architecture. I don't know how the author came to believe it's about short response times. EDIT: Reading the responses, I should clarify: The question is if a microservice needs to be be fast to respond to be considered a microservice, or if both types are called micro based solely on the fact that they are limited-purpose small services, together building a greater construct. I would say kinda-synchronous fast responding services are just as micro as very-asynchronous slow responding but still limited API services are.
- chrishacken 10y ago
  Nor do I. Micro services are built around being able to be scaled and manipulated without having those changes break your entire application.
- the_mitsuhiko 10y ago
  Microservices are SOA and there are two ways in which that typically happens: slow offline processing with many different workers. That's not really an issue and something that is a well understood problem. The second however is offloading work to different processes while something is waiting for a result and it wants it quick (a web request). In the latter case it's absolutely important that your services reply quickly.
- akerro 10y ago
  I'll return answer to your question in a week. Hope you will be still interested to hear it.
- detaro 10y ago
  (I assume) it is not about short response times, but short response times are necessary if you split your work in many (assumed partially serial) requests to small services and still want acceptable overall response time.
anfroid555 10y ago
What web framework is this on?
- killercup 10y ago
  Iron, apparently: https://github.com/dirk/metrics_distributor/blob/d29c897d156d7aa335561deaf2ae90b15da4ca80/Cargo.toml https://github.com/dirk/metrics_distributor/blob/d29c897d156...
  - IshKebab 10y ago
    Which has very disappointing benchmarks at the moment - even slower than some Python and Ruby stacks: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=plaintext https://www.techempower.com/benchmarks/#section=data-r12&hw=... I'm not sure why this is - I've Googled to no avail - but it is rather worrying.
    - andrewflnr 10y ago
      When you see Rust being "slower than Ruby" it's usually because you forgot to turn off debug mode.
      - frewsxcv 10y ago
        Looks like they use build with release mode: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Rust/iron/setup.sh https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
        steveklabnik 10y ago
        So it's important to not compare master to when the benchmark was posted; remember, they do them at a certain time, then work happens. So like, I sent a PR to update Rust from 1.0 to 1.6 at one point, for example. That said, I don't think that missing out on --release was the issue here, as far as I know, it has always been on.
vitalus 10y ago
Why not Go? Checks the boxes of "performant" and "safe" while remaining developer friendly compared to Rust
- bluejekyll 10y ago
  You can just as easily ask, why not any other language, for the exact same reason. But since you asked about Go, here are the 3 reasons that I would not pick Go: 1) no generics means less code reuse, which mean more testing of more code (potential runtime issues) 2) allowance of Null, means potential NPE/seg-faults (runtime issue) 3) non-type safe, inconsistent error handling (another runtime issue) Go is a fine language, like many others, but it's not the same as Rust, and doesn't offer the same features (like no runtime/GC), which means it's not as flexible in its usage. But, I will grant you that Go is "easier" to write code in. Anyway, there will be and are many great programs written in Go, as there have been in C, C++, Java, Perl, Python, Ruby, Erlang, Haskell, Ocaml, Ruby, JS, etc. To each there own. Mine is Rust today, was Java before that, C++ before that, C before that, and Basic before that.
  - vitalus 10y ago
    Sure, it just felt like a more natural fit than other languages given the criteria which is why I called it out specifically Thanks for your mention of additional runtime safety, it isn't something I had considered
- ben_jones 10y ago
  Oh connection pooling is handled automatically by the standard library ...jk not really, it leaks sometimes ... and ...down ...goes ...my ...production database. 2 weeks ago.
  - veegee 10y ago
    I'm not a fan of Go, but the connection pooling in the standard library doesn't leak. You're just not closing the Rows object if you encounter an error. It automatically closes if you fully iterate through it. But if you stop part way, you have to manually close it or the connection will not be returned to the pool.

81 points by wofo 10y ago

gue5t 10y ago

I don't think I have enough context to understand this article. What exactly does "response time" measure, here? The diagram of the system makes it look like this program is essentially just a scan over a data stream, so each iteration should be minimally computationally intensive--certainly not in the tens of milliseconds. Is this counting time to query the left-hand-side? Or is it time from receiving a message from the LHS to forwarding it rightward? I don't know what a "HTTP log drain front-end" is: is this software an HTTP client, or an HTTP server? If making HTTP requests across some network is costing you up to 10ms, what network is that, and why not simply run this code on the host that generates the data you're currently sending over HTTP?

ukyrgf 10y ago
I got an eery vibe that this was the equivalent of an /r/SubredditSimulator post for Hacker News.
throwanem 10y ago
"Log drain" appears to be a Heroku term of art for something that can receive shipped log data from their infrastructure, so an "HTTP log drain front-end" would be a client; if that or something like it is in play here, it would explain why they don't host the aggregator in the same place as whatever's generating the log entries it ingests. 40 requests/second does sound somewhat low, but that may just be the average rate at which whatever they're aggregating generates log entries, rather than a limit enforced by resource exhaustion.

cm3 10y ago

I may be getting this wrong, but I was under the impression that microservices are about having many small services as in a service bus architecture. I don't know how the author came to believe it's about short response times. EDIT: Reading the responses, I should clarify: The question is if a microservice needs to be be fast to respond to be considered a microservice, or if both types are called micro based solely on the fact that they are limited-purpose small services, together building a greater construct. I would say kinda-synchronous fast responding services are just as micro as very-asynchronous slow responding but still limited API services are.

chrishacken 10y ago
Nor do I. Micro services are built around being able to be scaled and manipulated without having those changes break your entire application.
the_mitsuhiko 10y ago
Microservices are SOA and there are two ways in which that typically happens: slow offline processing with many different workers. That's not really an issue and something that is a well understood problem. The second however is offloading work to different processes while something is waiting for a result and it wants it quick (a web request). In the latter case it's absolutely important that your services reply quickly.
akerro 10y ago
I'll return answer to your question in a week. Hope you will be still interested to hear it.
detaro 10y ago
(I assume) it is not about short response times, but short response times are necessary if you split your work in many (assumed partially serial) requests to small services and still want acceptable overall response time.

anfroid555 10y ago

What web framework is this on?

killercup 10y ago
Iron, apparently: https://github.com/dirk/metrics_distributor/blob/d29c897d156d7aa335561deaf2ae90b15da4ca80/Cargo.toml https://github.com/dirk/metrics_distributor/blob/d29c897d156...
- IshKebab 10y ago
  Which has very disappointing benchmarks at the moment - even slower than some Python and Ruby stacks: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=plaintext https://www.techempower.com/benchmarks/#section=data-r12&hw=... I'm not sure why this is - I've Googled to no avail - but it is rather worrying.
  - andrewflnr 10y ago
    When you see Rust being "slower than Ruby" it's usually because you forgot to turn off debug mode.
    - frewsxcv 10y ago
      Looks like they use build with release mode: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Rust/iron/setup.sh https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
      - steveklabnik 10y ago
        So it's important to not compare master to when the benchmark was posted; remember, they do them at a certain time, then work happens. So like, I sent a PR to update Rust from 1.0 to 1.6 at one point, for example. That said, I don't think that missing out on --release was the issue here, as far as I know, it has always been on.

vitalus 10y ago

Why not Go? Checks the boxes of "performant" and "safe" while remaining developer friendly compared to Rust

bluejekyll 10y ago
You can just as easily ask, why not any other language, for the exact same reason. But since you asked about Go, here are the 3 reasons that I would not pick Go: 1) no generics means less code reuse, which mean more testing of more code (potential runtime issues) 2) allowance of Null, means potential NPE/seg-faults (runtime issue) 3) non-type safe, inconsistent error handling (another runtime issue) Go is a fine language, like many others, but it's not the same as Rust, and doesn't offer the same features (like no runtime/GC), which means it's not as flexible in its usage. But, I will grant you that Go is "easier" to write code in. Anyway, there will be and are many great programs written in Go, as there have been in C, C++, Java, Perl, Python, Ruby, Erlang, Haskell, Ocaml, Ruby, JS, etc. To each there own. Mine is Rust today, was Java before that, C++ before that, C before that, and Basic before that.
- vitalus 10y ago
  Sure, it just felt like a more natural fit than other languages given the criteria which is why I called it out specifically Thanks for your mention of additional runtime safety, it isn't something I had considered
ben_jones 10y ago
Oh connection pooling is handled automatically by the standard library ...jk not really, it leaks sometimes ... and ...down ...goes ...my ...production database. 2 weeks ago.
- veegee 10y ago
  I'm not a fan of Go, but the connection pooling in the standard library doesn't leak. You're just not closing the Rows object if you encounter an error. It automatically closes if you fully iterate through it. But if you stop part way, you have to manually close it or the connection will not be returned to the pool.