2.2 Whose broker technology do you use?
Our own. We designed it from scratch to be massively parallel on 48‑core set ups. We don’t use Microsoft ServiceBus, VMware’s RabbitMQ or RedHat MRG / Apache Qpid (which is one and the same thing). Several of the underlying technologies, including non‑blocking timers, load distribution and multiplexed zero‐copy queue access and storage are unique algorithms and are protected as trade secrets.
2.3 Which database technology do you use?
Our own. We’ve heard of people using Cassandra, sqlite or Tokyo Cabinet to store message data. Or even mnesia. These people are mad. Message data is unique. It is not appropriate for a key‐value store. It is multiplexed, often fragmented and needs storage that reflects its first‐in first‐out nature. Our database design is currently the only one in the world capable of providing message replay for AMQP.
2.4 How do you do redundancy?
Shared‐nothing. Message queues are best made redundant using a shared‐nothing event stream of changes. Perversely, that’s exactly what most solutions don’t do.
2.5 Which underlying cloud provider do you use?
We don’t. This is pedal‑to‑the‑metal technology. Whilst theoretically it can run atop a virtual infrastructure, classic server virtualisation just isn’t appropriate to get the best out of Message Queuing.
2.6 What hardware do you use?
We have our own appliance designed around 64‑bit x86 AMDs, with a customised build of Ubuntu Linux. This allows us to precisely control release and deployment whilst focusing design efforts on just one combination to reduce the matrix of pain.
2.7 Can I download the server code?
We’re not currently open source. As we don’t sell training or consultancy and our technology contains trade secrets, it’s not open source. We really don’t want to give RedHat or Microsoft more of a leg up than we already have.
3 Free. As in Beer. Really?
Yes. We want you to use our service. We want you to try it, to experiment, to do things and not worry its going to cost anything when you decide it’s not for you.
3.2 So you sell my details on?
Nope. The only thing we want to know when you sign up is an user name and an email address. And we keep those details private.
3.3 So how do you make money from being free?
We don’t directly. If you like the service and use it a lot, you’ll eventually want to pay for more resources. And if you don’t, well, we haven’t lost much. If we tried to charge for such a small amount of usage, the credit card fees would cripple us.
4 What we sell
4.2 Do you offer something I can install locally?
Our technology platform operates as a complete end‑to‑end environment — it’s effectively an appliance with systems management. By offering Message Queues, as a Service, in the Cloud, we take the strain. For very high‑end needs, we can supply the same appliances as we build for ourselves. So you can scale all the way from casual use to world domination. Pricing is in the six‑figure range (hollow volcanoes are extra).
4.3 Do you sell consultancy?
Nope. We focus on just one thing: Message Queues, as a Service, in the Cloud. If you need one of appliances for a high‐end use, then that can include a proportion of consultancy, but it’s not a part of our core business.
4.4 Do you sell training?
4.5 Do you do speaking events?
We have a superb reputation for our talks. We’re definitely opinionated and a little different.
4.6 Do you offer bespoke clients?
We have developed bespoke clients in the past where there is joint value. However, we’d caution choosing a technology platform that needed one (particularly in the embedded space), as it slows time‑to‑market.
6 Is there a quota for messages?
There is no quota limit on how messages you can send or receive. Why? It’s simple, really. It bears no relationship to our cost of service. A message might be a byte – or it might be 10Mb. It’s the size that we store that matters. If you need more resources, you can pay a small monthly subscription for them. If you get ‘spikes’, then we allow you to become ‘overdrawn’ at a premium to your monthly quota if the resource is available – it’s first come, first served.
7 AMQP 1‧0 and Other Protocols
7.2 How committed are you to standards?
Without standards, there can be no interoperability. And so adoption is less. And so we have less potential customers. So we take standards very seriously. We currently take an active role in OASIS to standardise AMQP and MQTT. Our Chief Architect, Raph Cohn is the Secretary of the OASIS AMQP Technical Committee.
7.3 Why don’t you support AMQP 0‑9‑1?
AMQP 0‑9‑1 is a legacy protocol that differs vastly from AMQP 1‧0 which involves far tighter coupling of producers and consumers and no quality‑of‑service parameters worthy of the name. It was a good protocol (and we implemented it back in the day), but the world has moved on. We want a world of interoperable Message Queuing. Aside from RabbitMQ no other vendor is moving forward with AMQP 0‑9‑1, so that interoperability is unlikely to happen with it.
7.4 How interoperable are you with other AMQP vendors?
We’ve successfully undertaken interoperability exercises with other members of the OASIS AMQP Technical Committee as part of developing the AMQP 1‧0 standard. To use an AMQP client with stormmq, you’ll need to make sure it supports AMQP 1‧0 and TLSv1.
7.5 Do you support MQTT 3‧1?
7.6 Do you support STOMP 1‧1?
7.7 What about WebSockets?
7.8 Do you support XMPP?
7.9 What about WebRTC?
The caveats for XMPP go double for WebRTC. WebRTC is more about streaming video and audio, and so makes less sense to be used to send discrete message payloads.
7.10 Do you support JMS?
There are beta‐quality AMQP 1‧0 JMS clients available that should work with our service. JMS is a bit of a retrograde way of using message queues. And once you put Spring on top of it, you’ve really lost a lot of value.
8 Changes and Updates
8.2 How often do you update things?
We make minor updates on a fortnightly basis, although there is no fixed schedule. Changes are staggered across our server estate to provide slightly degraded service, rather than actual downtime. This allows us to back out any changes should the need arise.
Major updates for feature enhancements requiring sufficient are done no more frequently than monthly, and we advise by email no less than 10 days before hand.
8.3 How do you minimise deployment risk?
We follow best practice; agile, XP and testing is in our DNA. Even our Chief Architect, Raph Cohn, started life in IT as a tester. We use a four‑stage environment pipeline based around Debian packaging, with complete versioning of every change — including all the OS packages and security patches, sectioned by server role and hardware profile. So there’s minimal chance of a rogue push to a Debian repository wiping out production with some automatic