Ep. #40, The Uncanny Valley with Alexis Richardson of Weaveworks

Grant Miller: Alright, Alexis, thank you so much for joining us.

Alexis Richardson: Thank you very much, Grant. It's super to be here.

Grant: So, I'm really excited to kind of dig into your background.

How did you get into enterprise software?

Alexis: Yeah, so like, how did you get into crack?

I guess, I never meant to get into enterprise software.

It was passed around at parties.

I originally worked at Goldman Sachs and I got into finance because I did a math degree and I did a philosophy degree and I was sort of spending all my time dealing with theoretical problems around logic and numbers and that led naturally into an interest in betting, sports betting was becoming big back in the 90s when I was at university.

And I did a lot of that with my friends, also played a lot of poker and that gradually built up my interest in financial services as a potential job.

And then a friend of mine got a job at Goldman Sachs and he said, "Look, I'm having fun here. Why don't you apply?"

So I applied and I got a job at Goldman and then it was in the summer called the arbitrage group, which is basically what we used to call hedge funds in those days.

The word hedge funds as well, they were external to the banks, but the arbitrage group was there to be like an internal hedge fund with the banks proprietary money, and then make bets on where the markets-- what they would do.

And I was in fixed income, which meant that I was betting on interest rate movements with bonds and other instruments and also foreign exchange options and some of the other derivatives around that.

This is the early days of things like mortgages. So it was not so toxic as it became later on.

And we had this great big financial explosion in 98 when Russian bonds got defaulted on by the Russian government, which led to a crisis when a number of hedge funds that had over leveraged and had big bets that were related to the performance and emerging market debt went into a kind of mini credit crunch.

And I say many, because we all know that in 2008, there was a real credit crunch and we see what's happened since in terms of what can affect the general public with austerity and reduction in government spending and how this thing can have a terrific impact around the world.

But in those days, it wasn't many at all. It felt enormous.

It was shaking our world and all of the core investment banks were involved in buying and selling and lending to and borrowing from each other and to these hedge funds, long-term capital management being the primary one.

And so when that started to display signs of trouble, people got worried.

And then another similar fund at Salomon Brothers also got into trouble and shut down.

And then we entered this kind of spiral of fear where everybody was pulling out of the market because they thought they would be next.

And we saw this again later on, but at the time it was very frightening, even though it never got outside of the financial industry at that time, because we managed to contain it.

Although it did involve the Fed, getting all of the heads of all these banks into a room together to fix the problem.

And so after that happened, the financial industry managed to sort itself out, but a number of things changed at Goldman.

And one of them was that people were less excited about making risky bets with the partner's money that would then go south if somebody else's hedge fund blew up, that wasn't very appealing because the partners didn't like to lose money.

Grant: Right.

Alexis: And there was also an IPO that was planned as you know, from TAC.

IPO's depend on good faith in the market.

And Goldman did not want to have the reputation of being a risky bet and did not want to have the reputation of being involved at all with proprietary trading.

So everything switched over to what we call the franchise, which is basically about that's the girl that is doing things for customers as the primary source of revenue, investment banking, corporate insurance, things like that.

Some of my friends who were more experienced left to do hedge funds and did really well.

And I stayed inside the bank and moved into the floor side as we call it, the franchise, seeing a lot of business go through the bank.

And this is in the early days of electronic exchanges, when we've moved from floor trading, you've probably seen films and photographs of usually men in the trading pit, shouting at each other, wearing big colorful jackets and buy sell, and all this kind of thing.

It used to be how a lot of trading was done and that all became electronic and ran the late 90s.

And then we started to see people say, well, hey, if exchanges can go out electronic, why don't we make everything electronic?

And people started to propose automated trading systems for either making bets or providing prices in the market or doing other things.

And you could see this was a time of change.

The markets were sometime in the future going to become a lot more electronic.

A lot of the jobs that people trusted to be done by humans could disappear at any time, depending on really on the level of human input required.

So the things that went first are the ones where the level of human input was low, just being in the pit wasn't very useful.

So you could replace that with the screen.

And then the more, should we say high value ones would take longer, but it was really a matter of time.

And so another group of us decided to move on and go into tech.

Some of my friends went to form things like grocery delivery companies that have been very successful.

One of my friends Fred Destin went off to be what is now quite a well-known VC in the tech industry.

And for me, I started a tech company with a friend aimed at looking at the big need for technology inside places like Goldman Sachs.

So we'd been sitting there, we'd come into the bank.

We've both been pulled into high-end hedge fund style ways of trading, where we basically had a command and control center all around us on our desk with boxes and screens and things that we could use to make decisions supported by amazing computing power.

And we were surprised when that level of compute sophistication was not available to the general crew inside the firm, was not being used to make money electronically.

It was not being used to automate trade support and all kinds of things, as well as it wasn't being used to create new businesses in the market.

And so we thought it'd be really useful to create a tool that would be given to anyone in the financial industry and they would run it and they will be able to have a full suite of financial services capabilities.

They could then plug into their Excel spreadsheet.

So they would be able to have out of the box, a customized experience, which at its core would give them the same mathematical power as Goldman Sachs or Salomon Brothers, even if they were bank number 3000 in the market, or just some new person coming in.

And we did that because we could see that really what was driving the decision-making for these traders was tech.

And what was required was the ability to write code so that you could process the information you were getting and turn that into decisions.

So for example, you might have a bunch of prices and you might see price discrepancies compared to your model, your model would be possibly based on code and your model would be saying, "Hey, IBM is priced at 100 and Sun is priced at 99 and normally, they traded within two to three points of each other. So why don't you sell Sun and buy IBM and bet that they're going to get further apart and gets what the model was saying."

This kind of thing is very, very common.

And that was considered to be very sophisticated in the 90s.

We wrote a tool that would mean that anyone who could write Java could then run kind of similar programs to help them to do this kind of trading themselves very, very easily.

Sounds great, doesn't it? Except that we forgot about a lot of things.

Like number one, it's great you have a product, but how do you actually get customers to use it?

This is like reading these books about entrepreneurial 101. What is the sales model?

Do you have a distribution plan? Is there any marketing involved?

How do you ensure that people have heard of you? Why should they trust you?

You could go on and on and on all day.

And we just did the rounds of going to get in touch with people that we knew, doing demos for people.

We also did a lot of work for inter-dealer brokers that were early customers because they were less sophisticated price makers and risk-takers than the banks, but they needed a tech help.

Generally speaking, what we learned is selling technology is actually really difficult.

And even if your product is incredible, it doesn't mean you're really solving a customer's problem because the customer will see what their problem is.

They won't see how your tool, which is abstract fits into their problem.

And so that's what we discovered without really knowing where we were, what enterprise sales was like.

And then we discovered the other thing about enterprise software. It's very, very abstract and boring.

So when you have a problem that a customer is saying, "Hey, I love your tool, I get it, I get it, where you're going with this. I love the idea that somebody who's using an Excel spreadsheet at Goldman can do all these incredible things because they're plugged into all these systems and you're kind of giving that power to everybody else and democratizing it. But how does that apply to me?"

And you think, well, okay, I could turn this into an actual app, so I could put a gooey in front of it, with flashing lights and graphs that go up and down and I could have screens that say trading opportunity and there would be a button saying, buy.

And now I'm in the app business. I'm not selling middleware anymore.

And then I can sell it to humans who were like, oh, okay, yeah, I'm somebody who knows what this does.

I have a buyer and seller. I could buy a trading system from you.

But because we were basically nerds, we didn't actually want to do that.

We didn't want to build something as boring as a specific solution that would only solve the problem with one customer. We thought it'd be more sensible to build something that could solve the problem of a whole bunch of customers, not only trading customers, but also people doing other jobs in the industry as well.

And also even in outside of trading, things like online betting, online gaming, all of these kinds of interactive apps, pre Ajax were a big thing in the early 2000s.

And so that's when we realized that we were in the world of enterprise software because not only had we chosen to sell to the hottest buyers in the world who really didn't want to talk to us unless we had something they obviously wanted to buy, but also we were producing a product which actually was solving a middleware problem rather than directly solving the problem that they thought they had.

So we were selling software to other software people.

And that is in fact, the reality of most enterprise software, is you're building tools that have incredible power as a potential platform to solve more than one problem for your customer.

And a lot of the value comes from them standardizing on that, but them understanding the value is hard because they don't necessarily want to standardize on your tool, they start as a proprietary tool, even if you're using standard things like Java.

So we basically ended up selling enterprise software and building enterprise software because we were too bloody minded and interested in solving abstract hard problems and not really paying enough attention to customers saying, I just want a trading tool, or I just want a gaming screen.

And that guess that's how you get into this space is that you, you make a series of dumb decisions and then you're stuck.

Grant: I love that.

Alexis: You know what I mean?

Grant: Yeah, yeah, of course.

Then this is MetaLogic that you're talking about, right?

That's the first company that you founded.

Alexis: MetaLogic, yeah.

Which is not named after mathematical metalogic, but actually because my co-founders were Finnish, thought it'd be good idea to name it after heavy metal.

So the original brand was MetaLogic with lumps on it.

And the G was like an axe and that some people in our company thought that was awesome.

Grant: That's amazing. Okay.

So you're in the middleware business, what happened to MetaLogic? What was the sort of end state there?

Alexis: Well, we got a few bit of customers in the banks, people who could see the value.

I mean, essentially what we found, I mentioned standards.

I mean, what we discovered was we've written in Java kind of equivalent to the .net platform in the sense that it was a framework for building class of apps that would be useful.

It was an app server that involved a number of cool technologies like caching for distribution and as such, it was its own standalone stack.

And this is at a time when, if you weren't on net, you had to be Java and if you were Java, you had to be enterprise Java.

And if you enterprise Java, that meant J2EE and servlets and enterprise beans, which at the time people were discovering were just too damn complicated to build many apps server.

And I met a few people who had been involved in projects like Reuters Instinet, where they built a whole trading system for $20 million using J2EE.

But it was clear from talking to those people that they had felt they were fighting against the tool chain and they'd done it despite the tool chain, not because of it.

And we talked to a big bank, I won't name names because it would be unfair, but one of the biggest banks in the industry had done, I think over 100 projects using EJBs by 2002, and they reckon that only about three of them had succeeded at all.

The rest of the were definitely failures. So there was this weird situation in the market where everybody was using the wrong tool.

People wanted to build more web apps, but we didn't know how, we didn't have things like Ajax yet.

They were emerging. And people were beginning to realize that Java was great, but couldn't on its own work if you use these standards that have been designed by committees of enterprise vendors.

And so we had an alternative, but who cares what we have?

Because our tool was from some, no name company with some X traders running it out of England and Finland.

And like, frankly, who gives a shit.

And we got a lot of good advice from very friendly customers.

So one person said, why don't you go team up with Oracle?

You can stay in the cell top of times 10.

We were also, this is early days of open source enterprise software, like MySQL.

And we actually shared an investor with MySQL ib, friend's Swedish company.

And they put me in touch with Martin Nicholson, I had a phone call with him.

And Martin was very, very helpful.

And he said, "Look, I think your product would be great on top of our database, but you'll have to make at least some of it open source, otherwise we can't distribute it."

And I went back to talk to my engineers and they're like, "You're fucking crazy. We're not going to open source our software and give it away. That's madness. We actually spent time working on this stuff."

It was bad time of the markets.

But all the time, what was actually happening was that outside of our little bubble, other people were realizing that EJBs, J2EE and the relational backend were not enough to build the apps of the future.

So we had companies like Tangosol, which is still part of Oracle now with Coherence, Solarmetric, which is an actual relational store, Interface21, which became SpringSource, Symphony, which became MuleSoft and a bunch of other companies.

Some of the-- all those people are still around at the market in different places and a few others that people have forgotten, where people were realizing what you needed was just simple Java and POJO, people called it plain old Java object.

And of course, I think you know retrospect, that one group kind of broke through the barrier of--

There's a kind of uncanny valley that you sit in when you're near the right answer in enterprise software, but not near enough, you're recognizably what-- you look like a solution, but you're too damn ugly to let into the building.

So you sit there and uncanny valley with your uncanny shitty product, and you can't understand where you can't get real sales because you're almost a product market fail.

But actually whenever you show your product to somebody they're like, "Oh no, I just don't want to use this."

And what Spring did was they tricked people into using POJOs by wrapping them around J2EE, Tomcats, EJBs and convincing them that you could write a POJO.

And then through the magic of wiring and recompilation and dependency injection, and inversion of control, worth all of the things, you could turn it into something which could be using a standard product.

So you could then tell people, "Hey, write this in Spring, run it as you wish in Tomcat, running in WebLogic, run it in WebSphere."

And then they did what MySQL had done, was just say, "Hey, look, don't buy WebLogic until you're ready to go into production," MySQL would say, "Don't buy Oracle until you're ready to go into production. Just use MySQL for free."

And people would use MySQL for free and then they'd scale up.

And then some of them would buy a license, right?

Of course the models have become more sophisticated now, but that's how we thought in those days.

In fact, MySQL's model was even more-- They basically just said, the GPL is going to you unless you buy a dual license.

That was slightly strange, I thought. But the general idea was use the free thing, treat it as adaptable.

And then when you're actually running a production, you say you're going to move to the alternative tool.

But what you'll actually find is that you're on a tool that's working.

Grant: Right.

Alexis: And even commercial software did this.

So Coherence's business with the Tangosol, Oracle, as it is now, Jae cash implementation had a free dev license and pay for production license, which is sold on a per set up or per node basis, I think, per CPU, I think, sorry.

And they wouldn't charge you until you'd be running in production already.

And so they have this massive market cost of entry, but they actually got customers to trust their software and then commit to production.

This is very similar to the freemium model of open source, where you take a hit up front to do free distribution and then if you can figure out it up sell point.

And so this is all going on at the same time, as I'm finding out the MetaLogic is in the wrong places and the uncanny valley, and it's not going to be a happy, friendly piece of enterprise software.

And then at the same time, as we realized that all the things we've done wrong, we had a number of other issues largely to do with trying to be in two countries at the same time, without the infrastructure that we now have in 2021 for remote working.

So I was doing customer meetings with big banks in London, and then trying to explain to engineers in Finland, who I was working with, what the customer wanted and talk about lots in translation.

It wasn't easy to get your idea across.

And it was just because you have a meeting, you wrote down some notes, you get on a plane, you go to another country, everything is different. It's just things get just scrunched up.

And so actually we really should have all been in one place, we'll have Zoom or SameCast during this phase.

Grant: And so, did you sort of sell it, winded down? Because you started another company.

Alexis: Yeah, we got some customers, decided to go our separate ways.

The other founder and CTO got a job at a bank where he still is.

Various people went to get married and have kids.

And I decided to have another go using the lessons I've learned, which were open source is a way to get customers to try out your product before they need to get past the trust stage.

Grant: And so this is Cohesive?

Alexis: Yeah. MetaLogic to Cohesive.

So Cohesive came about because I wanted to do an open-source company based on what I've learned at MetaLogic.

Grant: Oh, cool. And this is 2006, you were like, "Okay, maybe Martin Nicholson was right and I'm going to go do an open source company and that's Cohesive Networks or what's now called--.

Alexis: It was originally called just Cohesive.

In fact, we went through a brief stage of being called Open car.

So we wanted to have a, we saw people adopting open source.

We saw the benefits of the distribution and sales model and what we thought customers needed was support.

We didn't understand what REL was doing in the support space.

We felt there were other areas of support that we could add value to, especially around a whole lot of the emerging new middleware stack.

And we came up with a business plan, which was so similar to what Tidelift is doing today.

When Tidelift launched, I was like, "Hey guys, this is great. We actually tried to do this before, but you guys think it'll be successful because we were just ridiculous the earlier and there weren't, there just aren't enough stuff and components to kind of support in this way."

And I thought that their thinking actually is incredibly sophisticated.

And the founder, Donald Fischer was the person who created the REL product value proposition.

So actually he and a few others were the people who figured out how to make money from Linux, which was very similar to what I said, which is people need support and they need bundles and they need supported bundles, but they did it around the Linux brand.

And now Tidelift is doing it again, but on a sort of more distributed basis, I guess.

So we try to do a supported stack.

And then we realized that what was really required was--

Because we're still thinking about financial services, a middleware stack that financial services customers could use, that was based on Java, which is what they wanted to use, but not tied to J2EE, not tied to EJBs, not tied to all the stuff that wasn't working, but instead tied to a category of emerging tools that we were very excited about, like a Apache ActiveMQ , or like or Spirit, or like Mule ESB, like Spring framework that we thought we could assemble into a larger offering.

So I got together with some people to do that and we couldn't quite see how to work together.

So we split and then I found another group to work with, which is folks in the U.S. who had come out of the banking tech sector.

And that's how Cohesive was founded and became called Cohesive FT, because cohesive.com was not available as a website.

And we were targeting financial customers. So we called it Cohesive Financial Technologies.

Grant: Ah, cool.

And you started the company with a handful of other co-founders, ran it for two, three years, that company still exist, right?

Alexis: Yeah.

So we were coming to market at a time when not only was open-source becoming clearly important, but also the way that software is packaged and distributed was changing and people were moving to software repositories as the primary source of software distribution instead of .EXE files and DLLs.

And also people were discovering that virtualization and the cloud were providing an on demand environment to run software.

So if you think about Docker today, you've got those three ingredients as well.

You've got like a build from source, generator roundabout artifact that run on and pretty much any infrastructure and build a package that contains the pieces that you want.

And so we thought we could build a business around a product called elastic server, which would do essentially those things and run-- you'd say this is what I wanted my stack and they would just run it on VMware for you, run it on the EC2 for you.

There are other versions of this tool, a really nice form was created by the company that Erica Brescia sold to VMware. What they called again?

Grant: Bitnami.

Alexis: Bitnami, yes. Yeah.

So Bitnami built a very similar offering and a few other people as well.

We did that because we realized that customers wanted a whole run of a lot of facts, which would support it.

And we weren't in a position to build a business out of actually supporting the individual components ourselves because we weren't hiring the developers for each of those components, while we were doing that because we were selling to finance, we realized that there was a gap in the stack for a good middleware message bus and JP Morgan were building a new protocol called AMQP, which was designed to be like HTTP, but for message buses and publish subscribe.

So it was going to provide a standard format for describing one-to-many-messaging, one-to-one messaging cues, all kinds of distribution patterns and pop stars and so on, did a cover of VM and IBM basically. So we decided maybe we should do an implementation of this and make it part of our stack as well, because it was so critical to the financial customers we were serving. And as we were doing that, I realized that we were now doing two products because we had the elastic server on the one hand, which was this kind of VM factory.

And on the other hand, we had this message tool, which we decided to call RabbitMQ or I decided to call RabbitMQ, which we jointly build with another company called Lshift that we partnered with.

And having an open source message tool was fundamental and very, very useful for the other business, but it wasn't necessary for the other business also it could easily go off and be its own thing.

So I found myself increasingly in two jobs, one is trying to look after RabbitMQ and focus on getting customers by leading with messaging and then talking about what they were going to do with the cloud and these new next generation apps around virtualization and so on. And on the other hand, just talking about the virtualization stuff.

And so I felt that I couldn't do both of those things and had to decide which one of those to focus on and decided to leave and focus just on RabbitMQ.

So I retained some shares in Cohesive, around about that time, what we discovered was that there were a bunch of very specific problems around the applications that you would build using virtual machines and the cloud that required things like networking and security.

So you basically end up setting up virtual perimeters for yourself. You know, how VPC works in Amazon today, right?

Grant: Sure.

Alexis: This is back in 2008, 2009, 2010, people needed on demand VPCs, they needed to be hybrid across the cloud and the enterprise.

And so Cohesive decided to double down on that opportunity and really focus in on cohesive networks, which is basically the backbone of virtual applications and sell that to enterprises basically as an appliance.

And I decided to leave at the same time and go off and really focus around RabbitMQ, which was being used to run the virtual networks, but was really a tool that was very generic and was powerful and was useful to many things.

So this is exactly the same stupid decision that I made when I did MetaLogic, because I decided not to do specific application, but instead to really double down on the general purpose middleware tool.

So as I say, enterprise software is highly addictive environment.

Grant: But I mean, RabbitMQ has been quite successful.

So was there sort of instant adoption or did it take a little while to sort of get people to start using it?

What were the early days of that? How long did you stay Cohesive before you actually decided to go off and run Rabbit technology?

Alexis: Cohesive for about a year and a month before I'd have to do Rabbit full-time and then I think took another year of just focusing on Rabbit and then we started to raise money, and wait, while we were raising money, we got an acquisition offer from VMware, which was actually SpringSource because they had been acquired by VMware in the summer of 2009.

And they were a partner company of ours.

You remember, I was working at Spring a few years earlier as the basis for the applications and the next application stack.

And VMware acquired SpringSource for that very reason.

They wanted to have a VMware based modern middleware stack they could offer to customers to expand their footprint and sell into people using application middleware.

So I had to decide with my colleagues, should we take the VC money and go for it on our own?

Or should we double down on just being part of the company?

And we authority to decided to go with the kind of bird in the hand option, it felt much more risky in those days than it does today to do a standalone commercial open source company.

We had worked very, very hard to get adoption.

We had used a lot of different techniques to make sure that our product was used and paid for by the right people. So there's was a lot of community development, market development, positioning work, sales work, product work to be done before we got acquired.

When we at the time of acquisition, we had about 300 production users that we were tracking or more, but we didn't track and about 30 paying customers and that number was growing quickly and we had a lot of community clients being built.

But one thing that I found difficult was when I was looking for money, I tried Silicon Valley and everybody there basically just said, "Oh no, you can't make money out of messaging and integration. That's ridiculous. Nobody is going to fund that."

Grant: Right.

Alexis: Remember very clearly, Peter Fenton at Benchmark saying, "This is silly Alexis, you should just... go take rods off and go work at SpringSource. It's a bit good thing to sell company."

And then a few years later he funded Kafka, I told him not long afterwards, I said, "But Peter, why are you funding Kafka and you didn't fund messaging?"

And he's like, "Oh, it's a completely different thing. This is data streaming."

And I'm like, dude, you have no idea. But they've done incredibly well.

So hats off to them. But I think, the point is that it was just a different time and very hard to see how to make anything successful at all.

So everything was, there was nobody to copy, nobody to follow.

And we had a few ideas, which I thought were pretty important.

Like we had this idea of make the product easy to use, because everything else that we saw was hard to use.

And if somebody asks for help, you have to answer them within two days, if it's on the mailing list and immediately if it's in person and try and be nice.

And there's no such thing as a bad question.

And I found out later on, that this is something that people really, really, really valued.

I bumped into Kelsey Hightower many years later when he was just starting his career and at least in the public eye, he's this kind of cloud superhero and he was still at CoreOS then, he said RabbitMQ was one of the first pieces of software he encountered after getting into the industry from what he was doing before.

And he really liked it compared to other software because it was easy to use.

And he'd spent his previous career and he's had a few years as a kind of CIS admin, installing software and hardware for customers at a retail level and he found there's a very clear difference between when those things were easy to use and when they were hard to use.

And you could see that normal people could be very successful at tech, if somebody made an effort to document it properly and to have good UX.

And he liked Rabbit because it had sort of done some of those decisions as well.

So I was very flattered by that.

And I thought that it meant that we did some things right, but we still had a lot of foot slogging to do.

We had to go and find people in different communities to take up our product and start to use it and champion it.

So that's how we fell into Debian and Ubuntu.

And we got into the Ruby community through Heroku, Engine Yard and a few other people around that group.

I used to spend a lot of my time in SF, hanging out in the ThirstyBear with the founders of those companies, because--

And then other also places down 10th avenue or whatever it's called 10th street because I needed to be there to talk to them about this product.

And I could see that they were building these cloud apps that could scale with messaging.

And that was our basic bet, was that messaging was a tool that had been used in the past to make scalable financial services apps like trading systems, like the kind of MetaLogic target apps.

And remember that when I did MetaLogic, we had these interactive applications, but actually what people were using was typically an app server and a message bus to build that pattern instead of what we provided them with.

So the same use cases were arising in 2009 and 10 on Silicon Valley, because people were building these high-scale cloud services, for instance, so Twilio, Engine Yard, Heroku, and others, so I spent a little more time with them helping them to be successful with those tools.

And then after we went to VMware, we carried on working at Rabbit, Redis came in with us because we'd be working Salvatori a little bit too.

So we were the Rabbit and Redis team for a bit.

And then we got fully merged into Spring and Cloud Foundry when Pivotal was launched.

What's nice about Rabbit is that it's kind of carried on growing at the same rate since 2007.

Grant: Yeah.

Alexis: Despite the fact that the team is changed several times.

And I think that shows not only the quality of the different individuals who've been involved, but also the underlying build this.

Grant: Yeah. I mean, and the needs there, right?

Alexis: That builds the need, everything. Yeah. Of course.

Grant: And so when you joined VMware, this is sort of re-introduced to big company because you'd been at startups for a while and that, since you left Goldman, but this is your first kind of tried and true enterprise software company that you're joining.

What lessons did you learn inside of VMware? What was challenging?

What was interesting and what were the sort of things you came away with that experience?

Alexis: Well, by the time I got to VMware, as you say, we've learned that the critical things were figure out the sales problem, have a marketing model, which in this case is open source distribution, solve a real need, which is scaling, identify that your customers with that need, help them succeed early on very critical, find distribution partners to help you scale people like Ubuntu and have the right commercial model, which is freemium in this case free, then jump up to something paid.

All of which we just had to learn the hard way and I feel was just a pretty good lesson basically. So that was the sort of early success.

Grant: Share some of those details around the distribution.

What did that partnership look like with the Ubuntu and Debian, what were the details there?

Alexis: So we had this concept of rock stars and platforms where if you were talking about a, some communities were basically tribal and they were led by rock stars like Ruby, it was all about Ezra, may he rest in peace, and the Heroku leaders and the GitHub people and other smart, cool kids around the area.

And then, Linux was a set of platforms, REL, Fedora, Canonical, Ubuntu, Debian, et cetera.

And we chased after the platform market because Red Hat, our competitor was doing an alternative implementation of AMQP and keep it in the Red Hat platform and chasing after a different customer.

And by the way, another crucial lesson was don't look too fucking weird.

If you have a product, make sure people understand where it fits into their world.

It's a message bus and it implements AMQP, which is sponsored by JP Morgan.

And it's a new thing which is going to disrupt IBM, end of story.

We had a few sexy things like Erlang, which at the time was of interest in the Ruby community because it was a kind of another functional language that had more power, but fundamentally it was the platform market for Ubuntu, what we did was there's a whole ecosystem around Debian which is an upstream feeder into Ubuntu those times, and you had to talk to people called the Masters of the Universe Ubuntu, and they would help you to create Debian packages, which could then be put into upstream bills and you'd make it into a release.

And Ubuntu works in much the same way.

We were helped by a lovely person called Elliot Murphy.

I remember sitting at my parents' house one Christmas, on Christmas Eve, learning about GPG for the first time because I had to get my packages signed together into Ubuntu on time.

And once you're in Ubuntu then everybody who had a disc on the front of a magazine would be able to install your RabbitMQ wherever they were going.

Grant: Oh, okay.

Alexis: And that would kick off a whole other thing, which was basically commercial upsell opportunities.

Ubuntu had a model called Universe, which was an outside ring of untested packages and they had an inner core of curated approved packages that had a number of properties that they could get support and so on.

So we gradually moved from the Universe into core.

That's when I met Steve George, who's the COO Weaveworks today, because Canonical said, "Hey, why don't you do a sort of business deal where we can resell your support? So that customers asking for Rabbit support on Canonical can get that."

All of this kind of thing. It's very similar to the kind of marketplace models that people are doing in the cloud today.

Grant: True.

Alexis: Yeah. So, I mean, those are all pretty important things we had to do.

Grant: And that was all while you were at VMware, right? You sort of--

Alexis: This is before VMware.

Grant: Before VMware.

So this is like you, I mean, that's pretty quick to manage, to pull all that together, build the product, get the distribution, start to really build some community and success.

I mean, all within basically two years, right?

Alexis: Two to three. Yeah.

Grant: Yeah. And then the acquisition by VMware integrated with their platform, roll it out.

And then I'm guessing, it became part of a larger support, purchased licensed with them.

Alexis: VMware basically had a number of different ideas about how to sell in this market, which they were trying out.

And the one that we got pulled into most at the beginning was called vFabric, vFabric was a standalone virtualized middleware stack, which is available in two pay for additions. One was the kind of standard stack and one was advanced with more things in it.

And the standard was basically Tomcat pay for edition, Rabbit, pay for edition and a couple of other things. And it was a lightweight alternative to buying WebSphere. In fact, you could argue it was a similar to buying WebSphere community edition, but with Spring around it, instead of just EJBs and stuff. And we sold that to what I call Oracle and IBM refugees.

So basically people who had made an investment in J2EE, which was painful and expensive, who realized that Spring was a better way out and they wanted to shift to a lightweight, more lean, less expensive, more cost-effective middleware base, which they could pay for a few hundred bucks a year at scale, instead of two or 3000 for the competing alternative.

And there is a market for that, where you have like an established app server type market and people get renewals every one or three years.

And every time they do that, you've got a chance to win over, let's say five, 10,000 licenses and your customer is making a cost saving and maybe 50%, maybe 70% on the base.

There's usually an up driving it too.

So those follow ProServ building new apps out on top of this stuff. It was basically identical to just selling middleware, except that it was provided as VMs to VMware customers.

But actually that turned out to be less important than just selling middleware.

Grant: And what was the difference between the pay for version and the sort of community edition?

Alexis: No, both versions were paid for.

There was a standard version which contains fewer components.

Grant: Okay.

Alexis: And there was a so-called advanced version, which contains some additional components, which were designed to help people orchestrate complicated applications.

Grant: But were there are two versions of RabbitMQ in the-- or was there three versions of RabbitMQ?

Alexis: We ended up making a commercial edition of RabbitMQ at the time, which had a JMS client in it.

And we did that because the people who wanted JMS were all deep enterprise buyers and they also wanted to do--

They wanted strong alignment with the whole JQE model, which had things like distributed transactions and we didn't support the full TeX model, but we supported enough of it and had integration at Spring so that people could get more done in that idea if that's how they wanted.

And so if you go talk to, I remember a customer at the time, that would be typical of this will be Amex, have tons of apps using JTB and JMX to manage and monitor them.

And all of the tools were in place and they want us to use the new stack, but it needed to have some pre-established APIs around it to make it easier to integrate. Another example was Cisco.

So, I mean, that's how you do enterprise version.

Today, what people tend to do is they tend to go for a free version, being a fully functional and the pay for version being, solving some problem associated with scale or security.

So a good example of that would be Terraform or Volt from HashiCorp.

The more you deal with those tools at enterprise scale, the more you're pushed to premium and enterprise versions, because they're solving problems that are addressed by larger scale use.

Grant: Right.

Alexis: And that's good because that means if you make your free tool one that encourages productivity, then it will self-replicate until you get to a scale point.

Grant: Yeah. And I mean, I think their perspective there is like, eventually you need all of this compliance and other management, and we're going to put those sort of features into the enterprise edition.

And you'll pay for that if you're using it at an upscale.

And then let's move into the Pivotal, so you're kind of building this Spring platform across the board at VMware, they spin out Pivotal, and then you end up as the head of product for Spring.

I don't know much about Spring, I mean, I kind of understand a little bit about it based on what you're saying here, but what's the core concept behind Spring?

It's still quite popular. What are the partners who were involved?

Give me the rundown on Spring and why it's important.

Alexis: So when I was in charge of Spring, it had about three or 4 million users that was about 50% of the Java developer population, as we thought it was at the time. We had a million unique visitors to the website.

Grant: Wow.

Alexis: And we have a number of other significant metrics.

I mean, Rabbit and Redis and Tomcat also had very good numbers, but not at that level.

And so we could see that we had this kind of umbilical or mental, or maybe metaphysical connection, astral connection, if you'd like, with the enterprise developer.

We were one of the standard tools.

And that's why Paul Maritz the CEO of VMware, thought I'll buy SpringSource as a means to get into the enterprise developer because they're using Java.

So what happened was that because of a bunch of reasons to do with how the acquisition worked, politics of VMware, different personalities involved in some other decisions that we don't need to go into here, basically Spring had been a bit neglected and quite a few people had left.

There were still some fantastic developers.

I mean, really Spring is about the development engineering team ultimately, and whoever is around that in a product or marketing role succeeds or fails to the extent that they can actually work with the core development teams, it's truly a great open-source project.

And there were still some brilliant engineers that some of them had been pulled off to other tasks like helping with car fabric or something.

But basically about half of the core team was still there, but the whole kind of coherence and mission had been lost because of these sort of flip-flopped decisions and whatever and then Pivotal was around.

And so we had this thing that still had great numbers, but didn't seem to have any kind of plan or reasons to stick around as a result of which some people would say, well, this thing is dead.

I mean, it was bought when it was 70% of the way through its lifetime.

It had already done its job, which is to make IBM and Oracle give up the go in terms of trying to control the jobs stack.

And it reduced the prices in that market down to affordable levels for the whole market and it commoditized everything, and now it's done.

So why don't we just fuck it?

And counter argument to that was, dude, if you go to any customer, they're all using Spring, even the ones that say they're not using Spring are using Spring somewhere," and okay, maybe they're using it for web apps, but that doesn't mean they can't use it for other things.

And people are like that'd be ridiculous, Spring is about web apps.

Some of them, no, no, no, no, no. Let's have a look at Netflix, LinkedIn, Twitter.

About 10 or 12 companies at the time, which had big name, Westcoast, CloudFirst, companies, all of which are writing Java code, LinkedIn Kafka, Hadoop from Yahoo.

And these were all done outside of J2EE. Why did people want to use Java, but not use Spring?

It's clear that the enterprise trust Java, it's clear the next generation of big digital CloudFirst companies trust the JVM, even if they don't trust J2EE, why can't we give this new generation of tool capabilities back to the enterprise customer base we already have?

Because after all, we're here to write a cloud platform.

So we could have a cloud platform based on, hey, look at Amazon, Amazon has these services on it.

We can have a bunch of stuff, think of it, like instead of Amazon services, you've got the thing that does messaging.

You've got the thing that does big data. You've got the other thing and the other thing.

And if we don't have it in the Spring stack, we can't use our existing fabric stack for it.

Let's go and use a Netflix tool or a LinkedIn tool or a Twitter tool or a, because they're all open source.

And they're all being curated by dedicated teams inside those companies that would love to see that project used outside of the company much more.

But now we'll have the first idea how to scale it or support it or do anything.

I spoke to the person who ran open-source at LinkedIn.

And he said, "Oh no, if you got an issue, you should talk to Ariel Tseitlin.

And he said, "Oh, and I've gone. Ariel is now at ScaleVP, if you ever go talk to them."

He's an amazing guy because he took the time out of his day to say, "Alexis, you should talk to this person at Netflix, if you want to understand Netflix, his point of view on open-source because he was there before."

And I spoke to Dianne is a Netflix who run the Spinnaker projects on all of Netflix.

I said to her, "Hey, Dianne, I've got this. I really want to ask you something. I know that I'm slightly strange person calling you from England."

And she said, "Okay."

So I said, "Look, you launched Netflix OSS a couple of years ago, and you've got these great tools and you put them all onto the one brand and you're expecting the market to pick them up.

So then you could say, we have a standard tool chain that you can run on any firm and then use that to negotiate Amazons and price concerns because you've got possibility maybe and nothing happened.

Nothing happened because actually let's face it, Netflix is writing tools for its own use, not for other people's use any other people using your tools are doing so coincidentally.

And this is early days for open source in Netflix.

You haven't really made a huge effort to make them supportable by the broad community, you don't have community manager.

You don't have an open source team dedicated outbound, why should you use Netflix? You're Netflix, you're making money from the movies and television."

And she said, "Yeah, absolutely. Things are great in Netflix. They especially have a great tool chain, but at the same time, the Netflix OSS official goal of becoming like an industry project hasn't been successful because really Netflix is sort of make software for itself.

It's great that we get to do open source and create new tools like Spinnaker that we can give away.

But ultimately, we're not here to become long-term Spinnaker company or the other company or the other company. And it'd be great if other people did that."

And I'm like, "Okay, well, here's why I'm calling, because here over at VMware Spring, Pivotal Spring, we have the opposite problem, which is, we've got incredible brands.

We've got loads of enterprise users. We know how to do support. We know how to run communities.

We can run conferences, we have websites, we have events, we can do everything.

But one thing we don't have is anything useful, people want to build cloud services.

So we'll have to build it from scratch or work with you. We can take Netflix and assess and wrap Spring around it and then ship that over to every Spring customer."

And I was having the same conversation about Hadoop with people at Pivotal working with Hadoop, you can be more successful with Spring Hadoop than with just the Yahoo Hadoop, API, some skepticism involved here.

And we had a number of other things going on.

So we had this idea of a next generation runtime that would get rid of all of the things that people didn't like in Spring, which has all the XML scaffolding, people would moan about it, similar to how they moan about gambling in Kubernetes and just have opinionated, conventional code, which could then be overwritten by developers'own opinions if necessary, but generally provided a simple, happy path.

We had a concept of a platform which would involve coupling that to distribution mechanism so that you could attach a number of other sub packages to your core run time.

And then you'd have a new Spring run time that could run cloud services.

We were missing the cool stuff. We were missing Netflix and missing Hadoop.

And so I'm super excited to be talking to the person running Netflix OSS, and we're having this conversation.

And she says, "Well, Alexis, this all makes perfect sense."

And I'm thinking, fist bump. And then she says, "There's only one problem."

"What's that?" "I really fucking hate Spring." "Oh, okay. Just you or just everybody?"

And she said, "Well, it's kind of a big problem here at Netflix. This is just not really me."

I'm like, "Okay, tell me more." And she said, "Well, what do you like? Do you like to study? "Yeah, I'm more of a Scala girl."

So, okay. So I could see the problem is that Spring's reputation was a little frayed and it had missed its early chance for renewal, it could have taken when it first came into VMware, VMware had stupidly neglected it, let a lot of the good people go and the other good people were demoralized.

So we were kind of on the back foot.

Anyway, we had this idea for turning it into a runtime for cloud services, which could let you write things in grooviest while at Spring.

And I showed it to Dianne on the call and she said, "So do you know what? I could imagine writing software in this new thing without being sick. But the only problem is that I can't talk about it right now because we don't have anybody here who would use it, but we're very happy to try this out in the future."

So long story short, they tried it out a few months later and got such good support from some of the other members of the core Spring team but they decided to bet on the next generation of Spring.

And if that hadn't happened, I think we wouldn't be having this conversation about Spring today.

But then we brought Netflix OSS into Spring and had a bunch of Spring, have that, we did the same story with Hadoop, with the same trickery, with some of the other release sets patterns.

And you see the results and now it has many more millions of users.

The platform tool, I mean, the new website we created it for it spring.io has got something like hundreds of millions of downloads a month.

And it's all because we took the opportunity slightly out of the line of sight of the community because people were very focused on Cloud Foundry to have a chance to rethink things.

And there were other things too, like the people who are working on it were just such high quality developers and one or two of them who were driving the core ideas, the inventors of it like Dave, for example and others, Phil, had really spent quite a few years feeling, frankly, quite depressed and wondering what they were getting wrong about interaction with users, because they could see that Spring was introducing these terrific new features, but they weren't getting the kind of excitement and buzz from users that they used to, what was wrong?

So, this whole second generation was definitely involved, many, many, many people and great moving parts and things like that.

So now it goes back to enterprises trust Java, and now they have tools they can use.

Grant: How did you revitalize the perception of the brand? If you have all these people that hate Spring, and then you come out with version two.

Alexis: Very simple, we basically just attach the brand to other brands.

So it's like, if you want to use Netflix, it turns out to be easier to use Spring.

Grant: Got it.

Alexis: And that was successful.

And if you're already using Spring and you're a bit worried that you're using the old tool, it's becoming a bit uncool, don't worry, because now you can see that it's also touching to the cool kids stuff.

So imagine that-- Okay, so we had these meetings with one of the investors in Pivotal GE and this is just after GE had set up a big center in San Ramon.

And it's like, they're going, this is going to be the new world headquarters of software.

Actually what they did was they did something really smart, which is that they realized that Silicon Valley had a bit of an ageism problem.

And there were loads of incredibly talented people with families who were aged between 35 and 45, who was struggling to get jobs at hip startups because they looked too fucking wrong.

Because people are ageist.

And instead could work at GE and they get a car and a house and a job and a school nearby for their two kids.

Really got good model and they thought, "Hey, these people are underserved by the market. Let's make them really comfortable and happy and give them some cool stuff to do."

And I remember talking to those people at these kinds of meetups we have, and they're super excited because they'd been on the sort of architect track now for a few years.

And then now an architect in charge of other architects.

This is the kind of role you have in these large companies.

And they've been using Spring for five years and deep, deep down they know that there's something not quite right.

We're just doing web apps using EJBs with Spring wrappers around because it's 2012, now, and people stopped doing that in 2008.

And now you show them, "Hey, look, you can do this thing, which runs in the cloud and uses Netflix and you can do a circuit breaker, which means that now you are back on the forefront of technology.

So you're working at this big trusted company, which is very important because you've got family, you've got a partner and children and all this stuff that you're looking after with this salary, not as high risk is that you're getting to work with the coolest technology building the hot new things."

And this is how you make an existing Spring developer happy because you give them something back that was lost.

And it's also how you win the hearts and minds of people who are saying, "Well, Spring lost interest for me from outside."

You say, "No, look, actually, these cool tools that you want to use, you can use even more if you get into the whole Spring framework."

Now that doesn't work with everybody, but what was one of the cool about this platform concept that I think Maven used under the hub to create these packaged distributions is that you could take existing combinations of software and make them available for sharing.

So that you'd have a Docker Hub style download center for different packages.

And again, that means that the barrier to entry of solving real problems is reduced because somebody goes, "Hey, I can get this thing, which already solves my problem."

And all of that is how you win the trust back.

Grant: Yeah, that's super helpful.

Alexis: And I will say that I was involved at some important moments, but this changed to many, many, many years.

And I left Pivotal in May, June, 2014. And he wasn't really into, I'd say 16 and 17, that this thing was out of the woods.

So you should talk to people who were there for the next couple of years and get their take because it was an interesting time as well.

Grant: Yeah. I mean, that's a hard transition for any kind of brand make and rebuild that trust and to get folks back to believing.

But I think your point of work with these sort of influential brands and then help, like have a halo effect from them is a really, really great insight.

So now you're still at Pivotal, Kubernetes launches where you found Weave, how did Weaveworks get started? What's the context there?

Alexis: So we were at Pivotal in addition to I spending most of my time on Spring, but also trying to stay involved for Rabbit and Redis teams.

One is an enterprise, Redis offering and Rabbit as a service, the Cloud Foundry and vFabric.

And we were all moving towards a Cloud Foundry based market model that we'd say whatever you do just buy Pivotal Cloud Foundry.

And then all the other things around the side will be jammed into that somehow.

So vFabric components will be refactored, re-provisioned into the new model and so on.

At one point the whole thing was called Platform one, which I thought was a better name, anyway.

So what we found was that writing cloud services like Rabbit as a service was not really easy inside the Cloud Foundry model, because really you're building something inside Heroku, which actually should be sitting outside Heroku as a backend service at the time, I'm talking about 2013 Cloud Foundry architecture looked a lot, like Heroku did at the time.

I mean, it's diverged since then.

Grant: Right.

Alexis: There are some technical reasons like, Cloud Foundry load balances through the web server and the database connection.

And actually what you really want is just one tier of Rabbit service with some TCP in front of them, instead of HTTP connections and so on.

And then the same for Redis and the hard things that sort of doing things like billing, quotas, distributing users across your firm, managing the firm capacity efficiently, 24/7 uptime log rotation, all of those classic software as a service things.

And there wasn't much in Cloud Foundry to help you do that, to have these additional items.

So then Docker arrives and I could see that it had all the right ingredients.

So the thing that we've been looking at i f you've been in this space since 2005, messing around with this problem set from all different directions, you start to get pattern recognition as to what it's going to be useful here. And there were things in Docker that were already identical to stuff that was in Cloud Foundry already, but it was also pulled out of the past and made its own thing. And it had its own packaging model, its own run time.

It retained its possibility and critical to all of this was that it was oriented towards developers using these operator tools and previously with Cloud Foundry at Heroku had also a lot of the stuff that I messed around with before that, these were very operator centric environments and Docker seems to be the first thing that said, this can be a developer facing thing with the same granularity as operator tools, without being a full pass.

And it might be more useful to have portable fast containers that are packaged runtime, that you can run anywhere than to have VMs or applications in the past.

It's a radical idea. We could see that this is how you could build a relatively portable data oriented messaging service this way, caching service this way.

And you could do a lot of other things this way.

You wouldn't believe how many customers we've worked with around the building application out of VMs model.

And we'd seen some successes, but at the end of the day, it's not using Lego and you're using DuPlo, which is the Lego for two year olds, the giant bricks.

Instead, what you want is modern Lego with tiny little bricks that you can make more kind of complex things out of, that resemble real things.

And the DuPlo is very limiting. It's could only fit together in certain ways.

It was big and funky. It's an analogy obviously, and containers just seem to be a lot closer to what people needed as the component model.

So we just thought, okay, let's leave and focus on containers.

And I reunited with the CTO of Rabbit, Matthias, who worked with me creating Rabbit in the first place and stayed at VMware with me, he previously founded LShift, which is the company we partnered with.

And we saw the market is very unclear, why don't we just build something that seems to be useful?

And we've been experimenting the base and can see that software defined networks, very, very powerful tools when it came to creating these cloud services.

And we thought that was one of the things application developers would need.

So we wrote Weave Net that became popular pretty quickly because there was no network at the time.

And then we got some funding and fairly rapidly moved on to trying to build out more tools.

Funny enough, Weaveworks was founded on the 10th of July, 2014, which is within the seven days of Kubernetes being announced.

And I remember just thinking, wow, what a stupid name.

This is typical of Google to take a stupid name for technology, but actually they did a really good thing.

It takes a while to get our heads around Kubernetes.

We started using it fairly early on, but it took us at least to kind of another 18 months to kind of trust it as a platform.

And 18 months of that time was also spent kind of slowly losing faith in Docker a little bit as the center of the universe or more as a component of the universe, which I think is probably a better place.

Yeah, that's kind of it on the Kubernetes front.

Grant: Yeah. I mean, so you started Weave and it was Weaveworks and you basically built it around this idea of networking to start.

So that was the first product of Weave Net and it's kind of like, you're still an open source project that's quite popular people use to sort of run the network, but it was all around Docker sort of Docker, you sort of had the same insight that we did, which was containerization, was going to change the way that applications were developed and deployed.

It was this new platform shift. Did you see the sort of business model?

Was it like, okay, we're going to open source this product, and then we're going to build more products, we're going to then do an enterprise version, supported version.

How did you imagine the business evolving?

Alexis: Yeah, I think that's where we probably should have thought a little bit harder.

So one of the things I learned at Pivotal was Spring just had so many users and Rabbit had so many users and Redis had so many users and we were not really doing a good enough job to maximize our marketing and sales to that developer base.

And if we assume that they would also be using containers and moving into the cloud, it should be a developer centric, bottoms-up marketing model for selling people, products and solutions that took advantage of the very large population of developers rather than doing the one by one enterprise sales that we'd seen ourselves doing at VMware and Pivotal.

So we'd had these sort of split brand scenario where we'd had very popular developer tools, but no direct market sales motion for them.

Instead, we've sold to large enterprises that were using those tools and there was very little connection between those two.

There was no customer journey or progression.

It was all outbound sales and it was basically based on things like application modernization and so on.

And I thought that we could do this with containers and we could start with networking and then build management, monitoring tools around that, which would help people see how their applications were behaving and let them manage them better.

The problem was that we chose to do this in an orchestrator neutral way, and we also chose to only address the developer end of the market.

And as it turns out, those are two both wrong things to do because you couldn't really do any kind of management monitoring or talking the orchestrator more than we were doing.

I mean, we're talking to it a bit, but not enough to really try to change.

Yeah, the other mistake was to think that developers would present this kind of homogeneous market that we could sell to, but actually all these developers are doing different things.

They were using different tools, free Docker, paid Docker ECS, free Kubernetes, different ways of using Kubernetes from different vendors, masters fair marathon, blah, blah, blah, blah, blah.

Instead, it was very hard to tap into that market coherently without a very, very clear value proposition.

And even then there just weren't enough people using the cloud because people were stuck doing enterprise promises of containers.

So it took us a while to adjust to that.

We wrote a SaaS product, which was aimed at solving problems, day two problems for developers apps in the cloud and found that people liked it, but they came back and they said, "We love your app, we might even use it when we get to day two. But right now we're really stuck just getting our first thing working with Kubernetes."

And you hear this again and again and again, and then suddenly you realize that people are going to be more interested in the Kubernetes infrastructure that you've built to run the app, the SaaS app, than the SaaS app itself.

So that's when we flipped our business upside down and said, right, we're just going to sell this Kubernetes know-how.

There were some pieces in common, like our SaaS use the tool called flux, which I think user replicated to do deployment, but we also use the POJO, Kubernetes stacks for our SaaS as well.

So that was a key piece of open-source that we continued to push.

And then we started talking about GitOps, which was the description we came up with for how we were managing our whole infrastructure environment automatically.

And the worst, very specific things about that, which we've talked about endlessly in public.

So, then we became an enterprise software company and I'd sworn when I started Weaveworks that we were not going to get on a plane to see a customer ever again.

And we would just do the SaaS thing and we would develop it first and it would be great because people would just put their credit cards into the window on that screen and everything perfect.

We just sit there making money.

And obviously that was really stupid.

Nobody because the market wasn't there, the need wasn't there, too early.

The market was fragmented. It was really an enterprise market. The market was wrong.

I talked to a friend of mine, who's a VC, Lenny Cross.

And he was saying, "Oh yeah, I was involved with Datadog in the early days. And they spent ages hand-holding their SaaS customers.

But before the whole thing became what you now see, which is this apparently seamless and easy self service experience and you're going, wow, they've already cracked it there were years and years and years of pain of wondering where the whole SaaS value was going to come from because every single customer needed unique amounts of love and attention."

Just that's when I realized that we just didn't nearly have enough budget to do this as a SaaS offering.

We were nowhere near what we needed to be.

But what we did have was a group of people with some great open source that we built for deploying and managing Kubernetes, plus we knew how to do enterprise sales because of the shared brutality of having done it for 15 years.

So we had folks who've done it with Linux. We had folks who've done it with middleware.

We had folks who've done it with other things too.

So that's what we've been doing since that 2015, 16 or thereabouts.

Grant: Yeah. I mean, this is one so common.

Everybody is like, "I don't want to do enterprise sales anymore. I just want to get credit cards and there's no sales people, there's no... it's like, I just..."

Alexis: Well them not having salespeople, but they can be remote and they can do inside sales or they can be set to the SDRs, but actually...

Grant: True.

Alexis: No, that's all bullshit. You've got to have the usual people and that can really cost your business.

Grant: Yeah. If you're going to build a company like in our space...

I mean, potentially with just with our know-how too, like the products that we build, the things that we know how to do are probably more tailored towards the enterprise market.

But I mean, several things that you've done so well at Weaveworks like the GitOps movement, you really defined it and it's--

I don't know, I think it's a foundation of other infrastructure software and I think you've done a great job of really describing that out to the world and helping people understand and adopt it.

Do you feel like you're commercializing GitOps as well as you could?

Or are there more visions around how to commercialize GitOps or is it more about, hey, we just want to be like use GitOps as the spear to be a great Kubernetes partner for people over time?

Alexis: I think we're entering a phase with our new product, Weave GitOps, where we will be commercializing it much more explicitly.

Grant: Cool.

Alexis: Go have a look at that, it's early days.

I mean, we've basically got a bunch of enterprise GitOps features, which used to be part of our Weave Kubernetes platform but now part of Weave GitOps enterprise and we're leaning into GitOps much more there now.

And we're doing a lot with our Kubernetes partners.

So we have the ability to deploy clusters and manage them for you, if you want.

We do a lot of that with things like Telco on bare metal, 5G edge, but there are also many, many cases where there's a perfectly good Kubernetes and now already, maybe it's Rancher, maybe it's OpenShift, maybe it's Replicated, maybe it's EKS--

Maybe it's all of these things. That's another thing we see quite a bit.

They've bought everything.

And you want to go up a level and you want to focus on, GitOps for applications, progressive delivery canaries, and then do this, a fleet management and do it full stack.

I want to deploy this cluster with these add-ons to have an ML stack.

So all of that is where it GitOps is taking us.

And then you just integrate things like security and policy into that to make it enterprise ready.

The bridge between that and our free products is through the middle tier.

So we've got a still very early bundle, Weave GitOps score, which is the entry point to that.

But that'll take us much more to a HashiCorp style model where you go free upstream in the foundation, free entry point, and then up into the upsells from there because people just want to do GitOps and that means that we can be a great GitOps partner for anyone doing anything with Kubernetes quite frankly.

Most of our business at the moment is with cloud partners, but we're doing a lot direct and we'd be happy to take on more partners.

I would say that we very, very deliberately decided at the beginning of all of this, that we weren't going to try and turn GitOps into a product or something we could copyright or merchandise or lay claim to, because it felt a lot like DevOps, but something that could have a more precise definition.

And I agree with you, if you really understand what's going on, it's truly foundational and absolutely critical and it's actually how everything is going to operate eventually, which is not there yet.

There's so many great pieces, infrastructures, code and so on, and it's an industry job to get that.

So there's no point in any one company trying to be the controller vault, but we can say we're the GitOps company, but frankly, so can anybody else.

What we didn't want to see happen is diffusion like DevOps and Agile, which kind of means something, but also--

We're all recognized by family resemblance and pattern recognition when things are really not Agile, when things are really not DevOps.

But we can very easily disagree about when two things are and how they differ.

So we wanted something that could be a bit more precise.

So did Amazon, Microsoft, Codefresh and Red Hat and some others.

So we formed this GitOps working group initiative inside CNCF an existing trusted foundation for company neutral collaboration.

And I can't remember whether Replicator are involved in that conversation, but there's a whole group of community people who are sort of helping to gradually write down a relatively simple definition of GitOps.

So people understand even what it means for the simple cases and then things like fleets and templates and scale and so on.

Grant: I love that.

Alexis: And that will allow people to be a little bit more precise.

We're still going to get ridiculous disagreements, but it will mean that it's less of a joke when people do.

So yeah, I think we're going to lean in to GitOps more commercially, but also we're not there saying we're the only people with GitOps capability.

Grant: Right.

Alexis: Because that would be silly.

Grant: Yeah.

I mean, it's not GitOps TM, it's like GitsOps this is the thing that we believe in and it's a philosophy and it's a pattern that everyone is going to be using over time. That makes a lot of sense.

We've been big fans of it. I mean, Mark, my co-founder, has been a massive GitOps supporter since the first blog post and it just made so much sense to him.

So yeah, I think that's really smart to sort of move into that more and more as a product around it and sort of a real strategy around helping companies to actually accomplish it.

Alexis: Yeah. So if you're listening to this call, you want GitOps, get in touch.

Grant: Love that. And then what's in the future?

What else is going on at Weavewoks, where do you see the market going? Kind of parting thoughts here.

Alexis: So when the CNCF was first formed, we use the same technique as with Spring and Netflix to attach brands to it.

So the Kubernetes brand, permits this brand and that created this pool of concentrated attention, which is moving very fast.

And I think that now we're in as a more mature state where we're starting to see the emergence of a common set of tools that people can more or less agree on.

In many cases, there's more than one tool and that's fine.

Sometimes they overlap. Sometimes they don't.

In other cases, there is one obvious standard like Kubernetes, doesn't mean it will be here forever.

It could probably evolve into a whole new life form and there could be alternatives, but this is a tool share, and we can be pretty confident about for a while, like Linux in the 90s and the web.

So I think now into the second stage of what can we do with this?

And so we're looking for what is the iPhone moment?

What is the cloud business opportunity created by this?

Where are the entrepreneurs going to come from to change the nature of the game here?

Because we see the demand.

We see the demand because we have got an incredible infrastructure coming through with cloud hyper scale, data centers, everywhere, machines on demand, charged relatively cheap, 5G networks, very high bandwidth communication to make a whole compute fabric runs everywhere around the world.

And that's just going to grow and grow and grow.

We also have companies that want to use digital experiences for everything, whether it's booking a hotel room or talking to a friend or, something I haven't thought of yet involving drones and IOT or something like that, all these possibilities, will all run on this infrastructure.

And there's-- I mean, system that need to be hundreds of millions of developers, hundreds of millions of developers, are they going to use tools which are being invented now and not going to care about tools that existed before now?

Well, they might, but they'll see them as old hat.

So this is the opportunity to create the-- develop a paradigm for operations, have application development, all of these hundreds of millions of people for the next 10, 20 years.

And that I think is just incredibly exciting.

Grant: I love that. We're in for the same journey.

So thank you so much for joining. It was really insightful.

I loved hearing kind of the context around the different companies you've been involved in and what you've learned along the way, and really excited about the future of Weaveworks and where you're going from here.

So thank you so much.

Alexis: Thank you very much Grant.