Alexis Richardson is one of a kind and truly unique and wonderful personality in the Cloud Native space. In this episode of the POPCAST, Alexis talks about his journey from university to goldman sachs to co-founding not only weaveworks but the CNCF. Alexis does this with wit and with his signature candor, you are all in for a treat!
This episode brought to you by:
***CIVO***
Civo is an alternative to the big hyperscale cloud providers.
They've launched world's first managed Kubernetes service powered by K3s.
With sub 90 second cluster launch times, a simplified Kubernetes experience,
and predictable billing, Civo is on a mission to create a better developer experience.
Get $250 free credit to get started. Sign up today at https://civo.com/popcast
***Sysdig***
Run Confidently with Secure DevOps Security for containers, Kubernetes, and cloud. Learn more and sign up for an upcoming webinar here: https://www.sysdig.com
***Styra***
Learn how to operationalize Open Policy Agent at scale with Styra (click this link): https://hubs.ly/H0Pnkm20
***COCKROACH LABS***
Discover @CockroachDB the most highly evolved distributed SQL database on the planet.
Kubernetes-native and built from the ground up to help companies of all sizes including Bose,
Comcast, and Equifax scale fast, survive anything, and thrive everywhere.
Sign up for a free 30-day trial and get a free t-shirt at https://cockroachlabs.com/popcast
Timeline/Topic
00:00 -- Check out sponsors
00:06 -- intro
00:15 -- Introduction to Alexis Richardson CEO Weaveworks
01:30 -- Alexis' Journey
03:18 -- Ludwig_Wittgenstein, Poker, and Sports Betting and Finance
15:15 -- Open Financial stack and rabbitmq
21:44 -- Starting Weaveworks
24:40 -- Pivoting to Kubernetes, Prometheus, and Cortex.
28:44 -- Flux and WeaveNet
29:29 -- Helping to found the CNCF and the first TOC.
35:33 -- What you would do different? Weave and CNCF
37:25 -- What work is Alexis most proud of?
Episode Links
Weaveworks - https://www.weave.works/
Flux https://www.weave.works/oss/flux/
Alexis on the CNCF's growth: https://www.enterprisetimes.co.uk/2019/05/20/alexis-richardson-on-why-the-cncf-is-growing-so-fast/
Weaveworks funding round: https://www.weave.works/press/releases/weaveworks-raises-36-million-ser
Alexis Fav Philosopher - https://en.wikipedia.org/wiki/Ludwig\_Wittgenstein
POPCAST SHOW DETAILS
YouTube: https://bit.ly/3xgmmCj
Audio Podcast (Apple, Spotify, and others): http://bit.ly/35MXfte
Follow us on (Twitter): https://twitter.com/PopcastPop
Follow us on (Linkedin): https://www.linkedin.com/company/the-popcast-with-danpop
- [Narrator] This episode is brought to you by these sponsors.
- Hello, everyone, and welcome to the POPCAST. I got a dear old friend. This is Alexis Richardson. He's the co-founder and CEO of Weaveworks. Welcome.
- Thank you, Dan. Nice to meet you in person for the first time.
- Oh, so I can't play up the fact that we're old friends? No? Okay.
- How long have we known each other? Not too long. Did you join Sysdig this year or how-
- Four years ago.
- Fantastic. I've seen your podcast everywhere, so I guess that's great.
- Thanks for being on the show. First, I want to congratulate you on the funding. This is airing in probably sometime in February, but again, really wanted to congratulate you all. I'm such a fan of you all, and so very much awesome. Congratulations to you.
- Thank you very much, indeed. We feel very proud that the team has pulled together through what's been quite honestly a very difficult year for everybody with many customers losing their way due to the situation with the pandemic, and I think that everyone's found it very hard, but I think we've managed to find a way through and looking forward to hopefully better times in '21.
- Without a doubt. Without a doubt. Let's talk a little bit about your journey. What's the first time you picked up a computer and said, "Wow, I love this and I want to make this somewhat my career"?
- I hate computers. I've never been a programmer for money. I'm more of a kind of, I guess when I was at school, I did subjects like mathematics and science and art, so there's this all things that kind of, and languages, actually, all things that people who are real programmers have done, and I studied philosophy at university, which I highly recommend, but no computer science until right at the end when I finished my degree and I stayed on to do a master's in computing, and I only did that because it was cheap because the government was spending money to try and encourage people to get into computing in the early '90s and trying to get people to go from being arts graduates into computing, so I did this kind of conversion course, which taught me absolutely nothing useful about computers. I learned about, everybody makes jokes about something called Haskell. Well, before Haskell, there were a load of equally more perverse languages like Orwell and Miranda that you've never heard of and you never will for good reason, and some really other crazy, terrible things, but I did learn that I might be able to have a career using computers. I'd first touched an Apple in 1977 or 8. It was a mystical object at my school. I was eight or nine years old. I was born in '69, so you can do the math, and somebody got an Apple II. Do you remember those computers? And me and a friend were the only people who used it, and he was the one who got really interested in computers and went and worked in the Apple shop and I was just the guy who hung out with him and we tried to write BASIC adventure games together.
- Can we go back to the, let's go back to the, let me ask you this. I want to go back to the philosophy thing. Did you have a favorite philosopher?
- Yeah, I guess everyone has a favorite philosopher. Not really, but yeah, I think Wittgenstein for me was the philosopher that I'm most excited to have studied, and the great thing about Wittgenstein is there's two of them. People talk about the early Wittgenstein and the later Wittgenstein and they say completely opposite things, but one of the things that I like about Wittgenstein, the later Wittgenstein, is he talks a lot about culture and that's something that, something very interesting to me at the moment.
- Gotcha, and so I'm sorry to cut you off. We end Apple. We're learning archaic languages we give zero craps about, so then what happens next?
- Then I decided to go work in finance, and I guess the bit that's missing from the middle of that is I stayed on after I did my master's to do a PhD in proof theory, and I started writing theorem provers, which are like these things for doing what are now called proof assistants, where you have a mathematical proof and use a computer to help you discover it, and that was what my master's thesis was in and I stayed on to do a PhD in that and kind of drifted into pure maths from there, and while I was doing that, I developed a serious interest in poker and sports betting and I found that very interesting and a lot of fun and occasionally a little bit frightening, and then I discovered that you could do the same as all of this with someone else's money if you went into work in financial services because they would give you some money and then if you were successful making money out of that money, you would get a piece of that, and if you were not successful but they liked you, they would let you keep your job. This is what's called the trader's option. Basically, it's no-lose unless you really screw up. I thought this sounded incredibly appealing. I could go gamble. I could do mathematical sports betting with a big pot of cash if I found the right job. I think a friend of mine got a job at Goldman Sachs and I then thought I will apply for a job here too and ended up working there in the prop desk, and what was cool about the prop desk, which would now be called a hedge fund, is that it was a very small group that was full of people who had a mix of skills, including math, science, trading and computers, and we all wrote our own code, so basically like a group of amateur scientists in the 1940s, and we had written masses and masses of computer systems, which were cutting edge for 1997, '98 at the time, so I learned a lot about the value of having the right tools to make money in finance, and then there was a market crisis, Russia defaulted and there was this hedge fund on term capital that blew up and the market nearly collapsed, as it did in 2008 eventually, and so they wound down all the high-risk businesses and asked everybody to go into the low-risk businesses or what we call the flow business, which is where instead of risking the bank's own money, the partners' hard-earned savings, instead you do deals on behalf of customers. A big pension fund will come and say, "Hey, we've got too much long-term risk and we've got a bit of excess short-term risk. Can you rebalance our portfolio for us?" And you do those big deals and it's relatively straightforward and you take advantage of being a big player and that's how you make money, essentially, and what I saw there was the issue of scale. Suddenly we'd gone from being in a small team, but everybody was a top dog in something, to being in a machine. There were thousands of people on every floor in London, New York and the other big offices all doing small jobs in this big environment, like in a factory, and you could tell that although there were some star performers and outstanding people and some assholes and some nice guys and everything else that you get in large organizations, if anybody was fired that day, the machine would just keep going 'cause it was a machine. It was much bigger than any one individual, no matter how important, and it was powered by information and execution and money and computers, and so I thought it was a inspiring thing that you could see that computers were gonna be the thing that drove all this in the future. I decided that I would leave and go work for myself, 'cause I didn't really like working for other people, and do a startup and build computers to solve-
- Can we double-click on that? Let's talk about it. Basically you, is this just you wanted to be able to stake your claim and do this? You didn't like, I guess, it's not so much a bureaucracy thing, you just didn't like to be able to be fenced down and be able to create your own thing. Is that the reason why you just were like, "Hey, I'm done with this quote, unquote sports betting in finance"?
- No, there's lots of factors, like first of all, in my first job, we were very autonomous and could do a lot of exciting, creative stuff. The second was a bit less creative, a bit more mechanical, and the creativity was much more on the sales side, which was actually really fun, but the actual work that I got paid for mostly involved staring at a screen all day long on my own. There were lots of other people sitting around me, but you can feel pretty lonely in a room full of shouting people, like you can feel lonely on the train, and you have these friendships with your colleagues, but they can feel a little superficial in financial services for some reason, and you think, "Well, hey, could I be doing something more with my life? What if I could actually make something instead of just sitting here pushing little tokens around?" Which is basically what you're doing. I thought it'd be more interesting to create things. I also didn't want to have a relationship with my organization that was mediated through political matters. I liked the idea of working with others and for others but on a transactional basis, that we would do things based on agreed outcomes and we would sell things and get paid money, but it wouldn't be the case that we would have to spend a whole year brown-nosing the boss, no matter whether you like that person or not, in order to get paid at the end of the year, and unfortunately, the system in financial services then, and somewhat still today, I believe, is what they call a bonus culture, where you've got a base salary, which is usually pretty good in finance, and on top of that, you get your bonus, which is tied to your performance, and your performance turns out not to be tied to just your performance but also how your boss feels that day, so it's kind of a different environment and it's much more fun working for yourself.
- What you build and where it takes you shouldn't be limited by your database. CockroachDB helps developers build and scale apps with fewer obstacles, more freedom and greater efficiency, so you can forget about the database and trust that it just works. Kubernetes-friendly, open source and indestructible, CockroachDB makes it easier to build and scale apps. It gives companies the freedom to serve customers anywhere and it's backed by world-class documentation and excellent dedicated support. Discover CockroachDB, the most highly-evolved distributed SQL database on the planet. Kubernetes-native and built from the ground up to help companies of all sizes, including Bose, Comcast and Equifax, scale fast, survive anything and thrive anywhere. Sign up for a free 30-day trial and get a free T-shirt at cockroachlabs.com/popcast. That's C-O-C-H-R-O-A-C-H-L-A-B-S dot com slash P-O-P-C-A-S-T. No doubt, and so, okay, you striked out on your own. What was the first thing, but obviously way before Weaveworks, what do we do first?
- I did this company, sort of ditched around a bit and ended up doing this company called MetaLogic, which was co-founded by a couple of Finnish guys, one of whom essentially had the same background as me. He'd gone to Goldman from MIT then ended up at Credit Suisse, wanted to strike out on his own and we ended up working together, and a couple of other folks as well with a terrific engineering background from the incredible Finnish technology schools, and we built what we would call a front office app server. It was basically the world's first Java POJO app server. We didn't know any of this at the time, but it was also a really, it was a good example of not product market fit. It really solved actual problems around people building gaming applications, online trading systems and other things, and the vision was that even somebody who just learned Excel could learn, it was as simple to program as writing Excel spreadsheets, and you could just do basic Java that you learned from a book that you could buy in the shops. None of this Enterprise JavaBeans shit. The problem was that what the market had already decided was the Enterprise JavaBeans shit was the way to go, and we did some other dumb things, like we baked an object database into our product, which never, ever, ever bake an object database into your product. That's one of the primary rules of middleware, by the way, and everybody I've met who's worked in object databases agrees with this truth that you should never write or use an object database inside your product, or don't talk about it. If you do, it's top secret. I don't know if you know this, but Microsoft Outlook has an object database, by the way. That's why it's so shit.
- Yeah.
- Yeah, the upshot was that we had a great technical team but a classic inability to find the right spot in the market, and we saw other people being more successful with better products, like Tangosol, which was built with some of exactly the same designs in mind, ended up getting bought by Oracle, is still part of the Oracle stack as Coherence. Great product. Didn't have an object database but had a lot of the same technology in the in-memory layer and worked in a very similar way that was tuned into the Enterprise Java world in a way that we just weren't, and Spring did the same thing. They reinvented Java around POJOs, but they made it something that Enterprise JavaBeans people could understand and use, whereas everything that we did just didn't seem to fit, so we really struggled.
- Gotcha, and so, again, let's talk about, okay, we created this software and then where does this go into what happened with starting up Weaveworks? I want to understand that transition from, hey, we started this and then you saw cloud-native and you were like-
- MetaLogic, what happened was that we nearly got bought by one of the large players 'cause we got pulled into help build them some really cool technology, and then that fell through and so the company fell apart. I started another company called Cohesive, which is still going, Cohesive Networks it's called. It was called CohesiveFT at the beginning and we decided to build a open source financial services stack. This is in about 2005, and while I was doing that, we decided to create another component called RabbitMQ, which RabbitMQ, again, because there's no open source middleware in the market for messaging that was really good. There was ActiveMQ, but that was very Java and there was nothing for other languages. We wrote RabbitMQ with some other people and that ended up being difficult for me 'cause now I was the founder and MD of business development at Cohesive, as well as being the founder and defacto CEO of RabbitMQ. I had to decide to do one or the other 'cause they were both growing, so I quit Cohesive and just focused on RabbitMQ for a few years.
- I need to cut you off. I want to talk to you about that. Let's talk about RabbitMQ because, again, I was at a time when there was MSMQ and all these other things like, and there was, RabbitMQ came in and everything changed to me. It was like everything was now in this, everyone wanted to use it and it was adopted very quickly. That's gotta be a feather in your cap, man. That's awesome. Starting something that is, as you're doing with Weaveworks, as you've done with the CNCF. Talk to me about the beginnings. What problem were you all trying to solve with RabbitMQ that you saw?
- We wanted to have a financial stack and everyone in finance builds messaging and integration solutions all the time. Even things like trading systems use messaging and market data uses messaging. It's fundamental to pretty much any financial services app, but everyone was paying a tax to IBM for MQ or TIBCO Rendezvous or if you were unlucky enough to be doing .NET, to MSMQ, and there were a few things out there, like ActiveMQ, but they weren't widespread. They couldn't do everything. They were just tied to one language. What's the point of doing integration if it's tied to one language? Somebody at JPMorgan called John O'Hara decided they could save the bank money by getting a bunch of people together across the industry and writing down a definition of messaging, like HTTP, that could just be an open standard anybody could implement and then inviting companies to implement it, and Red Hat put up their hand and said, "We'll do this," 'cause they wanted to have a messaging product to compete with IBM, and so did we and we were this funny little startup that happened to know these JPMorgan guys 'cause we're all in the same part of London, and I said to them, "Look, hey, if we did an independent product that could do this, would you buy it?" And they said, "Well, if it's good enough, sure, why not?" And the point, this is the whole point of the standard, is to make it something anyone can do. We wrote it and we started getting customers for it and then we had to find a way to distinguish ourselves in the market against Red Hat, much bigger company. We decided to do that by going after what I call, basically, your hipster use cases, so Ruby, Heroku, the cloud, even things like .NET, JavaScript. All of these new use cases that weren't traditional enterprise. We thought that what was gonna happen was that people would want to build scalable applications because they would build businesses that would need to grow and so messaging is a tool for scalability as well as integration, and we found that, yes, indeed, if we talk to the right people, they would build apps and tell their friends in San Francisco, "Hey, look at what I can do if I have a messaging product." That was very, very valuable and that proved the market, and then the second phase was, really, you mentioned MSMQ. We just worked really hard to add, through the community, a client in every language so that you could write an app and you could have .NET talking to Java talking to Ruby talking to Python and then it just becomes a universal tool in your box, so that's what I think-
- I worked on a portfolio management system called Geneva for this company called Advent and it was basically when every hedge fund was using this as a tool for portfolio management of trades and all of that fun stuff and positions. RabbitMQ came into play and everybody revamped. It was like every one of the folks at the hedge fund were like, "Okay, I'm gonna use this," so that's what I'm saying. There's technologies, like containers, like Kubernetes, like things that are happening with GitOps, which we'll talk about, that basically change the game, and it's awesome that that was what, to me, RabbitMQ changed the messaging game. It was like, "Okay, now we're gonna open source this. We're gonna go against the giants." It was a David and Goliath type of thing, and so again, props to you on that. That's fantastic, man. Sorry, were you finishing a thought there?
- You were talking about what am I proud of . You asked about the things that I'm proud of earlier on and we went to see, the IBM guys invited us to come visit them in Hursley and they said something very, very, very, very nice to us, which was, "Congratulations, you've won," and I said, "What do you mean we've won?" He said, "You've done all the cloud messaging stuff. It's great. There's nothing we can do at this point." We thought that was very, very, very generous of them. Then we went and we got acquired by VMware because VMware had hired this guy, Paul Maritz, who was a famous Microsoft NT guy. His job was to re-energize VMware for the cloud era and that's what he tried to do by having a public cloud. That wasn't quite the right strategy, He decided to go after applications and acquired technologies that people used to build apps. He acquired SpringSource, which was the company around Spring, the Java app framework, plus a couple of other technologies, like RabbitMQ and GemFire and a few others, and then we brought Redis in with us because we'd been doing quite a bit of work with Salvatore at Redis. Rabbit and Redis came into VMware at the same time. For a while, I was responsible for that, and then Pivotal started and everything got refactored into Pivotal, so I ended up being, running the Spring team for a whiles, had a product, and that led to a fun innovation, the second era of Spring Boot and Cloud, which was a very, very exciting time with lots and lots of different people contributing all at the same time to what ultimately proved to be pretty cool success, and then after that, I left to do Weaveworks in 2014.
- When starting Weaveworks, again, what were the initial problems you were trying to solve with the first couple of solutions that you all came out with?
- We'd spent time at Pivotal trying to build cloud services, things that didn't fit into the 12-factor Heroku model but would run in the cloud, like Rabbit as a service or Redis as a service. In fact, we'd been building Rabbit as a service since 2009, and we just learned a lot about some things that don't work. By 2014, we were pretty clear in our minds that containers were really key to the solution and that if you could have a container, then you could take the software in your container and combine it with software in other containers very efficiently to build larger applications that would run in the cloud in the right way and have the right properties in terms of startup time, portability, manageability to build complex things like Rabbit as a service or Redis as a service. The problem was that if you looked at Docker in 2014, there was no real way to build a whole app out of Docker components, and we'd also try to do this with VMware vFabric. We tried to have VMs as the components and that's a really clunky way to build apps, as it turns out, so Docker was gonna be better, but there were so many things missing. We decided to form a company with the goal of making it easy for developers to build apps and operate them out of containers by filling in the gaps, were missing, and that was a great, simple vision, except for the fact that there was so much missing technology that it was almost impossible for any one individual company or even product segment to fill in the gaps, and it was a much bigger evolution than we could bite off. We started off building a network and then we started building a tool to show your application what it looked like if it was in a network, called Scope. You could use Scope to visualize and then manage and interact with your app, and we realized that to manage it, you'd also need to monitor it and everybody said you need metrics on here, like the error rate, the latency, the request rate, and we were talking to the Prometheus people because one of our team was ex-SoundCloud. Went to see them in Berlin, loved them, thought Prometheus was a great tool, thought it could go into the CNCF, started using it at Weaveworks. Then we built something called Cortex, which is, Amazon launched Amazon Cortex this week, by the way, which is pretty neat, and Cortex was just-
- Again, congratulations on that, and again, it's a great, being able to store, trust me, I see it every day, being able to store all this metric data and do it at scale is a phenomenal thing. Even when I had Cornelia on and we were talking about a lot of the things that you all do and I'm just like, "You nail these things." It's just like you understand the use case and then you just, you have this great set of solutions for getting to it. Go ahead.
- Here we were trying to put a product together and we had the management visualization, we had the way to assemble things into apps using a network, and we had this Prometheus thing, so we wrote this Cortex thing to provide it as a service, and then we had a SaaS product that could give you management, monitoring, visualization of your app. The one thing it did not do deliberately was orchestration. We basically, our pitch was, "Hey, you choose your container, you choose your orchestrator, you set up your app, then you run our product with it and then it'll give you extra things." The problem was that 99% of people who follow that path get stuck getting the fucking cluster working in the first place. We're sitting there saying, "Great, well, when they've done all that, we're gonna have a great load of customers," but most of the customers that we talked to were like, "Well, hey, we'll come back in a while when we've got our cluster working, and we'll come back soon when we've figured out whether to use Docker or Kubernetes. We'll come back soon when we've understood a mess OSS," and after a while you begin to, your customer market ears start to tingle and you're thinking, "Whoa, hang on a second. The market is telling us something. The market is telling us that we're idiots is what it's telling us." We had to make changes, but we were very lucky because we had decided early on to use Kubernetes mainly because other things didn't work, and we had therefore learnt at the beginning of the lifecycle of Kubernetes how to set up, operate and manage Kubernetes clusters and stacks of apps in different zones and monitor them. We basically developed an operating model for Kubernetes 'cause we had to to run our SaaS, and then we found that when we talked to customers and they said, "Well, we love your SaaS, but we're not ready to use it because of these reasons," we would say, "Well, hey, okay. We've discovered how to operate Kubernetes by writing our SaaS. Would you like to talk about that instead?" And they would say, "Hell yes. Please, can you tell us how you've succeeded in making this bloody thing work?" And so we started to rebuild our business around that, and the GitOps phrase came about because I talked to the engineering team and asked them what we'd learnt from running this stuff and they told me and we thought about it a lot and had many conversations about it and then suddenly a few things started to gel around the operating model being entirely founded in Git, and I can't remember whether it was me or somebody else, but somebody started, the word GitOps came into the conversation and I thought that's a good one-word description to encapsulate this operating model where we have a standard way of dealing with a whole stack wherever it's running and redeploying it and making changes and adding security wherever we like, but we're driven by a developer tool, and so what we've done is we built this bridge that we always wanted to between developers and operations.
- [POP] Civo is an alternative to the big hyperscale cloud providers. They've launched the world's first managed Kubernetes service powered exclusively by K3s. With sub-90-second cluster launch times, a simplified Kubernetes experience, and predictable billing, Civo's on a mission to create a better developer experience. Get $250 free credit to get started. Sign up today at civocloud.com/popcast. That's C-I-V-O dot C-O-M slash P-O-P-C-A-S-T. Go check them out.
- I thought we would just do that and that's what we've been doing for the last few years.
- And again, so two tools there. Obviously Flux is such an enabler for, it's just a complete enabler for GitOps, obviously. It's the thing that does it and all of that fun stuff, but again, Cortex being what it is in terms of all that, even the underlying pieces we talk about, and when I had Cornelia on, I said it was, to me, the easiest CNI to deploy and get out there. I've been on record. I've said 1,000 times it's Weave. You click a, literally one, you set a YAML and you're good to go, and obviously there's a lot of magic that happens under the covers that you all have architected, but at the end of the day, if anybody just wants to spin up a cluster, y'all made it very simple to be able to do that, so props to you all for that. Let me ask you this, and in terms of, let's go back to the CNCF a little bit. You had a role, and I'm sorry for jumping on that, but you had a role in founding the CNCF. Let's talk about helping to found it. Talk to me about that, the CNCF itself.
- What happened with the CNCF was that, remember I mentioned that I was in charge of Spring for a while and then was right in the middle of the storm of the creation of Spring Boot, and we did that because we thought that we had this incredible brand with millions of developers, but we lost our way in terms of our use case because nobody wants to build traditional Java web apps. They wanted to do cloud services and big data and other things and they wanted a different user experience, and so we had this way of catering to that large audience and we adapted it to the new era and that's what Spring Boot and Spring Cloud did, and so when I started Weaveworks, my head was full of those things, and I looked at Kubernetes, which was launched the same week as Weaveworks started, and I bumped into Mark Shuttleworth at an OpenStack conference in London a few days after that and said, "Hi, Mark," and we chatted for a bit and he asked me what I was doing and I told him and he said, "Isn't that what Kubernetes is gonna do?" And I'm like, "Yeah, but what a dumb name, and who can trust Google to do anything? And they're bound to make it super fucking complicated," and all of these reasons why it was gonna fail, which are all true, but it didn't fail nonetheless, and I think that you could see that Kubernetes was hard to understand. When we we built Weave Net, we wanted to make it work with Kubernetes and we had a bunch of people in our team who really were pretty smart engineers and they struggled to understand the Kubernetes networking model, and we talked to some incredibly wonderful, kind, generous people in the Kubernetes team, especially Tim Hockin, who very patiently on email explained to us the Kubernetes networking model, which essentially is it's kind of hard to describe and there isn't really a networking model as such, but it kind of submits work like this and a bit like that. It just reinforced the impression that Kubernetes was complicated. For good reasons or bad, it was just complicated, and then I bumped into somebody who used to work with me at VMware who'd gone to GCP and was a sales guy there and he said, "Oh, come along and talk to this guy, John Wilkes, who's one of the Google superhero aging rockstar dudes. He's in London and he's gonna talk about Borg and he's gonna talk about what we're doing with GKE and where it's all going with GCP. You'd really love to meet him," and I went along to meet John, who is basically like Gandalf without the beard, and he was super kind and thoughtful and he asked me what I thought of Kubernetes and I said, "Look, it's just too damn complicated. You gotta look at something like Spring. Spring is something that has millions of users. Google has to decide do you want Kubernetes to be like Spring, catering to the developer community with millions of users, or would you want it to be like OpenStack, catering to 10,000 idiots who think that it's a good idea to build a private cloud?" By the way, I love OpenStack, but it's just a different kind of thing, and he looked a little bit surprised and said, "Why don't you come and have a coffee with me tomorrow morning?" Then we had a coffee, we met up at QCon, and I went onto this rant about this again. He said, "You should talk to this guy, Craig McLuckie. He's the product manager for Kubernetes." I talked to Craig. Craig and I developed a great working relationship and one of the things that Craig had identified would be essential to making Kubernetes broader and more useful in the future was putting it in a foundation. This whole idea of Google being an enterprise software company was one that was at odds with the successful advertising business. They were getting feedback from customers saying, "Are you sure you want to be an enterprise software company? You know what that means?" We got talking about foundations, and I'd been involved in creating the Cloud Foundry Foundation a little tiny bit and thinking about a Spring foundation, so I said, "Okay, I have some views on foundations. Let's talk about foundations." We wrote down half a charter and then he turned it into a charter and then he pulled together all these companies, amazingly, and suddenly the CNCF was being coming to life and a lot of people thought it was gonna be shit, but I didn't. I thought that Craig was really onto something useful here, and so when it came time to create a board to run this thing, the technical committee, I volunteered myself and was very surprised, actually, to get voted the sixth out of six into the TOC, but I thought it was a good thing 'cause I cared about this thing succeeding, and then when it came to the first meeting, they decided to choose a chair of the TOC and Brian bloody Cantrell nominated me and I almost spat my drink out on the Zoom call or whatever we were on, but he's an evil man. Anyway, so I ended up being the chair for a few years, which was mostly about, it was very similar to being the CEO of a tiny startup that has very few customers, very few users, and almost just a little bit of funding. In other words, everything is crazy. There's too much work to do. No one's getting paid and nobody understands you and everybody thinks it's a joke, but if you do the right things, you can get a bit of momentum going, and we found that our strategy was super simple. It's like no one's gonna get momentum from the CNCF itself. They're gonna get it from Kubernetes. They're gonna it from Prometheus. They're gonna get it from other things like that, that if we put those together, it'll have a multiplicative effect. People will see Kubernetes is moving forward, Prometheus is moving forward, this other technology is moving forward, and that will create this very strong sense of complete inevitability, which is what happened. That was getting it moving, and then I'm very happy to say that I was allowed to disappear after that because it was very distracting.
- I have two quick questions, and I know you're pressed for time here. Again, what are some things that you obviously got right and what are some things you got wrong that you say or that you would, I wouldn't say wrong, just that you would course correct, and time being time, you can look back to, hindsight being 20/20.
- With Weaveworks, I would say that I wish we had just doubled down on Kubernetes right at the beginning, embraced an orchestrator, not tried to be clever, and be orchestrator-neutral in our product. Just gone right to the heart of what people needed to do to set up, to get started. We thought that we would be adding value by enabling people to go into production with these extra features without helping them get set up, and of course, you've gotta help them get set up before they can do anything else. That was a bit brainless in retrospect. I think that also we were very, very lucky to be so successful with Weave Net, but we didn't actually think there was a strong monetization path around it and we probably should've been a bit more thoughtful about that at the beginning because we ended up with this super popular open source project around us that everybody loved using but didn't actually make any money and didn't actually drive the business very much, and that wasn't very helpful. I wish I'd thought about that earlier on. What else can I say? With the CNCF, for example, we very deliberately had a move fast and break things philosophy, which meant that a lot of people who like documentation, governance rules, best practices got frustrated 'cause not a lot was written down, and I think that helped us succeed, but then of course that meant that the next generation of people who came in had to do all the writing down, which was, I think, a little mean to them 'cause we could've done a bit more of that ourselves.
- Last question before you-
- I think those are the main things I would suggest.
- Gotcha, and thank you. Last question for you. Again I'm gonna reiterate a question that you somewhat answered earlier, but what work are you most proud of?
- I think, for me, the thing that I'm most proud of is doing the Spring turnaround, which was, it was a very complex thing in the face of some very challenging market and corporate conditions which meant that we had to get a lot of things right, and I think it was one of those stories where if we'd actually been in the spotlight inside the company, where everybody was expecting us to succeed, we probably would've failed and we benefited from being slightly out of the limelight and being allowed to make mistakes and get on with stuff ourselves without having the pressure of everybody else looking at you saying, "This is gonna be the way forward."
- Alexis, again, I appreciate you coming on the show. Thank you so much.
- No worries. Stay with us. Weaveworks GitOps is super exciting and I hope that my answer to your question in the future is Weave GitOps. We haven't reached enough users yet. We've got more work to do. It's just the beginning, Dan, so there's lots more to come.
- I'll be watching you. All right, thank you so much for being on the POPCAST.
- Thank you.