Shipping forgettable microservices with Rust

https://precompile.com/2016/06/23/shipping-forgettable-microservices-with-rust.html

by wofo • 10 years ago

81 29 10 years ago

gue5t• 10 years 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• 10 years ago

I got an eery vibe that this was the equivalent of an /r/SubredditSimulator post for Hacker News.

throwanem• 10 years 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• 10 years 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• 10 years 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• 10 years 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• 10 years ago

I'll return answer to your question in a week. Hope you will be still interested to hear it.

detaro• 10 years 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• 10 years ago

What web framework is this on?

killercup• 10 years ago

Iron, apparently: https://github.com/dirk/metrics_distributor/blob/d29c897d156...

IshKebab• 10 years 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=...

I'm not sure why this is - I've Googled to no avail - but it is rather worrying.

Lewisham• 10 years ago

I'm surprised people can use Iron at all. I tried really really hard to use it and found the complete lack of documentation (or, worse, outdated blog posts) made it impossible. Is there some magic necronomicon I'm missing?

I had better luck with nickel.rs because it has an examples/ folder with quick recipes of most things you'd want to do.

vitalus3• 10 years ago

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

ben_jones2• 10 years 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• 10 years 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.

lmm• 10 years ago

Lack of generics is extremely developer hostile.

bluejekyll• 10 years 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.

vitalus3• 10 years 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

pcwalton2• 10 years ago

The article helpfully answers that question for you. It's entirely about features unique to Rust.

vitalus3• 10 years ago

I actually saw very few unique features of Rust mentioned in the article which is why I was looking to contrast it at a high level to another language which met the criteria the author laid out while avoiding a mentioned drawback...I would hardly consider "it compiles to native" and "measured and thoughtful standard library" to be features unique to the language, though no doubt important!

Shipping forgettable microservices with Rust

Related Stories