Ecosystems: Find your place in the world

Cheryl (00:05): Everybody makes mistakes- and it doesn't matter. Generally, it doesn't matter. People can ask you questions and you say, "I don't know, I'll have to look it up and find out and tell you later." And it's totally okay.

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I've been to depths that remain classified. And Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom.

Marc (00:35): In the DevOps Sauna Season 3, we'll explore platform engineering and the people and cultures that make it happen.

Andy (00:42): Enjoy your time in the DevOps Sauna.

Marc (00:53): Okay, we're back. And it's a real honor today to have Cheryl Hung with us.

Cheryl (01:00): Hey, this is Cheryl. Good to see you again.

Marc (01:03): Yeah, it's wonderful, and as usual, my cohost Andy Allred.

Andy (01:07): Yeah. Hello. Nice to see you again, Cheryl.

Cheryl (01:10): Good to see you, Andy.

Marc (01:11): And we're saying again because we saw each other just a few weeks ago in The DEVOPS Conference - Copenhagen.

Cheryl (01:17): That's right. Yeah, I really love that conference. It's great. 

Marc (01:21): There's a lot of good vibes still going around where it just it felt like there was 350 people plus a whole bunch of people online that were thinking similar things and on the same page. And I detected a lot of passion from you, Cheryl. And there's a few different things that we could talk about. But first, I understand that you're starting a new role.

Cheryl (01:43): I am. I'm extremely excited to be joining Arm as Senior Director of Ecosystem.

Marc (01:52): Ecosystem building is clearly a passion of yours. And I think it's something that really kind of carried over to when we met in Copenhagen. There's been a lot of talk about your work with CNCF.

Cheryl (02:06): It really has been a passion of mine. In fact, I was thinking about this a few weeks ago, and thinking what is the thing that is really bringing all the strands together? The things that I've done through CNCF, running the Cloud Native London meetup through my new role. And I think I'm really passionate about bringing people together to build the future of infrastructure, especially around cloud native and open source as the means that bringing people together, getting that energy and ideas and spark really matters. It really kicks-off so much as we've seen from the global cloud native, all of these things have really changed in the last five years. That really is something that I believe very strongly in and I really enjoy doing.

Marc (02:50): Let's get a little baseline first. Would you like to describe to us, first off, what is Ccloud native? What does it mean?

Cheryl (02:57): Sure. cloud native is a way of building large-scale infrastructure that is resilient. Classically, if you're running infrastructure, you have to worry about hardware failures. And it's very hard to scale because you need to grow infrastructure and sort of bring on new hardware as your usage increases. cloud native is a methodology that came out of Google using Borg internally. Now they released an open-source version of that called Kubernetes. And a lot of cloud native is based around what we call containers, orchestration, what's the third one, Marc? 

Marc (03:36): Microservices? 

Cheryl (03:37): Oh, my gosh, I should really know this, microservices. That's not the only definition of cloud native. It's not the only way you can do cloud native, but it is the most common way to do it nowadays.

Andy (03:49): Often when I'm interviewing somebody for a consulting role here at Eficode, I'll ask them, "What's the definition of cloud native?" Just to get a baseline of how they see things and how they work. And I'm sometimes rather surprised at the wide variety of answers that are out there. But I think this was a pretty good one.

Cheryl (04:09): Now, I'm curious, though, what's the most interesting, surprising answer?

Andy (04:13): Well, I guess the most typical one is. Well, cloud native means you're using stuff in the cloud," and then dead stop. Silence. Okay, well, that's a good starting point. But what does it mean? What kind of thinking goes into it? And then the one that irks me, the most, I guess, I would say is, "Well, it means you just outsource all your problems to some cloud provider, and then you don't need to worry about anything anymore." Well, that's kind of an end result in some aspects. But when we're defining a system and like designing an architecture, cloud native means something; what would that mean? And I'm usually able to dig out something from it. But that's always an interesting thing because it says cloud, then that means too many people that okay, cloud has to be the main thing. But you can do cloud native without using clouds! Because to me, it's a way of thinking about how you're designing your system, what kind of tools you're using, what kind of ecosystem you're putting into place and pulling bits and pieces of this and thinking about things from a certain angle more than where you're actually running compute.

Marc (05:23): And you're building it in such a way that it scales so that you're only paying for users, you're not paying for things that you're not using. And you're able to scale to whatever the user base is, where I usually start from. So then, what is the Cloud Native Computing Foundation? 

Cheryl (05:39): Cloud Native Computing Foundation, also known as CNCF, is a sub-foundation of the Linux Foundation. So really, it's a home for the open-source projects that power cloud native. First was Kubernetes, but now there's over 100, I think, Prometheus, Envoy, gRPC, like, lots of really big ones. But the goal of CNCF is to get the people and the organizations and the technologies together in order to build these open-source projects.

Andy (06:12): I'm really glad to hear that you who used to work at the CNCF was like. I don't know how many, I think over 100, I guess some examples are. When I started working with cloud stuff in around 2017-ish, I came across the CNCF landscape. And first I thought, "Okay, for my system, I need to have one of each of these." And then I realized that's not really feasible, but it would be really good if I had tested and played around with each of these things. And then nowadays, I can't even recognize all the things.

Cheryl (06:47): I think everybody feels the same. And everyone thinks the same. There's so much on the landscape. Things change really quickly. There's new tools and new technologies coming on all the time. Yeah, I think everybody feels like, "Wow, this is quite overwhelming."

Marc (07:05): It's funny, though, when I saw the CNCF landscape for the first time only a few years ago. I found it comforting because there's so much there that like the imposter syndrome level comes down because how could anybody possibly know all of that? So actually, the complexity was something that gave me a bit of comfort, but I guess it's become somewhat of an issue now. Is there a problem to solve here with how large CNCF landscape has gotten?

Cheryl (07:32): The landscape is really designed to see the organizations, the businesses behind all the technology. It's not designed as an exhaustive list of everything you must know before you start building a cloud native architecture. For instance, includes the market cap of the companies behind it. And that's very intentional because CNCF is about building an ecosystem of organizations, not just about the technologies. I would say it's not a problem, but you have to understand why it was built and why it looks the way it is.

Marc (08:02): I think $18 trillion dollars market cap. I can understand how that in and of itself could be intimidating for some people.

Cheryl (08:10): I mean, it's been great for so many people, all three of us included. It's built a lot of careers and livelihoods around cloud native.

Marc (08:19): And I guess there's a lot of open-source here as well, which is really nice to hear. More than 76 (new) open-source projects.

Cheryl (08:28): I think a lot of companies rely heavily on open source. But it's hard to tie the value of open source back to something meaningful for the organization. I think this is actually 76 new open-source projects in 2021. Like this was added to CNCF in 2021. That shows you that these open-source projects are creating value within the ecosystem. 

Marc (08:52): There's all this open source. One of the things we talked about like with telcos and things is like when you are having lots of companies contributing to open-source projects, you end up with the standards are as code, or the standardization of things as code. Do you see some of that in CNCF?

Cheryl (09:11): What do you mean by that? Elaborate a little bit more on standardization.

Marc (09:16): Many technologies rely on some level of standardization. You have standardization bodies around protocols and things and then when these are instantiated as open-source projects, then everybody is basically contributing to the standard-as-code rather than something where everybody has a proprietary implementation of some common, say a telecommunication standard. 

Cheryl (09:41): I think that's one of the main goals behind CNCF and cloud native in general. Each one of the cloud providers used to have a very different way of running workloads within their clouds. And Kubernetes provides this API, standard API's across all of them. And the value of that means that you can now move from cloud. Well, theoretically, anyway, you can move between different cloud providers, you can move on-prem and into the cloud. And as you say, the fact that it's people coming together to write those standards is really, really important. It's not something that's been imposed by a single company on the rest of the industry. It's something where people have come together and decided collectively that this is the correct way to do it. 

Andy (10:28): And Marc was talking about telcos and synchronizing standards and whatnot, just came to my mind the case we heard that there was a SMS related standard. And there was example bits of code in the standard. And one company we were working with had implemented their version very, very strictly according to these examples. And one of the IDs, you could encode it as a decimal notation, or hexadecimal, or octant, or whatever kind of numbering scheme you wanted. But in the example code where you send it, it was in decimal. And in the receiving example, it was in hexadecimal. They built in all this translation to translate between decimal and hexadecimal in their code, just so they could follow what they thought was the standard, instead of following that this is an example implementation. And I think that that's one of the things that I haven't seen as much of in open source because instead of saying, "Well, here's an example," you say, "Well, here's some code, just use it." And when you have a problem, you fix the code and everybody benefits.

Cheryl (11:43): That is one of the great things about open source that that people can go and look at. Well, they could go look at the code behind it, right? It can see whether the format is important or not. And then yeah, people can benefit. Everybody benefits from the improvements that people make.

Marc (12:00): It's a lot easier to test something as code than to test something as a standard that then is instantiated differently by everyone. That's a really neat story from Andy.

Cheryl (12:10): Yeah, I'm sure it's particularly interesting within telcos because there is so much effort around standardization. So many protocols involved with that industry, things have to take a very long-term view, right?

Andy (12:22): Well, this is going to be our proprietary implementation because we figured this out, and we don't want to share it because then somebody else will value from it. And then just the whole way of thinking that even when we talk about open-source stuff, I'll talk with some ex-colleagues who are still in the telco world and like, "Well, why don't you just use this open source?" "Yeah, we fork that and we're maintaining our own now, so we can control it?" "Well, you're kind of missing the point of open source, but at least it's a step in the right direction. Good job."

Cheryl (12:53): I have certainly worked with and at companies where that's the case. Yeah, it's a pathway there. But in fact, it's much better if contributions can be made upstream to the vanilla version of these projects, and you use the vanilla version so that everybody gets the benefit.

Andy (13:12): Yeah, exactly. 

Marc (13:13): That's coming back to you. Do you have actual business differentiators because the technology in so many cases is not going to be one, everyone else is going to get there. So why not get there as quickly as you can by sharing some of the implementation and then try to do something unique in your business. But back to CNCF. I understand that people want to get involved and the landscape can be so broad, there are so many different ways to contribute. Can you give any words, Cheryl, on how someone can get involved? And what are the ways that people can contribute to CNCF?

Cheryl (13:46): Sure. I think that it might help if I describe the structure of CNCF. And then depending on what viewpoint you come from, there are different avenues to get involved. CNCF generally splits apart vendors and users and some other things, for example, training, consultancies, different kinds of organizations. And most people who work on these open-source projects work within a company to do so. I think people often think open source is individuals just spending their evenings and weekends, but I don't think that is the case anymore. I don't know if you agree. I think most people work through organizations contribute.

Andy (14:25): At least in the big projects. Yes.

Marc (14:27): I think most open-source contributors are paid software professionals working for companies utilizing that software within their business.

Cheryl (14:35): Exactly. And because it's good for the business, therefore, the business benefits from having the individuals contribute. Most people start out just by using the projects, and they'll contribute in ways which are more about sharing their experiences. For example, they'll join the Slack community and ask questions, or they'll go to or Stack Overflow or on GitHub, they'll file an issue and ask why things this way or what am I doing wrong here? I want to emphasize that that is a form of contribution. That is something that is not just about writing code or directly contributing to the project, but it contributes to everybody's source of knowledge about these projects. Typically, after using projects for a while, people start contributing them directly. This could be writing code or writing documentation, examples, writing blog posts, I really started contributing myself through meetups, starting the Cloud Native London meetup, this was probably 2017. I was looking for places to speak at, speak up and learn about cloud native technology. I was looking on meetup.com and I saw there was a Cloud Native Berlin and a Cloud Native Paris, and there wasn't one for London. I just created one and started running this meetup monthly. Firstly, it didn't have a venue, didn't have speakers, didn't know how to get involved with this at all. But I think the very first one that I ran, over 100 people showed up. That's when I thought, "There's interest, this is something new that people are looking for." And I've continued running the meetup over five years now, going to about 7000 members. And that is a form of contribution as well, people come together in these meetups to learn to share from each other. I want to emphasize like, apart from contributing directly to the projects, there are many, many different ways that you can contribute. You can also get involved through the tags, the technical advisory groups, or the different working groups, show up to the course, become a maintainer in the project, and move into those leadership roles as well.

Marc (16:41): I'm glad you mentioned, going to meetups looking for places to speak. We had Kelsey Hightower on the podcast last week, and he was talking about that was the first place that he learned speaking was one of his things, and I could see you had a similar path. And there's an interesting thing about people like you, Cheryl, which is that because you get out and speak. And of course, organize meetups and lots of other things. But you have the ability to influence so many more people than you would if your sphere was just your friends and your work colleagues. And I think that's a really amazing thing and then if you create a place like a meetup for people to come and do that, I think that's even more amazing,

Cheryl (17:22): I feel very lucky and privileged to be able to speak to lots of different people and it's just as important to me to hear what other people are doing as well. I think a good speaker reflects what's happening, and what they're seeing. I think it's easy to say, this speaker's sort of bringing information down from on high, and it's not. I think everybody should give a go, like try their hand at speaking. And you don't have to be a world class expert in things, you just have to get up and share what you know.

Andy (17:54): Quite often, we hear that you learn more from failure than from success. I think too often we hear talks and whatnot about this is how we did it. And this is how everything went so smoothly. But the most interesting and most useful one sometimes are, this is what we screwed up and this is what we got wrong. And this is the problem we had. And this is how we went to debug it. And this we have how we actually maintained and figured out a way to fix this long-term. We learn more from our mistakes. And from our successes, I guess I have a great career ahead talking about screwing things up.

Cheryl (18:34): I really agree with you, Andy. I' find those talks really interesting myself, I love hearing them. I really want other people to go out and talk about the things that didn't work so well.

Marc (18:51): Hi, it's Marc again, if you'd like to hear more from Cheryl Hung, her presentation, "Infrastructure Matters" was just released from the DevOps conference, Copenhagen. I'll leave a link for you in the show notes. Now, back to the show.

Marc (19:10): Is there anything on the path 'to the stage' that you'd like to share, Cheryl, like how you how you got to become a public speaker, or how you maybe have improved the craft of public speaking once you've started doing it? Would you like to share anything there?

Cheryl (19:27): Well, I think you hit on the right word there. It is a class. It's a skill that you can learn and you can get better at. I watched some of my early talks back and I think they're pretty terrible, to be honest. It's a case of like, record yourself, watch yourself back, listen to yourself, see what things you can improve. Listen to other examples of great speakers and how do they build their slides? How do they present these ideas? Everybody has a very different style. For example, you mentioned Kelsey Hightower, a lot of people really love the way he talks because he comes across as like the everyman, very relatable, very easygoing kind of person. For myself, I don't do the jokes, the comedy very well. My style, I like to inspire people and share stories and data and give them a future vision of something they can work towards, but I don't do so great at  'here's the little funny cutesy jokes and memes' kind of talks. Everybody has their own style, there's definitely no one perfect way to do public speaking. But if it is something that you feel strongly about, then I would just say watch yourself back many times and look at things you can improve, see how you can iterate and improve over time. And I think it probably took me two or three years to get to the point where I could say, I feel comfortable now as a public speaker.

Marc (20:58): I think it's important to understand as well, that everybody's nervous when they start out. I would say everybody's nervous even when they've been doing it for a few years or many years. Like when we get on the stage, I'm still nervous every time although I know that if you prepare well, then you'll do well up there.

Cheryl (21:13): You don't come across as nervous, Marc.

Marc (21:15): I turned it into energy.

Cheryl (21:19): Everybody's different as well. And people prepare in different ways. I have great admiration for the people who can just stand up and off the cuff adlib about everything. I prefer to prepare and rehearse over and over again until I feel comfortable. Everyone's different.

Marc (21:35): Everybody has a style. And what's important is to get up there. The other thing is, like you mentioned, something I really liked, which is some people look and say, "Well, you know, who are you to get up on the stage and say something?" It's like, well, you can to or everyone can. If you disagree with what you hear, get up and say what you would like to hear, or what you would like to talk about, I think that's something that's really important also.

Cheryl (21:59): I think one thing I've learned is that audiences are generally very nice, they're very forgiving. Everybody makes mistakes and it doesn't matter. Generally, it doesn't matter. If people can ask you questions, and you say, I don't know, I'll have to look it up and find out and tell you later and it's totally okay.

Marc (22:17): Excellent. Let's go back. Just a few words, I think sustainability and software development is so important. We can look at sustainability in terms of carbon and energy consumption, we can also look at sustainability in terms of psychological safety in the workplace, and work life balance and things like this. But I'd love to talk a little bit about sustainability in general. And I know you've given some presentations here. But, Cheryl, what does sustainable computing mean to you?

Cheryl (22:53): Sustainable computing is taking a long-term view towards the resources that we're using, and how we're designing our architectures to be most efficient with those resources. I think it's a relatively new topic. Certainly, on the software side, I mean, we've been talking about heating and cooling data centers, for instance, for many years, but it's still relatively new when it comes to, for example, how are we storing data? How are we replicating it? Are we making a good tradeoff between what the business needs versus how much resources we're consuming for that? Sustainable computing is really about some principles of looking at architecture. It's not about building a specific tool or specific technologies.

Marc (23:42): And as not every cloud native architecture necessarily has all of these sustainable principles, but as cloud native way to have more sustainable computing?

Cheryl (23:54): I think it is. And I think it is because the number one reason that Google came up with Borg was to be able to pack those workloads onto the servers more efficiently. If you're getting 80% or 90% utilization versus 10% or 20%, that makes a huge difference to how you're using those resources. I'm not saying that cloud native is a way to do sustainable computing, but it is one of the early principles. It was one of the reasons that cloud native was built in the way that it was to maximize the utilization. And that is super important. In fact, I went to a summit in Zurich, which was run by the UN about this topic a few years ago about sustainable computing. And most of the people in the room said, they're mostly hardware-based people. They said, "We've got these new cooling technologies. We think we can get a 5% better cooling", let's say for data centers, and I said, "Okay, great, but if you can increase the utilization of the actual servers from 10% to 90%, that is a 900% increase that far blows any, like 5% better cooling out of the water." The software side of it is really important. And it's not seen so much yet.

Andy (25:18): I was in a discussion one point with a developer who was really, really trying to convince me that I need to do all of my tools in C-Sharp, or C, I don't remember, no C, not C sharp, C, because the performance was better than the Python scripts I was writing. And I had said, "Well, yes and what I'm writing is a tool I'm using from an operational point of view, to install software I run it one time per year. The amount of time that it takes me to develop this is like vastly different. What's the use case of what I'm developing?" And then I was thinking after that, as you were talking that when I'm developing a software, then or an application, or whatever it is, what's the use of it? And where does it fit. From the hardware point of view, 5% in cooling sounds massive. But if we can change the way we're packing the software into containers, and whatnot, that can even be a completely different level when it comes to choosing what software we're using, what software language or whatever, it matters. And it's important that we look at this from all the different perspectives, not just one, what is this used for? Where's it used? How does it fit into the bigger picture, and then really, we're able to make an overall sustainable choice, instead of saying, sustainability check! On one area only...

Cheryl (26:48): One hundred percent. And you reminded me as well of how these overlaps with the FinOps approach, which is it's an iterative cycle, you identify the areas that are consuming the most resources. And this can be money or energy, or carbon or whatever and you look to optimize those. A tool that you use once a year, you're not going to get a big saving by optimizing that. But if you have something that is running, it's taking up 20% of your system resources that's worth focusing on. And this is not a one-off choice. This is something you're always going to be looking at just as when you're trying to reduce your cloud costs. You look at that over time, you don't pick one thing and never change. 

Marc (27:36): Okay, thank you, Cheryl. We have two more questions, please. Something that we've been asking all of our podcast guests. The first one is think back when you were young, what is the first thing you wanted to be when you grow up? 

Cheryl (27:55): A vet? 

Marc (27:57): Veterinarian?

Cheryl (27:56): Yeah. I don't really understand why because I didn't have pets at the time, but I thought being a vet would be great. Yes, yeah, definitely have to be a vet.

Marc (28:08): Wow, okay. That's a unique answer. Okay. The second one is that, think back on the path that you're on. Did you either need to change paths at a certain point or did you become crystallized that you're on the right path? Was there a decision point or a validation point?

Cheryl (28:27): Definitely. And when I was younger, when I was past the vet phase, I was absolutely certain that I wanted to be a software engineer at Google, that was definitely going to be my goal in life. I studied computer science and so on. And I joined Google as a software engineer. And after I left Google, I made the decision to move into developer advocacy and do the public speaking and do the events and not code as my full-time job anymore. And I found that emotionally really hard. Strangely, I built so much of my thinking around I'm going to be a straightforward engineer. And that's it. All I'm going to do is code. It was actually a big decision point. When I said, I'm going to let go of doing that and I'm going to go and do the external facing community open-source advocacy work. But I have to say, I think it's been great for me for what I enjoy. I love bringing people together. I love the teaching, the sharing, learning, all of that has been great for me. Very satisfying, personally, and good for my career as well.

Marc (29:33): Excellent. Thank you very much for joining us, Cheryl. It's been a real pleasure to go through these things with you. And I like how we've been able to talk so much about the human side of things, and we ended on such a human side of things note. Thank you for joining us today.

Cheryl (29:50): Thank you so much for inviting me. It's been an absolute pleasure to speak to you as well.

Marc (29:57): Before we go, let's give our guests an opportunity to introduce themselves and tell you a little bit about who we are.

Cheryl (30:04): Hi, I'm Cheryl Hung. I'm Senior Director of ecosystem at Arm, also founded and run the Cloud Native London Meetup. And I love bringing people together to share what they know and learn about cloud native, open source, and infrastructure.

Marc (30:18): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (30:23): My name is Andy Allred and I'm doing platform engineering at Eficode.

Marc (30:27): Thank you for listening. If you enjoyed what you heard, please like and subscribe, it means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.