In this episode of Semaphore Uncut, Cheryl Hung, VP Ecosystem at the Cloud Native Computing Foundation and founder of the Cloud Native London meetup, introduces us to the End User Community‘s latest initiative – the CNCF Technology Radar. Furthermore, we talk about the most common challenges companies face nowadays and why being part of the Kubernetes community is different.
Cheryl is a C++ engineer, a frequent speaker, and she leads the CNCF End User Community, the largest end user community of any open-source foundation.
We talked about:
- What the CNCF End User Community is and how it helps companies adopt cloud-native technologies
- The CNCF Technology Radar and how it helps the cloud-native community share knowledge about the many technologies available to them
- The necessity of service meshes
- Most common challenges for cloud-native end-users in 2020
- Why being part of the Kubernetes community feels special.
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited transcript
Darko (00:02): Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today I’m excited to welcome Cheryl Hung. Cheryl, thank you so much for joining us. Please go ahead and introduce yourself.
Cheryl (00:18): I’m Cheryl Hung. I’m the Director of Ecosystem at the Cloud Native Computing Foundation, the home of Kubernetes, Prometheus, Envoy, and many other open-source projects within the cloud-native world. My mission there is to help drive the adoption of these projects among end users. I work mostly with companies like Spotify, Apple, and Mastercard – not the cloud vendors, but the ones who are adopting it – getting them active and engaged within the open-source community.
Darko: Do you reach out to them, or are they approaching you, how does that process start?
Cheryl: It’s a mix of both. Some companies who are very interested in getting into open-source will come to us – those are the bigger companies. And then some of the smaller companies, we say, “Hey, it looks like you’re doing some really cool things within the open source projects. Have you considered coming and joining our end user community and being a more formal part of the ecosystem?”
CNCF and its end-user community
Darko (2:03): Can you give us a brief overview of CNCF and how it works?
Cheryl: It’s definitely not a typical organization. So firstly, it’s a nonprofit, so we don’t sell products, or any services. Of course, it’s all open source.
There are effectively three big chapters within CNCF, and they’re run by three different committees. One of them is the Technical Oversight Committee, who decide on the technical strategy of CNCF. There is the Governing Board that mainly handles marketing and budget decisions. And then, the third chapter is the End User Community. This is the one that I mainly work with. And these are, as I said, the end users of cloud-native.
End users are not trying to sell cloud services, so it’s more about understanding their needs. How do you make sure that they are productive and successful when they adopt cloud-native? Because if the end users are not successful, nothing else matters. Building a project that has no end users is not a good use of your time. So understanding the people and why they want to be involved is most important.
CNCF Technology Radar: a community-driven guide to cloud-native technologies
Darko (5:15): I saw recently that you launched the CNCF Technology Radar. Can you please talk a bit about that?
Cheryl: This has been something I’ve been working on for a couple of months, and we just launched it in the middle of June 2020. We have a private forum for the 140 end user companies of our community where they can discuss what they’re doing privately with no need for legal and PR approval. I wanted to help surface some of the discussions in a more aggregated and anonymized way so that all of the general community interested in finding out what the end users do with cloud-native can learn from this community.
The radar is a series of concentric circles and technologies plotted nearer the middle are usually more mature, they’re stable, they’re applicable to a wide range of use cases. As you go further out on the circle, these are upcoming projects or things that are no longer being so actively used.
We discuss with end-user companies, how are you using cloud-native? What different tools and projects do you use, where do you recommend them internally? And then put them together onto this graphical layout. Every quarter, we pick a different use case and publish a new edition, which is community-driven and shows off what the end users do. The first one we just launched was in continuous delivery, So if you go to the CNCF blog, you can read the full blog post and see what that looks like.
Darko: Do you have a predefined list of topics that you plan to cover in the next quarters, or are you deciding on the fly based on interest?
Cheryl: Go to cncf.io/tech-radar – this is a redirect to a GitHub issue. And on that GitHub issue, I’m crowd-sourcing opinions. And so people have said observability, monitoring, security. We’re taking opinions and votes, it’ll be up to the end users to decide what they want to learn about.
One important thing to note is that the data is not anonymized within the end user community. As I said, within the end-user community, they can share everything so they can see which companies are using. Externally is the anonymized version. But if you are an end user, and you want to see who’s using what, you could also come and join our end user community and start to actually contribute and see the real, not anonymized data.
Darko: I see this as a great safety net, also for many, many smaller teams and companies, because we can copy it from the big guys in a way.
Cheryl: It can be a full time job just to try and keep up with all the new things that are coming on and testing them and trying to make sure they work with all the other tools. I think everybody is facing the same challenge. Kubernetes is the winner on the container orchestrator, but then now how do you pick everything else around it? The monitoring tool, what security, and how do you deal with stateful data? How do you deal with the storage side? There’s so many decisions to be made.
Cloud-native adoption: Challenges of 2020
Darko (13:05): What would you say that are open questions of 2020? What requires the most attention from teams to decide on and to figure out?
Cheryl: I’ll give my opinion as well as some data-backed opinion. The thing that I find interesting and I think is still an unsolved problem is persistent storage for containers. Most companies still would prefer not to deal with persistent storage themselves. And there are some very large companies who run their own on-prem, everything on-prem, everything in their own data centers, and they need to have an answer to storage for containers.
I think there will be a point in the future, I think it will be years from now, when it becomes much better understood how you run persistent storage with containers. It’s a really hard problem, there’s no leeway for errors. You can’t lose 1% of data and just be okay with that. So it’s technically a very interesting problem.
Talking more on a data-backed view: every year, the CNCF runs a survey to the broader community. And one of the questions that we ask them is, “what are your biggest challenges?” So they can choose more than one option.
The number one challenge that people say now is dealing with cultural change. Bringing that DevOps mindset to a team and having people understand how to do GitOps, how to release frequently and often. And that’s the big difficulty now. And that’s a question of training, education, just time.
Improving the deployment experience
Cheryl (22:29): I think that’s quite interesting that service mesh is still a big topic. I still see some use cases that don’t use service meshes, but they tend to be quite, not exactly static, but they’re not expecting to grow very large or very fast. So it’s kind of okay, it’s kind of manageable to keep just a few services running. But if you go full into microservices, and you explode the number of microservices you have to run, then at some point, the overhead of dealing with networking in every service just doesn’t make sense. You should be putting it out and running it as a service mesh.
Back in 2010, I was a software engineer at Google, building features within Google Maps. I never had to worry about almost any networking things at all. I genuinely miss that a little bit because it’s just such a nice platform Borg, the predecessor to Kubernetes, where you don’t have to think about any problems really with the actual infrastructure. Of course, that comes with tradeoffs as well. So the complexity of it is much greater. You can’t just grab some logs off one server and go and inspect them. I have to find my service, find the actual job that’s running and figure out where those logs are.
Part of the Kubernetes community
Cheryl (26:50): I was at Google for five years, so for five years I had all these things taken care of for me. And then you come outside and you go, “Oh, I actually don’t know any tooling. I don’t really know how to build products without the assistance of all of this tooling.” But that’s one reason I really like Kubernetes and the way that the community has focused on being multi-vendor, multi environment. So it’s not just tied to a single company; as an engineer you can take your knowledge to another company, and if they’re using Kubernetes as well, you’ll also have the same understanding.
Something I find fascinating in the Kubernetes community, is that many people who work on these projects define themselves as being part of that project first, they’re a Kubernetes maintainer, they’re a Prometheus maintainer,etc. And as they change employers, they care more about the project than about what employer they work for. It’s nice to be able to say the work that I’m doing is open and that’s what I’ll continue to do, even if I change my employer.
Darko: We’ll let our listeners review your Technology Radar. And in the show notes, we are going to link to that GitHub issue that you mentioned so they can see what other people are interested in, and maybe they share their opinions. And good luck with Technology Radar, we’re looking forward to the next quarter and the next iteration. Thank you so much for joining us.
Cheryl: Thank you. And I’m really grateful to dozens of people who put time and effort into creating this first version. I want to make this a useful resource for the community. So, I want to improve this over time. Please feel free to put your thoughts into GitHub issues. You can email me at chung@linuxfoundation.org. You can find me on Twitter. I’m very open and I really want to hear your thoughts. Thank you very much.
