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?
"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.
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.
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.
(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.
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.
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.
[+] [-] gue5t|9 years ago|reply
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|9 years ago|reply
[+] [-] throwanem|9 years ago|reply
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|9 years ago|reply
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.
[+] [-] the_mitsuhiko|9 years ago|reply
[+] [-] detaro|9 years ago|reply
[+] [-] chrishacken|9 years ago|reply
[+] [-] akerro|9 years ago|reply
[+] [-] anfroid555|9 years ago|reply
[+] [-] killercup|9 years ago|reply
[+] [-] vitalus|9 years ago|reply
[+] [-] bluejekyll|9 years ago|reply
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.
[+] [-] ben_jones|9 years ago|reply
[+] [-] lmm|9 years ago|reply
[+] [-] pcwalton|9 years ago|reply