Yeah, Mongrel2 looked like a good idea… but turns out it's kinda pointless. Why talk to your app via HTTP-reencoded-as-ZMQ when you can just talk straight up HTTP? Pretty much all languages have very fast and concurrent HTTP servers these days.

I thought it was because there's a lot about http that's overhead and/or tough to get right, which can then be delegated to the server.

Also, websockets actually map pretty badly to http, conceptually, and fit zeromq much better IMO.

Regarding websockets (admittedly off-topic re Mongrel though), I recently found out about Pushpin[0], which seems to be an elegant way to translate WS into HTTP, should it be of interest to someone. Basically a proxy-server that takes care of accepting either websockets or HTTP on the front, and talking only HTTP on the other side.

[0] http://pushpin.org

I evaluated PushPin for a project recently but ended up going with Nchan

https://nchan.io/

Pushpin uses Mongrel2 under the hood to handle incoming WebSocket connections, so not entirely off topic. :)

It's pulled in as a dependency and launched in the background.

I thought PushPin was based on Qt?

It's multi-process. The core logic is a Qt application, but it delegates the external protocol I/O to separate processes. Mongrel2 handles inbound and Zurl handles outbound (Zurl is a project of ours that is basically the inverse of Mongrel2).

Parts of mongrel2 were sadly a solution in search of a problem. Mostly the "let's redo FastCGI via ZMQ". Was still immensely fun working on and with it.

Mongrel2 was indeed a nice idea on paper.

It never had much momentum though -- but what it lost and killed it was Zed's interest.

microservices on their face seem cool, but in reality not so much. really, it's just SOA taken to an unnecessary extreme.

It's really SOA without the XML based service bus.

Oh the "service bus" <strike>xml</strike> json is coming back... its called lambda architecture.

And again nothing new except someone else takes care of some server software for you with the promise of reduced price and maintenance but the reality eventually becomes tight proprietary coupling and eventual price gauging.

Amazon's own Lambda is that, yes. But the Lambda architecture it inspired is the opposite: a de-facto standard (based on the way Amazon's works, but probably eventually an open standard) for servers any org can use to stand up their own public or private FaaS cloud, which developers can deploy Lambda functions onto rather than having to build an entire container/VM just to slot it into OpenStack.

I doubt it will ever be a standard. Amazon loves vendor lock in. Plus most of the cloud services love to do their own thing for each service type. The main exception seems to be Kubernetes. Google has it in GCE, and Amazon has said they are working on their own Kubernetes service. If that happens, I bet Azure will follow if they aren't already working on it.

I (and others) are not so much imagining a standard between cloud vendors, as we're imagining a standard "FaaS server function API" (sort of like how the web has a standard DOM API) supported by several FOSS FaaS server implementations (sort of like how the web has several FOSS Javascript engines.)

Given such a standard API and compatible servers, you'd then deploy a FaaS server cluster to your public/private cloud of choice, the same way you deploy e.g. a Kubernetes cluster, or a Riak cluster.

There would likely by small public clouds attempting to be "FaaS native" by exposing only such servers in a multitenant configuration (like small public clouds like Hyper are currently doing with CaaS.) Their implementations wouldn't always be exactly compatible, and might have some lock-in.

However, once FaaS "caught on" with the enterprise, a FaaS server would likely make its way into the OpenStack architecture.

At that point, you'd see medium-sized public cloud providers like OVH and DigitalOcean set up their own multitenant FaaS clusters as well, probably with custom code, but built to be compatible with the OpenStack FaaS tooling, to allow enterprises the freedom to move FaaS functions freely between public and private clouds.

And, eventually, the other major cloud providers would feel the need to support the API.

---

This path has already been followed: it's what happened to Amazon S3—first cloned (but not compatibly) in FOSS by tools like Riak CS; then standardized by OpenStack Swift; then cloned compatibly in FOSS by tools like Minio; then picked up by medium-scale clouds like Rackspace; and then, eventually, picked up by Azure and GCP as secondary APIs to address their equivalent offerings (that originally had quite different APIs.)

You can definitely do microservices that way but in reality they tend to be more granular both functionality wise and density-wise.

With old skool SOA you'd typically have a monolith app with a bunch of endpoints. With microservices, especially in a containerized environment they tend to be more lightweight.

Microservices is just SOA rebranded for the cool kids. The fact that modern orchestration and tooling makes it easier to have more granular services changes the equation for how you factor the services, to be sure, but it's an evolution not a revolution.

This.

True. XML => Json.

Wait, zeromq lost momentum ? When did that happen ?

Unfortunately, the founder of ZeroMQ, Pieter Hintjens passed away (due to cancer) [1]. He was a regular on HN [2].

ZeroMQ still works great and the open source community is still maintaining it on GitHub [3]. I just think people are also looking at other technologies. A lot of interest popped up in things like Apache Kafka and Samsa. I still think ZeroMQ holds a unique place due to its lightweight and simple nature.

[1] https://news.ycombinator.com/item?id=11547212

[2] https://news.ycombinator.com/user?id=PieterH

[3] https://github.com/zeromq

I have been curious how the community would hold up after Pieter's death. This project is a unique case because of how much work went into building community and welcoming contributions. That said, the world is a different place than in zeromq's heyday. Other commenters refer to Martin leaving the project, C++ regret, and a poor fit with node.js. Maybe in the face of all those changes zeromq's mature community is primarily why it lives as a project.

Yes, I am aware that Peter had passed away. I thought that it was implied that the project is not maintained anymore, which is not true.

It has the same momentum, but too much mass and not enough velocity.

In which direction do you want it do move, if you want velocity that is.

I more often find platforms have too much velocity. And if not too little mass, then too little solidity.

Zing!

I recently switched from zeromq to straight libuv sockets with jsonl (\n-separated json) payloads. Because I'm working inside a Node process, combining zmq's threading model with Node's threading model was a pain. Now, there's a single IO thread which is the same as the Javascript engine thread, and I can use uv_work to run CPU-intensive tasks on multiple cores.

Do you not allow \n inside your JSON or encode your JSON as base64? If not you might have problems with disambiguating frame ends from line breaks inside frames.

A common way for framing is to prepend each frame with it's encoded length. That's easier, faster and less error-prone than searching for ASCII delimeters.

If you do the JSON serialization yourself, there's no reason for newlines to be in the JSON. (Newlines within strings are encoded as \n.)

I'm generating the JSON, either with custom C++ marshaling routines or with JSON.stringify which doesn't include newlines unless you give it extra arguments. I believe that any valid JSON can be converted to a single line by changing any '\n' bytes to ' '. Literal '\n' bytes are not allowed inside strings, and outside strings any whitespace is equivalent.

a newline is encoded as the two characters "\n" in json and would not be confused with a literal \n (aka \x0a) character

I think it happened in 2012 when this came out http://250bpm.com/blog:4

Before that, I used to hear people talking about it all the time.

Cool article! I guess that's why Go does its error handling without exceptions.

When the main developer decided that it wasn't good enough and started working on nanomsg (http://nanomsg.org/)

zeromq is still very much in wide use. nanomsg doesn't have nearly as much documentation and community support as zeromq does.

Dunno, I spent close to a week trying to get it to compile with and without encryption on Windows to no avail.

Ended up using a Linux container on Docker to get the thing working.

That is troubling. I always thought of zeromq as having as good Windows support as anything not written exclusively for Windows.

So did I, that's why I selected it. Did my development on OSX and Linux and thought that deploying a static binary on Windows would be a breeze.

It wasn't, turned out to be a Class 4 hurricane :P

Looks like there is a path hardcoded in the build files causing problems. After some reflection on the msvc/README, renaming the project directory to libzmq (was: zeromq-4.2.2 from the release or libzmq-master from github zip download), and launching cmd.exe using the Developer Command Prompt for VS2015 link, libzmq/builds/msvc/build/build.bat successfully builds all configurations.

When was the last time you heard something about it?

When was the last time you heard something about zlib? At a certain point - libraries are basically done. They are widely distributed, everyone knows what they are, there is no reason to talk about them but they are still maintained and heavily used.

Libraries can be done, but that has got nothing to do with momentum. Momentum depends on mindshare, on the willingness of people to use and to keep using it. Most programmers don't choose technology based purely on merits, they choose it based on "I heard X talk about Y and s/he said good things, so I guess I'll use it". We programmers aren't as rational as we think.

Like it or not, popularity and momentum are important merits of a technology. They lead to all sorts of benefits, like healthy maintenance and further development, better documentation, and support when you run into trouble. It is rational to consider these things when choosing technology.

This morning when I used it.

I don't use zmq nearly has much.

I'm using it for a project now. It's a bit weird, but it does work. Cool thing: you can slot a file descriptor into the zmq provided poll ... point is that you can poll on both zmq and sockets in the one loop.

Pro Tip: Use 'cbor' for serialising.

> you can poll on both zmq and sockets in the one loop

Which is magnificent. The ZMQ poller is tons of fun. (Although I think this doesn't work on Windows.)

Thanks for the tip. In which language(s) do you use CBOR? I want to like it, but the various C APIs look a bit cumbersome and lacking docs.

Python 3.

That is a really cool idea, do you know of other projects like it?

Nginx Unit? :-)