In this RedMonk conversation, Alexis Richardson, Founder and CEO of ConfigHub, discusses the evolution and significance of messaging in distributed systems, and particularly RabbitMQ, with Kate Holterhoff, Senior Analyst at RedMonk. Alexis shares insights from his experience in the tech industry, including the development of messaging protocol AMQP, the founding of Rabbit Technologies and its acquisition by VMware, and his role in founding the Cloud Native Computing Foundation (CNCF). The discussion highlights the importance of messaging for asynchronous communication, scalability, and integration in modern technology, particularly in financial services and cloud computing.
Links
Transcript
Kate Holterhoff (00:13)
Hello and welcome to this RedMonk conversation. My name is Kate Holterhoff, Senior Analyst at RedMonk, and with me today is Alexis Richardsonon, CEO and founder of ConfigHub. Alexis has founded and served as CEO for several companies, including Rabbit Technologies and Weaveworks, and is a longtime friend of RedMonk. Alexis, thanks so much for joining me today on the MonkCast.
Alexis Richardson (00:35)
Thank you very much. Really good to be here, Kate.
Kate Holterhoff (00:38)
wonderful. I invited Alexis on the show to continue my ongoing investigation of the history and future of messaging and MQs. So let’s begin there. At a high level, first, how do you define messaging? And second, what do you tell folks who ask why it is important for distributed systems in 2025?
Alexis Richardson (00:56)
my gosh, I should have printed out all the things that I sent when we talked last time. How do I define messaging? So I think that there are many definitions and this one’s probably wrong, but messaging is really all about asynchronous communication in which you have a way for two parties or maybe more, but at least one sender, the person who sends the message. and or the agent or the computer to get data to a receiver or more than one receiver.
And in that sense, it’s a bit like email. And the reason that we have messaging systems is because email actually doesn’t work very well as a solution for real world systems like telemetry, market data, payment, all these things, which are real world applications of messaging. But the patterns are the same. You can think in your mind about, I’m going to send one thing to Kate, or I’m going to send an email to all the RedMonk people, because I know them by name.
or I might be sending something to, there might be a RedMonk alias where I can send something to RedMonk. I don’t even need to know who works at RedMonk. I can send it to RedMonk and then even the person who joined yesterday that I haven’t met yet gets an email from Alexis saying, see you at Monkigras. And wonders who the heck I am. And then you have other messaging patterns like, you know, that sort of built up from messaging as a fundamental component, like request response. So.
I could send a message to all the RedMonk people and you could get it and you could go, hey Alexis, you didn’t need to send that to everybody, I know you’re coming to Monkey Ground or something like that and then I’d get the reply, so you would send me a message. So that’s unusual because we are communicating in the way that computers do but in two parts instead of one. So I’m sending you a message and you send me a message and then we’ve made a communication whole. So that kind of pattern is messaging and then we have different ways of doing it.
Kate Holterhoff (02:44)
Alright, and in your mind messaging is as important today as it was 30 years ago, correct? Like in the age of distributed systems, Messaging remains a core technology.
Alexis Richardson (02:55)
Yeah, if you look at the history of distributed systems, it’s surprising that messaging was invented as early as it was. I think one of the reasons it was is because email was useful for talking between people. People wanted to have private communication, one-to-one or one-to-a-group.
They didn’t want to put everything on a bulletin board or a news group in case somebody else read it that they didn’t want to see it, which is a bit like putting something in a database. And then somebody said, hey, why don’t we apply this model to business? When two systems want to talk, they could talk with messaging. And that’s great because maybe the receiver doesn’t need to be online connected to the network.
when we send the message, just like when I send you an email, you might be asleep in America and I might be awake in England and you don’t need to see it because it’s held in a server somewhere and you can go pick it up. So that sort of ability to decouple us in time and space is very powerful. That’s the asynchronous pattern. And people said, this could be useful in business too. If we want to send money, it’s better to send it through a system that doesn’t require the bank to be online.
rather than saying, wait for the bank to wake up and then talk to the bank and the bank confirms they’ve got the money. All of those things are messaging. So I think that that was kind of why people did it early on So I think that’s important, but actually,
When I said it was surprising it was invented as early as it was, what I was thinking is today we have these incredibly varied, highly distributed dynamic systems where if you ask a computer to do something, you may not even know what that means, where it is, who owns it, who’s doing it. And that of course leads to all these concerns that people have about privacy and who can see your data. And if
I’m in Germany or Ukraine, can Donald Trump read my emails and this kind of thing? And probably he can. And so, yeah, it’s super important now and understanding how to implement it well is even more important. I think what really, really, really kicked things off is the cloud, actually. So that’s when we moved from the old days to the new days. And RabbitMQ was fortunate in that it was born at the time the cloud was born as well.
So it kind of was the first tool that was designed for that era, slightly by accident. Actually, there’s a lot of things about Rabbit that are not really cloud messaging, but just because it was co-evolving with the cloud, it became a cloud messaging solution.
Kate Holterhoff (05:14)
Ooh, I look forward to digging into that bigger story there. But before we talk too much about RabbitMQ, I suspect our listeners would be interested in hearing more about your background, especially as your LinkedIn explains that your first job out of university was as a trader for fixed income derivatives at Goldman Sachs. So how did you end up in the tech industry in the first place?
Alexis Richardson (05:39)
Yeah, most people end up in tech after trying everything else. know, bar work, finance, gambling,
I was doing a degree, I did several degrees in mathematics and philosophy. I mean, my first actual job was to be a research assistant at a fusion research facility, which figured out how to run, you know, a fusion reactor, which is still an important thing. And it’s, happened to be two miles from my parents’ house. I could walk there or cycle there. And I knew the person who’d built the capacitor, which was
amazing because you’d walk into this room and you’d see this kind of command center like you see on the TV with space launches and there’s all these scientists. You know they’re scientists because they have pens in their pockets and they’re watching the screens and then the person who’s showing me around said I’m going to show you the battery that we use to charge up the plasma that is the fusion reaction and you’re standing on it and you look through the glass panel on the floor and
You can just about make out the curvature of a wheel that’s over 50 meters in diameter, more like 100. And he says, we take power off the grid with this thing, and it speeds up.
and then like throwing a sling, all that power goes into the plasma. So I’m like, this is exciting. That was my first job. And I was responsible for building graphs that made my physics employers results look good for their academic papers in publications, which was an important task. And so then I, afterwards I joined
the armed forces for a while. And then I went to university, I had various jobs. And finally, I got very interested in gambling. So I discovered you may know that there’s red betting and sports betting, which appeared in the 1990s. It was very exciting to me because you could, and I was playing a lot of poker at the time, you could have a sports match and then you could basically place a bet that paid back depending on how right you were.
So you could bet on the number of points scored in the match. if you thought there was going to be 20 points scored and the spread off it was two to four, you could buy at 4, and then if it got to 20, you’d make 60. And this kind of thing. was very cool. And it was a way of thinking about the difference between the model of the world and reality, which I was quite good at. So after a few ups and downs with that, I realized the best thing for me to do would be to go and do this.
professionally. The great thing about doing it professionally, the best thing of all is it’s other people’s money. And you have this thing that’s called the trader’s option, which is when if you win, you get a cut of the winnings, but if you lose, you keep your job. It’s pretty awesome. And so long as you keep smiling and you don’t get fired, you can stay for decades doing this work.
And yes, I managed to convince Goldman Sachs to employ me to do this. And I was in a group that was doing derivatives trading, betting on whether or not, you know, various countries would join the euro in Europe, or various mortgages would collapse or not in America. And what I discovered is that this whole world of finance was sitting on top of an enormous computer, basically.
And I thought that it’d be more interesting to figure out how that works than to spend my life staring at a screen, shouting at people about buying and selling stocks, which is less fun than it sounds. so I decided to leave again in early 2000 and teamed up with some people who were like me, had kind of got a technical background, but dabbled in things like philosophy, mathematics, logic, computers.
all the stuff that would now be the kind of groundwork for something like AI and then just got a job in finance because it was the best paid job in the street. And then they got into that and thought, well, actually this isn’t totally fun. It’s great making money, but everything else is quite boring. And, you know, it’s more fun to make things and talk to people and do things with them. You know, that’s a lot more cool. So let’s build things instead of buying and selling them. So we decided to form a company which is called MetaLogic and we built a
Java application server. I know it sounds really cool. And it was one of the first tools to do.
what a few years later was called POJOs, plain old Java objects. And if you talk to the gray beards in your company, and that’s probably a sexist comment, if you talk to the wise older people in the company, then some of them may know that the POJOs were kind of the cool thing when they started RedMonk, actually. they were several teams, including my team and another team that built
something on top of Java spaces and several others. We’re trying to kind of do something without using enterprise Java beans. This is what was the industry had told us we had to use to build enterprise systems. And I and my colleagues thought we could do something better because we’d come out of finance. Everything was super easy because you just build all your apps in spreadsheets. So you know, Airtable today, you go on the web, you get a table and you sort of build a spreadsheet and you can do a little app that way that does something like,
your company budget or a room booking system or something else or reporting tools. And we had that plus all these financial plugins to calculate, you know, bond yields and option prices and what have you. So we could build any incredibly powerful application just using any spreadsheet or other tools like Mathematica backed up by these kind of calculators and databases. And we wanted that ease of use and immediacy to be present in Java.
Because we could see that people coming out of university, they learned how to program, they could write a web app by following some instructions. But if somebody said, write a game or create a trading system or build a data store, they couldn’t do any of those things because when they would try to find out how to do it, everybody said, go use enterprise Java. And nobody can understand what that was. But we thought that they could do all those things without learning anything new.
They could just use what they’d learned at college and have a system that could store what they wrote, share it with other people and make it easy to use based on plain old Java objects.
The only problem with our system, were two problems. One was that I wrote it with a bunch of crazy Finnish people, which is a great thing to do in life at least once. But as a business thing, we spent more of our time flying backwards and forwards between the UK and Finland trying to figure out what to do than working with customers. So we only had a few customers, so that wasn’t good. And then the other thing is we made a very fundamental technical mistake, which is building an object database, which is the technology equivalent of
starting a land war in China, in Asia, I should say. Never start a land war in Asia. Never build your own object database. And if you’re ever talking to a RedMonk client, or even worse, a friend, and they say, Kate, we’ve got this brilliant plan we’re taking over the world, and you’re hearing it, and you’re thinking, yay, this sounds awesome, when can I invest? And then they say, blah, blah, blah, and the words object database come out. That’s when you pull the rip cord, you leave the room, and you them to it.
Kate Holterhoff (12:37)
Sage advice.
Alexis Richardson (12:39)
many people in my life who’ve been down this road and done the object database thing. And what we do is we form a little circle, we get some drinks, we cry into our glasses together. because Larry Ellison eats it all in the end. So, what I learned from doing this is if you have a distributed object store where, POJOs can, and by the way, the POJO thing, the person who got it right was Rod Johnson with Spring.
around the same time and his idea, which is brilliant, is make it look like POJOs but also make it look like Enterprise Java at the same time. It’s a clever trick, sleight of hand, brilliant, and then you start off with POJOs and it compiles into stuff that you can run. But we were much more hardcore than that, which made our product unusable. So the thing that I learned though is that…
We spend a lot of time talking to customers about what you could do with this tool, like real-time gaming and exchange systems. I had a friend who built Reuters Instinet He spent $20 million building the Reuters market access platform. So Reuters had been distributing market data for 10, 15 years. They started as a news platform. Then they became a market data distributor. And then they partnered with TIBCO which is Derek Collison’s company.
And then they started sending messages with the financial data over the TIBCO bus into, actually it was called the Reuters Message Bus, I think. And then they sent it into enterprises like Goldman, and then TIBCO bus would distribute the prices around the room and the traders would do things with it on their Excel screens, which was me. And Reuters decided to go one step further and build an actual marketplace. That’s what everyone was doing around about the year 2000. They were going from
electronic systems they used to push data to screens and do settlement overnight. After you’ve done a trade, you would check that your trade was actually correct with the counterparty and money would change hands slowly. But the new thing that everybody wanted was to actually do trading in real time, like in a computer game. It’s like, it’s so much fun. I can go online and be multiplayer game. I can shoot everybody up. Why can’t trading be like that too? Why can’t I buy and sell derivatives in this way?
And so a whole load of people wrote these systems. If you want to talk to somebody who built the one that actually was successful, talk to Bryan Boreham, who is now at Grafana Labs. Anyway, he was at Barclays at the time. But Reuters built their platform and my friend Duncan was in charge of it. And what I learned from that is two things again. One is if they’d had a free choice of technology,
Reuters should have built it on a distributed object store. The same model that we built at my company, MetaLogic, and the same model that was successful actually at Goldman Sachs and other places. Afterwards, I can send you a link about these financial systems called SecTV. But actually that architecture wasn’t gonna work for financial data and market trading. And what made a lot more sense was to use a messaging system and a database together.
and not have one system trying to do everything at once with the cache and the message thing all updating at the same time, but send all of your data to the customer over the message bus. And when you want to transact to trade, don’t try and be too clever and send messages, just send a thing to the database saying we’re transacting now. So this is a sort of abbreviated version of more complex argument, but from that I realized that actually sending data around can be
much better for building incredible systems that don’t go down, are available, are highly scalable, are highly reliable for finance, than having some sort of clever clogs all in one system where it’s all done for you, but actually there’s all these edge cases it handles really badly. There are reasons why people don’t use object databases for this. So that’s when I realized that doing an object database was never ever ever gonna work in the market.
And I’d also been told this by many, many friends and it was sort of finally sinking in. People had taken me aside and said, look, don’t do it that way, do it this way. Make it look like it’s an Oracle add-on, this kind of thing. Have another drink and I’ll tell you how to do that. So having learned to do messaging, I became determined to understand that. And I started talking to a bunch of folks, James Strachan, who built ActiveMQ.
Rod Johnson, was building Spring at the time, Ross Mason. What Ross had done is he built this tool called Mule, which is what we now call an enterprise service bus. Well, I’m not sure what he called it. He thought of it as a bag of tools carried by a mule, so it’s a mule. And it was an enterprise integration solution. But the messages were sent over messaging systems. And we had another friend, Steve Ross Talbot, who built a tool called Spiritsoft, which is a VC-backed.
Java messaging service, JMS bus, in the early 2000s. And the USP of that was you’d have a Java layer that could go over TIBCO or over IBM MQ queries in Java and implement the Java messaging service. So customers should buy that because they had an enterprise approved Java model for messaging. It could do all the patterns they wanted, like one to one, one to many, request reply, et cetera.
And it could work with the old technologies that people already purchased like IBM and TIBCO and some other ones. And so Reuters Instinet, that’s all I was talking about, was built on top of that. And I began to think about talking to Steve, about Spiritsoft and James, about ActiveMQ and other people and trying to understand, know, and there was this other company that did streaming queries. You would attach a query to the message bus and it would alert you when a pattern was met, you know.
These things are all commonplace today, Kate. That’s an example of how the demand has grown while the technology is standardized. Anyway, what was clear here is that the technology was going to be around for a long time. It was very, very different from storage and objects and databases in some fundamental way that maybe we didn’t fully understand. But what was lacking was a really
easy to use, developer friendly, a standard that could scale with the needs of new systems. And so while I was very curious about all of these things, I had basically converted myself to thinking about all these application types in finance as being from object style to message passing.
I found out from another friend we were involved with called John Davies at C24, another startup, and they did another financial messaging add-on for FIX and SWIFT He said, look Alexis, you should come and talk to these people at JP Morgan. They want to do a IBM competitor called AMQP, and the idea of AMQP is you’ll never pay IBM a single cent again if you’re a bank, which is a win.
And then I met with them and they told me that, you know, they’d done their back of the envelope and they reckoned that about 30 % of their annual budget in IT was going on spending for these messaging systems. Not necessarily directly, but all these integrations they had, they were using tools like Mule and other commercial competitors like Sonic ESB and Sonic MQ and Spiritsoft. They had, bought
custom built message buses that did clever things like content-based routing. They brought specialist tools for accessing markets. They had Reuters market data coming into the room, Reuters market data service. had TIBCO, they had IBM, All of that adds up and they’re spending all this money just trying to fix this stuff. And then they had all of these new standards for different classes of messages. Like I want to send a FIX message because that’s a…
an exchange trade, or I’m gonna send a SWIFT message, because that’s gonna be a payment, or I wanna send an FpML message, because that’s gonna be like a description of a derivative. And these are gonna get bigger and bigger and bigger messages more and more per day. So let’s make it all work simply, and they couldn’t get it to work, because they’ve got all these thousands of different systems that they bought every day over 20 years, so they’re all non-interoperable up the wazoo. And all of the things that purport to make them cheaper and better actually turn out to be more expensive in the end.
Also because anytime you build a custom system, you have to maintain it yourself. That’s the law of enterprise software. And if you buy a custom system from a vendor, that means you keep paying the vendor and you have to maintain it yourself. Anyway, so JP Morgan said, right, let’s have, let’s do to this horrible mess what HTTP did for the web. And more importantly, prior to that,
TCP did for networking. Because the web was kind of a surprise, but TCP, you could sort of see it coming. People built networks, they had to have ways of connecting computers together, otherwise they were really limited. And they were all done in proprietary ways, so it became obvious that converging on standards like TCP/IP and the sort seven layer network stack was a very good idea. And once that happened, suddenly over a space of a couple of years,
all these large organizations stopped wasting tons of money on networking products. And all these salespeople, whose job it was to take people like you and me out to lunch Kate and tell us why this version of the software was better than last year’s version and you had to pay to upgrade. We’re out of a job. They had to go back to driving taxis. And so, all of that stuff was, you was good. And the idea was to do that to messaging.
Kate Holterhoff (21:51)
I can’t get over that 30%. That’s significant. Do you have any idea what that looks like today? I mean, What does that translate to?
Alexis Richardson (21:59)
Absolutely no idea. I mean, this was a one-off calculation I think that the reality was that probably about 30 % of the work they were doing had something to do with integration. That would be very plausible. Also, I know they had identifiable pockets of their budget, which they could get rid of and go down to zero. If they could get rid of those systems annually,
and replace them at something cheaper. So they used all that money to fund replacements from initially a company in Belgium called iMatixs, which was founded in the back of a garage. I literally you walk past the cars and there was a software company behind them. And Red Hat, which was a different sort of company by then. And then Rabbit was the third one to get involved. And…
we were like sort of halfway between the two extremes. Anyway, they wanted to use money freed up from budget that was going on these projects that they want to get rid of to stimulate competition and standard in a new market, which is a very, very good thing to do. And it’s something that has been done before in other places. You see it happening now with things like…
know, energy interoperability and green standards and grid and all people are doing is they’re trying to lower the cost of having multiple participants in a marketplace who can buy and sell from each other, share information, share commodities, which might be, you know, energy or something. And then on top of that, build value-added services, which are more useful to the majority of real world consumers. And, you know, we’d built this amazing infrastructure that created the
I don’t know how big a sector in the world finance was when JP Morgan said this in 2007, but this is just before the market crash of mortgages. So must have been enormous sector of the world market, maybe 10 % of sort of financial stuff. And somebody’s saying, we are wasting a huge amount of this money on messaging and integration. So let’s fix that, which is how AMQP was born.
Kate Holterhoff (23:58)
Right, and I’m hoping to have John O’Hara on the MonkCast sometime in the future. So I know we’re going to be thinking a lot about AMQP, which if anyone’s not familiar, the acronym is for Advanced Message Queuing Protocol. But I feel like I have a better understanding now for where the need for this protocol came from. Talk to me about founding Rabbit Technologies.
Alexis Richardson (24:24)
So I had founded another company after MetaLogic went in 2003,
Kate Holterhoff (24:29)
I’m sorry to hear that.
Alexis Richardson (24:30)
A number of reasons which I would describe as, know, nose diving the plane into the ground at full speed. Yeah, I mean, we almost got bought by a big company. We had a few customers, but the market was in a trough, a real pit. And we just didn’t really know what we were doing. We had a lot of baggage that came into the company because of that, blah, blah, blah, blah, blah. Anyway, I could go on about it, but the short answer is it all just sort of had to come to a halt and fell apart, really. I learned a huge amount from it. I mean, you learn so much by doing things wrong. Somebody was…
on the Randy Shoup episode of Oxide that I was listening to this morning, Bryan Cantrill interviews people. Randy was talking about, only gain experience from failure and then you can only fail by trying and all this kind of stuff. Actually, one of the nice things about that era is I met the RedMonk people for the first time. yeah, anyway, so yes, I went on to found another company which was called Cohesive, which is still going.
And the idea of Cohesive was to have a complete open source enterprise software stack support contract for initially everybody, but then we switched it to just financial services. So the initial proposition, which was actually called OpenCare, and I can send you the deck, was essentially the same as what Tidelift are doing today. And when Tidelift was announced, I actually sent them my old 20 year old deck. What I discovered is, and this is 20 years ago, when open source is just taking off.
it’s really uneconomic to be a support broker in open source. So what you have to do is something else. And Red Hat cracked out. I didn’t really understand how they’d done it until many, many, many years later. But they came up with this concept of the enterprise aggregation bundle or something like that, which was you buy a package from Red Hat, they’ll keep it up to date. They take all the money for that. They don’t give it to people upstream. That’s bullshit. economically, that is. Anyway, so.
I tried to do that and then realized that actually we’d better off to try and do a modern cloud native virtualized financial centric stack. And I teamed up some people who’d been in finance for a long time. They, the CIO and his team from big Swiss bank, we formed Cohesive and started working with customers. What we found was that there was a lot of appetite for the stack, but very little appetite for contributing to it.
And that’s one of the sort of golden rules of open source and financial services is banks generally are bad at figuring out how to contribute to open source, partly because when they write software, it used to be treated as an asset by the accountant. And every time you moved a contribution into a common area outside the bank, like a trust or a foundation or an open source project, that would be a book loss. And you’d have to compensate for it by a book win, which a developer wasn’t positioned to do.
which made it very, very difficult to do all kinds of things.
What we noticed was also that in addition to there being appetite for a robust stack, the stack itself was not complete. So at the time there were good solutions for database, MySQL, and other things where people were building. There were app servers, was Tomcat, there was Spring, were integration tools like Mule and C24.
And there was some other stuff. What was missing was a message system. And the problem with ActiveMQ was that it was Java only and heavily tied to enterprise Java implementation of JMS. And both of those things were not what most financial organizations wanted because they were doing messaging in .NET, in C and C++, in Objective-C and believe it or not, Lisp.
and Python and Ruby and things like that. So AMQP was very appealing because it was a protocol that meant that you didn’t actually have to commit to a specific language upfront. The messaging server, which is one of the standard patterns that messaging products have obviously benefited from is there is a server, like a database server, spoke a protocol, like a web server speaks a protocol, and the messaging client spoke the same protocol but could be implemented by anybody.
Like, you I can use the Chrome web browser from Google to talk to a big website like eBay that I think is still running Microsoft IIS on the frontier or something like that. And it’s all fine because they speak HTTP. I mean, know, hand wave mostly. There are different versions of HTTP. And not all the caching servers around the world speak the same versions of HTTP and there are proxies and all kinds of cool stuff. But apart from that,
Interoperability is pretty good for HTTP and we wanted the same thing. And Java didn’t provide it. Actually Kafka is still catching up with that today. So AMQP was completely language neutral. And that therefore would be solving the problem. So we decided to talk to JP Morgan about whether or not it good to have an implementation of this. And then I was given as a result of that conversation a printout of the…
draft AMQP standard, I took it back to the office where I was working and Cohesive, my company, had rented space from another company in London called L-Shift, which is based very close to Old Street Roundabout or as we now call it, Silicon Roundabout. And I spoke to Matthias Radestock who was the CTO of LShift and I said, I think you should have a look at this. And Matthias being Matthias, brought up in East Germany. looked at me, nothing, took it out of my hand and put it in the bottom drawer of his desk. Little tough.
Anyway, about two or three years later, I was doing something else, like, you know, picking my nose and he came up and Matthias has this way of sort of appearing behind you like a kind of, like, have you seen Spirited Away where the ghost appears? He’s like that. my God, he’s behind me. And he had the paperwork in his hand. Actually, it probably more like five or six or seven, eight weeks, I don’t know, was ages. And he said, Alexis.
I’ve read this now, oh good. It would be quite easy to implement this in Erlang. And I’m like, okay, that sounds fun. Do you think anybody would want to use it? So we went back to JP Morgan and we said, thank you very much for the last meeting. We’ve looked at your spec. We have one question which is, would it be okay to implement this in Erlang, expecting them to say, out now, you fools! I think that’s stupid inside.
I mean, so long as it works, we don’t care what language it’s implemented in, which is complete bullshit. Anyway, so we said, well, here are some preliminary experiments we’ve done to show you what kind of messaging throughput we could get. And the reason we like it is because Erlang was designed to implement switching exchanges for telephone companies in Sweden. Ericsson built it. And in switching exchanges, there is a pattern, which is a call comes in.
and it needs to be connected to a particular recipient. And the first thing it hits is like an exchange, what we call the exchange, which is a bit like, you know, if you watch one of those cartoons from 1940s and Hong Kong Phooey tries to talk to somebody and there’s an operator who picks up the phone, connecting you through and they take your call and they have a physical wire and they plug it into another socket and you’re calling from, I’ve forgotten where you live Kate, somewhere on the East Coast, you’re calling me,
Kate Holterhoff (31:45)
Atlanta.
Alexis Richardson (31:46)
Atlanta, there you go. It’s Atlanta, I’m connecting you to LA, click, click, click, and they plug you in, and now your call is actually on a physical connection through the center to the circuit that will take you to Los Angeles. And that is exactly how AMQP works. You have this kind of routing bit, and then you have a connection and communication bit, which is called a queue. And…
We brought in the person who Francesco Cesareani from Erlang Solutions, now part of Trifork. And he said, yeah, this just looks exactly like what we spend all our time building for telcos. So we told JP Morgan, look, we think what you’ve designed with AMQP with this company, iMatix and maybe Red Hat, I don’t know, looks a lot like what Erlang is used for every fucking day. And the cool thing about Erlang is it’s designed never to go down because it’s running telco workloads, not your pathetic bank workloads. It’s actually running real software.
And they said that sounds cool. Well, you know go for it. So we felt that was a good enough reason to have a try at this thing and So Cohesive FT. It was called FT as well Cohesive made a partnership with LShift so I and Some of my colleagues and LShift and some of their engineers basically got together to build you know a financial solution and That worked out really really really really well
There were several things that we did that were probably best discussed another time that I think would be of interest to RedMonk, developer marketing and so on. Kelsey Hightower told me Rabbit was the first product he ever came across that had made an effort to be easy to use. That was many, many, many years
Kate Holterhoff (33:15)
That’s high praise, my goodness.
Alexis Richardson (33:18)
at the time he was in a complete, this was before he worked at CoreOS and everywhere else, but I think it was testament.
to our having tried to do the right thing. We had a famous webpage that said, if you can’t start this in 15 minutes, you can send an email to legitimategrievance @rabbitmq.com. And then we moved 15 down to five. That was good for a while. Of course, now if things don’t work within five seconds, people think you’re an idiot. That’s the modern era for you. But in those days, five minutes was important. And we had customers coming in saying, you know, in my bank,
If I wanna do a thing with a queue, I have to send an email to a central team, and then six months later, I’ll get a reply saying, your queue is ready for you to use it. And with Rabbit, I downloaded it and set up my entire architecture, built my system, proved all of my POC points before I got an email back from the team saying, your queue is ready to use. That’s the difference between developer-centric, RedMonk-style way of working and the old way of working.
And that’s one of the reasons Rabbit did very well. So the other reason was that we sat down and we thought, okay, how are we gonna do well with this product? It seems that people like it. JP Morgan wanna use it. They are sufficiently mad to use it. And what else can we do with it? And I just thought it was really unlikely that we would be able to sell this product to a lot of banks because we’d already found mad people at JP Morgan who were willing to do a new protocol.
and make bets on this crazy team. That was clearly a bad idea. And what was interesting to me was that you could see on the West coast of America, and actually all over the world, people were building really big websites. the way they’d been built had changed. This is going up to your question about messaging. So in the nineties, Amazon came about by having a database backed website.
You know, you go to the website, you type the book that you’re looking for, is it in the database? Yes. I buy it. Now I have a fulfillment process. I pay money. You know, it’s pretty straightforward actually. And suddenly they moved from that to 2010, 2009, 2008, when the website was very popular. They were selling all kinds of things. You couldn’t just have one webpage for everything. You could have lots of different webpages. If you’re on the gardening page,
it would work very differently from the book page. And they realized that because they had a global audience and they were operating at much larger scale in 2007, eight, nine, 10 than 97, 98, 2000, 1999, 2000, it would make sense to build the webpage dynamically from little pieces. So they, you had this thing where you’d go to the Amazon webpage and you’d say, I’m interested in gardening. And then it would
bring you back pieces of the page and you’d see the page being built dynamically. Sometimes if a piece of the page was delayed, you’d see a little blank white square on screen. And then half a second later, they would get filled by some graphics that came from another job that was being done behind the scenes. So what was happening there was that Amazon was breaking up your request to see the webpage into a large number of little jobs, which were independently carried out by workers behind the scenes, like minions.
and they would all go and do a little bit of the page and then would come back with a piece of the page that was requested and then an assembler would just build a page for you dynamically. They’re using messaging to do that, of course. And all the work was going in a message queue, the minions were grabbing the jobs off the queues, they were doing the work, they putting the results back on a results queue. And I’m like, okay guys, people, folks, this is messaging. Why aren’t we taking our product?
to these people and saying, you all wanna be doing scalable enterprise patterns that have been developed in banking, in other companies, by big corporations, you for all these purposes, like market data and settlement and payment and what have you, device management, telemetry, blah, blah, blah, blah, blah. You can take those patterns. There are books by people like Gregor Hohpe called Enterprise Integration Patterns. It’s a great book.
There’s the Gang of Four book. All these things are telling you how to do this kind of work. And all these kind of web digital people don’t know about it because they’re all about three years old and they’re doing Ruby on Rails and it’s all new. So, you know, this is very common in technology, having sort of generational changes. So our idea was just focus.
Kate Holterhoff (37:43)
You know, you’re talking to me right now. I’m taking this all very personally.
Alexis Richardson (37:47)
Yeah, well, you’re too young for all this technology. come on Kate I don’t know. So yeah, I mean, we felt that there were people who were clearly gonna recognize the problem, but hadn’t had the opportunity to use a tool that was designed for them, because they were just different markets. It was a segmented market, I guess. And so we made it our mission to focus on Ruby and Python and those kinds of things.
And in order to keep our competitor Red Hat busy, we convinced Ubuntu and Debian to get RabbitMQ included. And we also published a bunch of very high performance messaging results with Intel’s help, which basically sent the Red Hat team mad. And they spent the next three years trying to do better numbers. And so we just concentrated on much easier customers who weren’t interested in reliability.
And as a result of that, Rabbit became very popular. And then people built things on top of it. Heroku was built on it, and OpenStack was built on it, and many other things. So that’s how we ultimately ended up getting acquired by VMware. At the same time as expanding the company through VC, we were thinking about that. And so, yeah, that was the end of that story as an independent company.
Kate Holterhoff (39:00)
Can you give me some years on that? When was Rabbit Technologies acquired by VMware?
Alexis Richardson (39:05)
The acquisition was completed at the end of March in 2010, announced a few days later, and actually officially, ha, we had a really clever transaction that bridged two tax years in two different geographies. It was kind of fun. The lawyers went nuts with joy. But we completed the transaction over the weekend of the fourth, fifth, and sixth of April, which meant that some parts could be done in one tax year and some parts could be done in another tax year.
And then it was done. And that was at the same time as the VMware acquired Gemfire. They were trying to acquire Heroku at the time, which didn’t go through. And then from there, we built the VMware cloud platform.
Kate Holterhoff (39:42)
That makes sense. And I’m glad I asked this because I know in 2011, that’s when AMQP became an OASIS member section.
Alexis Richardson (40:01)
Yeah, that was the beginning of the end for AMQP. All of that stuff has been negative for AMQP.
Kate Holterhoff (40:06)
Tell me more. What’s, yeah, I mean, we don’t have to dig too deep into OASIS for the sake of time, but I mean.
Alexis Richardson (40:16)
OASIS was a fine enough thing, if you look at it over long period of time, it is not the home of the world’s most exciting and plausible standards.
Kate Holterhoff (40:25)
All right, fair enough.
Alexis Richardson (40:26)
And when you ask somebody, hey, think of a great standards organization. I mean, if they don’t run away screaming, no one will say OASIS.
It’s to go to die. You know, it’s the commuter associate of standards bodies. The original goal was to do something else like, you know, ISO maybe But I mean, the problem was that the main issue with AMQP is that
One group of people thought that in order to declare victory, we should focus not on interoperability, which had been demonstrated with the first set of standard protocols, 0809 and 091, but instead, we should focus on extending the protocol with a whole set of distributed transaction capabilities, which were allegedly very important to you.
large financial organizations and there were people who would say, I can’t use this in my organization unless I have these things. Now, of course you could overlay those things in other products like Spring Integration and JBOSS and many other things would let you do transaction models over messaging perfectly well enough. And so that would give you a way in while having most of the economic benefits of decoupling you from IBM and TIBCO. But.
That wasn’t enough. And what happened was that some people in the AMQP community decided to go and sit on the Scottish Island for a long time and try and write their new protocol and then came back and it was like Moses from the mountain. And what was fascinating to everybody who’d been working on this for five years is that the protocol had been essentially dumped and replaced by something completely new. So the candidate was proposed for AMQP 1.0, had no users, had a lot of strip back functionality and basically was a way of
describing a message format. So it was like STOMP. There was a protocol around at the time called STOMP and STOMP and AMQP 1.0 are very, very similar. It had some benefits, but it really didn’t constrain behavior enough to deliver interoperability. So what we ended up with, to be very, very generous to everybody, is two completely different protocols. One, which describes messaging patterns like publish, subscribe, queuing.
request response based on a model which is absolutely certainly can be described as flawed and you can contest it and compare it with other things and say it’s not good enough or whatever you like, but it works pretty damn well in reality. And another model which is a bit like a sort of peer to peer message transport, which you you could sit on top of the first model, but described a completely different set of use cases and was touted as the winner. So,
Some people have used that and what’s the world we’ve ended up with, and this is perfectly okay, is one where there are many implementations that was intended and they speak multiple protocols. That was also a good thing. So you’d have, know, Rabbit speaks AMQP, both versions, and MQTT, which is what Andy Stanford-Clark worked on. It’s a great protocol.
and a few others as well, and I think it speaks STOMP. But then you have other implementations that speak these things as well. And that was actually the end goal. So we ended up in a better world, but we didn’t end up in a world where there was one true protocol for messaging, which I think was the original real flag on the hill that we were gonna go for. And the OASIS is sort of irrelevant, of footnote in that story, because AMQP 0-9-1
is not an OASIS but has far more users than 1.0 even today.
Kate Holterhoff (43:35)
Okay, and so we know that AMQP was designed as a way to bypass paying for IBM’s MQ at the stage of AMQP 1.0.
Alexis Richardson (43:47)
for the protocol. So when you use the IBM MQ series, which is name for IBM WebSphere MQ, you had to buy a license to use the protocol because it wasn’t an open protocol. You couldn’t actually get a document off the internet that described it, but AMQP upended that and said, here’s a protocol. You can download it. You can read it. If you read AMQP 1.0, it’s called Advanced Message Queue Protocol, but there are no queues in it. And you can see all of that because you can download it and read it.
And that was the change. to finish your question, but it was really the license for IBM MQ’s protocol that was the challenging commercial factor that was removed by having an open.
Kate Holterhoff (44:25)
I think some of the stories that I’ve heard around AMQP 1.0’s era is that it’s brought back in some of the enterprise players. So I’m thinking of Microsoft and IBM. Can you speak at all to that? Like, where were they during this process?
Alexis Richardson (44:44)
Microsoft joined before AMQP 1.0 was begun. So it’s not correct to say that AMQP 1.0 brought them in. The people who were working at Microsoft on AMQP and messaging more generally at that time were people who had a lot of experience in distributed objects from the 90s, distributed transactions and workflows, and that was kind of their thing. So they saw it all as very natural way of doing it.
messaging. We and others like say, I don’t know, for example, the Heroku team saw it as a total waste of time and massive unnecessary complexity. And we were more comfortable with the idea that these complex edge cases could be supported as extensions or as modules or as add-ons or expensive versions or enterprise additions. You take your pick. It just didn’t have to be forced upon everybody who was doing it, who didn’t need them.
Nonetheless, we ended up where we are. There was definitely a spirit at Microsoft that they wanted to convince the world they’d come in at the right time and done the right thing. But in reality, that’s not what happened because they ended up with a forked protocol. IBM, so one advantage of AMQP 1.0 is it’s so basic and stupid that you can put it in front of MQ series. Because MQ series defines what the broker does.
and it replaces the protocol with an AMQP 1.0 transport. And that I suppose is kind of a win, but I could see that happening on the old trajectory as well. Anyway, it is what it is. I mean, I don’t think anyone is the worse off for any of this. And it is good that IBM is supporting open protocols, something that they’ve done with MQTT themselves. They pretty much initiated that. I think that one of the ways in which the industry
learned a lessen from this is for a long time, MQ series was one of IBM’s keeper products like Oracle databases for Oracle as a company. You can go to Oracle, there are so many things they do. They do everything. All these business products they’ve bought, but really it’s about the database at the end of the day. That’s why Larry’s still there, you know? And IBM for IBM, MQ was that product for awhile.
and it was very, very difficult for them to move away from all the assumptions that had made it so amazingly successful and so powerful and so useful for the world. But the industry needed better. They needed a cloud messaging solution that wasn’t tied to one language, easy to set up, well IBM wasn’t tied to one language, easy to set up, lightweight to tear down, was very comfortable dealing with sort dynamic distributed systems in the way that modern
messaging tools are like Derek’s tools, for example. And RabbitMQ just happened to be there at that amazing phase shift in the industry. So although it was designed with a lot of assumptions that came from the past about queues and PubSub and exchanges and things, really it became a first tool of the new era. And then since then we’ve had all kinds of innovation, which is great.
Kate Holterhoff (47:30)
Right. So there’s two more topics that I’m hoping we can address before we ramble on for too much longer And one has to do with your time at the CNCF.
the other is just rounding out your tenure with Rabbit so which of those makes sense for us to talk about first?
Alexis Richardson (47:50)
Well, I give you the Rabbit Pivotal version first. when I was doing Rabbit, we were very interested in Redis. I spent a lot of my time talking to Salvatore. He became a great friend of mine and an industry colleague, I would say. And I kept thinking it’d be great to have Redis and Rabbit sort of somehow in a single company or doing something together. The way that ended up happening was that
At the same time as Rabbit had a great acquisition offer from VMware, several people were trying to convince Salvatore to come to work with them. And I asked VMware if it would be okay to bring Redis in with RabbitMQ to be a foundation block of Cloud Foundry and the Cloud platform that we were building. And everybody said that would be fantastic. So I talked to Salvatore and I said, you know, are you interested in coming to work at VMware? Because we’re about to accept an acquisition offer. Don’t tell anyone.
And he said, let me think about that. And he came back and said, what I really like about VMware is it’s a proper engineering company. And there are not many companies in the world that fit that pattern, and I would be very interested in Redis being sort of under that umbrella. So that was the beginning of a longer conversation that led to us being in the same team. And for a while there was a Rabbit in Redis team at Pivotal and VMware and so on. And Derek was part of that move as well, with multiple different orgs and changes. And around the time that I sort of stopped.
consciously thinking about myself as working on this stuff was probably about 2012. So the acquisition was 2010. I spent 2010 to 2012 making sure that OpenStack was successful, VMware was successful. VMware started adopting RabbitMQ in multiple products internally. Cloud Foundry was using RabbitMQ, although they ultimately went on to build their own mini broker which became NATS. Spring and the vFabric platform were starting to make money, out of RabbitMQ
as a commercial product. And then Pivotal happened around 2014 and I was in charge of several things, including the Spring platform, the vFabric platform, and a bunch of other stuff too. So I started to focus on Spring. Many people had asked me to spend time on Spring up until that point in time after Rod had left. There were so many crazy political things happening at VMware, which is a longer conversation about all of that. But the net result of all of this is that we ended up.
as a larger team, creating Spring Boot, Spring Data Flow, and other amazingly successful products, which is a fun story in and of itself. So that’s the Pivotal story, and by then I was kind of out of the world of messaging. One footnote is Spring had a thing called Spring Integration, which I’m a big fan of, which is a bit like Mule. It was a sort integration portfolio around messaging, which is very, very popular as well. And one of the things that we did when we…
became part of the Spring Source VMware team is make that all work nicely. So that’s the Pivotal story. don’t know if that helps you. I mean, I could talk more about it if you want.
Kate Holterhoff (50:32)
no no i think that’s great i just wanted to make sure that we rounded out like how Rabbit became part of that story and your career arc.
Alexis Richardson (50:44)
so I think the main thing I tried to do then was make sure that having acquired the product, VMware would not shut it down. So that’s a longer conversation, but I was quite successful and I’m very pleased to say that Broadcom is still employing RabbitMQ people. You can go and buy Broadcom RabbitMQ today. I hear it works really very well. It’s on version four now. The architecture they’ve got is fantastic. It’s challenging Kafka in lots of ways.
Kafka makes a billion dollars of ARR, and if you’re a customer, go look at RabbitMQ, or some of the other products too. It’s doing well, I mean that’s amazing, and it’s kudos to Broadcom for being aware of these products which are frankly outside their core business, but are probably adjacent to their core business and helping them in some important way. you mentioned AMQP 1.0, I noticed that Rabbit,
has always supported that, it announced the new module supporting it recently. And that was, that was tied up with something they did with Bloomberg. Bloomberg is using RabbitMQ a lot. So I’m sure that that’s sitting on top of a Broadcom, you know, vSphere infrastructure. So that combination of, you’re a big organization like Bloomberg and you want to do international data distribution. And you’ve got all these different applications, the cloud applications and traditional applications all somehow connected to one backbone. You’re doing it on Rabbit on Broadcom? That is fucking incredible.
Kate Holterhoff (52:05)
Alright, I like it. Yeah, that completes the story well, I think, in terms of your experience with messaging and it tells us where Rabbit is today. So let’s sign off with talking about the CNCF. I know that’s a huge topic, but 2016, that’s when you became the foundation chair of the CNCF’s Tech Oversight Committee and you remained there until 2020. So you clearly have a long tenure. Talk to me about the CNCF. How did you become involved?
Alexis Richardson (52:34)
It’s a long story. mean, the one thing I wanted to say about this that relates to the previous conversation is that when Derek asked me if NATS should be a CNCF messaging system, I was very excited about that because I think that one of the things CNCF is for is to encourage a diverse set of projects because we don’t know where things will go in the future. You know, there might be use cases that NATS is just much better at than everything else.
And the worst thing that the CNCF could do is say, no, no, no, no, you know, we can’t take NATS because we already believe in something else. So that’s why we have this concept of no kingmakers. And we also were sort of an organization that was kind of anti-standards in the sense that we thought it wasn’t our job to set standards. We thought it was our job to make sure there was fantastic technology that was standardized in its usage.
but not enforced upon people as a legislative standard in the way that sometimes that can happen with technology. And then it gets rejected 10 years later when everyone can’t use it. So that came about from a lot of bad experiences with AMQP where people became over-rotated on the importance of the standard and under-aware of the value of just having working software that solved problems for people.
The reason I got involved in the CNCF is because I went from being in charge as product person of the whole Spring world. Suddenly we decided to leave and do containers. And we’re building a network to connect containers together, to have apps. And then there’s a single Kubernetes, which appeared within seven days of my founding Weaveworks.
And the first thing I thought is, wow, this is a really stupid name for a product. And then I discovered that it was also quite complicated in reality. And it took us ages to understand it and install it in things. And I remember I had a friend who worked with me at VMware who was in sales, Rob, and he’d gone to the GCP Google Cloud Platform team to be a salesperson there. I bumped into him somewhere and he said, Alexis, I’m doing a mini…
seminar next week in Google’s offices in London and Victoria. Come along, you’ll meet some interesting people, including somebody who invented this thing we call Borg, which became Kubernetes. So I go along to that. I hear all this marketing stuff about the cloud, which is pretty good actually, it’s impressive. And then I meet this very, very tall English guy, I’ve forgotten his name, John Wilkes I think. And he’d gone to Google right at the beginning and built all of their infrastructure.
And that was the Borg design and he’s like, you know, the old wise person of Borg. And we had a lovely conversation. I really enjoyed meeting him. He was clearly a lot of, you know, very significant, sophisticated person with an enormous space inside him full of things. And one thing I said is, you know, what do you want Kubernetes to be? Do you want it to be like OpenSpark, which has about a hundred users?
a lot of potential users, but it’s of stuck in that bucket. Do you want it to be like Hadoop, which has maybe 1,000 users or 2,000 users, a lot of potential, but it’s kind of stuck in that bucket? Or do you want it to be like Spring, which I’ve just spent two years trying to reboot, and has a million unique users a month coming through the website, now many, many more. And he looked at me and he said, Alexis, you need to talk to the product team.
I made some other comments which are slightly more negative than that afterwards. anyway, said, come and talk to the product team. And I met Craig McLuckie through this. And Craig had basically been tasked with making this thing successful. And he’d made it successful enough that he was starting to think, what next? And part of that what next was talking to customers. And they were saying, well, hey, Craig, we love this new thing that Google has just spat out.
but we don’t trust you to do support for it. This idea that you’d be an enterprise software vendor is ludicrous. Already you’ve made fools of yourself with Android. What next? And he’s like, hmm, this is good feedback. So what many of the customers had suggested is go team up with Red Hat, put it in a foundation, get Red Hat to support it like OpenStack and like Linux, and you’re off to the races.
because they’re a credible support organization and Google is not, for enterprise software at the time. I said, well, that’s very interesting, Craig. So we switched from me basically moaning and bitching about why Kubernetes was a stupid name and why it was too complicated and why it wasn’t stupid for individual users and a bunch of other crappy things about it. Anyway, he said, look, I really want to put it in the foundation. And actually, that’s a good thing because if it were in a foundation, there would be a community.
of developers like you or I’m not a developer, he meant people that you’re working with and others and people that we know, people we don’t know, people we haven’t met yet, new people would come along and potentially the project could thrive around that and it would be also decoupled from all this kind of baggage that unfortunately has brought into the world with it.
And I said, that’s very interesting because I’ve been helping my friend Adrian Collier while we’ve been at Pivotal build something called the Cloud Foundry Foundation. And the reason the Cloud Foundry Foundation exists is because Pivotal was created out of about 10 different companies and projects, including Rabbit and vFabric and SpringSource and things from EMC like Pivotal Labs and Postgres, Greenplum and some other things I forgot and Cloud Foundry and…
They looked at the numbers of the outgoings and a lot of money was going out on Cloud Foundry stuff. There was this data center in Las Vegas and it was not clear what it was doing. And then the users were small in number and they were trying to figure out, we shut this thing down? Should we reboot it? Should we pivot it? Anything is open. Should we plug it into other things? And IBM came along and said,
We’ve heard you’re doing this thing called the Pivotal Initiative. Do you want this Cloud Foundry thing? Because we can take it off your hands if you don’t want it.
because IBM had been trying to build a PaaS that was like a Heroku but open. And how we got to Heroku, open Heroku to cloud, to Cloud Foundry is another discussion. anyway, IBM said, we’d like this thing. And of course, when IBM say to you, want something, the correct response is, you can’t have it. They also tried to answer with, Adrian and I spent a lot of time talking to them about spring as well. So.
the result of that was that Pivotal shifted that posture on Cloud Foundry to one, which was, and I’m being careful what I say here and polite to people, you know, a little skeptical to one, which is, Hmm. You know, people are seeing something in this that maybe the whole world hasn’t seen yet. Maybe we should do something about that. Can we be creative? Can we, can we be smart? Can it be a win-win? And so they sat down with IBM and they said, can we do this with you?
in some way. And IBM said put it in a foundation and we can collaborate. And so they had to create a new foundation which is the Cloud Foundry Foundation which is a subset of the Linux Foundation. And it was designed with a very specific set of rules in mind. It was designed to encourage end user firms to get involved. It was designed so that Pivotal had most of the decision making power for the first five years and maybe even ten years. But IBM could be in the room and sell Cloud Foundry implementations to customers.
So there was a balance of competing interests and it was designed so that Pivotal could basically benefit from IBM support and get to IPO, but IBM could kind of take all the chips off the table at the end of the day. And which they love to do with everything. They bought DataStax yesterday, talking of which. So I said to Craig, look, I’ve just been, I’ve been a fly on the wall working with Adrian on this.
I think that what we’ve learned from the Cloud Foundry Foundation could be applied here for Kubernetes. And that is, don’t use Apache, don’t use Eclipse, don’t use Mozilla, don’t use GNU, do use the Linux Foundation, do it as a sub-foundation, and have your own charter that lets you have a balance between economic and community interests. And more specifically, you must have a
the cross-section of interests that you need to account for. End users. We learned from Cloud Foundry Foundation that end users, if you bring them in the room, they’re very valuable. Big vendors have always sponsored these things, but they can overwhelm them. We learned with OpenStack, they basically slowed it down. Don’t be OpenStack. Small startups are the lifeblood of a lot of these new technology waves. We learned that from Eclipse and some other things.
And individual contributors have always, throughout open source, been a really important part of all of this. Always, always, always. And so, how can you have a foundation that allows for all four of those parties to have their piece? It’s like a table, a four legged table. If you cut off a corner, it will topple over. So, what does it look like? you need to have something which is friendly with regard to startups making projects, but also lets the big companies have their say.
And there’s a certain way to do that. And I wrote a draft charter for it and I sent it to Craig. And that kind of went through many, many iterations and was eventually the charter for the CNCF. You can still see bits of my text in there. Which is not me claiming credit, it was just the story. That’s bits and pieces. Many, many, many, many parents. And then we started the CNCF and the first thing that happened was that they elected the TOC and I was somehow pulled in. That was probably Craig’s fault.
And then Bryan Cantrill, the bastard, nominated me as the COC chair, which was when I spat out all of my drink and shouted at him over the conference call. But it worked out quite well because it meant that I think what I brought to that was kind of the same thinking that you would do in doing a startup entrepreneur mindset, which is there’s a lot of stuff that people want, that’s just gonna have to wait five or six years.
And we’re just gonna focus on what do we need to do to get off the ground? And that was get great projects. They will provide everything that we need at the beginning, everything that we need. So we just focused on getting Kubernetes, Prometheus, Envoy, and a few other projects involved. And what happened was that a lot of people tried to stop us or they thought they were helping, but they tried to stop us. And we just had to find ways to put them away or shut them down or give them something else to do.
and just focused on getting projects on board and suddenly everybody wants to be part of the CNCF. And then they had total FOMO for a couple of years and then suddenly it was a big thing. And then somebody did the stupid, I was responsible for suggesting we have our own map of the projects because VCs kept publishing the wrong map. it would be like the elephant was upside down or something. And we did an official map with Redpoint and another investor.
and Amplify, I think it was. And then Dan Kohn decided to take it off us, make his own version of it, which is why we ended up with this huge CNCF wall map that we have now. But apart from that, it was quite successful really. So the main complaint I have about it today, think that the, first of all, I’d like to say that Emily Fox,
who’s the TOC chair, is an absolutely outstanding individual. I think she’s doing a really fantastic job, and the TOC is doing a great job. I think the challenge for the CNCF is, now that it’s in a more mature stage, it needs to go back to some of the first principles and ask, how can we have this balance of interests so that the big projects, the small projects, the late projects, the early projects, all move forward quickly?
How can we be an environment where if you’ve got a really great new project, you want to be in the CNCF, you don’t want to be out of the CNCF, at least if you’re in the right domain of technology. And I think we had that model at the beginning and then it of became overrun a bit with people with some different ideas. They brought a lot of the bad things from other foundations, like masses of bureaucracy and an obsession with what they called community, which turns out to mean something else. and lots of other stuff, but it is what it is.
Kate Holterhoff (1:04:15)
I think that’s the most complete history of the CNCF that I’ve ever heard. So I appreciate you laying it out from the beginning and talking about some of the inner machinations that went on and your own involvement. My goodness, I didn’t anticipate that you would have, you know, been involved in drafting the charter and then like, I’m just very glad that I asked the question.
Alexis Richardson (1:04:38)
Well, I wasn’t thinking about it that way. It was more like, hey, Craig, if I wanted to see a foundation that works for what we’ve been talking about based on what I’ve seen with the things we were talking about, here’s how I’d do that. And it’s like two pages of bullets. And when the CNCF was founded, we had something that looked more like a charter that Craig had basically polished up and made official sounding. He’d had to put in things like an architecture, which was a huge bone of contention for a while. Anyway.
Kate Holterhoff (1:05:04)
Well, they must have been compelling bullets regardless. So, okay, I’m gonna stop us there because I know you and I could continue talking for another three hours. So I am calling it, how can folks hear more from you? What are your preferred social channels so that everyone can continue to benefit from your insights and expertise?
Alexis Richardson (1:05:24)
So we’re talking about things that I’m not doing anymore. But if people
Kate Holterhoff (1:05:27)
You’re offline.
Alexis Richardson (1:05:28)
wanna. I am, discoverable and contactable and present on, Slack, LinkedIn, both the main, short form social media, and, email. so on LinkedIn, I’m tending to post about, you know, work stuff.
I would like to have a blog. keep forgetting to put something on it, but that’s kind of substituting for it at the moment. think actually think LinkedIn is pretty good for conversations like what we’re talking about today. And then Slack is good for, short form private conversations or, transient conversations. So you can find me on the CNCF Slack, Kubernetes Slack. My handle on all these things is monadic and That’s also true of the short form social media. But it is pretty easy to figure out how to get hold of me if you need to.
Kate Holterhoff (1:06:09)
All right, works for me. And I will add those to the show notes. I’ve really enjoyed speaking with you, Alexis. Again, my name is Kate Holterhoff, senior analyst at RedMonk. If you enjoyed this conversation, please like, subscribe, and review the MonkCast on your podcast platform of choice. If you are watching us on RedMonk’s YouTube channel, please like, subscribe, and engage with us in the comments.
No Comments