[saintfiends]

From the looks of it I assume they are using HTTP/1.x as the communication protocol. I've always wondered why most use HTTP for micro-services instead of JSON-RPC (or any other encoding) over a TCP/IP socket. What are the benefits?

[patio11]

It's easy to understand for developers and "plays well with everything."

Don't underestimate the importance of toolchain support. Want to spin up a Ruby microservice which speaks HTTP? Sinatra and you're done. Go? Whatever the Go HTTP library is and you're done. Need to interact with it from the command line? Curl and you're done. How about from an automated testing script written in Ruby? Net:HTTP/HTTParty and you're done. Thinking about how to deploy it vis-a-vis firewall/etc? Port 80 and you're done. Need coarse-grained access logging? Built into Nginx/etc already; you're done. Uptime monitoring? Expose a /monitor endpoint; provide URL to existing monitoring solution; you're done. Deployment orchestration? Use Capistrano/shell scripts/whatever you already use for the app proper and you're done. Encrypted transport? HTTPS and you're done. Auth/auth? A few options that you're very well-acquainted with and are known to be consumable on both ends of the service trivially.

Edit to note: I'm assuming, in the above, that one is already sold on the benefits of a microservice architecture for one's particular app/team and is deciding on transport layer for the architecture. FWIW, I run ~4 distinct applications, and most of them are comparatively large monolithic Rails apps. My company's bookkeeping runs in the same memory space as bingo card PDF generation.

Things that would tilt me more towards microservices include a very rapid deployment pace, large engineering organizations which multiple distinct teams which each want to be able to control deploys/architecture decisions, particular hotspots in the application which just don't play well with one's main technology stack (as apparently happened in the app featured in this article), etc.

[Animats]

Their "microservices" are kind of macro. Rendering a PDF file and sending an email are reasonably large operations, so the overhead of local HTTP isn't that bad.

For a finer-grained application, such as the way Facebook generates pages from about 20 servers feeding data in to be assembled, that wouldn't scale. Facebook has Thrift and Google has protocol buffers. Both work, but result in a somewhat complex build procedure with a pre-compiler for interface specs.

(Serializing and de-serializing data into and out of databases and networks is either interpreted and slow, or compiled through clunky tools. Technology in this important area still sucks. There's a long history of clunky solutions to this problem, from DCOM, CORBA, and ASN.1, to SOAP to REST/JSON.

Part of the problem is political. If you expose an API defined in any of those except REST/JSON, there's a formal, checkable definition of the API in machine readable format. If the API doesn't match the spec, the server is broken. With a REST/JSON API, you get to blame the caller for doing it wrong. This is convenient for API developers.)

[chralieboy]

The "micro" in "microservices" refers more to the size of their conceptual complexity than how large of a task it actually is.

PDFs are one conceptual bucket that can have their own datastore and a simple API. Sending email isn't included in that service's contract, as it actually outsources this task to Mailgun.

REST/JSON can have formal specification – check out http://json-schema.org/. Swagger (http://swagger.io/) is another example of this and works really well for automatically generating client libraries in many languages and auto-updating documentation.

[cmelbye]

Simplicity.

[nexneo]

Exactly. (I implemented these services) - I don't see any reason of not using JSON-RPC but JSON over http is more simple for me.

At one place "form-urlencoded" is also used, so its not only JSON.

[harshreality]

json-rpc is pretty simple, and if the app uses json in the http bodies anyway, json-rpc eliminates separate http protocol (header) handling.

Does json-rpc have a standardized crypto wrapper, though? That seems like the most important reason to use https. Although json-rpc + nacl/sodium might be better in theory...

[chralieboy]

This makes the assumption that their bottleneck is the overhead of HTTP. This assumption is common on HN, but (in my experience) is a rare problem to have for most companies.

It looks like they do a good job of tackling performance problems as they see them, even at the architectural level. My guess is they didn't tackle this because it wasn't a problem worth prioritizing compared to the compounded shitshow of a monolithic Rails app.

[nexneo]

After my talk many people voiced same concerned of overhead. But I don't see it that way, overhead is not much over simplicity and familiarity benefits.

JSON has advantage of human readability and for that tooling support is required which probably you will loose with RPC. For example I use many tools to inspect requests that won't support it with RPC