Ep. #23, Cloud Infrastructure with Abby Kearns of Cloud Foundry Foundation

Grant Miller: All right, Abby. Thank you so much for joining us.

Abby Kearns: Thank you for having me, Grant. I am super excited.

Grant: Great. Let's just jump right in. Let's hear a little bit about your background and how you got into enterprise software.

Abby: When I graduated from college with my BS in computer information systems, which I actually don't think is a degree anymore, but essentially it was a comp sci degree with a couple of business classes.

The first job I was able to get, because I graduated in the height of when the bubble first burst in 2000, so I took the first job I could get which was working for Sabre.

For those of you that travel a lot, you'll know it is the reservation system behind American Airlines and many others.

I got a job there as a project manager on the global infrastructure team and was managing infrastructure implementations and large scale infrastructure rotations, and I got hooked.

I've been in enterprise infrastructure ever since. I moved into software about 5-6 years ago when this thing called "The cloud" started getting real traction, and I've been here ever since.

I can't think of a more exciting place to be right now in the world.

Grant: You mentioned enterprise infrastructure versus enterprise software, how do you define the difference between those two?

Abby:

Nowadays the line is super blurry. But back in the day, enterprise infrastructure was things like servers and racks and data centers, and the software was something you put on top of the infrastructure, and it was completely separate in an enterprise.

Most of the actual development work for any custom software was actually done with offshore teams, and so there was a lot of hard paths.

You implemented the infrastructure, you ordered the servers and the network gear, and you racked and stacked them and put them in data centers, and you cabled them up.

Then somebody came along and laid down the operating systems and a lot of the drivers and did the configurations on firewalls, and then after that you deployed any of the custom software that you were implementing.

I worked a lot of e-commerce, so we did a lot of ATG and WebSphere implementations, so there was a real clear delineation between what was infrastructure and what was software.

Now it's been super exciting to see those lines blur over the last 5-6-7 years, as what's defined as "Software" and what's defined as "Infrastructure" are really merging.

It's exciting, but I also worry that we're losing sight of what that actually means.

Grant: That's really interesting. I don't think about it, I tell people that Replicated is infrastructure software.

That's just how I think about the world, so I guess to your point it's that cloud abstraction and the ability to abstract away to hardware that allows that to be so true.

But in your mind, you're saying "One, it's not actually how it is. There is still hardware behind that."

But you think about enterprise infrastructure as the real physical pieces that allow for the software to run. Is that right?

Abby: Yeah. I think my concern along those lines is that when we talk about-- With cloud, we spend a lot of time--

I know I spend a lot of time talking about "The cloud," and the magic that happens in "The cloud."

I think we've lost sight that that's actually still hardware that's running in a datacenter somewhere, and a lot of the problems are still the same.

We've added abstraction layers to a lot of them, and there is a ton of automation that exists now that didn't exist 10-20 years ago.

But there's still hardware, and I think "Yes. It's so awesome what all of this software-defined infrastructure does in terms of both networking, automation, replication, what a lot of this technology is bringing to the table.

But I also worry that we're losing sight of what that means, and what are we automating? What's the point of that automation?"

For me, I still find it quite magical to be able to spin up a VM in 30 seconds. I remember the effort it took to order that server, rack it, stack it and cable it, and get it online.

I remember all of the effort it used to take, so I think if you haven't had to do the work you don't appreciate what's automated, but you also don't understand the ramifications of that automation.

I think that's my worry about where we are right now.

Grant: Interesting. What do you think the downstream effects of that are?

Abby: Everything from the way we think about, "What does resiliency even mean anymore?"

Architecting your applications for resiliency, but not assuming that the cloud is going to take care of that for you.

Prior to thinking about cloud native architectures, it was all about BCDR.

"Business continuity, disaster recovery," and the way you thought about "How am I going to handle this if there is an outage in the data center?"

Trust me, there's always an outage in every data center and that still continues today.

There's always going to be some failure, so how do you architect your applications for resiliency in the face of failure? How do you think about scale?

I think one of the great forcing functions when you're having to order hardware and install it and configure it, that was a really great forcing function to think about what you're doing because you had time.

You had to wait, you had to think ahead of time about scale and how much capacity you were going to need at a web layer, at an application layer, at a database layer.

You had to really think through all of that and plan it out because that was months lead time getting up to that.

One of the things that you don't have to think about now is that you can automatically spin up VMs and containers, and you can setup a solid resiliency, but you're not putting a lot of thought into what you're doing and why.

When you don't have to think about it, you run the risk of not properly thinking about resiliency for your applications.

Not thinking about the capacity that you need, just assuming it will be there, and also not thinking about what you need to shut down or reallocate.

So you have that sprawl that exists, too.

Grant: It's interesting, the level of thinking that is required in order to build for systems when you were doing it on physical boxes, it's pretty intense.

Abby: You had to think it through. You weren't just going to have a DL380 tomorrow, so you had to put some thought into it.

Grant: But one of the challenges is that everyone, because they were thinking it through themselves, invented a different way to do it every time.

You just didn't have the well-defined patterns and primitives that I think we have today that allow us to get there faster.

I think if you parallel it to security, like when people were doing their own-- Writing their own crypto algorithms in order to encrypt something, it's like "That's not really the best way."

So maybe these new patterns and primitives can provide a faster path to better systems.

Abby: I agree. I think we've gone so far and we've done -- You're able to do so much, and it is of better quality because you can do that.

You can replicate patterns and you can leverage a greater breadth of standardization around it, but what I hear a lot are people not fully thinking through what they're doing. That's my concern.

Why do you have this? Where are you scaled out to? What clouds are you running on and why?

Your own data centers, why do you have this deployment and what the intent of it is?

I think when anyone ever asks my opinion around the way they should think about what new technologies to adopt or how to build out cloud native architectures, I always come back to "What are you solving for? What do you hope to gain? What is the outcome you want?"

Back into that, as opposed to "We're going to deploy some stuff on the cloud and hope for the best."

Grant: You don't just go to whatever's trending on Twitter?

Abby: That is a way. I don't know that it's going to result in the best outcomes for you, but you'll certainly score one for buzzword bingo.

Grant: That's interesting. You think about the outcomes, dive into that. What are some different paths?

If the answer is "It depends," what are some of the details that it depends on?

Abby: I think anyone that ever says "I want to move to the cloud because I want to move to the cloud," you're like "OK. That's not a reason to move to the cloud.

The cloud is not some magical place that's going to solve all your problems. In fact, depending on your types of applications, the types of workloads and what you're hoping to do, it could be a disaster for you."

So if my goal is to have better control of my applications, be able to iterate more, be able to write more new cloud applications as I'm trying to digitize my business.

That's great. Let's talk about that. Let's figure out, "What does that mean? When you say velocity, what does that mean?

How is your team structured around that? What types of applications are you using and developing? What is the back end on that?

What are your systems of record? Where are those located?" All of these things should still be part of the consideration.

I'm not saying that you shouldn't move to the cloud, I'm just saying that it may not be the right approach for everything that you do.

Grant: I think what would maybe be helpful right now is even just a little more detail around after you were doing infrastructure, what you got into software and how you were doing that, and what your role is today? I think it would be great context.

Abby: Today I run Cloud Foundry Foundation, an open source software foundation that sits at the heart of a lot of what these different movements are, which is the open source cloud native architecture movement and the Enterprise Digital Transformation Movement, as well as the technology provider and hyperscale cloud provider thrust to be part of this space.

It's a really interesting apex of a lot of different trends that are both hitting all at the same time, but also feeding each other.

It's a really interesting moment in time, so I've been part of the Cloud Foundry community for over five years.

I was at Pivotal prior to joining the foundation, so I've been on this journey with Cloud Foundry since the early days and it's been a really exciting opportunity to watch the role platform as a service can play in the enterprise.

The whole purpose of it, which isn't just because it provides a highly automated abstraction layer on the underlying infrastructure, but also because it really offers a great forcing function for organizations that are looking to push more agile teams.

That's been a really exciting evolution, and I think it's also taught me a lot about patience that I don't possess as a common trait of mine.

I'm not very patient, I'm aspirationally patient, but I think you're more patient than I am, Grant.

I am very impatient, so being in open source and working with enterprises tends to be a really good forcing function to slow down and think about things.

As I think about where all of the technology is unfolding, I've really brought that back to "How do I take a moment and think about where we're going and why, and then what role does technology solve in that?"

Grant: Throughout your experience, like at both Pivotal and Cloud Foundry.

You've worked a lot with some of the biggest companies in the world as they make that transition to cloud, as they make that transition to a more agile development.

I always thought the idea of digital transformation was somewhat a bullshit marketing term.

Abby: A lot of people do.

Grant: But I now acknowledge that every company has to become a software company in some capacity, it's the only way that you're going to be able to compete and run as fast as the next generation of companies that are going to be software-enabled.

It actually started to make sense to me at some point.

That's what it means to me, is that the same thing that it means to you?

Abby: Sort of. I'm a little more humble in that I do think that not every company wants to be a software company.

I tend to modify that a little bit to say that "Every company wants to digitize their business with technology," and I qualify it that way because I used to say it the other way, but I feel like that shouldn't be everyone's goal.

I think everyone should try to use technology to solve their business problem, not necessarily become their business.

I do think there is a slight nuance there, but it's also important as we think about the role our technologies that we create as technologists play.

Like, our technology shouldn't be used for the sake of using technology .

Our technology should be used to solve a business problem, either that is making your business more efficient through automation, through supply chain management, logistics automations, to changing the way you engage with your customers through either mobile apps or web apps or highly automated experience in terms of notifications. But it should be there in the background serving an outcome for your business, it shouldn't be your business.

Now, I'm being a little pedantic about it because obviously the things I just listed are done through technology and they're done primarily through software.

But I also want to make sure that we, as technologists, recognize that our technology is here to be part of a larger solution to solve an outcome, and that you're not investing in this technology for the sole purpose of that singular technology.

Grant: I get your point, which is - - I think I totally agree.

Technology for technology's sake is just not it.

Even at a software company, when you're building software and that is the thing you're selling, you're still selling the value and the product that solves a problem for a customer.

The technical implementation and how beautiful the code is, that's not the product.

The product is "How does someone use it? How do it provide value to them? How does it make their life easier, or whatever else?"

Abby: I'm being particular about it because I do find that a lot of us, particularly in the cloud native ecosystems, spend so much time talking about this one piece attack that's going to be everything.

It's going to solve everything, it's going to automate your life, it's going to make your toast, it's going to turn -- It's going to do everything for you.

I get the point of the hype and I get the conversation around it, but I also like to caution to say "Sure. But this is a piece of a larger puzzle.

Everything that we're all working on is a piece of a larger puzzle that is solving a bigger problem, so as we tell that story and we think about it, how do we describe it in a way that says 'We're working on this larger solution?'

It can automate so many things, it can pull so many different technologies together, but at the end of the day it's going to be part of a larger puzzle as you, the customer, works on using this to improve your business."

I'm going to get on my soapbox here for a second, Grant.

Grant: Perfect, I love it.

Abby: I feel like we sit around and talk about-- To use your earlier phrase, "What's trending on Twitter," and it's like "Oh my God, it does everything."

I also find that we start using the same words to describe a lot of different technologies, particularly in the cloud native space.

I look at some websites and I'll have to read it three or four times, and I'll honestly--

I'll ask a founder, "I read your website and I have no idea what you do. You used all the same words that everybody else does. 'It's cloud native. It's for enterprise. It's software -defined.' Sure, but what does that actually mean? What are you actually doing?"

I am deeply empathetic for enterprises and even CIOs and CTOs that are like, "I don't even know what this means."

Grant: That's an interesting point, because I think it's often hard for software vendors to talk about their products beyond just the features.

Beyond the marketing terms that drive interest, like what's the value it provides.

How do you think about discovering the right way to describe the value of your software, if you're selling software?

Abby: By the way, I'm just as guilty of this as anyone else.

I'm not going to say that I'm above this, but I do think it would be great if we could all sit down-- Maybe this is because I'm an open source, and so my open source d-ness is coming out.

Which, by the way, is that a description? "Open sourced-ness?"

Grant: Definitely.

Abby: That community-driven approach to solving problems.

It would be like, "Maybe we all sit down in a room. A good like 60-70 of us, and just have a conversation about how we should talk about this and how do all these different things slot into that, and how do we tell this story in a way that doesn't really come back to the same two or three one-liners?"

I think that could be fun, and if not else, it would be really great off site.

But I do think it would be interesting, because I struggle to explain it sometimes to people that are new to technology and are asking me, "OK. What does all of this mean? How does all of this fit together?

Like, if I'm trying to build out a new application portfolio or a technology portfolio for my business, which ones do I choose and why do I choose?

All of them? Some of them? Half of them?"

I do worry that there's so many different choices and so many different things that are top of mind and top of conversation, how do you tell someone what to choose and why and when?

I'm sure you struggle with it as you think about how your technology slots in with other things as well.

Grant: The challenges are that it's an ever changing landscape, so things are evolving, particularly in the cloud native ecosystem. It's just so fast.

To position what you're doing in a way that makes sense to your target audience, who sometimes are early adopters, I think particularly for some of these ecosystems where you don't really need the person who doesn't really understand the buzzword you're using to understand it.

Because you only need early adopters in the beginning, because they're the folks who are going to suffer through the pain and they're going to give you the feedback and be the first folks to use your thing because they want it, because it's new and because it has promise.

But then, eventually I think that these technologies need to settle down to more value-based things.

How do you describe this in a way that anyone from any large company can understand it?

People can talk through it, and even procurement people know why you're paying so much for this?

Abby: I agree. How do we even explain it to someone in procurement that is used to buying off the shelf software and trying to figure out how to relate this to ROI and standards that they have in place today?

I think it's hard. I come back to "It's pieces of a puzzle, and figuring out what you want the puzzle to look like."

But I also really understand how complicated it is right now.

Like, do you use the latest technology that's open source or do you choose a fully wholly integrated solution that may not incorporate everything that you want, but at least gives you a single channel end to take an advantage of some of these technologies as they come up?

I think it's a difficult thing to weigh .

Grant: To your point, I think there's a lot of words. This is one of the goals of EnterpriseReady, is to help create a common vernacular so that way when we're talking about things people aren't talking past each other, but they're using words with the same meeting.

Because I think oftentimes we use words and we have a specific connotation around what it means to us, but somebody else hears it and it means something completely different to them.

I think it's really important, particularly with folks from different worlds, if it's cutting edge startup and technology vendor meets enterprise or just people of different adopter curves to spend some of the time upfront establishing that vernacular.

Saying, "We're going to define a few terms because we think it's important for us to know what we're talking about when I say--" Even "Cloud" is a term that I feel like people have different definitions of, and when you say it some people think one thing versus another.

Abby: Some people think cloud is this magical data center in the sky that's wholly different from a data center that you're familiar with, and it's not.

It's a data center. It's got a really fantastic API on top of it and great SaaS operating around it, but the day it's still somebody's data center.

Grant: It's funny, because my definition of cloud is closer to infrastructure as a service. That's how I think about cloud.

I think the hyper clouds are the term I've heard more and more recently, I don't know why, but that's the big three providers.

Then I think that there's software as a service, which I put separate, and I think about the services that are offered probably on top of some other cloud that are offered as software that you can access and leverage making it even more confusing.

Some of the cloud vendors, the infrastructure vendors, they almost all have additional software as a service offerings on top of their own cloud, so it embeds in itself.

But that's how I try to define it, I'm not sure if that meets your definitions.

We didn't even get into the idea of a private cloud, which you're very familiar with.

Abby: I think that also the challenges is the terms are changing.

When I think about "Hybrid cloud," I thought about the way I used to define it. "Hybrid cloud" is you have a private cloud and you're bursting into a public cloud somewhere.

Whereas now hybrid cloud has almost the same meaning as multi-cloud, which is you're running a variety of applications on a variety of clouds.

I think that's also problematic, the terms that we use for things are evolving.

For me, I think about the cloud as somebody else's data center that has a really nice API on top of it with a ton of automation, but they're managing it for you.

You have access to it through those APIs, and that's just the way that I think about it because I came at it from my career through an infrastructure standpoint.

I always come back to "Where are the servers? What is this? Where is the hardware that this sits on?"

I think about it hardware up as opposed to software down.

I just think that also plays into the way that I really take a step back and think about all of the things we're building and where they slot into the arc of the movement that's happening, as we're rewriting a lot of the technology that that really got us to where we are today.

I'm a big believer in multi-cloud, I think multi-cloud is here to stay.

I don't think all of the workloads are moving to public cloud, I think there's still a strong play for on-prem application workloads and I think there will be for a very long time, so I think there represents a tremendous opportunity as we think about "What does that mean?

How do you manage application workloads across a variety of data centers that may or may not be close located to each other?"

We have the speed of light problem, and you have a data problem at that point, and a networking problem at that point and an observability problem at that point.

So I still think there's a lot of problems left to solve as we think about what the future looks like at scale, but I always come back to "Where does the hardware sit, and what does that actually mean for the applications that run on top of it?"

Grant: That's really interesting.

We've come back to this point of seeing the world based on either infrastructure first or software first, infrastructure up versus software down.

I think you're right that perspective definitely changes how you think about the ecosystem, how you think about the applications and all the different components that make that up.

Because to your point, you're thinking through "What are the physical limitations?"

You talk about speed of light, so that's going to be a very hard problem for us to solve.

It is going to be a constraint that we have to work with and it's a constant, so we know that it will always be there.

But when you're thinking about the application down, it's just not something that you think about at all. Right?

Abby: No, because if you think about "I'll just always be able to deploy on somebody's infrastructure somewhere."

Maybe it speaks more to my lack of trust, I don't know if that's a whole separate podcast on trust issues that I have.

But thinking at it from the infrastructure layer means "OK, that has to be part of that consideration as I think about where my workloads go and why, and what does that mean for the rest of my architecture?"

I think through that. If latency is a problem for me, and that's something I think we'll speak a lot more about over the next couple of years as AI and ML workloads become more pavilion.

If latency is a problem for me, I have to have my applications near my data. Now, what does that mean?

That means that I may be limited where I can deploy my applications, and then you layer on the complexities of data sovereignty and things like GDPR and all of a sudden you have a very complex landscape as you think about where your workloads can go based on where the data is, based on the requirements you have around that data.

I'm not even factoring in-- Obviously at this point I'm really talking about security and compliance, which is a whole different layer on top of that.

Grant: From the way you're describing it, I think it feels like you're talking about it from the enterprise perspective around primarily leveraging first party software that they write and create internally.

But then there's the whole other aspect of third party application vendors who are trying to deliver applications and services to those organizations, and how should they think about how the downstream effects of these different regulations and compliance pieces impact how they need to look at that software or that service?

Abby: Yes, it's true in both. Even if you're just operating a SaaS, it's something you have to think about.

If your customer, an enterprise customer wants to consume your product on-prem because they have on-prem requirements, either from a security compliance standpoint or a pure latency standpoint.

How do you service that? How do you deliver that? How do you measure against that, as well?

I think those are our requirements on either end of that spectrum, but are very much an important part of the conversation.

Grant: Luckily, that problem is solved with Replicated, so we don't have to go into that too deep detail.

Abby: Great.

Grant: Cool. One of the things that I love about you, is you have some really interesting experience in China.

I think there's this big opportunity that not many people really understand, and if you look at some of the biggest companies in the world right now they are some Chinese technology companies.

But I love your perspective on how software folks and vendors should think about China and the opportunities there.

Anything, any advice you have on that side?

Abby: Oh my God, I love China. The last 18 months I've been there six times. In fact, I was just in China last week.

You mentioned top three cloud providers, and when I think about hyperscale cloud providers I tend to think of top four. I include Alibaba in that list.

Grant: That makes sense.

Abby: I know Alibaba isn't as prominent here in North America, but outside of North America it is very big.

Alibaba and Huawei are very big in terms of public cloud providers outside of North America.

Thinking about not just China, but Europe, Southeast Asia, Latin America.

I think we lose sight of that within the confines of the United States, but there is a whole wide world out there of companies, technology companies, that are building and growing and running at an amazing scale that I don't know that we often fully appreciate here in the United States.

I get really excited about China because it's such an interesting market that is so different from any other market.

It's moving so quickly and at a different scale that it's really hard for us to wrap our head around here in the United States.

The scale that companies operate in China, that startups operate in China, and how fast when they launch the reach and the impact that they have.

I think that there is a ton of innovation and iteration that's happening in China that I don't often think we get enough credit for, particularly in AI.

The work they're doing in AI is just so phenomenal in China.

The opportunities that exist because of their massive data sets is the ability to really work on and develop against AI at a much faster pace.

I think just from an interesting market standpoint China's super fascinating, but I think selling and delivering in China as a technology company there's a ton of opportunity.

It's also really complicated right now with the trade wars and the scrutiny that's happening on services delivered to China and from China.

I think that makes, particularly if you're a startup or a small company, that's obviously super complicated and really hard to figure out how to navigate.

But if you are up for the challenge, there's just such an interesting market there.

Grant: Do you have any examples of companies in the US that are technology companies that have been pretty successful with delivering enterprise software or some other type of software into China?

Abby: You have to structure in such a way, but Elastic is very popular in China.

Grant: Interesting.

Abby: Just to name one off the top of my head. There's a lot of technologies, particularly open source is becoming very popular in China.

There's also a lot of homegrown technologies that are also being incubated and developed there.

It's just such a different scale, and the way they think about development and iteration is so different.

We like to say that we iterate quickly here in Silicon Valley and Belfast, but comparatively we're pretty conservative.

In China, they will iterate quickly and they will fail fast, and they will be "OK. Let's learn from that and move on."

I think it just happens at such a faster pace sometimes that I'm always really impressed about how quickly things can move.

Grant: I'm guessing Elastic was successful there based on some open source adoption, and then started to enter the market?

Abby: Yes, that's my understanding.

Obviously I don't work there and can't really speak to their sales motions in China, but I do know that they've been-- I hear them talked about quite a bit when I'm in China.

Grant: Interesting. It feels like a whole other world. There's different go-to market, different technology adoption.

In previous roles I was working for a SaaS company and I helped open up Japan as a new market.

It was a unique experience, we got a local partner and we went to market that way.

That company always worked with the largest banks first in the country that it went to, so we got the banks as customers but it was still a very big investment.

That's a publicly traded SaaS company to open up a market in China or in Japan, and then I think China feels like a step beyond that in terms of accessibility and opportunity.

To your point the level of publication around not just IP, but also around these new modern contexts around trade wars and things, really complicated.

Do you have any advice for where someone should go to even think more about this, or learn more about how to do that?

Abby: Step one, I would say go to China.

It's one of those things it's hard to explain to someone unless you go and spend time there and go to the meetings and you listen to what people talk about.

You can't really say "It's like America, but a little different" because it's so wholly different. Just spending time there really helped me understand exactly where companies were in the adoption cycle, but also their understanding of tech and the role of the tech played in a lot of solutions that were being developed.

By the way, this is changing quickly. No joke, in the last year and a half from when I went in January 2018 to last week is so different.

It moves so quickly. It really does change, and it changes fast.

If you're considering going to China you definitely need to partner with someone, because as an American you cannot create a company there.

There's a lot of limitations around assets that you can own, including digital assets.

That has to be ran through local companies and local and Chinese nationals, so that's something you need to think about.

Who are you going to partner with and what does that partnership look like? How do you want to structure that partnership?

What does your go-to market look like? Because it's going to be very different in China.

What are the channels you're going to use?

For example, you can have a digital presence in China through a website, but if you're going to do any marketing a lot of that marketing push is going to happen through channels like WeChat.

Grant: Interesting.

Abby: The predominant conversations that happen, happen on WeChat.

That's how you meet people and that's how you exchange cards, that's how you communicate, but that's also how you start and initiate conversations and do marketing.

It's just a very different model than--

Grant: So, would you do a cold outbound via WeChat to someone who is a prospect at a big Chinese company?

Would that be an appropriate way to try to introduce your company and your service to someone? Like, the way we would do cold email here in the US?

Abby: I guess you could. I don't know how successful-- That might work, but I think more likely you would join and participate in a WeChat channel.

They have channels where you can have groups and conversation, group conversations, so you might join one of those and start one of those conversations.

Grant: Similar to Slack communities, basically.

Abby: Yeah, it's a lot like Slack, but more like Facebook Messenger. It's a combination of a lot of different things.

It's not identical to Slack, because for example, they don't hand out business cards in China.

They have them, but more often than not you scan your WeChat on the way out of the meeting.

I use WeChat 100 % when I'm there. That's how -- You don't email people, you WeChat.

Grant: This is such a crazy topic. I feel so uninformed. I have zero context, I've been to China once or twice.

It was an incredible experience as a tourist, but I didn't really do any business there.

This feels like such a crazy foreign topic, but definitely something that I've talked to you in the past and you've always been so excited about the opportunity there and the adoption of open source.

I'm always eager to hear how you feel about it.

Abby: I think China's super interesting. I think it's complicated, and I think it's wildly different.

I am always encouraging people to check your hubris at the door a little bit and go in with an open mind and listen, and just get a gauge for how things work, because it is very different.

If you go and expect the same level of discourse and same motions that you have here in the US or even in Europe, it's going to be very different.

It's just a very different offering model, but if you can partner with someone local like I have.

My team that I partner with that is local to China, they've really done a great job of educating me on how things work and why they work that way, and how to have really interesting conversations and what that means within the broader context of the company you're talking to.

Grant: That's for the Cloud Foundry Foundation?

Abby: Yeah.

Grant: Is that because there's a pretty broad adoption of Cloud Foundry within the companies over there, so you're trying to figure out how to get more companies involved?

Or, what are you doing in China today?

Abby: Membership. Obviously, getting new members.

But also we have some really great members there, Huawei and Alibaba are both gold members so I spend a lot of time with both of them.

Digital transformation is just hitting the enterprise in China now, so you're starting to see that uptake in conversation around platforms like Cloud Foundry, but also the digital transformation conversation is really starting to take off just now.

Huawei and Alibaba are trying to figure out what their cloud solutions are, and they're looking to what has been done in North America.

Because obviously, we started the digital transformation conversation in North America 4-5 years ago and Europe followed a couple of years after that, and then really now China is starting to really go into that conversation in greater depth.

Speaking to people that are users, but also providers, and figuring out the role Cloud Foundry can play in that market.

Grant: It's interesting, it made me think about the role of a software foundation like the Cloud Foundry Foundation and taking a step back--

I'm just going to take a little bit of a guess at one of the objectives.

When you think about why a foundation is created, obviously there's value around governance, but I just realized one of the other maybe primary reasons is really to provide--

You call it "Thought leadership," I call it "Category creation," you can call it "Education around a specific topic" that is going to drive the future of some type of technological change.

Do you agree with that statement?

Abby: Yeah, because a lot of the things that are important to us in North America are, and particularly on the technology side, are becoming important in China.

Cloud native architectures are becoming deeply important.

A lot of companies that provide cloud services just in China are trying to figure out "OK, how do I scale that and what does that look like beyond China?"

If you're in enterprise, "I'm really trying to digitize my business," if I am a bank in China "I'm also trying to become more agile because you have the fintech startups in North America and Europe, but in China it's growing like crazy."

WeBank is a digital only bank and is trying to change the paradigm in the way you think about infrastructure, so you have the same challenges in China, it's just happening at a very different scale.

Grant: But just in general, the idea of a foundation, even the Cloud Foundry Foundation, part of your founding purpose is to help disseminate and share a perspective and educate and help bring a new way of thinking into the market.

Do you agree with that, as a reason this would be around?

Abby: Well, I think our reason to be around is to hold and incur a sustainable ecosystem and community around the technology.

I also spend a third of my time educating people on the space, and "What does it mean? How does this all translate? How does this technology translate into the outcomes you're trying to go after?"

Digital transformation is a big topic that I speak a lot about, because that's mainly what Cloud Foundry is used for.

You can't really use the technology if you don't understand what it's solving for.

Grant: I think that's so true. Obviously, the first part is to be the governance and to make sure this is a project that lives beyond the company.

There is collaboration, but to your point it's about value and the value of this technology is--

I think I see the conversations that you lead as not about Cloud Foundry as a technology, but it's more about digital transformation.

Which I think is to your point, you're talking about value.

Abby: Yeah. It's a bad habit I'm trying to break, Grant. I can't help it. They're like "Why do I need a path?"

"You need a path because you're trying to develop more applications that scale faster." So it's back into that "What are you solving for?"

And then "This is why you need this."

Grant: Yeah. The "Why" is super important before you get into the "What" and the "How." You have to buy into the "Why."

Abby: I've been telling the Cloud Foundry story now for over five years, and I feel like I've perfected that.

I feel like five years ago I started with, "Let me explain to you how paths work. OK, do you know what a container is? Let's talk about that and then let's work from there."

Now I'm like, "What are you solving for? OK, now we'll back into that. Here's how technology enables that, but let's not start with what the technology is because that isn't answering your question."

Grant: The other part that leads me into is just about open source.

A lot of folks that are building open core, open source companies that are trying to think about the right way to manage that, do they donate it to a foundation?

Do they build their own foundation around it? Do they just manage it themselves?

I'm guessing you have a perspective on this and the advantages and disadvantages to those different approaches. Is that something you think about?

Abby: Oh my God, I have so many opinions on that.

Grant: Perfect.

Abby: I have opinions. First and foremost, this is my soapbox that I carry around is there's no such thing as an open source business model, period.

If you think you're going to develop a technology, open source it, and that's going to be your path to riches? You're going to be very sad. So, start with that.

Grant: I'm crying right now.

Abby: Are you? I'm sorry. If I'm crushing dreams, I'm really sorry, but I feel like someone needs to be honest.

There's pros and cons, like what's the point of a foundation? I do feel like there's a lot of unknowns about "What does a foundation actually do? Why do we need so many of them? There seems to be so many."

The purpose of a foundation is quite simple. A foundation is, in the United States our tax entity status is we are a 501-C6.

We are a non-profit, but we are not a philanthropy so you cannot donate money to me at Cloud Foundry Foundation and hope for a tax write-off.

We're not here to help you do good in the world. You can do good on top of us, but just recognizing that we're not a philanthropy.

The importance of the 501-C6 status is that-- What that means is we hold, as a foundation, we hold the IP and the trademark and the assets affiliated with Cloud Foundry.

I'll use Cloud Foundry as part of this description.

So, we hold the assets and those assets once transferred into our legal entity can never be transferred to a for-profit company.

That is super important, because that means no one can take their ball and go home.

Moving into a foundation is a great way to create a neutral territory and really enable trust, because at the end of the day what do you need if you want a successful open source project where you would like other people to contribute to have a community and to build an ecosystem? You need trust, first and foremost. A foundation helps create that trust because it is a neutral place where everyone can gather around and no one has the upper hand.

Now I realize there's a lot of ways you can gain the upper hand, and I won't go into those right now, but at the end of the day that's the whole point of a foundation.

It creates that neutral place, and the foundation's duty beyond holding the IP and the trademark is to really foster a sustainable ecosystem around that technology that extends the value and really enables growth and successful evolution of that technology, and to encourage and support the members that contribute to that.

A lot of that has to do with really telling a story and keeping people excited, because open source is super awesome and people love it and they get real excited about a project for the first year.

But after that, it gets super boring because--

To quote what other people have said much better than me, "You're chopping wood and carrying water and that's boring. Nobody wants to be here for the boring stuff. They want to be here for the sexy, cool, fun edge cases."

Keeping people excited and keeping that contribution going to the core parts of the technology are what I spend a lot of time doing, and that's done largely through marketing and awareness.

To go into, "Why would you open source anything?"

Open source is great because you can get other people to help you collaborate on the development of a technology.

So, collaborative R&D. It's a great way to get other people pulled in and to really accelerate the development of that technology.

It's also a great way to quickly build a community around that technology, as well as accelerate the ecosystem that you're building around that.

"What extends the value of your technology?" Open sourcing technology is a fantastic way to do all of those things while also helping, if you're doing grassroots development or hoping to do a grassroots outreach to developers, it is a fantastic way to do all of those things.

But if you're open sourcing, you also have to realize that you're now allowing other people to have control over your code.

When you open source something, you have to think, "Am I OK with someone else dictating how this software unfolds over time? Am I okay with other opinions dictating the roadmap and the direction?

Am I OK if someone else takes part of that and uses it for something else, or forks it and does something else with it entirely?

Or uses it to, if I made a for profit company, uses it to compete against me? Am I OK with that, and what does that look like for me?"

Also, there is work involved in developing and fostering a successful community. There's work involved in fostering a successful ecosystem.

Those are things that take time and effort, and they don't happen on their own.

Grant: It's interesting because I see open source still a bit differently.

Primarily because we don't have any massive open source projects or foundations, but we open source little components here and there.

Other pieces that we do, and part of the reason we open source stuff is, one, we think it's a great way to create transparency and visibility into what's actually happening.

If you're trying to do something and prove it's secure, having it open source allows people to vet and do their own audits and pieces of it.

The other part that we see is just marketing value.

Somebody can use your tool, they get some value out of it, maybe they find your primary service and maybe they want to work with you.

That being another key driver, partially because I think it is quite difficult to build an open source project that actually gets a community and gets contributions.

Those are pretty high bars if you think about open source.

Abby: They are. I have a question for you.

Grant: OK.

Abby: How many of those users that you have that use your open source tools, convert to paying customers?

Grant: We don't really know. You don't really know who's using your software when it's open source.

They can own it, they can just copy the code and they can get it however they want. They can start using it.

The only way that we know is when folks come to us and say, "We found that open source project created," or "We really love that thing you build and we've been using it."

So that's the only-- You never really, it's hard to get to a true conversion rate. Right?

Abby: Exactly. I'm just curious if you had a percentage of how you thought, but I think that's a great way to think about it, as a channel. It is a fantastic channel.

I think it provides a lot of value, but I started off with the open source as a business model because I think my perspective is you should have a business model and a business, and open source can be part of that but that can't be your whole business.

I was curious how you had it setup at Replicated, because I'm sure you have a business and a business model where open source is part of it, but it isn't the whole business.

Grant: Yeah, of course. We have additional components that are proprietary, we have a hosted service that's actually not the hosted version of the open source stuff.

It's just complementary to the open source components, so that's how we leverage open source.

Even the EnterpriseReady.io website is totally open source.

We wrote this content, we were like "We should just make this a collaborative thing, that if somebody wants to add some content into this guide to building better enterprise software, they should be able to make a pull request."

That has gotten some contributions, so I think content is a great way to leverage open source even though it's not code.

It's still something that as a community "We can all edit" Wiki kind of things than it is a truly open source project.

Abby: That's awesome. But I think that's the way you should think about it.

I think that's what you should think about open source too, is there's a lot of structure and framework and process about and around larger projects.

But think of them like a Wiki, you're contributing to the whole and you're participating in larger conversations and larger evolution.

I think that's a really important way to think about it, Grant.

There's a ton of opportunity in open source, and I know I sound a bit like a naysayer but I think people should think of open source in the way that it is.

Understanding the pragmatic aspects of it and there's a ton of value that can be garnered from it, but you really have to understand what it can bring and what it can do for you.

Grant: Yeah. The other part of it is I think we all recognize that we're at companies and we're not necessarily going to be there our entire lives.

It's nice to be able to build pieces that we can then use ourselves in the future, and so you're doing this as an advantage to your future self because you want to continue to leverage that thing that you built and you also know that if this piece that you built that somebody--

If you open source it, your company that you built that for is going to be much better served if it's continuously leveraged by lots of different companies and managed and improved, rather than becoming a piece of legacy code that never gets changed again and it sits in a repo that no one looks at.

There's massive advantages for both employees and for the organizations.

Abby: Exactly. I think that's actually a great way-- I didn't really ever think about it that way, but that's also a great way.

Code you can have access to once you move to a different company. That's a really great way of thinking about it.

Grant: I pulled that from the Android founders, there's some podcast I listen to and there were maybe just some of the early employees there.

They were just so excited, they were like "This is the last time I have to write this specific mobile phone interface, because now it's all open source."

They had done this three times before, and they were like "This is going to be great. We get to reuse this in the future."

Abby: That's awesome. I hadn't really thought of it that way, but that's a really good frame as well. One thing I'd also want to add is a conversation--

I've taken this from someone else, but the tragedy of commons of open source. How one of the downsides of open source- -

And this is true of anything, when something is everyone's responsibility then no one is responsible.

That's one of the downsides of open source, is if everyone is responsible for making it healthy and secure and evolving the innovation around it, then no one feels accountable.

You have to really keep people engaged and excited about something, and that's the challenge around open source.

Grant: Yeah, it's interesting. I'm going to say something that's going to be heretical.

The opportunity with the tragedy of the commons is if everybody uses something and then the responsibility of using that falls everybody else, somebody should go in there and commercialize that thing and build a company around it. Put 10 engineers who are all full time on maintaining and enhancing that core piece, and then build a company around it, and then it becomes valuable to the ecosystem.

If more people want to contribute, they can all add in their own engineers and continue to contribute.

I think that the only-- If you think about how there's a lot of components that nobody is really paying these people to manage, and it's a one person show to manage and maintain something, but if people get in there and help and then commercialize it people will probably get pissed, number one.

But number two, it'll be maintained and you're probably going to end up with a much better piece of software long term.

Abby: I think that's how open source is. It's governance by contribution.

Grant: Exactly, yeah.

Abby: That's a short way of saying, "If you're really passionate about something and you're going to put the people on it, then you can make that happen."

That's the positives of open source, is because you can really direct where it goes.

But the negatives are if you really want this thing and no one wants to work on it but you, and you don't want to work on it, then it's not going to happen.

Grant: Exactly right. But there's so many - -

There's probably a really amazing business opportunity out there to go look at all these components of open source, whatever they might be, and be like "This is a core piece of infrastructure for so many folks.

Let's become the core contributors to it and help out and advance what we want to get done with it, and then let's commercialize it. Let's build a company around it."

I'd say there's just for a lack of imagination and maybe a lack of awareness around how to do open source go-to market that hasn't happened yet.

So, maybe that's a way we can help solve that tragedy of the commons, is people can see the commercial interest and then go serve it in the name of capitalism.

Abby: I try that a lot, Grant. Because trust me, I come at open source from a very commercial outcome.

I'm very commercial driven, so I understand the value it brings to the open source.

That doesn't always work though, you would think that would work more often than it does.

I think there's a ton of opportunity that exists around open source and I think open source is really-- I do think it's fundamentally defining what the future of the cloud is going to look like.

It's a core part of that, but I also don't know.

This circles back to our earlier conversation, and I don't know that enough people understand and appreciate what that means, and take it for granted.

That's the risk, is that there's a lot of people that take a lot of this innovation and work that's happening and open source for granted as a given, and the impact that it's going to have without fully appreciating that it requires contributions from a broad number of people to make it innovative and make sure that it keeps evolving.

It requires a lot of people to chop wood and carry water, and yeah it's not sexy, it's not fun. It's a lot like work, but it's also deeply important.

Grant: I just think it's really hard to get people to do that for free.

The value is if there's a commercial interest in it and you have a business that's growing and thriving around it, you're just very incented to keep it going well.

Abby: That's what largely happens, right?

Grant: Right.

Abby: The people that are doing the most contributions are people that either are using it in their company, or have a distro of it and have commercial value on top of it.

But those are the people that are doing the work, it isn't someone that's--

You'll occasionally have the hobbyist at home that really cares deeply about this particular technology, but at the end of the day most of it's done by people that are using it commercially.

Grant: I think that maybe that's part of it.

There's this myth that there's so much open source created by people who are just doing it in all of their free time.

If we look at the-- It's a poor gauge, but the number of lines of code committed in open source. The vast majority of those lines are probably paid lines.

Abby: Yes. I would say, if not nearly all, like probably 99% are people that are paid to do it.

Because honestly, people should be paid for their work. We shouldn't expect the future of enterprise software to be written by people in their free time.

Is that really what you want? People that-- It's written in their free time and on nights and weekends?

No, you want people to be compensated for the work that you're building your company on.

Grant: To your point, it's becoming such an important part of how companies are run and cloud is being formed.

Like, everything is just becoming such a foundational part of what the future is going to look like.

Abby: And what the future exists now. Just think about Linux, Linux is in everything. I don't care what you are, it's everywhere.

It's in your car, it's in your cell phone. It's everywhere. It's on your home phone. Just think about the fact that our world rides on the top of open source.

It's weird to think about it that way, but it's also super powerful to say "I'm using this technology in one form or another, it doesn't matter what job I'm in."

I don't know enough people take that seriously to think, "I should be contributing back in some way."

Grant: That's another great point. Another reason to create open source is to continue contributing back.

We've all gotten -- We stand here on the shoulders of giants, so we might as well keep giving back in order to help make the world better and better as we as we grow.

Abby: I need to figure out a way to do like Wikipedia does, where sometimes you go to Wikipedia and its like "Contribute now."

I feel like we should put that on a lot of software. If you're going to do something and all of a sudden it's like, "Contribute now."

Grant: You go to try to connect to a website and they try to get you to pay for TLS, or something.

Abby: Yeah, I think we should do that. Because I don't know that enough people realize they need to give back, and that means them too.

Grant: I think that trying to convince the average consumer they need to pay tech people more might not be the best route.

Abby: No, I don't know that I'm going to go on stage and advocate for more money.

But I'd say "Instead of money, time. Feedback. Like, anything. It doesn't have to be money, and frankly I don't know that money is helpful.

I think more feedback and contributions, it can be lines of code or it can be feedback on docs. It can be feedback on the experience."

There's a lot of opportunities to contribute back to open source that aren't just simple code requests.

Grant: I think maybe even you could shorten procurement time.

"If this is an open source product, we go through the speed procurement path where we don't try to negotiate you as hard. It's the easier path to procurement."

Abby: Hallelujah. That would probably-- I think a lot of people would be excited about that one.

Grant: Exactly. Abby, this has been amazing. I really appreciate all your perspectives on a wide variety of topics here.

I want to give you a chance if there's anything you want to say or if you have any ending thoughts around the future of enterprise software, I'd love to hear your perspective.

Abby: The future is coming. I think a lot of people think that we're hit. We're in the heyday, its peak cloud, its peak everything. It's not.

It's early days, and who knows how this is all going to play out over the next five years? There's a lot of companies, we're going to have a lot of new players, we're going to have a lot of technology that goes away. We're going to have a lot of innovation that happens over the next five years and I think we're just getting started.

There's a ton of opportunity, but there's also a ton of formation and froth that's happening that creates a lot of confusion.

I think I would like , as a call to action, "Let's figure out a way we can pull everyone together to talk about this in ways-- In terms of adoption.

Like, who uses it? How do they use it? Why do they use it? What does it solve for and how do all of these pieces fit together?"

That would be my call to action for this podcast.

Grant: All right. Maybe we'll get together in LA or SF some time and make that happen.

Abby: We should. Is there a way we can do that? Like, create this massive off site of people?

Grant: Yeah, it sounds fun. Or Hawaii, that's another good place for the off sites.

Abby: I just feel like there's a ton of opportunity to have a bigger conversation around where things are going and the role technology plays, and I think that's a conversation that's worth having that I don't know is happening outside of small little pockets of people.