CRAIG BOX: Hi, and welcome to the Kubernetes podcast from Google. I'm Craig Box, with my very special guest host Adam Glick.

[MUSIC PLAYING]

ADAM GLICK: Hey, Craig, great to be back.

CRAIG BOX: I had to look up when you were first on the show. Turns out it was episode number one.

ADAM GLICK: Indeed. It was actually on the episode zero, I think, if anyone remembers the pre-roll that we did for the podcast.

CRAIG BOX: I think we excised that very quickly, when we realized--

ADAM GLICK: [LAUGHING]

CRAIG BOX: --what kind of show we were going to do. Anyway, I couldn't think of a better host to join me on April Fool's Day. Welcome back.

ADAM GLICK: I say, I've just woken up from a sleep, What day is it? What time? Did something change?

CRAIG BOX: No, the world's just like it was when you went.

ADAM GLICK: Awesome. What have you been up to?

CRAIG BOX: It's been a painful week to search the web for news about containers.

ADAM GLICK: [LAUGHING] I imagine you've got a lot of things that didn't have to do with Kubernetes.

CRAIG BOX: No. I think one of the most fun examples I saw was a website where there was a model of the Ever Given ship that you could basically pack in whatever waterway that you wanted, and you could navigate it around and see. You could see the scale of it, versus your local river or your swimming pool, or something like that. But I managed to park it in the Thames and completely get it stuck.

ADAM GLICK: Have you seen someone had an aerial video that they'd posted online of all the ships that were backed up, waiting to go through the canal? And it was just-- like, you realized the scope of the challenge and the problem that exists. It reminds me a little bit-- not to tie this too much back to technology-- but the reply All threads in email that blow up email systems and just people start replying and replying and it just starts filling the email queues of those things.

There was a case, gosh, probably about 10 years ago, where the US State Department had one of these happen. And it took down the email system for all of the Department of State for the US government for three days. Because all the emails queued up. And then, of course, they shut down the system, emptied the queues. But then the other replicated servers brought the emails out of their queues back into the initial queue. And it just kept feeding itself.

CRAIG BOX: This is why we love distributed systems.

ADAM GLICK: True enough.

CRAIG BOX: A couple of related things I saw-- there was a great picture of a truck, which I think was somewhere in Asia, which was from the same shipping company, that managed to T-bone across a highway and block traffic in a very similar fashion.

ADAM GLICK: There is a thread going on Reddit that I saw yesterday of just people posting pictures of various vehicles that are turned perpendicular to the flow of traffic and blocking them and just people being like, here's another one, here's another one. It's good that people can find some humor in what's happening.

CRAIG BOX: Yeah, Britain's decided, especially after Brexit, that it wants to have a little one of everything else that the world has got, and it managed to get a small container ship stuck in a small harbor somewhere down south this week.

ADAM GLICK: [LAUGHING]

CRAIG BOX: Just really wants to play along.

ADAM GLICK: Congratulations on joining the zeitgeist.

CRAIG BOX: I hear there's a tunnel boring machine digging under your feet as we speak.

ADAM GLICK: There is, here in sunny Seattle, they're digging tunnels to put some of the roads and some of the transit underground. And they decided to do a voting thing. So much like we talked about the voting for the bird of the year, it's always interesting to see when people open things up for internet voting.

CRAIG BOX: Can't possibly go wrong.

ADAM GLICK: So they've been a little wiser about this one, that the voting is available. There'll be a link in the show notes that people can vote for what is the name that they want of the machine. But they've limited people to the five finalists, to keep certain things from staying out of there-- though I will unabashedly speak up for the one that I love, which is Sir Digs-A-Lot. For those of you that don't know, Sir Mix-A-Lot is from here in Seattle. And so I just think that that would be a wonderfully fun reference.

CRAIG BOX: We like big drills, and we cannot lie.

ADAM GLICK: Indeed. Shall we get to the news?

CRAIG BOX: Let's get to the news. Hot on the heels of last week's interview, Replicated has launched a new open source project. Outdated is a kubectl plugin, to show out-of-date images running in a cluster. Be sure to check out their website for some deliberately Outdated style.

ADAM GLICK: If you want to validate and benchmark Kubernetes storage, check out Kubestr by Kasten, by VEEAM. Kubestr is a newly released set of tools that let you identify the various storage options present in a cluster, validate if the options are configured correctly, and evaluate the storage using the FIO benchmarking tool.

CRAIG BOX: You are not a cloud native database these days without your very own operator. The latest member of the club is Aerospike, an in-memory no SQL database popular in the ad tech industry. The operator does all the things you would expect for a 1.0 release. And while it is open source, it says it is only available to install the Aerospike Enterprise Edition.

ADAM GLICK: Tanzu Kubernetes Grid-- the runtime at the bottom of all the different flavors of VMware's Tanzu has been updated version 1.3. This release upgrades Kubernetes to 1.20 and adds support for Ubuntu 20.04. Other features include a unified CLI, support for the NSX load balancer, and integration of pinniped for authentication.

CRAIG BOX: Last May, we brought you the news of an upcoming Red Hat OpenShift service on AWS, and that product is generally available this week. Just like the Azure variant, you buy the service, nicknamed ROSA, through Amazon, who will also provide your support. The new platform is charged by the hour, with annual commit available for the notes.

ADAM GLICK: Red Hat also announced that they are updating the front end of the Quay container registry. You will need to access it with a Red Hat account starting on June 30, at which time they will remove login options for GitHub, Google, or Quay itself. It will remain a public registry with a free tier, and your Quay.io credentials will continue to work for pushing and pulling images with Docker-like tools.

CRAIG BOX: Traditional security vendors are also making sure to get in on the container scanning business, with antivirus vendor Sophos joining the party this week. Cloud Optix, with an x, is a security scanning service for the three major clouds. Sophos has added scanning of containers and a handful of common registries to it and also supports scanning your build pipeline via an API.

ADAM GLICK: We talked to the team from Kubecost in episode 124. And this week, they announced a $5.5 million Series A funding round. In the announcement, Kubecost says they're helping 1,000 customers look at a $1 billion worth of cloud spend. This first round was led by the aptly named First Round capital. And other investors include the founders of Replicated, who just keep popping up.

CRAIG BOX: Finally, there are lies, damned lies, and best practices. Itamar Turner-Trauring has been on the mission to clear up one particularly egregious best practice, that you should not install security updates while building a Docker container, because you have to do that as a root. He has been rolling around the web, aiming to comprehensively bust that myth, and lays out the reasoning behind it in the blog post this week. Go well and be secure.

ADAM GLICK: And that's the news.

[MUSIC PLAYING]

CRAIG BOX: Alexis Richardson is the co-founder and CEO of Weaveworks, the company behind cloud native projects like Weave Net, Cortex, and Flux CD. He was the first chair of the CNCF TOC, serving for three years. Prior to cloud native, Alexis was a founder of RabbitMQ and a director at VMware after its acquisition. Welcome to the show, Alexis.

ALEXIS RICHARDSON: Thank you very much, Craig. Happy to be here.

CRAIG BOX: If I were to build a tech startup founder in a lab, I might want someone with a background in computer science and maybe experience in business or finance. The founder of Weaveworks started teaching mathematical logic at Oxford University.

ALEXIS RICHARDSON: That's true.

CRAIG BOX: Was that an active career choice, or was that just what you were studying?

ALEXIS RICHARDSON: I was studying mathematical logic at the same time as teaching it, yes. The reason I got into that was because I started off doing mathematics and philosophy, which is what we call a joint school in Oxford. We don't have the European-American model, where you do multiple subjects. You typically have a strong major from day one or sometimes a major and a minor subject. And in my case, it was 50% math and 50% philosophy.

And so dark tech industry secret is there's a lot of people with that degree floating around the tech industry right now. The other one is physics and philosophy as well. And philosophy is a very good thing to do, if you want to get into tech, because it's got nothing whatsoever to do with computers in and of themselves. But it generally breeds a certain kind of skepticism about the sort of claims that people who work with computers often make, which I find to be helpful.

CRAIG BOX: So it'd be good for critical thought.

ALEXIS RICHARDSON: It's definitely good for trying to help you to think, but also, it's good for trying to help you understand more about how people, who have to use these damn things, might actually think, too. There's a really could essay-- oh, maybe it's a blog post-- by Stewart Butterfield, the founder of Slack, who also had a philosophy degree. And he believes, as all people with philosophy degrees do, that it's a mandatory starting point for becoming a technology entrepreneur, certainly much more useful than an MBA.

CRAIG BOX: You mentioned there was mathematical logic. Was there a computer science component to that course as well?

ALEXIS RICHARDSON: No, not at all. So computers in England, where I went to university, were quite uncool. I myself was first exposed to Apple II in 1971. And then, the ZX spectrum and the PET, do you remember those?

CRAIG BOX: Oh, of course. I'm a little steeped in computing history, but I think you might have probably been about the right age for the Computer Literacy Project.

ALEXIS RICHARDSON: Yes. So I was born in 1969, so I was being given these 1980 machines and going into a dusty room which was called the computer room. There was nobody else there except one other young man-- he probably needed a bath-- wearing a brown shirt with a very big color. And then there was a very dusty dot matrix printer, which I loved. And then, all we could get excited about was getting a Gulfport printer. Those were the good old days.

Anyway, so then was the BBC, which was basically this kind of technology triumph in the UK, where the BBC brand got associated with some people making cheap computers for the home and schools, which was called the BBC Micro. And these really took off and essentially, told a generation of people how to program and how to build networks and how to think about computers. And I think a lot of the folks that you've run into, if they were at school in the UK around that time, were almost certainly exposed to the BBC Micro. You may have come across, in London, Jeremy Ruston--

CRAIG BOX: Uh-uh.

ALEXIS RICHARDSON: --who wrote TidllyWiki, who I worked with for a little while. Jeremy has still got some outstanding classics of the day. "Jeremy's Guide to the BBC Micro," which he wrote when he was at school, has a wonderful photograph of Jeremy with a huge afro on the front cover of the book. So yeah, I mean, I didn't really do anything with computers, except informally, until after I finished my degree, when there was an opportunity to stay on at university and do a master's, a conversion course in computer science. Or in Oxford, it's called computation.

And I had a friend who I met in my first year, who had done mathematics and philosophy, who'd stayed on for an extra year to do this course. And he'd recommended it as a fun thing to do just for a year, after you've done your undergrads, because computers might be useful one day. And I thought that computers might be useful one day in 1990, '91, and might be just helpful, whatever my career would be, to know how they worked a bit better than I actually did.

So I got on this course and learned all about the joys of completely pointless academic languages, like we now have Haskell. But in the old days, we had these, like, Orwell and Miranda, and things like Modula, which is a kind of crap version of C, with modules instead of objects as well. And then OCaml was my favorite language that we used a lot. I ended up writing a huge theorem proving OCaml for my-- sorry, in SML, as it was then-- for my thesis, which meant that they said "do you want to stay on and do a PhD". So I ended up just sticking around at university like a kind of cockle shell, because that was quite fun. And that's what I did for teaching.

CRAIG BOX: So it sounds like you picked up a few functional programming languages around that time, and they might come in relevant as your career progresses.

ALEXIS RICHARDSON: I mean, it means, that when you talk to people who do things like FRP, or even JavaScript today, or dependent types or other funky stuff, you tend to know what they're talking about, which helps. I mean, it really does make a difference. And if you look at jumping ahead to the present, to things like GitOps, where really, we're trying to push the declarative model as far as it will go in terms of providing a real system.

Understanding functional programming and evaluation systems and where they came from is certainly very, very useful. Although, I will say, I do watch Twitter and see some remarkably brilliant people still working on pretty much exactly the same stuff that we were fussing about within the '90s. So things haven't moved along too far in academia, though.

CRAIG BOX: So after academia, to broaden out the startup founder portfolio, we have a few years working at Goldman Sachs. How did that come about?

ALEXIS RICHARDSON: Well, another thing that's not in your typed history, Craig, is that when you're doing a PhD-- which I never finished, by the way-- one of the things that happens is you have a lot of time on your hands. So I did lots of the obvious things, like sports, and other student stuff.

But one of the things I discovered that I had a real passion for at university was gambling, sports betting, and poker, which were becoming popular at the time. In those days, it wasn't online. It was the early telephone and TV-based teletext systems, where you could get live on some sports. And what I found exciting about these was that they were clearly highly structured and patterns. Like in a football game, they had interesting things. You could bet on the time until the next goal or stuff that had a mathematical foundation. And the other thing that I enjoyed was playing poker with-- we had a big poker school, friends of mine. We played all the time. And what that taught me was that gambling is really fun if you have someone else's money to do it with.

CRAIG BOX: Indeed.

ALEXIS RICHARDSON: And then, if you get paid a segment of the rewards, but don't have to be penalized if you lose, it's even better. So that led me naturally into finance.

CRAIG BOX: What led you out of finance?

ALEXIS RICHARDSON: Well, I was very lucky to have a very high-end job in finance very early in my career, surrounded by some really outstanding people, some of whom had gone on to do great things. But what I found really not so cool about finance was that you're always on your own. So you basically sit in front of a screen all day long. And you consume information at an incredible rate, and you process it at an incredible rate.

And part of your advantage is being able to do that better than anybody else, both as sort of mathematics, sort of physics, engineering side of it, and the informal side as well. You're just a massive information machine. And then you make decisions. And then you manage the risks on those decisions for extremely complex financial instruments.

And you can do this without getting out of your chair, which, if you're a lazy person or completely introverted-- very, very nice things. But if you're somebody like me, who actually likes working with other people, likes teams, and likes things that work to impact groups of people as a whole, or if you're somebody who is creative and likes to build things, there's a real limit to what you can build in finance. You can build more complicated financial instruments, but even back in the '90s, I could see that that wasn't necessarily always going to lead us to a happy place.

CRAIG BOX: No. I was going to say, your career in finance was, thankfully, before they invented some of the things for which finance was frowned upon in the 2000s.

ALEXIS RICHARDSON: Well, I was actually privileged to be part of a group that was involved in the earlier version of that crisis. So in 2008, when everything blew up, there was a dry run. I don't know if you know this. There was an alpha version of that, that we went through in 1998, when Russia defaulted on its bonds, and a bunch of hedge funds blew up, and then a lot of other things went wrong.

And I could see, all the patterns that we saw in 2008, we've seen up close at Goldman, when I was there. And yeah, so I mean, it just seemed like this is great, if all you want to do is make money and sit in a chair, making money. But if you want to go and build something cool, that people get excited about, there are many other things you could do.

And so I decided to leave and build computer systems that people in the trading world could use to do what their job was. When I was at Goldman Sachs, I was initially in a group that existed only to do proprietary trading, which is very much as I described. And then there was another group, which is the so-called customer-facing side, where we also had businesses coming to us, saying, hey, we want to do this. We want to do that. Can you trade on our behalf and help us do it?

And what I could see, is as you got more and more customers, the importance of computer systems grew. But the computer systems that were enabling customers to do these things weren't very good. And moreover, the people building them inside the organizations weren't necessarily thinking about the computer systems in a particularly imaginative way. Because in a bank, all the power flows to the people making the money. And consequently, they make very short-term decisions about what the computer stuff should do.

So if you want to really help them, you need to step outside, build things outside as a product, as a software product or a hardware product, and then sell it back to these people. So that's what I decided to do. So that led to founding a company called Metalogic.

CRAIG BOX: Yes, I think that's probably very true of consultancy as a whole. You may have a good idea inside a company. But if you can have someone outside the company that you pay a lot of money to give you that same idea back, you're more likely to have it implemented.

ALEXIS RICHARDSON: That's also true. And I mean, it's doubly so if you have products as well. So I started building software products with other people who felt the same way. And the first product we built was-- and don't laugh, because everybody does this, if you follow this path. We built our own object database. And then we built an application server on top of it.

The idea was that somebody would sit in the front office of a bank and be able to build a trading system or a risk management system or a trade processing system, one of the main things you do quickly by themselves on top of Java application platform, that we provided. And we thought that was pretty clever. Unfortunately, the mistake that we've made was we hadn't fully grasped how deeply the industry had committed to what was then the Sun Java 2EE, engineering mobile EJBs, which you may remember.

I think a lot of people who worked on that stuff went on to write Kubernetes, by the way. But they were overcomplicated and consisted largely of moving parts that only made sense to their designers and not necessarily to the end users. Stop me if this sounds at all familiar.

CRAIG BOX: Somewhat the opposite of microservices, shall we say.

ALEXIS RICHARDSON: Yeah, I mean, microservices came about as a kind of rejection of a lot of that bloatware. And my company also rejected it, because we could see that it wasn't necessary, because we haven't been tainted by that. Unfortunately, what we'd also done for ourselves was created zero route to market. Because there weren't many people who wanted alternative in 2002.

It wasn't until a couple of years later, when Spring came along, people did it. Spring did clever thing of saying, hey, let's work with Java 2EE, but provide a kind of way of making it tolerable, rather than a complete alternative. Anyway, one of the things that happened around then was that people became aware of the importance of open source.

So Metalogic was not an open source company, but we came very close to becoming one. Because our investor in Finland was also an investor in MySQL AB, which was a little known Swedish company that had built an open source database or had formed around this open source database called MySQL. And I spoke to the CEO Marten Mickos, who said, yeah, we'd love to partner with you. But you'll need to release some of your software as open source.

And our engineers just didn't want to do that, because they felt like they really put a lot of effort into building their software and couldn't see why other people should use it for free. So you can sort of imagine those times were different then. So that led me to say, well, I'm going to get into open source as a way of shipping software. And that led on to other companies in the future.

CRAIG BOX: Marten Mickos went on to do many other things. But one of them is that he was the CEO of a cloud company called Eucalyptus. And they had an implementation of the Amazon APIs, I remember. You also ended up getting into cloud soon after this. Tell me about Cohesive Networks.

ALEXIS RICHARDSON: Metalogic did not succeed, for various reasons. And I decided to reboot and did a few things to get into shape and eventually, found a team to work with to build company number two, which was called Cohesive. And originally, I wanted to call it Monadic, which ended up becoming my Twitter handle instead.

CRAIG BOX: Is that a Haskell reference?

ALEXIS RICHARDSON: It's also a kind of reference to the yin and yang symbol, because that's a monad and Leibniz's concept of the essence and other things, too.

CRAIG BOX: Again, a philosophy degree will get you a long way in the tech industry.

ALEXIS RICHARDSON: A long way down a long, dark hole mostly. But Cohesive is like a more mainstream word that means essentially, unified in the essential, like Monadic. So Cohesive became the name of the company. And the idea of the company was to build a open source financial services platform, a bit like what Red Hat did for Linux infrastructure, but around the tools that people were going to use in finance.

And so we ended up calling it FT Financial Technologies. What we found was that there was an incredible appetite in the financial industry to do a shared services open platform. But they were more likely to do it using technologies that had been developed for general purpose consumption and not specifically for finance.

CRAIG BOX: Right.

ALEXIS RICHARDSON: So that coincided with the rise of tools like Spring, Mule, and others. And so we created this kind of assembly tool for taking those things and making them work in a financial services environment, which do things like you would go to a website, and you key in what layers of your stack you wanted. And it would generate for you a machine or a virtual machine that you would then be able to run wherever you wanted.

And that's when the cloud appeared, and we realized that what people could use this for is making cloud-ready application stacks, which was Cohesive's primary business, to begin with. And then, while we were doing that, we felt there was a missing layer of the stack we kept running into, which is the messaging piece.

CRAIG BOX: Yes.

ALEXIS RICHARDSON: Because if you're doing financial applications, you often want messaging. And you don't want to have IBM MQ in your neat, little open source stack. So we teamed up with JP Morgan and some other people on the single AMQP, which became as a protocol like HTTP, and wrote RabbitMQ which was this implementation of a messaging product that could meet that need in that part of the stack.

And long story short, I ended up leaving Cohesive because of that, because I thought Rabbit was going to be a fun thing to do in its own right. And I had to choose between the two companies. And after I left Cohesive, that's when it doubled down on networking, specifically. And for the last 12, 13 years, it's just been Cohesive Networks and has sold a number of really cool products to people who want to basically bridge between the enterprise and the cloud. That's what it's really a solution for.

And it's now seeing quite a lot of business coming through, due to this edge environment that we're hearing about so much in telco. And so that's the Cohesive story. I jumped off the train around 2007, 2008, and just focused on RabbitMQ, which ended up getting acquired by VMware.

CRAIG BOX: And so probably a good choice. Why the name?

ALEXIS RICHARDSON: Why the name Rabbit?

CRAIG BOX: Yeah.

ALEXIS RICHARDSON: Well, I've named a lot of things that I've worked on. Rabbit's another one of them. It's forgotten, but at the time, there was a fashion to name your things after cute little animals, because you'd have a natural sort of identity immediately. Another factor was the JP Morgan influence, because JPM had their own open source stack, called Tigger. And Rabbit is another character in "Winnie the Pooh."

Then there's the idea that messaging is about communication. So in England, at least, we would say rabbit, rabbit, rabbit, for somebody talking too much. That may also be true where you're from originally. And so that was another reason. So they talk a lot.

And then the last reason was, we're used to the idea that there are lots of rabbits. We don't really think of one rabbit unless we are looking at a GIF of a very cute white rabbit with furry pink eyes and big ears.

CRAIG BOX: Where I'm from, rabbits are a problem that we address with shotguns.

ALEXIS RICHARDSON: I'm coming to that. So then, actually, normally, people think about rabbits as being very numerous and living in warrens. And in some parts of the world, they don't mind about eliminating some of them, if they're not necessary anymore.

And so we sort of accidentally stumbled upon the concept of pets, versus cattle there a little ahead of time, because we wanted our rabbits to be things that were more disposable than the highly precious, expensive IBM server that you bought, where you'd be shot if you shot it. But of course, in the earliest Rabbit, we would do things like run them on-- I can't remember what they were now.

But there was the predecessor of the Raspberry Pis. There was something else that you could buy in about 2008. It was a tiny, little computer the size of a cigarette packet.

CRAIG BOX: The BeagleBoard?

ALEXIS RICHARDSON: Not BeagleBoard, but something else like that. And we would have engineers dressed up in white coats, wearing big goggles. And we would have an array of these things all networked up, and they would all be rabbits in a cluster. And we would have a screen showing messages going through. And then we would get the hammer out and start whacking these things, to prove that, you know-- [LAUGHING]

CRAIG BOX: Again, it's Something we used to demonstrate Kubernetes in the early days-- very similar.

ALEXIS RICHARDSON: Right. I mean, and it still happens when you unleash the wrong people in the marketing channel.

CRAIG BOX: I asked you before about functional programming. That was sort of to query the fact that RabbitMQ was written in Erlang.

ALEXIS RICHARDSON: Yes. The story there is, that while I was in Cohesive, I was renting space in the offices of a company called LShift, which is a London company nearest to the roundabout, a small consulting agency that was ahead of its time in terms of picking up a lot of the techniques, we now take for granted, around how we deliver products and what it means to be a developer. And the founders are friends of mine, and I saw them often.

So it was natural, when we started this distributed Cohesive thing, for me to ask to use their offices. Because the other team was in Chicago. And that went great. And then I got hold of the specification pre-release for AMQP, which was given to me by the JP Morgan team.

And I gave it to Matthias, who was the CTO of LShift. He sat a few desks down from me. I said, hey, Matthias, this is something that I think could be quite interesting. And he said, yes, Alexis, then opened his bottom drawer, and placed it in there, and then closed his bottom drawer, and then carried on answering the email that he was doing before I'd interrupted him.

Anyway, some months later, AMQP was officially launched. And my memory of that day is that I was also doing something else. And then suddenly, Matthias materialized at my side, which is something that he would want to do, using some sort of puff of smoke, and then he would appear. And then he was holding in his hand the documents. And he placed it on the table, and he said, Alexis, this AMQP thing, I think Erlang might be a good language to implement it in. But i don't know if anyone would actually use it. So I said, OK, let's find out. So we did.

CRAIG BOX: Yourself and WhatsApp are perhaps the only two Erlang case studies I can think of off the top of my head.

ALEXIS RICHARDSON: Well, the one that the Erlang community constantly loves is ejabberd. Rabbit is not particularly well known in the Erlang community, because we didn't really go to any conferences. And we just kind of did our own thing.

We ran a prototype. A gentleman called Matthew Sackman, who works at a company that I'm blanking on the name of, near you in West London. And he demonstrated some nice throughput latency availability properties in the prototype. And we took those to JP Morgan, and we said, look, you've got this AMQP thing. If we wrote an implementation that was written in this funny language, but had decent properties like this, would you use it?

And they basically said, the whole idea of the protocol is it shouldn't matter how it's written, so long as you speak the protocol correctly, which was nice of them. I think that may have been a slightly misleading answer. But we said, OK, fine, we'll just write this thing.

So then I think version one of RabbitMQ was written mostly by Tony Garnock-Jones, a New Zealander, now living in Holland. And that was released February of 2007, I think, or 2006, ages ago. can't remember. And the fact that it was written in Erlang was considered by people on the West Coast to be a cool thing for a few years. So that helped us to get attention from people like Heroku Engine Yard.

And in the US, people would say, look, this thing does what we need, which is to scale our websites. So they were writing early stage paths. And the reason it's more bombproof than the crappy middleware, that you've heard of from IBM, is because it's written in Erlang, which is this famously five 9s, six 9s, or somebody foolishly had said this at some point in the past, tool for availability in telco.

And so we thought, OK, we'll take that. We'll accept this piece of free, generous marketing from the community. And reality is that Erlang, if misused, is no less deadly than anything else. But it was quite cool.

And I suppose the interesting part is, that in Erlang, some people wrote something called the Open Telecom Platform, OTP, which is basically all the things you need in a distributed system to make it work reliably and available. It was basically a very, very early version of a Kubernetes back in the '90s, using this strange alien tool, thinking about the use case of telco switches. And when we get to the AMQP stack, and we went through it with some friends who knew Erlang, they said, the Erlang language design follows a lot of the patterns we see of telco switching exchanges. And AMQP also follows those patterns.

So actually, you've got a really strong design affinity between the messaging problem you're trying to solve, which is integration, Pub/Sub queuing and scaling, and where the language in the platform has come from. So that gave us a lot of confidence that we were going to do OK. And people are still using it today. So I guess it works.

CRAIG BOX: RabbitMQ was acquired by VMware in 2010. The company Revit Technologies, that you worked at, was behind that.

ALEXIS RICHARDSON: Yes.

CRAIG BOX: What was the problem that they wanted to solve with a Message Queue system?

ALEXIS RICHARDSON: Well, it was the same as the one we'd started Rabbit to solve.

CRAIG BOX: Was the problem that they had to sell the IBM equivalent to their customers?

ALEXIS RICHARDSON: Yes. So basically, the reason we started Rabbit was because we saw a gap in the stack for an open source middleware product that was modern and could solve modern problems and had some certain properties. And VMware acquired SpringSource, because they wanted to compete with IBM and Oracle for Application Platform business. And remember, Oracle had acquired BA or Blodget not too long before that.

And so they thought, Ah, OK, this Amazon cloud is going to be a really big deal. But VMware has existing cloud providers among its customer base, people like Verizon. So what we will do, instead of having our own VMware cloud, is we will release an application platform that can run in the cloud. And then we'll have a global PaaS business.

And they said, this will be used by developers in the enterprise. What is the most popular tool for developers in the enterprise? Java or .NET Well, .NET, we can't do, so we're going to do Java instead. So that's acquired SpringSource. And SpringSource said, if you want to do this, you need a full stack. So you also need to have a messaging product, and you need to have a caching product.

So Gemfire, which is made by Gemstone, was acquired and RabbitMQ. And we formed this company Rabbit Technologies, the corporate vehicle of Rabbit. That was acquired, as well, and brought with it some people around it, too. And then we all ended up in the application platform division at VMware in 2010, when Heroku was taking off. So that was kind of a fun time.

CRAIG BOX: You worked there for four years ending up at Pivotal as their head of product for Spring and app platform. Were you able to do all of this based in London?

ALEXIS RICHARDSON: Yes. Although I will say that it's harder to-- it certainly was a lot harder then. I mean, I do think it's got a lot easier to drive a group that's spread internationally. If you're working for an American company, you may have run into this yourself, Craig.

CRAIG BOX: Very much so.

ALEXIS RICHARDSON: At some point, there's this sense of, well, if you're not in the right building, in the right corridor, in the right office, at the right time of day, then you will never get taken seriously. Because you're competing with other people who see the CEO every day-- visible, audible, probably other things as well. So that was definitely quite difficult.

It was probably made easier by the fact that the teams of engineers and products that I was in charge of, which were Rabbit and Redis, other open source things around OpenStack, that we dabbled with at VMware, plus Spring, Tomcat, and this thing called V fabric. The bulk of the team working on all this stuff was actually outside of California. And in many cases, they're in Europe. So that did make sense.

CRAIG BOX: Were they with you in the UK?

ALEXIS RICHARDSON: There were many Spring people in the UK, because the origins of Spring were one engineer in London and one engineer in Austria. Yergen, who's still there. And then there were two more engineers. Rob Harob is now at Excel and another gentleman, who I can't remember the name of. And that was when it's called Interface 21.

And then SpringSource was formed. And SpringSource's first office was in Southampton, because somebody joined from IBM, Adrian Collier, that you probably know. And for a while, there was a bit of a center of gravity there.

But then when SpringSource became really successful, it was when they moved to the US. And they have an office in San Mateo. So when the acquisitions happened, everybody consolidated all the business folks in Palo Alto. But the engineers were still distributed all over the world, including a lot in Europe and the UK.

CRAIG BOX: You mentioned Matthias Radestock before, who was one of the co-founders of RabbitMQ. You and he then went on to found Weaveworks And Weaveworks is one of the earliest startups that I recall in the Docker and Kubernetes space. First of all, the thing I didn't remember is it was originally called Zettio. What happened to that name?

ALEXIS RICHARDSON: I mean, that name was dead. We left Pivotal, wanting to do a new company that was focused on enabling developers to make apps that operated. We weren't quite sure what that would mean, because the world was changing very, very quickly. But we knew the containers would be central to it.

We decided that a network would be the first thing that we would roll out, because we had seen some evidence that networking was useful for building containerized solutions. And we needed a name that suggests a scale and that could have websites. So I was thinking about zettabytes and zettabyte era. And I suggested Zettio. And that wasn't a bad name. It just was ugly. It didn't mean anything really to anyone.

So when we started working on the software, we then had the Zettio name, which we'd come to fairly quickly. But we'd had more time to think about the name of the software. And I'm a very big believer in things having simple names that you use in regular speech, which is another factor in Rabbit and some of the other things that we've talked about.

And I liked Weave as a name of a network. Because you just say Weave all the time. We've just gone out in the sunshine. We've decided to sack you. We've all gone home. Or we'll see you in the pub. We've just started ordering-- all of these things. And it's also, of course, a mesh.

CRAIG BOX: Well, I could have understood, like, Weave, as in weaving containers together and the mesh story, and so on.

ALEXIS RICHARDSON: Well, that, too.

CRAIG BOX: But it's like the We in Nintendo. It's got this global name, but it's very inclusive. It's we. It's we've. It's the past tense of we.

ALEXIS RICHARDSON: All of those things went through my mind. And I very clearly remember walking around, walking my dogs, in Hampstead heath where I was visiting some friends. And I had a thought. This is a good name. We're going to call it Weave.

And then after that, I got a phone call from James Governor of Monkchips. And I said, "I've just thought of a name!". And James says, "I've just thought of something else!". But I remember that moment very clearly. So Weave was definitely a good name for a network.

So we released Weave, and we had a little bit of a PR push around it, not much. What we found was that, as with all these things, timing really, truly is everything. And we'd just brought this open source solution out just at the very moment when the largest number of people so far had decided that they were really pissed off about Docker's lack of networking. And suddenly, this thing appears, and it just works. So we just got this uplift of interest.

That was a very, very double-edged sword. Because on the plus side, I got phone calls from American VCs for the first time in my life, offering to fly out to London to talk to me, which had never happened with any previous companies. On the minus side, it took us a long time to shake off the idea that networking was the thing that we thought was the most important thing, when it was just-- we just thought it was a building block to an application and that sort of platform, DevOps environment.

And I could see that Zettio was a crappy name, and Weave was doing much better. So we decided to brand the company around Weave. And so we had the other classic of picking your domain name, which anyone starting a company has been through. Luckily, there was this TLD opening up with ICANN around that time, which you probably recall. And suddenly, it was possible to have--

CRAIG BOX: Weave.info.

ALEXIS RICHARDSON: Weave.info. Weave dot anything. So we ended up with dot works and the fact that I was in the offices of Shoreditch Works at the time and was thinking of Hortonworks IPO. And ThoughtWorks maybe probably not so relevant.

CRAIG BOX: Some good synergy.

ADAM GLICK: Anyway, so Weaveworks is the name. And then we've got Weave.works is the website. And off we went. I think, later on, looking back, I would say, I'm not sure if that was the optimal sequence. What we should have done is probably either had a different name of the company and then individual product names or something else. What we did in the end wasn't quite right, because it caused a lot of confusion.

Because people would say, I don't want to use your Weave cloud SaaS product, because I'm using Calico, or I'm using the Amazon provider network. And so you spend years and years and years building a product for managing and monitoring containerized applications, which has got nothing to do with networking. And somebody says, I don't like your network, so I'm not going to use it, which is like, if your marketing person would want to sack people, he'd come up with that strategy, I think. So yeah, it's a double-edged sword. We were just too successful around that name early on.

CRAIG BOX: We've enjoyed your working with us, but we've decided to make a different choice at this point in time.

ALEXIS RICHARDSON: And you get it three times. You said it.

CRAIG BOX: What was the state of the industry at the time? This is just after Kubernetes has come / and you mentioned Docker doesn't want to deal with networking. One of the things that I remember as being a catalyst for people adopting Weave was the need for some kind of overlay network, in order to connect to their nodes, to be able to give individual IP addresses to every pod in the new Kubernetes environment, which was unheard of at the time.

ALEXIS RICHARDSON: And still very, very, very important and useful-- indeed, there are many people still using Weave nets. And we still have a small maintenance effort on it, because it's basically a done product at this point. And the stats we get from users is just incredible. It's just great for the use case it was designed for, which is I want to build apps out of networks of containers. I don't want to think too hard about how those networks come together.

But what we've also seen is other generations come through of networks that, if you like, are slightly deeper design philosophies, like Cilium, which has designed an entire stack around eBPF, which is very interesting, and also, Calico, which had a different philosophy towards how addressing networks would come together based around reusing L3.

CRAIG BOX: So given that Weave was a company set up to be developer-focused, and as you say, networking was really only sort of a means to an end for you, would you recommend someone who is building their own Kubernetes today look at using Weave Net? Or do you think that it's run its course?

ALEXIS RICHARDSON: No. There are still great use cases for Weave Net. I wouldn't tell people not to use it. I'd say, though, it's best if you want to have a easy set-up experience and if you want to have a very reliable network. But it's got some scale limitations. So if you've got 100 hosts or maybe up to 150-- not containers, not hosts. You could have thousands of containers. That's probably pushing the limits of what Weave Net can do.

And it's really great in an environment where portability matters. So if you want to have the same implementation for your dev, test, and prod, laptop, dev cluster, and Amazon in all one network, Weave Net is spectacular at solving that problem. It's also really good for some edge environments, because it does a lot of work for you in terms of network address translation, tunneling, security, and general other gotchas and hybrid setting up scenarios. And it's more flexible with regard to topology.

So we see people using it with devices in IoT type cases. Where I would say it's not the best choice, for example, is once you've decided I'm going to commit to running on Amazon, or I'm committing to running on Azure, why would you not just hardware into the local cloud network? The overlays of today are NET and Calico and a few others, don't have that much extra overhead. But there's still some, and you could just go straight onto the cloud providers network.

Of course, Google is famous for talking non-stop about the high quality of their network. You probably wouldn't want to put an SDM on top of that, unless, as I say, you had a strong reason for portability. So that's probably not the time to use it.

Very large networks is another. I mean, it's really designed for-- so there's a certain model of applications that I think is really important. And Weaveworks believes it. But not everybody believes in this. So our belief is Kubernetes is really an application server.

And you can understand how somebody who'd work on Spring and Tomcat might think this. But I say this not because there are other use cases. There are. But it is not an alternative type of stack. Kubernetes, actually, for example, doesn't have a very good multi-tenancy solution. When Kubernetes first appeared, many people of a certain type said, it's going to follow the same trajectory as OpenStack. And therefore, we don't necessarily need it, because it's a private cloud.

They didn't obviously look very closely at Kubernetes, because one of the things that Kubernetes conspicuously is not very good at is multi-tenancy. And how can you possibly build a big private cloud without multi-tenancy? And I think, if you looked closely at Google, you'd realize that they didn't have to follow the same rules as other people with regard to these things, which is why design number one didn't have it.

And we now have solutions, of course. But actually, people have realized, that if you can start a cluster easily, and you can shut it down easily, it's a lot easier to associate multiple clusters with multiple teams than to have everybody on one big shared infrastructure, where, if somebody blows up, they can cause other people around them to share their fate, unless you have an SRE team that's amazing and can set up a platform that can deal with that.

So if you're a GKE or some other competitors today, I believe those teams know how to deal with exploding clusters. And they can minimize the blast radius. But if you're JP Morgan or Tesla or somebody else, you've got fantastic technologists, but not necessarily people who could know how to run GKE scale, GKE clusters. It's just a lot easier to say, let's just have lots of little clusters, and then we'll have the ephemeral clusters, that are like cattle; we can have small clusters on the edge; or we can have bigger clusters in the center. Some of them will be shared, but we won't assume that they're all on one just colossal shared infrastructure.

And Weave Net was designed for application owners to own their network on that cluster. That's why it doesn't try very hard to have a large network. It basically assumes I'm a developer. I need an app. I'm just going to not care about how the cluster and the network came to me.

And of course, you can solve that in two ways. You can go to a massive service provider like Google, and they know how to set that up for you on their cloud. Or you can do it yourself. And if you do it yourself, Weave Net's a fantastic solution for that.

And Flannel is quite similar, actually, a small-scale network for DIY use cases. And so I think that those use cases will continue. And therefore, Weave Net's use cases will not go away. What I would like to see happen with it is I'd like to see more integration with tools like Cilium and Calico, so that the benefits of those networks can be more seamless for people who start out with simple dev clusters using NET. And then they might want to migrate to larger environments or some things with additional properties, like you get with Cilium.

CRAIG BOX: All right, Alexis. This has been a fantastic conversation. It's running long, so what we're going to do is bring you back next week, if that's OK, and learn a little bit more about GitOps and Weaveworks.

ALEXIS RICHARDSON: Look forward to seeing you in a week, then.

CRAIG BOX: Until then, please look up Alexis on Twitter at Monadic or on the web at weave.works. You'll hear the rest of our conversation next week.

[MUSIC PLAYING]

CRAIG BOX: It has been a singular and unique pleasure to have you as my April Fool's Day guest. Sadly, I guess that means you won't be back next week.

ADAM GLICK: Very sad indeed, but I'm very glad to be able to come back and guest host and also, say hi to all our old friends in the listening audience.

CRAIG BOX: If you enjoyed the show, please help us spread the word, and tell a friend. If you have any feedback for us, you can find us on Twitter @KubernetesPod, or reach us by email at kubernetespodcast@google.com.

ADAM GLICK: You can also check out the website kubernetespodcast.com, where you'll find transcripts and show notes, as well as links to subscribe.

CRAIG BOX: I'll be back with another guest host next week. So until then, thanks for listening.

ADAM GLICK: Take care.

[MUSIC PLAYING]