4 ms·

We knew from the start that we would be the next ((facebook+google-apple) ^ spacex), that's why we started with distributed microservices, (you can't ignore doc

We knew from the start that we would be the next ((facebook+google-apple) ^ spacex), that's why we started with distributed microservices, (you can't ignore docker these days on hn frontpage, you HAVE to use it), golang + node.js + kafka combo. We're not in beta yet and we have 150+ services, isn't that insane right! We need a protocol for rpc, http+json was the slowest one --> clear winner. Everytime we need a new function, we can make it a service and make it distributable on our polyglot (because why not!) docker infrastructure behind http load balancers + json data-type and make it infinitely scalable!

blibble 10y ago
I think Josh Berkus said it best: https://youtu.be/nPG4sK_glls?t=47 https://youtu.be/nPG4sK_glls?t=47
obeattie 10y ago
Author here. We are in beta and have about 40,000 cards issued to customers in the UK, with a waiting list of about 200,000. I think we have good reasons for making the architectural decisions we have made, some of which are laid out in the post, but perhaps I did not explain them in enough detail. For example, we chose HTTP as our RPC protocol because it is widely supported in many languages, and has mature support in Finagle. HTTP/2 fixes most of the performance issues with HTTP, and we have options (eg. to use mux) if we still find there are performance problems – although at the moment, we are quite happy with performance.
- ddorian43 10y ago
  How many of those 150+ services depend on other services ?
  - obeattie 10y ago
    Almost all of them interact with other services to do something or other.
threeseed 10y ago
HTTP+JSON can actually be very quick if implemented correctly. And most importantly it is easy to debug which is critical when you are starting off. JSON can be faster than binary in many cases: https://github.com/eishay/jvm-serializers https://github.com/eishay/jvm-serializers And your sentence sounds like the ideal scenario, no ?
- ddorian43 10y ago
  No. Put a monolith behind a loadbalancer and every function/route inside that monolith will be scalable. This goes until the time you need to break up in services. Can-be faster, sure, but usually is not (text vs binary).

blibble 10y ago

I think Josh Berkus said it best: https://youtu.be/nPG4sK_glls?t=47 https://youtu.be/nPG4sK_glls?t=47

obeattie 10y ago

Author here. We are in beta and have about 40,000 cards issued to customers in the UK, with a waiting list of about 200,000. I think we have good reasons for making the architectural decisions we have made, some of which are laid out in the post, but perhaps I did not explain them in enough detail. For example, we chose HTTP as our RPC protocol because it is widely supported in many languages, and has mature support in Finagle. HTTP/2 fixes most of the performance issues with HTTP, and we have options (eg. to use mux) if we still find there are performance problems – although at the moment, we are quite happy with performance.

ddorian43 10y ago
How many of those 150+ services depend on other services ?
- obeattie 10y ago
  Almost all of them interact with other services to do something or other.

threeseed 10y ago

HTTP+JSON can actually be very quick if implemented correctly. And most importantly it is easy to debug which is critical when you are starting off. JSON can be faster than binary in many cases: https://github.com/eishay/jvm-serializers https://github.com/eishay/jvm-serializers And your sentence sounds like the ideal scenario, no ?

ddorian43 10y ago
No. Put a monolith behind a loadbalancer and every function/route inside that monolith will be scalable. This goes until the time you need to break up in services. Can-be faster, sure, but usually is not (text vs binary).