 Welcome back everyone to the LiveCube coverage here in Vancouver for Open Source Summit 2023. I'm John Furrier, hope with my co-host Rob Streche. We're going to talk about the CD Foundation. We've got a great end user of Fidelity Investments here inside the Cube. Fatih Damaji, who's the executive director of CD Foundation of the Linux Foundation and Gerard McMahon, product area leader for ALM tools and platforms at Fidelity Investments. Gentlemen, thank you for coming on. Thanks for coming on. So thank you for coming on. Fidelity, great end user. I know you guys do a lot of R&D, a lot of development. It was on the forefront of it. Fatih, the Foundation is doing very well. Congratulations on your momentum. Yeah, yeah. Let's get into the momentum. Give us some updates from the snapshot of what you guys were releasing and on stage today, some great news. Share the update. Yeah, we were pretty excited actually during the morning keynotes of Open Source Summit in North America. One of our community members, Tracy Reagan, talked about some of our projects, such as CD Vans, Orteleus and Tecton. And those projects are actually are the projects we made announcements this week. We see great momentum for those projects and many different organizations are joining to support our mission because Continuity Theory Foundation is a place for everyone to come and contribute and collaborate on Continuity Theory and DevOps topics to make sure we push the domain forward in a collaborative manner. And one of the announcements we made was about CD Vans project, which brings interior to Continuity Theory ecosystem so the organizations could use these different continuous-level technologies in an interoperable manner, which is a big win for everyone in the ecosystem. We've been talking about platform engineering for years on theCUBE this past year. We got definition around kind of what it is. It's not SRE, that's what Google does, all the big guys. It's more ITs, we call it a KubeCon, more mainstream, a lot of traction, a lot of stories around that. But CD is a big part of platform engineering, interoperability and supply chain. Fidelity, you guys have some news, open sourcing, some tools, let's get into that. What's the update? Yeah, we're delighted. We're, you know, financial services company, we're very much into our digital transformation and cloud adoption. And one part of it is, how do we embrace open source more? Open source brings the world of many thousands and thousands of developers from all over the world with all different experiences and essentially they create better code. When you have a thousand eyes on a piece of code and you have a thousand people collaborating, communicating, discussing, et cetera, you know, you can trust in that code and it scales out faster. So we, as part of the, you know, we're an end user member of the Continuous Delivery Foundation and one thing we contributed recently as part of CD events was Jenkins plugin. So as Jenkins runs and it runs pipelines, it runs, you know, what you do in your pipeline, your different stages and steps, et cetera, we just wanted to know what that, all that data was, you know, compliance, security, quality, et cetera. So we've contributed that to the open source community as part of the Conjures Delivery Foundation and we hope to get more contributors from elsewhere and other users. So, you know, we can, they can contribute additional features, which we can just inherit then. And the benefits of the plugin is what? Consistency, what's that mean? Benefit for the plugin. So it helps us understand the continuous integration and continuous delivery of process for each application as they're deploying to cloud. So are you security scanning? Have you got any vulnerabilities? Have you done code quality scanning? Have you done your chaos testing or performance engineering? Have you run your governance and your compliance checks? So we can have evidence and security and compliance around the SALC process and have a really consistent then for every application team in Fidelity. How does that play into, I mean, again, being an end user and financial services heavily regulated and how does this help you from a platform engineering perspective and bringing things together? So if you, you know, think way back the monoliths, you know, we deployed to data centers, you had this giant artifact that was produced over a period of time. And that was, that was the extent of it. You handed that to somebody and they put it into the environment. Today with cloud, we think of there's infrastructure as codes, there is your applications, your microservices. So the complexity and the amount of work that an application team has to do, every application team has to do is getting greater and greater and it's reducing the amount of time we're spending on business value. So platforms enables us, provides platforms for developers to use in order for them to just focus on business. Does that help when you're rolling out, yeah, you're transforming your internal applications as you digitize them. And as you transform them to be more cloud native, is this helping you report back to the health of those applications and where they are in supporting your customers? Absolutely. So one thing is it provides us the consistency in how to get to the cloud. So we can build those guardrails into the platform. So as teams are going to cloud, they can go as fast or slow as they're capable of doing or as the maturity increases, but the guardrails are constantly there to keep them safe and secure. And how different do you think your journey has been than say others that are outside of the financial services industries? We've seen some others here as well, but... We were having this conversation yesterday that we're all solving the same problem and I think one of the benefits of the foundations is we can all work together through the open source community to solve these problems as an industry. And then everybody, all the enterprises can then adopt those solutions because it's common. Fadi, what's the issue in the interoperability of interoperability in the ecosystem? What are the core challenges? What's going on to solve those problems? This is one example of highlight for fidelity, but interoperability in the ecosystem has been something that you guys have been working on. What's the update? Why it's not time? Well, it's actually what you asked about platform engineering as well, like if you think about a typical pipeline and if you have different technologies there and you want to make those capabilities available to our development organization, that pipeline and surrounding technologies need to be integrated to platform so the developers don't see those details and they focus on adding business value, as Jar said. But currently, because of lack of interoperability in the ecosystem, that effort bringing those different technologies together, whether it is like software code configuration management, build tools, artifact repository, CICD orchestrators, test frameworks, observatory tools, application security tools. Because of lack of interoperability in common language, the problem becomes so huge and everyone needs to do this integration themselves. Spending time, effort and energy, it's costly and it's open to problems because open source community is more fast. Your integration may be broken the next day. What interoperability brings into picture is to remove this complexity and actually make sure all these different types of technologies can speak on the same language. We can have them as part of your platform and hook them into your platform using that language and then the rest of the organization don't need to worry about that. So that is what brings to the table. Yeah, so do you see that, I mean, fidelity goes in those Jenkins, do you see that others are going to have to contribute in that ecosystem or is this something that's being embraced by those other projects and those other tools? That is one of our announcements we made during our Silicon GitHub event Monday and Tuesday this week. In addition to Jenkins, Ericsson, for example, from telecommunications industry, they contribute a request for comment to Spinnaker project which was accepted by the Spinnaker community recently and the implementation is currently happening. And if you think Jenkins and Spinnaker, many organizations use these two technologies together. Jenkins for CI perhaps, Spinnaker for continuous deployment sites. And this will allow them to use these different technologies to get seamlessly because of this CD-Vance protocol or interability ports we have. The third project is Tecton. They have an experimental controller again using CD-Vance bringing in interability and we got a question recently asking like, what about the projects outside of CD Foundation? And we have a project called TestCube which is an independent open source project and they recently introduced test events to CD-Vance protocol making test framework to speak in same language. So currently we have these four projects adopting CD-Vance bringing interability for their users and we are talking with CNCF projects such as Argo, Flux, Harbor and so on to find out how we can bring them to this broader collaboration effort and have interability across different projects regardless of where they are. I think also the one thing and I think Tracy actually brought it up was that security, right? Because I look at this and you know, SBOM is the sexy new thing to talk about all everybody's got, you know, we do this for SBOM, we do that for SBOM. How does this play into the security aspect of that as well? You contribute the case study to continuous deployment foundation talking about some of the security concerns this might help address. Yeah, so it's, you know, security starts at the developer, the idea at their fingers and security is continuous when your applications are running in production. Security is continuous and it happens across every stage. So how, you know, how we maintain that, how we ensure that we are secure and safe on a continuous basis. You know, that's where I look at CD-Vance as well as a way of how can it provide the consistent way to talk about security, communicate with security and integrate security. So we can constantly monitor security across whether it's developer coding, whether it's, you know, something like log4j which can after the fact, right? So it was something that had secure one day not secure the next day. So it allows us build tooling, build monitoring, build observations, observability on our security posture and no matter at what stage of a SDLC. And one thing, sorry if I may add. Now, one of the key things, especially when we talk about Microsoft's cloud native and this, you know, desegregated, you know, world, if you think about like a commit going through pipelines and getting, being part of many microservice and getting employed in many different regions around the world, the traceability becomes a big issue. And security and traceability closely related. If you learn that there is a CV in one of the applications running in production environment in one of the regions around the world, you don't have too much time to fix that issue and such interability helps you track your steps back from the deployment back to commit. So you can easily identify which commit actually introduce that problematic dependency, for example. So we, I personally think the interoperability and security, they go hand in hand. Like if you don't have interoperability you can trace back to the origin of the problem. And that actually becomes much more difficult thing. And the other thing, if we think about integration in this context, integration causes loss of information because when you integrate two tools together then some things will not be available. You lose that data. But with interoperability, the information model, data model is there. As long as you have that, you have all the data with you. So they're tied together. You got the interoperability, which gives you the signals for the supply chain so the S-bomb can connect to the telemetry or data, vulnerability data happening in real time. That's more efficient than not having visibility into the container. Yeah, and it also allows you prove, right? So if you sign anything, so it allows you prove that this object, whatever it contains and what you've signed it is, it allows you verify that. So you can be constantly, you know, there is a trust model, but you're almost always able to verify that trust at many points. It's interesting, I want to get your guys' thoughts on a concept that's been kicked around by some people, not us, but others. They're saying that platform engineering has emerged because of the complexity of Kubernetes and containers. Don't think that's accurate. I think it's more of platform engineering came from infrastructure as code, which we come from, you know, SRE kind of mindset. So I want to get your definition of what platform engineering is. I mean, for the mainstream market, because there's the hardcore hyperscalers that do stuff at such scale, but I call them a little bit of an anomaly. They're like a unicorn. They do their thing, but, and it's probably just starting to get that scale going. So as platform engineering comes in, what does it mean? What is it? And then how is that different from say the developer, developers in the CI-CD pipeline? So what's your definition of platform engineering? Actually the organization of workforce called Cloud and Platform Engineering, we just actually, we were the cloud engineering team, so enabling cloud for fidelity, and now we're going moving into the platform space. So when you think of an application team, they're taking an application, their business code, putting it onto the cloud environment, and then making, you know, so their customers can access that value. There's a tremendous amount of infrastructure and cloud resources that need to be created as part of just enabling that technology or that value to be accessible. Every, you know, we have 4,000 application teams. If every application team is building out that application infrastructure, building out all of those resources, they're taking time away from the value mark that our customers are looking for us. So, but the platform to me enable application teams deploy their value much quicker. There's another piece here. There's the platform engineering team setting standards and scale. The app teams, which has developers in them, can be sitting on top of that. You guys enable them. We enable them then adopt all of these tools and capabilities. Okay, now the next question, great. Thank you very much for highlighting that. It's super valuable. Now the next level is as third party tools come in and manage services from skill gap standpoint. How do you guys look at that? Obviously, fidelity, a little bit, probably have more developers than the average company, but for the most part, how do you deal with managed services and things of that nature? So we look at the platform not as an abstraction on top of either individual services, capabilities we write ourselves, managed services, or third party tools that we might purchase from a vendor. And then the platform and the experience of consuming that platform is where we then look at creating on top. So you can have, like if we take CI CD, you have your source control management system, you have your CI system, your CD system, your code scanners, your security scanners. You've got all of these things. Now if a developer team, well, they have to use this one and then they have to talk to this one and they're chaining all of these things. So if we can create a platform and an experience, a consumable experience, then that's how we enable the developers. And the final question on this platform engineering definition is that there's an abstraction between the app teams and the platform teams. And then the next question is, is that can you have too many platforms? It becomes a platform, you can't have, it's like tools, you've got a lot of tools, but company can't have 10 platforms. I mean, platform engineering is almost like it is the foundation bedrock. Yes, it becomes, and that's why we in Fidelity, we've centralized as platform engineering. So we're serving the entire enterprise as part of making these platforms available. But you talk about the dynamic here because everyone loves, it seems to be platform, like love rail, I'm going to build a platform. I mean, it's almost like aspirational but not really real or not. In my previous life before joining the CD Foundation, I was working as software engineer, working with different tools and technologies. And no, for software engineers, when you see a problem there, you have this urge, I need to go and fix this. And if you do something three times manually on role, you go and think, I need to automate this. And this actually results in creating solutions that becomes useful to your friends within your team, then it becomes useful to other teams. And then you grow this kind of platform-like thing from within the team. And that's been there for quite some time. You create these things, put a web interface in front of it, and people just push few buttons, fill boxes. That is a platform in very simple terms. But where we are going now is we are still learning what the platform engineering means in this cloud-native world or in this new age. I think, as Jar said, every passing day, we will be putting different technologies under this platform. If we see our developers, our development organization, spending so much time on doing something, or if the cognitive load on developers increasing unnecessarily, then that could become part of the platform as well. So it's like, I think it's kind of continuously rejoining. Because platform engineering, the way you describe it, is a centralized, operational construct as well, but you can have an application that could be system-oriented with dependencies, cross-groups, that's an application. They're different, but kind of not, right? Correct, they're different, but yeah, but they're similar in function. And again, to me, as well as, if we take, and then the other thing that platforms can do is, and there is a finite number, right? There's not just multiples, is platform to platforms. So that's another opportunity, I think. So if we take observability necessary in your production services, and you've got your software delivery, can you combine the data and the intelligence between them to offer something of more value? Do you find that that actually gets pushed back from the developers because they feel like they're constrained in what platforms they can use? Just speaking out of my experience at Amazon, it was the Wild West, right? Every two-peats a team could go and do whatever the hell they wanted, which I think is the complete opposite of that. Developers love to develop, they love to innovate, right? They're in technology, that's their chosen career, and that's why they do it. So being told to do something and use something particular can be conflict, right? There can be a lot of conflict. I think you're understanding the word revolution, that will be rejection. You know, we're all very opinionated on my ways, but in your ways, but in your way, and yeah, so that's a constant balance, right? I think you've got to find a way to allow developers to innovate and allow their ideas to come back in, right? So we say, hey, well, this is a fantastic idea. We see five, 10 teams adopting this. Maybe that's a time to bring that back into the center. And I think that's the thing about platform. I'm bringing this up because I'm a platform thinker, I love platforms, but everyone, you can have an app that looks like a platform that's not platform engineering, it's just software engineering, app development. So then you have pure software development. So it's a nuanced point, but it's important to understand that some people think they're the platform, but they're not. But they're not, yes. Yeah, and it's how do you allow them to innovate and how do you allow them to contribute back? So we talk about open source being in the community, can you have inner source? So one of the concepts we have in Fidelity is how do we enable the inner source community so all of our internal developers and that they can contribute. And that's where I think you get adoption and openness to use these things because you're part of creating it. Well, we got to leave it there. Patti, thanks for coming on, Gerard. Thanks for the Fidelity investment masterclass on platform engineering and interoperability. So far so good. Congratulations on all your accomplishments. Thank you very much. You have the state of CD is out. Give a quick plug and what's going on. Yeah, state of CD report is a report we publish on a yearly basis during our CDCon event, which the fourth one was published this Monday. And state of CD report, your list of software delivery performance across different types of organizations, small, medium, large enterprises, different industries and so on. So the report is available on our website, CD.foundation and it has many interesting findings like use of different technologies, how it helps organizations to become better performing organizations and so on. So I think you should check it out. And DevOps continues, DevSecOps continues, infrastructure is code, really amazing story. Cloud continues to boom. Platform engineering, enabling development to be faster and more secure. And this is what it's all about in open source is the Q bring you all the action from open source summit here in Vancouver. I'm John Furrier with Rob Stretchy. Stay tuned for more segments after this short break.