 Hi, welcome to this session on cloud native best practice for the Telcom domain. I'm Taylor Carpenter, a co-owner of Vault Co-op and a co-chair of the cloud native network function working group within CNCF. I've been an open source advocate and a Linux user since the mid 90s with a background in DevOps software development across multiple industries. Vault Co-op is a worker owned software cooperative, which started in 2013. We are a geographically distributed team providing consulting development and DevOps services. Today's session is about CNCS Telcom initiatives, some Telcom challenges, and how the different initiatives can help the people and community in those groups. Then at the end, we'll tell you how you can get involved. So who are these end users within the Telcom networking community? Well, they're creators as well as the users that are actually utilizing the technology for their customers. The creators may be developers of firewalls, routers and authentication applications, platforms. Some examples are Hitachi, Fujitsu and NAC. Those using the technology includes communication service providers, as well as cloud providers. Some service providers would be KDDI, NTT communication, and cloud providers like IBM, Google, Microsoft and AWS. So when do the Telcom users and the community adopt new technology and new ideas? Well, some folks may think that the Telcom industry doesn't adopt until very, very late. Maybe past even the most skeptical users of technology because they're risk adverse and they never want to go down. And I would argue that this is not the case. The Telcom industry has actually been part of innovations from the beginning. If you look at Bell Labs, you see different things coming out like UNIX systems, BSD, UNIX, NetBSD. These sort of things are still around. The TCP IP stack from BSD was heavily used. So there's a lot of innovation there. Even today, we have stuff like VPP, which is a networking technology that's coming out and available in a source that you could use. So where do they lie? Well, I'd say that sometimes it could be later, sometimes earlier. So what's the difference? Well, in the Telcom domain, I would say that they're assimilators, usually of technology and knowledge. They'll go out and look at stuff open source or otherwise. Linux, for instance, was adopted into many of what were physical systems. The network equipment manufacturers went out and they said, let's start utilizing Linux and BSD into the devices because it worked and they were able to take advantage of that. Virtualization came along and you started saying that technologies from open stack, open daylight, all these different things, bind the open source DNS software is utilized all over. So what's different here? We can take in technologies and beyond technologies. If we look at stuff like standards and methodologies around testing, you see all of these things within Telcom. So what's different? Well, with assimilation, often you're trying to make it fit into existing ideas and concepts that you have your containers. You're saying, how does it fit there? And sometimes the software technologies and even the methodologies are broken up and tried to shove into place and they don't always work. So what will happen with new technologies and new ideas, methodologies like Kubernetes and psyllium networking technology? What's going to happen? I think the Telcom industry will take advantage of these, but what we don't want to see is more of the taking apart and not gaining the benefits. To get around this, you have to go a different path, accommodation of new technology and new knowledge. This means coming up with new ideas, being open to expanding your view on how things work together. This allows you to come up with new solutions that you wouldn't have arrived at before if you're just assimilating the technology. And we look at other industries that started with various types of testing and have ended up with the capability to continuously deploy changes right into production while mitigating risk. This is what you see. Similarly with networking, you have things like GRPC, which is new and solving lots of problems that could be utilized in the Telcom industry. It's about growth and understanding where things can apply in brand new ways. The CNCF is all about this and they've created some new Telcom initiatives focused on helping the Telcom industry grow in these ways. Specifically around cloud native computing, where it wants the Telcom industry to be able to benefit specifically from the methodologies and technologies that you see there. These include principles and practices like being loosely coupled, microservices, automation design, which goes back to that CICD. To understand these things and dig into the technologies, you have to get back down to the principles themselves. At that point, you can start gaining the benefits that we've been seeing in the cloud native area and community, resource efficiency, resiliency and availability, all things that you want to see in the Telcom industry. These are for these end users that we talked about, the service providers, those network equipment manufacturers, application platform developers, it applies to all of them. There's existing standards that are within the Telcom industry, so we need to be able to understand that when we're coming together to communicate. We need to be able to integrate things that exist and then look at how to expand from there. We want to help with these long development cycles. We also want to make sure that we're aware of the low risk tolerance and the Telcom industry and try to show how we can solve these sort of things with new paths. In this way, the CNCF has created four initiatives, the Telcom user group, the CNF testbed, the CNF working group and CNF test suite. Right now we're going to focus on those last two, the CNF working group and CNF test suite. We saw CNF several times there, what we mean is a cloud native network function, which is an application that's providing some type of network functionality. That could be firewall, the BGP speaker, some type of gateway. When we say cloud native, we mean that it's going to be designed and managed in a cloud native way. It should be showing behavior that's following principles and practices that we're seeing in this industry. That's why it's important to know and understand what is driving these type of technologies. What's below a methodology rather than just taking it and copying a piece over, you understand what was the viewpoint. We recognize that there's challenges though. CNS or these cloud native network functions, these networking applications are hard to develop and operate. And we want to make it easier. We also know that there's good and bad ways to build these applications. So that's why, just like in most of the open source world, we want to share the pitfalls that we've had in the past so that we can learn from them together and avoid them moving forward. We also want to look at how open source standards have developed. So that we can have consistency that we can all share and grow from at the same time and expect that the applications are going to work in different environments. We also think it's important for the Kubernetes, the open source communities to understand the telecom community. So we look at stuff like use cases and user stories that are important in the telecom world, like supply chain attacks. Network and use cases and the lifecycle management that they have. From here, we can start looking at cloud native best practices. These can cover a lot of areas. Here's a set that we are focused on. There's going to be overlap and some, but it's important in any domains, observability, diagnostics, security, configuration and lifecycle. We want to be able to install, deploy, upgrade. All of these things are important in the telecom world and other industries. From here we can dig down. So what do we mean when we're talking about cloud native applications? So cloud of APIs designed for automation, compatibility between interfaces, security best practices, we can dive down in and look at things like least privilege, auditing capabilities and isolation. From here we can look at specific practices that we may want to talk about like relinquishing privileges, not using root within containers for processes. Don't run your systems with privileges turned on by default. So we've taken these best practice ideas and we've created a working group that discusses them. It meets every Monday at 1600 UTC, which has a goal of creating the documentation around these ideas, whether that's user stories, use cases, looking at best practices that we can write up and recommend. And then talking about how they're important and how they're relevant in the telecom domain. We have different interested parties from both the cloud native and Kubernetes community, as well as the telecom community service providers and creators of these networking applications alike. And then from the Kubernetes and CNCF community, we're pulling in experts that think about security, deployment, networking observability, to provide their feedback on how they can help the telecom industry to grow. As well as projects themselves for those that want to adopt these technologies so we can talk about how they can be utilized to maybe solve some of the challenges and use cases that are important to telecoms. We would love to have other groups join us like Fujitsu, Atachi, and anyone here listening, please come check out this group. We'd love to get your feedback on challenges that you're having, maybe practices that you've seen that have been effective. The other initiative that we mentioned was the scene of test suite. It's a compliment to the working group. It's focused on validation of those best practices. It's open source. It's a framework and a set of tests can be used by creators, those developers of the applications, as well as operations teams, ops integration type teams that are working to deploy these type of applications. And you can run it and test the applications with a little bit of testing for platforms that we will extend on. And then it gives you feedback on how well it's following these best practices. It's designed to be optimized on its feedback, give you quick feedback in specific areas you can run on. You can integrate it directly into your pipelines, whether that's your development workflow or onboarding of new applications before it goes into production. It also helps you to get aligned with the rest of the CNCF and cloud native ecosystem. So we work directly with the projects themselves with the different groups. We try to get their language, their information into the test suite on why specific tests are important, how they're going to be useful, and then bring you back to those tools themselves so that you can check them out and see how they could be used as well. The test suite itself is self-contained. You can get it started with a minimal set of requirements configuration, and it should work in any certified Kubernetes environment. We've utilized it in lightweight environments as well like Micro-K, it's K3s and kind, and we've added support for doing self-hosted and protected type environments. If you need that. We also have a flexible scoring system that tries to help you with different suggestions or mediation. If you're interested in trying it out, one of the things to note is what are we testing. So we have a focus right now on workload or the applications running on the platform. So this could be a single small service that's running in one container and one pod where it could be spread across multiple nodes and multiple pods and containers. It could be like a transparent firewall that sits there looking at traffic, or it could be something more complex like a 5G convergent charging system with many different components across many systems. The test suite is going to look at all of the containers that you've identified for testing and give you feedback. You'll look in those categories that we mentioned, and you can pick specific categories or run across all categories for all the tests that we have, or even an individual test. You'll go through, run each of those tests for the area, and then eventually give you feedback on the different parts of the test suite for the application. If you'd like to try it out, on the GitHub, in the readme, we have five steps that you can run, grab the latest binary, you get a couple of things set up with the setup command, and then you need a configuration. You can, if you don't have one or don't want to create one, you can download one of our examples, and then you run the tests that you'd like. For example, we show running the workload, which will run all of the tests within that are labeled for workload, which means all the different categories. After that, you'll start seeing some feedback on your console for any fails, any pass, any skips on how it's doing, and it'll provide you some information on the specific test. Once it's done, it'll save all the results into a file, which is in a YAML format. You can open that and look at the results. We also provide a link from the different tests if they failed back to a usage guide where we have more extensive information about each of the tests and why it's important, and what you could look at if you didn't fail so that you can make improvements to the test itself. We'd love to see contributions if you'd like to on the test suite or the working group itself. If you want to come and communicate some of your challenges, talk about your needs. We'd love to bridge the gap between what is happening in the cloud-native community and Kubernetes with your needs and the networking and telecom work. Again, the working group meets on Mondays at 1600 UTC. If that time is not good for you, please reach out to us. You can open a GitHub issue and suggest maybe some other times. We'd be open to looking at maybe an alternating time or something like that, but we do have a mailing list, a GitHub discussion board. There's several ways to talk there, including Slack if you want to chat with us. The test suite itself meets at 1515 UTC on Thursdays. This is a dev-oriented meeting around using the test suite, adding new tests. We'd love to have you there if you'd like to join. Again, my name is Taylor Carpenter with Vault Co-op. If you'd like to schedule a direct demo with me or to discuss how we can work together with any of these initiatives at CNCF, then feel free to schedule on our calendar there. Thank you so much. These slides will be available on Sketch. Thank you and you have a great day.