Hacker News new | past | comments | ask | show | jobs | submit login

The interest in using HTTP for microservices is because it's familiar to most developers. It's the same reason almost all public APIs are based on HTTP. There are just so many tools in the HTTP API ecosystem, from management gateways to documentation generators.

Interestingly, even public APIs with push capability are usually HTTP-based (e.g. Twitter's streaming API, GitHub webhook notifications, etc). I predict most microservices will end up working this way too.




It also really depends on what is meant by HTTP. If we are including Websockets and HTTP2/SPDY than yeah I might see HTTP as more viable choice over AMQP, Thrift, custom sockets, etc.

The problem is internal communication and (especially micro-service where you might have many hops)... latency is often a serious concern. Often the best technology to reduce latency is not HTTP. In fact its best you don't rely too much on the protocol (ie be agnostic). Since you brought up Twitter see Twitter Finagle: Most of Finagle’s code is protocol agnostic, simplifying the implementation of new protocols.

And that leads to the previous segue that perhaps Hoverfly should be written in a protocol agnostic way. I'm not sure if it is (ie how coupled it is at the assumption of HTTP 1.1).

Otherwise I see Hoverfly as just a HTTP proxy tool.. of which I have used similar tools such as TCPTrace and ProxyTrace for ole school SOAP (oh the pain).


Indeed, internal communication is often treated differently. Even at my company we primarily use ZeroMQ between microservices, because it's fast and our (small) team understands it.

The movement behind the HTTP ecosystem is undeniable though, and the common practices for public APIs are moving internally. You might check out an API conference or meetup sometime to see what I mean (not that any of us are obligated to follow this trend; I'm just bringing it to light).




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: