PurePerformance - Understanding the Cloud Native & OpenSource World with Carmen Andoh

Episode Date: June 24, 2019

Can you explain Cloud Native? What are the key OpenSource frameworks you need to know? How about all these OpenSource Licensing models? Why do they exist? Which one to use? What are the monetization models and why to watch closely how Big IT & Cloud companies are impacting this space?Carmen Andoh (@carmatrocity), Program Manager at Google and former Infrastructure Engineer at Travis CI, helps us understand how to navigate the Cloud Native & OpenSource world and gives answer to all the questions above. The IT world is changing but its up to us to shape the future by inventing it. If you want to learn more after listening check out the CNCF Trailmap and follow up with Carmen on social media to get access to her material around that topic!Trailmaphttps://github.com/cncf/trailmap

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have my loyal companion, faithful co-host, the amazing, wonderful, talented, amazing dancer, Andy Grabner. Hi Andy, how are you doing today? Wow, what an intro. It's amazing how many attributes you could find for me. I was wondering which name are you actually going to say in the end?

I'm, I'm good. I'm fine. It's early morning here in Las Vegas where I am this week. Yeah. So good. Well, I'm sure the weather is better for you.

We have dark and rainy here in Denver and, uh, and another lockdown for two days in a row of school shootings. So hooray. Oh, um, yeah. Anyway, hooray. Oh, yeah. Anyway, let's move on to more fun topics about performance, shall we?

Well, yeah, actually fun topics, performance, but more so about open source. And the speaker, the guest that we have today on the show, Carmen, I actually met Carmen at DEF ONE at our conference in Linz earlier this year. It was like mid of April. And I was fascinated by, she did a keynote. And after the keynote, we had what we call the chalk talk, where it was actually not, we didn't have a chalk actually. But we basically sat down and we were discussing the topic with attendees. So it was a great way for attendees, for those folks that listened to her at the keynote to ask more questions about the topic and then have more like interactivity. And so that's why I thought the topic about open source, how to navigate the open source world is very important for all of us in the

industry. And that's why we have Carmen on the show today. Now let's actually hear if she's actually here with us. Carmen, are you still with us? Yes. Hello. Hey. Well, last time we saw each other was Linz. Now we virtually see each other uh kind of a almost a uh well a continent distance apart because you are on the east coast i believe yes in new york oh i used to be from that area i was north jersey my whole life until five years ago oh wow yeah the tri-state area oh wait actually so you mentioned i'm totally sidetracking this but this is what happens when people come from the same you know in the same area um are you working in the build the um the old port authority building yeah i am i used to work there at um webmd oh wow i was

working there in fact i was working there when google bought the building uh and what i'm seeing is that google intends to kind of use all the building once leases run out. Yeah. So I don't know if WebMD is there any longer. I have no idea. That was, I left there in 2011. So it was quite a while ago, but anyway, off topic, we just see any, that's just what we do, right? No, but actually a good segue because we now already learned that you're working for Google. So maybe Carmen, can you give us a little bit more background about yourself before we jump into the topic? Sure. I just joined Google earlier this year in February. I joined the open source strategy team and my project is the Go programming language. And before that, I was a infrastructure or ops developer for Travis CI,

who started, hosted continuous integration and was really kind of came onto the scene to create YAML. I kind of blame Travis for the reason why we use YAML as a configuration language for many of the ops and infra as code things nowadays. That means you are one of the people that prefer JSON versus YAML. Is that what you're saying? Oh, how about gRPC? No, I'm kidding. I'm kidding. I'm just saying that because, you know, it's Google. So put my little plug in yeah cool so um that's interesting so travis ci operations engineer now a program manager at google i think when this

actually this question was the first question that i had to you at the jock talk could you explain a little bit more of what a program manager actually does because i for me it felt i mean i've heard it and I know that different organizations have different definitions of what a program manager does. What does a program manager do with Google? Good question. I'm still trying to figure it out myself because it is a bit of a career change. I work in the intersection between developer relations and strategy. And of course, for a very technical thing, which is a programming language. So I need to wear multiple hats.

I think that a program manager, depending on what their program is, is a person who needs to make sure that all the stakeholders are identified and engaged. They are great executors. They make sure that timelines stay on track. It's a bit more than a project manager because you may be managing a bunch of people who are managing a program such as the Go programming language, you may take aspects of it and see where things need to be strengthened, where you strategically need to embed yourself so that they can improve and execute on a number of things. So I think that's the definition that I've, uh, come to know now. Um, I know that that's probably going to evolve as I evolve into this new role. That sounds like, yeah, that sounds like pretty heavy duty stuff.

Yeah. Yeah. I feel it's interesting because I feel like code isn't hard, although it's hard, but I think that the hardest problems in our industry are people problems, are collaboration problems, are any number of things. And so this is an interesting jump for me. And I'm excited for the new challenge. Yeah. And to add one more thing to the mix and to kind of segue over to our topic, the other challenging thing is open source licensing and the crowded open source space which was actually the topic that you present and i think you did it in a very cool way at your at your keynote the way you visually represented like in a walking walking the open source cloud native space can

you can you feel maybe the audience in and how what your analogy was sure i think we are moving into cloud and we have um i'm a very visual person and i think a lot of other people especially when they're trying to design something or understand um interrelationships and hierarchy and a number of things the first thing they want to go to is the whiteboard, right? Whether that's code or whether that's architecture, networking, what have you. And so when I thought of cloud native, I thought, well, what does that even mean? And how is that different from cloud computing? And so I've been in this space and we, in my previous role, we did everything in the cloud.

In fact, we did four in the cloud. In fact, we did four clouds, so multi-cloud. And so we're just trying to not only keep up with the existing system, but improve the system and then investigate new technologies, new languages, new everything to be able to keep up with the times and make sure that we were solving the business problem in the most efficient way possible because cloud can be expensive. And so we were doing a lot of cost ops is what I call it. Like you've heard of DevOps. Well, there's an emerging thing that engineers and engineering leadership looks at, and which is how can we reduce our costs in the cloud? And now you have on top of it. So there's just all of this kind of spinning your

head around and trying to understand it and you get in the weeds. So the keynote that I gave was, well, how do you navigate the overworld? And the overworld is a term that is used in most adventure playing games, whether that was tabletop or, and my first adventure playing game was Zelda at 1986. I'm dating myself. Yeah. And so I kind of, I opened up and I said, I've always loved maps. I'm kind of a map geek, but maps are, they, they kind of tell you a lot of different things, right? They kind of position you and they get you the lay of the land. Um when navigating the overworld of open source, I couldn't help but in my, and I said it to Andy and the audience, the German speaking, Austrian speaking audience, the Kopfkino, right? The head cinema. The Cloud Native Computing Foundation about three years ago

came out with this cloud native landscape, which is, it's been just growing and growing and growing and growing. And I think now it's even interactive because they have like, you know, six or 700 cards of each company. And they've tried to put that into different categories and then subcategories of those categories. And it's just a lot. I mean, how can you make sense of it? And it was the same kind of feeling that you get if you look at an overworld in a game and try to make sense of it without having played the game and have been in the weeds first. So it's kind of an ordering problem. It's a sequencing problem, right? And so that's kind of just the cloud native landscape. But then you start to navigate into this interactive landscape and you can click on a card that interests you. Maybe Kubernetes, because Kubernetes kind of seems

to be the platform with which we're building on top of the cloud native landscape. But when you go there, then you get sidetracked and you get further pulled into the weeds. So what the cloud native computing foundation did is that they paired this landscape with a trail map. And the trail map, I think that it's moving in the right direction, right? Because maps are great, but you also need directions, right? You need to be given step-by-step, turn right here, turn left here, start here, end here. And I think that the two compared together is really what is helping. Now, we still have a lot of work to do. I think that the two compared together is really what is helping. Now, we still have a lot of work to do. I think that the emergent nature of what is cloud native and a bunch of newcomers onto the scene and a lot of people rebranding for this new paradigm, we're still trying to figure it out.

And so you throw that on top. And then the last thing that I kind of said was you throw on top of the big cloud players, because that's kind of what I said as the elephant of the room. So what they're not mentioning in this cloud native landscape, the CNCF is AWS and GCE and Azure, right? And those cloud providers are further muddying the waters because they're kind of creating services that are competing with open source companies or companies whose monetization is based on technology that the cloud providers are forking and then using their engineering talent

to build their own solution. And that's really at the heart of what Andy mentioned. We're kind of, you got the sort of five-minute backstory there. And this is finally where we come to when we're talking about why all these new open source licensing, licenses are emerging, especially in the last calendar year.

So yeah, that's kind of, and I kind of – in the talk, I kind of said, well, here's how cloud providers are disrupting monetization on open source. Here's what the different monetization models are. Here are the two ones that have been the dominant models for the last decade more and more. And here are the three new emergent models, which is new restrictive licensing or hybrid licensing or the idea of open core. And it's a lot. And I kind of, it was a keynote. I only had 30 minutes, but I really, in order to feel like I could give

justice to that talk, I wish that I could have been given an hour. I don't know how I'd bore the audience or not, but it certainly is fascinating to me. But yeah, so I just kind of talked about all of that and, and I wanted to kind of validate the people out there who are in the front lines, trying to code, trying to make things happen, trying to say, or finding a gap in the solutions and saying, hey, we should start a company with this solution that we can't seem to find elsewhere, and helping them navigate forward, whether that's companies or open source projects that start off as projects, but then maybe spin off into companies. And then also to kind of get a sense that with the seismic shift in a technology that's kind of coming in with the cloud native paradigm, developers are, so first of all,

enterprise is moving into this and they can't seem to make sense of it. But developers themselves, because DevOne was a developer conference, developers have a lot of decision-making powers, more than they know, right? They may not have the decision-making power to maybe choose the cloud provider, but they have influence. And they certainly have influence over certain parts of the stack, which is all of those cards that you find in the cloud native landscape. And the reason why they have influence is because just like in Zelda, if you've played every single grid square in Zelda, that overworld makes complete sense to you, even if it's not your job to steward that overworld. So it is kind of a contradiction in sorts.

It's a contradiction of vision and strategy, which is the 30,000 foot view, and then the implementation details, which is the 30,000 foot view. And then the implementation details, which is getting into the nitty gritty and the, and the gameplay, if you will, in the squares. So yeah, there's my, uh, my 5 cents run through of that talk. A lot of information, obviously. And I think, as you said, probably you would need more than an hour even to, to cover all of it. I believe the, if people are interested, the session was recorded, I think it's already on YouTube. And then the slides that you use, I assume you, you have the

slides up where I do. I have them. I used Google, Google slides. I didn't share them because I, I don't know. I'm a bit hard on myself, but I also feel like the, the topic again, because it was so short, um, it did feel like I was trying to cover too much in too little time or cover too much ground. So I was just like speeding by and I want to flesh out these slides into maybe another talk that I could give in another conference who cares about this kind of stuff and stuff. So I'm kind of holding onto it until it's a little more cooked and maybe that's a deterrent or that's not good. And I shouldn't be such a perfectionist, but if you think there's value, I certainly could quote unquote open source them.

No, I think there's definitely value, but you know, it's up to you obviously to decide when to release them, but we will definitely do, we will link to your social profile so people can follow you. And then once you are ready ready then i'm sure you will post and tweet and whatever else you do to get them to the world and then people can can get access to it um i have a couple of questions because i think for the audience um and also for me when i sat down with you later on i had a couple of questions so you obviously talked about the map that we have that kind of gives an overview of the cloud native space. For me, if I'm new to cloud native and you talked about the trail map, where do I get started? Where do I get started and then kind of find my path through it?

Because if I look at the map, as you said, it's completely overwhelming. I mean, I could start with Kubernetes, which seems to become the platform of choice anyway. But do we have any other tips and tricks on if somebody is just getting started, let's say from a developer perspective, first of all, what are the projects that you should look into and then find your way from there? And then the same thing for the operations space. If I'm in operations, where would I get started and what are the projects I need to know? And then how do I navigate from there? Well, I think I was surprised when I realized that so few people understood what exactly cloud native was because the cloud Native Computing Foundation, they purposefully maybe keep it a little bit vague

or to be punful, cloudy. It's a very cloudy definition. Waka waka. Waka waka. And what I've realized, and I asked the question actually within my open source team in our chat, I said, so does cloud native mean Kubernetes?

And someone said, well, that's a good question, I guess. But it doesn't really mention Kubernetes specifically. And what you find in the trail map is that the first stop in your trail, the starting point is containers. So basically, I put two and two together without anybody explicitly saying that, that cloud-native means that you are now moving towards a container

as your compute or your runtime, right? And that is very, what I also realized is that there are still a lot of companies out there that are running their operations on, say, VMs, right, and hypervisors. And, you know, what I call the still dominant mode of virtualizations, VMs, hypervisors, and whatnot. So EC2 is far from dead in terms of being used. But there is going to be the next generation, which is moving away from EC2, which has been super expensive for these companies that already are running in the cloud, and trying to make use of containers and containerized infras and containerized and everything that comes with that. reminds me of university. And what I really liked about university is that you have, when you go to the course catalog and it says, hey, we're leveling these courses anywhere between the 100 levels,

which are introductory, all the way to maybe five or 600 levels, which are masters. But they also, if you try to take a course, there's prerequisites that you need to take. So you cannot take, you know, vector calculus without having taken trigonometry and geometry and all the other things before. So they have explicit prerequisites that you need to know. And I think I would like to see that. So the trail map starts to hint at that. They say, okay, you know, containers and learning about containers and how you do rework your development workflow to use containers and your deployment pipeline, what have you, that's the starting point. So I think that the trail map is far from done with regards to helping people who maybe aren't

savvy or aren't early adopters, but moving into the adoption cycle of maybe early adopters to early majority. So that's kind of, it's a very, it's a long answer, but I, it's still, you know, we kind of realized maybe even where I'm at Google or having even worked for an open source company that did cloud since the beginning, it was like the super early adopter. We forget really soon what kind of a bubble we're in with regards to us being early adopters. And we have to ever be ever conscious of like a Zen mind, beginner mind to the majority, because everyone says that, oh, everyone's moving to cloud. But in my keynote, I said, you know, I did the research and I see that the move to cloud is

far from over. We're about 10, five to 10% done in terms of actual enterprises. Certainly high tech and super early adopters are maybe already established, but everybody else is still kind of running on-prem workloads with their VMware vCenter. They're not using cloud. So yeah, so that's kind of, I wish they'd just be more explicit about that and how to get started and then fill out the details. The other thing about the trail map with regards to a developer, a developer, you have a kind of either a dev setup and you have a dev workflow and you have environments that you push to

and you make sure that it works on all these environments and then you have a whole work stream that you have, whether you're on-prem or maybe using cloud, but not containers and or container orchestration and all the things that that brings. And so I really would love like a glossary for like, if you're doing it in this old paradigm, here's what the new paradigm equivalent would look like, right?

Some sort of like english to german translation book right and it's never one-to-one but certainly you could say uh break it apart into component pieces so some sort of like old paradigm new paradigm um you know glossary or how new things are done and i think that that is incredibly hard to do, but it's needed. And there was a tweet by Liz Rice, who works for Aquasec, and she's on the CNCF. I think she's on the committee that reads all the CFPs for the KubeCon conference in EU, as well as other places. And she actually tweeted out, like, do people think that the trail map that is used by the CNCF is useful? And it was a quiz. And it was interesting because she got more

than 200 or 250 results. And the results were mixed. Like, yes, it's helpful. No, it's not helpful. It's kind of a mixed bag. And even what is the trail map? And so it was just, again, another reminder that so many people just don't even know of its existence. And some people are still at the very foundational level trying to develop a glossary and a taxonomy of vocabulary surrounding this new paradigm. And then the last thing I should say for a trail map, again, the elephant in the room are the public clouds.

And what I'm seeing is that too often you're going to be running, even if you're using one of these 600 plus companies that are within the landscape, you're still going to probably be running it on a cloud. And therefore you need to work with the SDKs and the APIs of the cloud provider. And so I think developers, what they're really looking for are solutions, right? Like pragmatic solutions, like, oh, okay, networking. Well, here's networking APIs for GCE, right? Or now we're going to have to think about security or auth or any of those number of things that you kind of do as an operations person

as getting the setup started. auth or any of those number of things that you kind of do as a operations person as, you know, getting the setup started. And then of course, as the developer writing the services on top. And so the one thing that I saw in this tweet thread, and maybe you can include it in the transcript, is he's a data scientist named Daniel Whitenack. And about a year ago, he wrote this gem of a blog post that tried to do exactly that and then columnize the different roles, understanding that devs are going to have a different sphere of concerns for what their responsibility boundaries are for cloud native. And then of course, infra and ops and how they're going to be responsible for their areas of cloud native and then the the intersection points where um you know you're not throwing it over the wall

because it is you want to adopt the devops mindset but you want to be able to make sure that the uh the api boundaries or the boundaries are crisp and clear and the communication is there so i can certainly um share that uh maybe i'll tweet it out or i'll share with you andy yeah but i just thought you know it's a year it's a year later and of course so many new companies have come onto the scene but it still was a good framework for attempting to try to give a pragmatic solutions for the developer or the ops person yeah and so first of all well thanks for that there's a lot of information and i what i did in the background, the trail map is easy to find for folks that want to see how it actually looks like. Just, you know, Google.

I just looked it up. Yeah, CNCF trail map. It's got dragons on it. Exactly. Exactly. And some bulls and whatever, dragonss cactus yeah um but the so that but carmen you're right i mean there's a lot of people that are just getting started i don't even have a clue about that cncf actually exists the trail map exists i think that's why it's so important that people like you

are talking about it at conferences that we're doing this podcast because you know we need to get the word out because it's going to become the reality for people and the more information insights we can give them to make their adoption and their path easier the better it is and because eventually people have to deal with it um the so thanks for thanks for the intro on cncf how to navigate the map uh the coming back to the the topic of open source and especially licensing, because I believe this is, at least for me, a little, how do I say, it leaves a bad taste in my mouth because I feel like I, as a developer or somebody with a development background, I'm completely overwhelmed with the licensing models,

the things that I have to take that to be aware of. I don't want to be, and I think you mentioned it actually at DevOne, it feels like we have to become lawyers to actually understand what we're doing. And, and, and this should,

I mean, this is for me, it's stupid, right? I mean, why do I need to, why do I need to understand all of these things and the ramifications i may have with the code change with the pull requests

is there even you know can there be any legal action or is there anything that that could be problematic if i contribute to an open source project is there anything that will hunt me later on if i start a new project and I forget to put the right license in. So the question to you now is for somebody that wants to contribute to an open source project, that has an idea and wants to start an open source project, what are the basic things this person needs to understand when it comes to licensing and when it comes to starting a project to make sure they're not making a mistake and all of the intellectual property is then potentially taken over by the big ones out there and then all goes to waste. So just some, some tips and tricks, some hints, things we need to know.

Sure. I think, and this is, uh, totally my opinions. Um, but from what I have done in terms of researching all of this, I think for the developer, um, if you do not start opening open immediately from the get go, you are already hampering yourself from the start. Right. So it's just, they hurt adoption, right. And they turn off potential users.

Right. And we still are coming from the sort of second generation of this open source ethos that everything should be open, right? And that's, we're talking like Richard Stallman and Eric Raymond and that, because it was this kind of ideology. And so restrictive licensing happened only after the monetization was there from really big companies, right? So this is including Redis Labs and Elastic for Elasticsearch. And they were reactionary, right? So I don't think anyone is going to start off with restrictive licensing from the start. This was reactionary because quite frankly, AWS was stealing their business by forking

or just doing proprietary things with the absolute open source that Redis and Elastic provided. And so that's, I think, when you start off, you use, you know, GitHub has a really, if GitHub or GitLab is your workflow for code hosting and version control, they already have helpful hints as you have a wizard to kind of start the repository. And they suggest maybe MIT or Apache 2 or GPU. So yeah, GPU, wait, confusing terms. GNU, right? So anyway, yeah. So the other thing I'm going to say about that is not only from an adoption standpoint, is it going to hurt, but also ideologically or

historically, the future is open, right? And the chef, CTO Adam Jacob actually wrote, and I didn't include this in my conference talk because I didn't know about it until recently. But earlier, like the week before or two weeks before, he wrote a big blog post about how and why he believed that they're going to stay open and why that has helped them. And they're going to just realize that the future is open. And also, if you kind of do your, you know, my other major in college was history. And I say that in my talk. And I'm always just fascinated by history of technology. And when we say technology, we're talking, you know, going back to the crossbow, anything that's going to be giving you a leg up with the tool, right? We could think of fire as, as, you know, Promethean fire is,

you know, you're a very seminal piece of technology. But anyway, you rewind to almost any historical technological success, and you'll see that what was behind it was or the success. What was behind it was when something became open. And I think that for open source, that's we're kind of getting reminded about that again. Right. And I think that's the runaway success of Kubernetes, right? They decided, Google decided, we have a scheduler, it's Borg, we want to try and rewrite it and go, we'll make Kubernetes. And they also knew that, you know, the dominant paradigm that everyone else outside of Google in terms of running world-scale workloads was still quite outdated in their minds, right?

They weren't using containers. The dominant workload was VNs, right? And so AWS is a black box indirect success for EC2, right? But when Kubernetes came on the scene and Kubernetes became open, it changed the compute paradigm, right? And, of course, it changed the compute paradigm to such a degree that the mass network effects that we're seeing, it's now forced this new, fungible, portable, liquid compute dynamic across all the leading clouds.

And that's just the beginning. And that is the power of being open. And so when I say to any open source person, you know, it's not just about I don't want the clouds to take over. It's rather I want to work with a cloud that can take my idea and work with me. And so I'm a little biased here, but I, it's kind of why I took the job with Google because I believe that their open source philosophy is doing exactly that. And you're seeing that with some of the partnerships that they're having with the larger open source companies and also with some of the things that they've launched, right right so they have this new thing called anthos and kelsey hightower who's you know i would say

the developer advocate that we think of when we think of cloud native and kubernetes he's moved on to sort of talk about that and that's basically saying we want you to have choice we also aren't going to fork your project and we want you to be able to use Anthos to be able to multi-cloud or on-prem or hybrid or whatever you want. And we don't want you to have to think about SDKs and APIs and implementation details that are tethered to any single cloud provider. We want to make sure that it's free for you. So I kind of went all over the place there, but I, I think that the, that the, you know, essence of what I'm trying to say is that if you look at any history, uh, open is where successful history lies. Very cool. So now let me ask you a question though. One, one follow-up.

Um, and again, this is my lack of knowledge of all the licensing that is out there. Coming back to Kubernetes, what prevents one of the cloud vendors to fork it and then provide a commercial offering for Kubernetes in their own way? I think it's just the sheer size of what they're going to try to fork, right? The API server and all of the different components that make up Kubernetes is just massive. And so you would need a staff of developers that would be equivalent to the thousands of worldwide contributors that are already contributing to the master tree. So yeah, I think nothing is preventing you. And I think that where Kubernetes is what it has become

is it has become the platform that people develop on. And so it would be similar to saying, we're going to fork the Linux kernel and make our own kernel and call it, you know, NUNIX or what have you. There's just, it's just too, I think once you've got a critical mass of community and or developers that are around this particular platform and it, you know, it happened with Linux 25 years ago and 25 plus years ago with the operating system.

And now it's with Kubernetes. And in fact, Open is one so much that the Microsoft CEO, he basically, I think one or two years ago, pretty much shut down Windows. And he's going all in on Azure. And what I read that as is that he realizes that people are not caring about the operating system. It's been commoditized

to such a degree that it's enabling the next step up, which is compute, cloud compute. So yeah, I think that, again, that's also another story that can be talked about, like why open one? So yeah, and not not to bring up Azure, because I know you're with Google. But that's one of the things that always astounds me with what Microsoft did, where we've had several people from Microsoft on, and we discussed how you can run a.NET Core free on Linux OS, no license, right? All you're paying for is the is the compute right and that's the micro you know going back to microsoft being this very protective very we want to monetize every single aspect of the operating system and everything exactly to your point they said hey we can let's open all that stuff and let people do or use whatever they want. Well, just make money on the compute, you know?

That's right. Exactly. And they sort of, they also kind of did away with Wasm. And sorry, Wasm. Let's edit that out. Not WebAssembly, but Windows subsystem for Linux. They're just going full on Linux. Yeah, I just saw that, right?

That was like just this week, right? Yeah. And so they've basically said, you know what? Sure, we'll continue to sell laptops with the Windows operating system in it. But they know that the future is towards cloud. And so and they said, you know, our chief, our main goal now is to provide that compute, like you said, right? Yeah. Hey, one question I had going back to the idea of everything being open, right? Yeah. Cool. or Amazon selling compute, what is the monetization for these large companies besides maybe services and support?

Is there like, in my mind, when I hear so much of this open, and it's probably some of my naivete, but I just sit there wondering how short term it's great, but how in the long term are businesses that commit so much to open going to stay in business?

If, you know know what's the monetization strategy that is the million dollar question that's also what andy's trying to get at with licensing right there is a fear that um the more managed services that cloud providers uh have the less need that they have for the mom and pop shops, if you will. I almost like to think of it as to use an American term. So the Walmart, the Walmartization of open source, right. And I, I didn't use that in my keynote in Austria because there aren't Walmarts in Austria, or maybe there are, but you know, you sort of see that we had main street and mom and pop shops. Um, and now you have the Costco's and the Walmarts and the Sam clubs, the big box stores

are the ones that are taking over. And even further, you have Amazon as a virtual retailer, that's kind of killing that off. And so I, I kind of am trying to make sense of that with cloud. And now that I'm working for a cloud provider with the computing language behind it, I often wonder like how is that going to be placed out? And some of the people that came out of open source and created automation and are kind of the key individuals that helped enhance the DevOps space. They are also saying, you know, we're creating a world where this consolidation or this Walmartization is creating efficiencies at scale.

And that means that we're going to have like, you know, 10x developers really be a ratio of like 200x and then all the smaller developers are going to go away. But I just think that really be a ratio of like 200 X and then all the smaller developers are going to go away. But I just, I just think that that is a lack of imagination in the same vein that the horseshoe, uh, horseshoe manufacturers and the horseshoers of the early 1900s felt about the advent of the automobile. So one of the things that I found is a fascinating historical fact, the most popular profession in the early 1900s was a horseshoer, right? That is the equivalent of the auto mechanic today, right?

And then also the horseshoe, the blacksmith, the horseshoe, quote unquote, manufacturer. And they were really up in arms when cars came. But now look at all of the things that the automobile industry has, has enabled. Right. And we're not going to put people's back in horses and buggies. And so we're not going to, in the same way, we're not going to be spinning up our own web servers, right. To make our own mail or, you know, I think that that, that is kind of where the motion is going. And so the suggestion that I say to developers nowadays is, you know, if you want to be certain of the future, you need to invent it.

That was something that actually my boss, Sarah Novotny, tweeted out, I think, earlier this week. And I just thought it was a fantastic quote. And that's really hard to do. And that's really hard to see. It's almost looking into a crystal ball. And then inventing the things that you're, inventing the things so that you don't have to need the crystal ball.

So yeah, that's really, really hard. What I'm thinking is, if you think, okay, I no longer have to worry about all my physical compute, right? And I don't even have to worry about all the things that I needed to care about, not just with like racking and stacking and blades and switching and routers and laying down cable, which is, you know, there are very few people with that left. I mean, if you're in this industry five years less, and we're noticing that devs on the whole are only five years into

industry or less. So we're a perennially young industry. And so we forget that the skill sets that so many of us older sysadmins had are now kind of obsolete with managed clouds and or data centers, right? Those skill sets are now for a person that works as a data center engineer in one of these several thousand data centers for all the cloud providers. And the same thing as well as an infrastructure engineer who needs to care about, say, load balancing, right? And then they would have to weld load balancing or maybe availability or even something like HAProxy. All of this is a paradigm shift that's happening with what we would call sysadmin, now DevOps, aka, you know, ops or infra. And then, of course, there's the backend dev as well, who needed to care about maybe database drivers, or

gosh, and any number of things, or care about logging and monitoring and whatnot. And now it's more about how can I, how can I envision a tool that's going to help me if, if I make the assumption or how can I write my app or my service with the assumption that all of this is already going to be provided for me instead of making it myself. And that's, that's the crystal ball that I'm talking about. Yes. Yeah. I just, Andy and I have two different outlooks kind of, well, not completely different And that's the crystal ball that I'm talking about. I don't know, but I think what you say is very, very apropos. It is kind of a it is a situation where you do have to keep moving forward. And the I love what you said about, you know, make the future. I think that's always the case.

And what we see, Andy and I both came from, you know, performance testing, performance engineering into things. And it was this idea of if you look at them now, the performance testing teams, there's a lot that has changed. And if you're sticking to the old style of performance, your options are becoming more and more and more limited. So it's the idea of embracing what's going on, moving forward and thinking about, hey, how can we do something new and cool? You know, we had another, that's not quite in the performance team, but Andy, there was that team who makes the AI that creates the Selenium scripts, right?

I mean, so there, I mean, that's like a great example of what you're talking about, right? Like make the future. They're taking in all sorts of like rum data and saying, instead of having engineers have to create Selenium scripts and figure out what those steps should be, we'll let the AI figure out all the most common patterns and then generate the scripts for it. So anyway, I think what you said was spot on. And I think for people who've been in this industry for a little bit longer, I have a colleague who said something that just blew me away, Dan Bentley, who started Windmill. And he said, but people are proud of their scars, right? They're proud of their calluses and their scars. And what that means is that all this toil about things that could be maybe given away to ML or AI or can be generated or can be automated, we kind of had to do it by hand. And we want to be able to say, you know, I walked both ways to school, 10 miles uphill, barefoot in the snow, right? But we don't realize it sometimes. Whereas the

next generation of people taking up the helm are people who kind of just take it for granted, right? So like in CICD, my company kind of, my old company, Travis, did exactly that, right? Where the province of setting up and standing up a build server was a person's full-time job, right? And they had to get into the minutia of build scripts and imaging and mastering those images and whatnot. It was just a full-time job for them. And what the travesty I had before thought to know is this is the same story as like saying, standing up your own web server for email. And when a hotmail, gosh, I'm dating myself came out on like 1999, they basically turned that, you know, the, the, the consumer immediately saw the, the value in it, but it was the old school sysadmins who had, you know, already calloused themselves standing up send mail or postman or what have you that just weren't ready because

they, they got those callouses and they, they want those callouses to be worth something. And I think that could be said for anything, not just performance testing, but for any other domain of coding or engineering that you're doing. And so, again, trying to sort of like embrace the fact that we are in a new paradigm, that paradigm is container based, infra based with using containers as the primitive and running on various clouds. Yeah. And to add to this, because, you know, like defining our own future, Carmen, I think we talked about this when you were in Linz. We are also currently contributing with an open source project that we call Captain because we want to also make the life easier for future cloud native developers to deploy their containers through a fully automated pipeline with capabilities like automated rollbacks, automated build validation. And our goal is also to contribute it to CNCF. And, but I like now as you, as I listened to your explanation, now I have a new tagline on how I

explain why we're building Captain, because we want to be certain of the future, obviously. But really, we don't want people in a year from now to figure out how to deploy their containers, how to configure Istio, how to do the build validation, how to do rollbacks. This is something that they shouldn't have to do in a year from now because open source project that we'll be building in this case are going to take care of it. And I really like that. So that's, I think you gave me some ideas on how I, how I kind of tell the, tell the open source community on why we're building this and why we make their lives easier and how we are redefining their future. So that's good.

Cool. I have one last question. So we talked a lot about, obviously, open source projects and we talked about licensing and that's all good. And thanks for the tips and tricks on that. Certain GitHub and GitLab, they all have their wizards to make sure we don't make a mistake when they guide you through. But one question I have, there's a lot of open source libraries out there.

And if I want to, if I build something new and I want to use one of these libraries because I don't want to reinvent the wheel, is there anything I should be watching out for in terms of, am I picking a library that is solid enough, that is, uh, you know, has enough support that, um, you know, what do I need to, if I have five different libraries, open source libraries that essentially do the same thing, are there any tips and tricks on, on picking the right, on betting on the right horse to come back to your, to your horse history lesson. Yeah. I think there are three things that I've done in the past. Um, well, first of all, I want everyone to know that, um, close enough is good enough. And sometimes what you do is you kind of, and we've seen this all

like in a code comment, like this is just a temporary workaround. And then it's been in production for about two years. Um, many people just try to get the job done. And because open source is always ever moving and evolving, and you know, they don't, they're constantly contributing. The open source tool or the third party library or packages that you're using, you know, from two years ago might not be the best one today. But that's why I say you can kind of get yourself into kind of a choice recursion that will render you immobile. So close enough is good enough. And there's three things that I look at when I think about maybe looking

and kind of using packages that I trust or third parties that are outside maybe the standard library. The first is I go to, and this is kind of a common practice, and I'm sure you've heard of it. Awesome. The awesome series, awesome, go awesome, Ruby, awesome, rust, whatever. And there's also lib hunt, which is the same idea, right? And so you kind of say, well, I want to use a, I don't know, a, an HTTP router, right? What are the best things out there for this language out there? And it'll show. And what a lot of these outside websites show is the number of GitHub stars. And I know that that's not the best indicator, but GitHub stars has kind of become a proxy for that. So the other thing about these, uh, websites is that they

also help you compare other, like they say, Oh, well they're here, all the ones under that category that you put in your search term. And so here's, you know, what we've ranked, they actually do the ranking for you and they have like a methodology for their ranking. Right. Um, the other thing is I go to a place where I know that they're super trusted and it's because I work in Go. That typically was shops like Kubernetes and or HashiCorp. HashiCorp is mostly, if not all Go. And so I would say, well, what do they use for third-party libraries? And if it's good enough for them, it's good enough for me, right? You also, when you're looking at, and it's either GitLab or GitHub, and that's kind of the industry standard for where people are

posting their code nowadays. But I often go and see, there's two things that you look at. I look at the commit history and I kind of see, is it being maintained? I look at the number of issues that are out there and are the maintainers responding to them. And I just try to spend, I don't want to spend too much time again, because I don't want to go into choice oblivion, but I want to spend a little bit of time researching, you know, what is going. And then, of course, each language community has their own IRC and or Slack and or community watering hole, if you will. And so sometimes it's really great to just go ahead and ask questions in there. And sometimes they have channels, right? Based on

maybe the task that you have at hand. I know for Go, they have GoLang newbies or even just tools that you have. So I kind of do, that's kind of my way of figuring out what's the best tool to use. And sometimes if I just have no clue and I just use, like, I'm trying to describe this is what I want to use. And I have an idea in my mind, well, I think I would be using maybe multiple packages. I could get a completely different solution with a completely different approach in these communities. So I lean heavily on those three things. Very nice. Thanks.

Yeah, that's because, you know, I believe this will be helpful for many folks that are looking into open source libraries and, you know, picking, well, that's not the best choice, but at least having some kind of process of filtering out what might not be the first choice is always good. Thank you so much for that. Yeah, you want to make sure you're not buying the first choice is always good thank you so much for that yeah you want to make sure you want to make sure you're not buying the Yugo yeah oh no

Andy anything else or was it time to sum it up I think it's time alright well so Carmen thank you so much I know in dev one you would have needed at least an hour. And I'm pretty sure the topic is so extensive, you would probably need several hours of podcasting space to cover this topic. And I'm sure if you look at the OVA map, you can probably only just cover the OVA map in an hour and then dive deeper. Thank you so much for the insights. I think I can definitely encourage everyone to look at the trail map that is out there.

Just Google CNCF trail map, where you can see that, you know, everything starts with containers and then it goes down the path of, I know, really leveraging cloud native technologies and frameworks. So in the end, we can all focus on building software better and faster and really focusing on what we need to do is, which is building software and not just redoing things that we should no longer do in 2019. And I'm pretty sure if I listen to this in a year from now, then I probably certain things have again been automated away because somebody started a new project that make certain

things so much easier. I also like what you said with always start open, don't close off users right from the start, make it easy, make it open. Be aware obviously of the licensing models and you gave some good tips on that there is a lot of help out there already built in into GitHub, into GitLab. So that's great. And the last thing I want to end this with, because I really like the quote, and you need to remind me again who to contribute this to. I think it was your boss. If you want. Yeah, Sarah.

Sarah Novak. So if you want to be certain of the future, invent it. So I really, I really like that. I do too and the the other thing that goes hand in hand of if you want to be certain of your future invent it um some advice i'd gotten a while back just in my job like i was i was dissatisfied in one of my previous jobs that happened to be in that building in new york um but someone else who was kind of mentoring me a little bit it was like well make your job what you want it to be you know know, and if you can't do that, then that's when you

know, to move on, but it's similar concept, but taking it a step further in terms of, uh, the, the, you know, building your future in terms of technology and, and what, what things are going to look like and what tools are going to look like and all this other kind of stuff. So Carmen, thank you very, very, very, very much. Uh, was there any, any last things you wanted to get in or, um, any, any upcoming appearances maybe in the next, you know, over the summer that you wanted to promote or anything? Sure. If you are interested in any of this, you certainly can contact me. I'm available, Karmatrocity, on Twitter. I am going to think about good events that I want to be at in the coming months, certainly Go-related events, since I do work for the Go programming language,

but also the intersection between how developers are now trying to keep their skill sets sharp for a cloud native world. So yeah, Karmatrocity on Twitter, my DMs are open. And look, I'm happy to speak with anything about this. And I just looked up that quote that I attributed earlier. And the quoter was Alan Kay, the great Alan Kay. Awesome. Well, thank you very much to our listeners. If you have any questions, comments, or if you have any stories that you'd like to share and come on the show, tweet us at pure underscore performance or send an old fashioned email to pure performance at Donna trace.com.

Thank you all for listening. Carmen. Thank you once again for spending some time with us, Andy. I'll speak to you in a few days when we record our next episode, I guess. All right. Thank you all.

Bye-bye. Thanks. Bye.