 Hi all, thank you for joining our session, the road to interoperability in cloud native continuous delivery. My name is Fahad Dermanji, I work for Ericsson Software Technology as a developer based in Stockholm, Sweden. I am also co-chair of the Continuous Delivery Foundation, Special Interest Group Interoperability. Hi all, I'm Karatana Mok, I work at CloudBees with the Jenkins and Jenkins X open source projects, and I'm co-chair of the Continuous Delivery Foundation's Interoperability SIG. Thank you for joining our talk on the road to interoperability in cloud native continuous delivery. In the context of continuous delivery, what do we mean by interoperability? Interoperability, composability, and extensibility are all terms to describe the openness of the system. That is, it's ability to offer components that can be easily used by or integrated into other systems. However, integration and interoperability will often used synonymously or not the same and have significant differences. Integration is generally understood as combining applications to function together. These applications don't necessarily have common interfaces, and often use different data formats. The result is often when engineering teams need to have these applications work together, they write the code. And these custom solutions have maintenance costs. In addition, services can be taken tightly coupled, and it can be a significant engineering effort to later replace one of the applications for something else. Interoperability, on the other hand, focuses on open interfaces and standardized metadata that enable controlled and defined access to services or information from a different application or system. Let's consider interfaces as an example of an abstraction which enables interoperability. If the interface is well specified and openly available, multiple service providers can implement the service and enable customers to consume the service in a known way using the defined interface. This provides a number of practical advantages. For example, if client A consumes a service by B through a well-defined interface, A could switch to C's implementation of the same service, which uses the same interface, and A should not experience any failures. How B or C implement the service is not relevant to A, which is only concerned with the specifications of the interface. The ability to replace one implementation of a service with another that operates in the same way without causing failures is interoperability. Well-defined public interfaces enable interoperability by enabling both access and multiple implementations. The result for end users of those interfaces is that they have a choice in which implementation to consume and the ability to switch between implementations without experiencing any failures. In addition to open interfaces, standardized metadata is another abstraction that enables interoperability. Standardized metadata enables systems to incorporate content from other disparate and independent systems. In other words, interoperability is achieved through data formats and communication protocols, which the systems can use to function together in a standardized manner without deep customizations. Definition of interoperability in the CI-CD domain is not different from how it's defined in other domain. It is about data and the exchange of it. As you can see on the slide, everything under integration is basically work that the end user has to do. And everything under operability is the result of work that has already been done when building the services that users consume. So the result is less work for end users. OK, when we look at the continuous delivery landscape, and this landscape has been developed by the continuous delivery foundation, we can see that the continuous delivery ecosystem is flourishing. There's a rapidly growing set of CI-CD tools available for end users, and this is fantastic. The new tools and technologies being developed bring fresh approaches to problems or issues within the CI-CD domain. However, the explosion in the number of tools is not without its challenges, interoperability among them. So let's look more closely at interoperability within the CI-CD context. First, pipeline standardization and or standardization in pipeline languages. The goal here is to have the ability to migrate or run pipelines created on one tool on another one as this. Next, the ability to connect pipelines, running on different tools in a standardized way. And pipeline data for traceability or visualization. The goal is to propagate data from CI-CD tools in a way that external tools can consume, regardless of what CI-CD tool created that data. We will look at two open source projects that help you gain more visibility into your CI-CD system and consider the work that they are doing to map the different data formats of different tools and how greater interoperability could help. For CI-CD events, we defined an event following the cloud events definition as a data record expressing an occurrence and its context. The goal is the standardization of events so that CI-CD tools that adhere to the standard can interoperate with each other. The common theme across the different perspectives is data and exchanging data across various tools that may be employed by an organization as part of their CI-CD pipelines. The data could either be in the form of pipeline definitions, consumed by pipelines as input, or produced by pipelines as output. This means that the definition of interoperability in the CI-CD domain is similar to how it is defined in other domains. It's all about the data and exchanging data. Among the activities of the interoperability SIG, we look at existing case studies, such as how Jinx and Zax incorporate Stecton as its pipeline engine to help users build and deliver software using the cloud well. Jinx and Zax helps you manage the lifecycle of your application, including continuous delivery on Kubernetes. Jinx uses Stecton for standardized declarative pipeline APIs and build execution. When users install Jinx and Zax, Stecton is also installed into the Kubernetes cluster. When users create new applications or import existing ones, Jinx and Zax will automatically add pipeline as code Stecton resources to the Git repository alongside the source code and configure web hook handling for Git events. The Stecton pipeline resources that are added come from a base set of reusable pipelines that live in the Jinx and Zax pipeline catalog. The Jinx and Zax project essentially aligns its pipeline definitions with Stecton and makes it super easy for any test when the Stecton catalog has to be used inside a Jinx-created pipeline. That level of interoperability between CI CD tools is relatively rare and remains specific to individual projects. So now let's look a bit deeper into some of the benefits of interoperability, especially as regards the maintenance of your CI CD system. And then we'll look at some tools that some of the source tools that have been created that help you in this regard. So additional benefits of interoperability. Greater interoperability between components provides many benefits, including improved scalability, reliability and maintenance. There's much to be said about these benefits and Fatih will touch on how interoperability improves scalability and reliability. So I'm going to look at how interoperability can help improve the maintainability of your system. And as we know, the effort for cost of software is actually not in the initial deployment and its development, but in its maintenance. One of the most important ways in which interoperability helps us with the maintenance of systems is in managing complexity. In complex software, for example, with systems with many components and much of blue code to integrate them, there's a greater risk of introducing bugs when making changes. And reasons for that include that the system is harder for developers to understand and reason about, that there are some hidden assumptions and that the unexpected interactions and unintended consequences of making changes are looked. So reducing complexity greatly improves the maintainability of software. That simplicity is a key goal for any system. And making a system simpler does not necessarily mean reducing its functionality. It can mean removing the complexity that is created when you are implementing the solution that you are trying to solve. By reducing the need for application blue code, interoperability helps make your system simpler. It also reduces type coupling in the system. Again, making your system much more maintainable. It is likely that the CICD systems requirements will change. There could be legal or regulatory requirements that change the growth of your system will force some changes and new tools will emerge that you'd like to incorporate. The ease with that you can modify a system and adapt it to changing requirements is closely linked to its simplicity and its abstractions, such as standardized data formats. Good abstractions help reduce complexity and make the system easier to modify and adapt for new use cases. Increased interoperability can also help us with the operability of the system. So good operability with standardized data models can help make routine tasks easy by exhibiting predictable behavior and thus minimizing surprises, providing good support for automation and providing visibility into the runtime behavior and internals of your system with good monitoring. This increased visibility into your system can help with investigating failures and finding and fixing bugs. Good operability means having good visibility into your system's health and having effective ways of managing it. We're gonna look at two really interesting open source projects that can help you gain more visibility into your CICD system. The tools use variations of data mapping between different data structures to be able to achieve that visibility. And so we will consider how greater interoperability could help reduce that mapping work and facilitate expansion of the capabilities of these tools. So four keys is an example of a project showing insights that can be monitored by CICD event data. The DevOps and Assessment team has identified four key metrics that measure teams' software delivery performance. Now deployment frequency, that is how often an organization successfully releases to production, the time for changes, and that is the amount of time it takes to get a commit into production and time to restore service. Just how long it takes for an organization to recover from a failure in production? And change failure rate, which is the percentage of deployments that cause a failure in production. Using data on GitHub events in CICD prep lines and making inferences about links between incidents and the events evolved, the Forks Keys project generates the four keys to a metrics. One of the challenges of gathering these two metrics is that the deployment change and incident data are usually in disparate systems. So for the four keys, solution was to create a generalized pipeline that can be extended to process inputs from a wide variety of sources. The Forks Keys project in effect creates a mapping between events in different pipelines and tools in order to be able to generalize the data it receives. Standardized metadata for CICD events help with the mapping work that the Forks Keys project has to do between the different data structures or the different tools. Creating standardized metadata for CICD events is one of the main work streams of the Interoperability SIG and is considered critical for the interoperability in the CICD domain. So in addition, standardized metadata would help improve the maintainability of your CICD system by facilitating connections between pipelines and other systems. And we reduce the need to write adapters or Google. Standardized metadata of events in CICD pipelines would enable much greater interoperability between tools and platforms and more consistent data to be used for analysis. So now we'll look at the Gingotek CD indicators. So this add-on to the Gingotek CICD platform helps you gain visibility into your CICD system. These insights are based on the Dora metrics and the space framework. The metrics are generated using Git events as with the Forks Keys project. In addition, Gingotek has a Kubernetes custom resource definition for a Gingotek specific type called the pipeline activity. A Kubernetes controller watches a Kubernetes API server for these custom pipeline activity events. The two main types of event data, so Git events and cluster events are kind of mapped together and combined to create the metrics displayed in the Grafana dashboards, which is an example on the slide. But this mapping for now happens within the context of one CICD project, Gingotek, and not across multiple projects or tools. It's a different mapping that done by the Forks Keys project using different data inputs. But note that this mapping work between differing data formats needs to be done by both of these projects. So the tools and technologies that are used to construct CICD pipelines and the pipelines themselves produce a lot of data. Organizations will collect, store, and use this data in various ways to get value out of it. Within the interoperability set, we are focusing on ways to reduce the need for data mapping between projects, tools, and other data sources by increasing interoperability through abstractions. I mostly discuss standardized metadata for CICD events as one of the ways to increase interoperability. Currently, the CICD tools and technologies have no standardized way to produce and consume that metadata. That is why standardized metadata for CICD events is one of our main areas of focus within the interoperability segment. In addition, how such metadata could be consumed and produced is another topic. This is being looked at within the Continuous Delivery Foundation's events segment. Fatih will not speak more about the work we are doing within the interoperability segment and within the wider Continuous Delivery Foundation community. Thank you, Farah. I would like to start talking about Continuous Delivery Foundation, which is a sister commit to Cloud Native Computing Foundation. As we all know, there are many great technologies out there one can use to have construct pipelines and establish cloud native continuous delivery within their organizations. However, there's not without challenges and one of the challenges is the fragmentation within the CICD domain. It is challenging to adopt, use, integrate, and contribute to various CICD technologies. Here Continuous Delivery Foundation comes to rescue. Continuous Delivery Foundation was founded during March 2019 hosted by New York Foundation, providing neutral home to collaborate for the next generation of Continuous Delivery. There are various ways Continuous Delivery Foundation enables this. First and foremost, it provides home to various open source CICD projects such as Jenkins, Jenkins X, Skinnaker, Hecton, screwdriver CD, and more tedious. In addition to hosting projects, it also accounts for creation of special interest groups and working groups for community members to come and collaborate on various topics within Cloud Native Continuous Delivery. There are currently five special interest groups, security, MDOPs, interoperability, best practices, and events, each looking into different areas within Continuous Delivery. As you can guess, these groups help community members to find like-minded people to collaborate on a certain topic, reach out to the projects, and find ways to contribute to projects and broader Continuous Delivery ecosystem further. When it comes to the topics that are critical for interoperability within Cloud Native Continuous Delivery, I would like to talk a few of the key topics, we identified and have been working on, so you can see how it impacts our bandwidth to become better doing Continuous Delivery. Four topics I would like to highlight during this talk are shared vocabulary, standardized metadata, events, and policing. As you notice, these topics are not pretty disconnected from each other. It was similar for us as well. However, when we started diving into the topic of interoperability and get into the details, we began realizing that the problem is much bigger than just how to get the CIC technologies interoperable with each other with well-defined interfaces or by standardized approach. It is also very challenging to tackle these problems alone in our community, because there are already many things worked on by our sister communities that could help addressing them either by learning how they solve similar challenges or directly using some of the things they develop rather than us re-menting things. Let us start with shared vocabulary. Special Interest Group Interoperability was approved during January 2020 by Continuous Delivery Foundation technical oversight community. So we are a little bit older than one year. We were very eager to get hands-on with the technologies we are using and working with. However, we started noticing that even though everyone knows what continuous integration, continuous delivery, and continuous deployment are, the problems we use to communicate with each other as humans differed. Apart from that, problems used by different CIC technologies to describe the same thing differed as well, contributing to the challenges with human communication. For example, we identified three different terms are used by various technologies when they talk about pipelines, workflow, activity, and what pipeline. As you can guess, these impacts are a bit to communicate with each other since if I am using a certain technology, I naturally use the terminology of tool during my day-to-day communication, and I may have difficulty to put someone using a different technology since that person is probably using a terminology of technology they are using. We then need to spend few minutes to map the terms with each other or translate them so we can talk to each other. This made us realize that even before we start talking about technology issues, we need to put effort to improve how we communicate with each other. We spent few weeks to discuss and collect the terms used by different CIC technologies on a document, but no one remembers from those projects to describe the terms we collect from their projects point of view, and we finally create the table that maps different terms across different technologies with each other. This helped us a lot since we can now have an easy way to look at the terms we don't know and see what they mean for us using different terms. We pulled this document for the HEPA stone for CRCD, and currently it has terms for 14 CRCD projects. In addition to CRCD technologies, we include terms for software configuration management tools, such as GetIt, GitHub, and GitLab. This is a community-maintained document and we welcome contributions, so please check it out. Are we done with this? Definitely not. Since this topic is relevant to more the interoperability area, these topics continue to work by special interest group best practices, so they look at what sort of term was first time described, such as content integration, content theory, content development, and DevOps, who defined the term first time and what it went through over the years. The next topic I want to discuss is standard item data. The CRCD tools and technologies that are used to contract CRCD pipelines and the pipeline stem cells produce lots of data. We as users collect, store, use, and analyze this data in various ways to get value out of it. There are two questions we are looking at answers for metadata. First one is about what are the types of metadata we use, and the second one is about how we produce, consume, and use them. One of the contributing factors is the lack of standardized way for CRCD tools and technologies, which first what metadata is to produce and consume. How to do that? It is true that there are initiatives across various open source projects to align the way this is done, such as in Porto, Baranthes, Jenkins X, and Tecton. However, this topic regards a holistic and collaborative approach to identify the needs and challenges first, followed by analyzing existing efforts to explore possibilities to streamline how this is done, either based on existing efforts or by combining them to come up with a standard way collaboratively. Then comes what we are doing within Controversial Foundation, and especially in terms of interoperability. We are currently documenting the types of metadata we produce and consume, starting with commit and artifact data. In addition to this, as I noted earlier, we are not after creating our own team, so we are also talking with various committees to learn more about what they are doing, see the overlaps, gaps, and explore collaboration opportunities. The reason it starts collaboration with SPDX community since we know that they also work on some of these topics within the data. I realize I didn't talk about how question for the metadata, how the metadata is produced and how it is consumed. And this is on purpose since one of the Controversial Foundation special interest groups, special interest group events is looking after this, explore the use of events within CICD. As we have been discussing since the beginning of our talk, these continuous integration and continuous delivery systems do not port to each other in a standardized way. This leads to problems related to interoperability, multiplication of failure issues, and poor automation. Who address these issues? The topic of events was brought up by community members special interest group interoperability to see if there are others who want to take a closer look at using events within CICD given that events are everywhere, offering solutions to various issues such as stability, resiliency, coupling, traceability, and so on. The discussion resulted in the formation of a work stream within special interest group interoperability with the aim to look at events more closely. In February 2021, this work stream has become a top level special interest group within continuous delivery foundation to take the idea to the next level and look at standardizing around the events within CICD. This special interest group is looking at how events can help to create CICD systems with a big up of architecture that is easy to scale and makes it resilient to failures. Using events could also increase automation and connecting workflows from different systems to each other. As a result, empowering, facing, visualizing, auditing of the connected workflow through these events. Community members from various open source projects take part in special interest group events bringing their perspectives, thoughts, and ideas to the groups. Some of these communities are from within continuous delivery foundation such as Tecdon, Spinnaker, Jenkins, and Otelius. We also have participation from other projects such as Captain from Cloud Native Computing Foundation, Python. The group aims to provide reference implementations such as event listeners and event senders on top of cloud events. The last key topic I would like to highlight is policy or to be more precise, policy-driven continuous delivery. This topic looks at how organizations could define standard policies for cloud native continuous delivery pipelines. This topic was brought into special interest group in Tripoli recently and it gives us a different perspective as it comes to what issues like interoperability within CIC domain causes. We know that most of the CIC technologies provide ways to enforce security policies within the organization. We also noticed a trend within CIC domain by that policy agent for this so things look relatively encouraging. However, when we start going into the details and looked at various different use cases, we restart realizing that there are things to work on further to enable organizations to define standard policies seamlessly. One of the things we noticed that the use of open policy agent by CIC technologies does not necessarily mean things will just work across different CIC technologies since there are slight differences when it comes to how these technologies bring open policy agent. In addition to this, there are other things to take into consideration such as existence of external systems and their role in enforcing policies. As we try to illustrate in the diagram, when an organization uses two different CIC technologies as well as external systems as part of their policy enforcement mechanism, things get pretty tricky. Apart from that, there are other policies than security policies such as business policies. These topics will also need to be looked at further. As most earlier, this discussion started with a special interest of interoperability recently and we will reach out to various projects that are actively working on policy topics, policy agent, not the network automation platform, policy framework. Please join us if you have interest to participate in the discussions and contribute. So these are the four topics I've selected from the work we have been doing including Continuous Delegation Foundation. There are obviously more topics we are working on. So please join us and help us with these topics based on your experience and ideas and organizational needs. Until now, we talked about projects and communities. But what about end users? So I would like to touch to the end user aspects of Continuous Delegation and Continuous Delegation as well. I am from an end user organization and it is important for my organization to keep itself connected to the ecosystem and contribute to the projects we are using. This can't happen without active involvement and collaboration within our consort where we can take part in the discussions with the communities which will impact how our organizations utilizing these technologies as part of their Continuous Delegation journey. Apart from joining and collaborating within the communities, it is also important to highlight our needs, use cases and challenges to the projects from end user perspectives. Continuous Delegation Foundation end user concept provides such an opportunity and allows end user organizations to take part in the discussions. End user concept recently published, it is 2021 plan based on the input from end users. The public, the group plan to work on doing 2021 are measuring develop success, developer productivity and experience, including them, technical choices and governance and compliance. As you can notice, all these topics have relations to interoperability in one way or the other. For example, measuring develop success require organizations to collect key metrics to evaluate their work performance. It is very difficult to achieve that since the tools that are used by organizations, whether SEM or CI CD, they expose these metrics in different ways. So if you are from an end user organization, please join us at us with our journey within Continuous Delegation Foundation. Finally, feedbacks about future, which is what I try to summarize during discussions about key topics. We work with various topics within various specialist groups. As you can see here, the three Continuous Delegation Foundation specialist groups looks at various topics and will continue to study them. We would like to contribute collaborative Continuous Delegation Domain in various ways. White papers, case studies, as practices, specifications, and reference recommendations, and so on. In addition to working with these topics within our community, we will either continue collaborating with other communities such as CNCF, SBDX, Unified Foundation Networking, and so on, or look for new collaboration opportunities. It is critical that we assist the communities to work on this like a single community to tackle these challenges and collaborate with them. Thank you. Most of the work in the CI CD domain is driven by communities. And so we invite you and your communities to join us in the Interoperability SIG. The ideas incubated and specifications developed by communities tend to become candidates for de facto standards, for example, with cloud events. We believe that cross collaboration and pollination across communities and industries is key to addressing challenges. Because these bring diverse perspectives that enable us to develop better solutions together. Please, you join us in the Continuous Delivery Foundation's Interoperability SIG. There are links in the slides on how to find out more about the Interoperability SIG and the Continuous Delivery Foundation. We thank you for listening to our talk, your interest in interoperability in cloud-native continuous delivery, and we welcome your questions.