This session talks about FINOS (the Fin-tech Open Source foundation), a community creating open-source oriented solutions for financial services. This episode features special guests James McLeod, Director of Community at FINOS, and Amol Shukla, an Executive Director at Morgan Stanley talking all things FINOS, DevOps mutualization, banking and tech.
Announcer: Welcome to the Cloudify Tech Talk Podcast, taking a deeper dive into all things, DevOps, all things, toolchains, all things, automation, and all things orchestration.
Jonny: Guys, welcome to episode 11 of the Cloudify Tech Talk podcast. My name is Jonny, I’ll be your moderator. Today’s session is going to be focusing on Finos, which is the FinTech open-source foundation, which is a community and creating open source-oriented solutions for financial services. So as usual, we’ve got some very special guests with us and as usual, I’m going to hand them off to Nati Shalom our CTO to introduce them and to kick things off.
Nati: Hello everyone, we are here in the Cloudify Tech Talk Podcast again, and with me is the distinguished… for the couple of… let’s say a couple of months friends, I’ll let them introduce themselves. We’ll start with Amol.
Amol: Thanks, Nati. My name is Amol Shukla. I lead the Morgan Stanley Development Environment Group. We are responsible for all of the tooling that’s used by the thousands of developers and stats at Morgan Stanley, as part of their development and deployment processes. So, our group really is focused on two goals. One is to improve developer productivity and obviously, DevOps is a big part of that, but also doing it in a way whereby we can enforce some of the controls that are required from a regulatory perspective, as well as from our internal InfoSec perspective. And as of last year, I was also nominated as the lead for the DevOps mutualization special interest group. Which was really a group to foster a common understanding of DevOps practices across regulated FinTech institutions like banks. I’m very happy about the invitation, Nati to help…to talk a bit more about some of the work that we’re doing in that special interest group.
Nati: Excellent. And I’m sure we’re going to have more questions related to what you’re doing with Finos and why we need Finos, and what is Finos in, let’s say my broader scheme. And why we are even having this podcast and this discussion. But maybe I’ll let James introduce himself and Finos at the same time. So, James,
James: Hi Nati, thank you so much for inviting me to this podcast. So, I’m James McCloud and I’m the director of the community of Finos. Finos is the FinTech open-source foundation. We are a part of the Linux Foundation, which I’m sure, if people who listened to podcasts have heard of the Linux Foundation. Who have a project such as high college and nudge and various other open-source tools, that you would use if you’re not part of financial services? But from a financial services point of view, we actually bring the regulated industry of banking and FinTech together. So, whereas before, where banks were solving problems within their own corporate firewalls and it was very difficult to collaborate outside of a bank. Finos actually understands the regulatory perspectives of how banks can come together within an open-source environment.
We provide the environment so banks can actually collaborate on the outside of their firewalls. And so, that’s why I’m here today. Is to explain to your audience what we’re doing and also how they can get involved as well. Because being an open-source foundation, we actually… We are always better when people join our activities, join projects, join our special interest groups, and really do collaborate across locations and boundaries. So, thank you for inviting me.
Nati: Sure. Let’s start with a discussion: why are we even having this topic today? What’s changed? what’s new here? DevOps are definitely not new. Right? And I think financial organization has been for a while now. So, what is really new here in terms of the trend? Why should people even look into that as an opportunity? For that, I wanted to say three words and then James will open that for discussion. I think we’ve… just the first time where I could engage with DevOps was almost in… I would say 2013, 14. And yeah, that was the beginning. At that time, it was new. It was there versus, [inaudible 05:09] and it was breaking the culture and it was a lot of questions on culture versus technology versus product.
And it was very dominated by startups. It was very dominated by born in cloud type companies. When you move to the cloud, you have to adopt pronation, especially if you’re running a self-startup type of business. So, that was the way when I thought… We thought that the industry was mature. Everyone knows what DevOps is. There are best practices there. And I would say in the past couple of years, there wasn’t too much new stuff around here. All of a sudden, we’re starting to see new interest around that coming from organizations like yourself Amol. And the question is, why? And what is the common ground beyond this class of organization? Like Morgan Stanley that you mentioned, that is different from the first early adopters of DevOps.
Amol: That’s a great question. As you said, there’ve been a lot of tools and best practices around DevOps, which the various regulated FinTech institutions really embraced, right. But many of these organizations are Finos members. We have a unique set of challenges when it comes to DevOps adoption. And they relate to some of our regulatory requirements, some of the internal information security or technology risk policies and really to address this. We set up this DevOps mutualization special interest group so that we can actually identify and then document a common understanding of these challenges and then find ways to collaborate together on overcoming them.
So, this really provides a platform for Finos members… This SIG provides a platform for these Finos members to share their approach on how they’ve been accelerating DevOps adoption while providing the continuous compliance and assurance that’s required from a regulatory and an internal policy perspective. And we’ve had…
Nati: Yeah, go ahead, Amol, sorry.
Amol: And we’ve had some great collaboration in the past few months both from members… banks, such as Morgan Stanley, Citi, JP Morgan, Deutsche Bank, Capital One, Dow Unibanco, and really also from the vendors, who are really building the ecosystem around DevOps. Members like CloudBees, GitHub, even Cloudify. And I think that mutual collaboration is really what is needed to overcome these unique challenges around DevOps that many of our regulated member banks have to overcome.
Nati: So, tell me Amol, and maybe James you could, since you’re covering a lot of those discussions yourself, what has changed? what brought the banks to actually be open rounded it? I remember the days where…we’re in the grid computing days, a good couple of years ago. When a lot of the banks were very secretive about their operation, about their IT. It was considered very internal; they’re very protective about what’s in their data center. And all of a sudden, we’re talking about open-source community, collaboration, everyone is open about it. What is happening here?
James: So maybe…Nati, if I take that?
Nati: Yeah, for sure.
James: Say the thing…. say before joining Finos, I was actually a part of a retail bank in the UK. And the big thing that we had was acceleration. How can we actually get things moving faster? And really joined together the bank, and the banking products and the customer, and say engineering that sits between the products that the bank actually wants to produce and the people who consume it. And so, from an engineering point of view, the whole digital transformation that I’m sure people have heard about is, how can we actually streamline engineering activities that get the ideas that product owners and business stakeholders have out of the bank and actually into the hands of the people who need those products or need those tools.
So, the first wave was, how can we actually cut down the number of dependencies that we have between the idea and production. And so, looking at agile, and looking at DevOps, and looking at automation rather than manual processes, or that first round of digital transformation. Say in terms of DevOps, are there tools out there that we can actually leverage? Which incidentally is good for you, they are actually from open sources, such as Jenkins, et cetera, to actually build those automation pipelines. Can we leverage these to build those pipelines rather than asking people to do it through raising tickets or asking central teams? And then, extending off of that, can we automate the testing of our codes. Can we have compliance scripts, that make sure that we’re hitting all of our internal policies? And rather than people manually ticking boxes and manually checking code, seeing if we could accelerate that through automated mechanisms.
Now, what we actually found was, engineers within banks are super smart and they’ve been able to solve all of those problems amongst their own teams. But if you think across the industry, all of the various different banking and FinTech engineering teams, they’re also solving those problems to accelerate the banks. What that actually leads to, is almost like the next wave of efficiency. So, the next wave of speeding things up, which is to bring all of that knowledge together and compare and contrast everybody’s approaches and see if you can mutualize it. Seeing if you can draw out the best of what everybody’s doing and really learn. And so, DevOps neutralization from an open-source, and Finos point of view, is bringing people’s experiences to the center.
So, bringing them into an open environment so we can share, and compare, and contrast. Then ultimately are the mechanisms, are there… is there any code? Is there any Terraform script? Is there anything that people have done that we can then share in order to really try through that efficiency? This then leads to an increase in velocity from a banking product to a consumer point of view and also a reduction in cost. And I think that’s been one of the central drivers. How can we actually take this digital transformation of individual banks to the next level, which has to come from learning from the industry? So that’s…
Nati: And maybe James and Amol, maybe a question to both of you. I mean, we talk about DevOps and automation and regulation at the same time. But aren’t those two conflicting things? How can you automate the automation in many ways, bypass regulation and bypass those processes? And trying to be agile means that you don’t want to have those checkboxes in the way that I think James, you had talked about. How general do you even think about that? Amol, do you want to take that?
Amol: Yeah, absolutely. So, I think, I mean, one could get confused that these processes, if you will, that they work and these regulatory pressures are in conflict. And many banks have had internal policies that were influenced by either internal or external risk groups. And that had inhibited the adoption of some of the DevOps practices, right. And some examples, if I can provide them, include things like, traditional FTSE or change management policies that may not allow for automated change deployment or many use cases. Many banks have traditionally segregated of duty policies that run counter to some of the DevOps and SRE practices in the industry. And this disconnector is being problematic for app devs. But many of our app devs now come from a set of an unregulated backgrounds.
And we are equally under competitive pressure to deliver value quickly, as James alluded to previously. And I think most banks have had to not really overcome these challenges. And at Morgan Stanley, for example, we have managed to get buy-in from our information security team so that we can actually jointly design policies and standards so that we can better balance the risk and control needs, but also the efficiency needs that our app developers need. And in many ways, by getting to the heart of the issues that the original policies were created to address. They actually not only help with the adoption of the DevOps processes and tools, but they actually improve how this gets addressed in our tools and our approaches. So, I think it may initially seem like DevOps and regulated industries there’s inherent tension. But I think I’m seeing a lot more regulated organizations taking a similar approach and then redesigning some of the controls and policies that they have so that they’re in better alignment with agile and DevOps principles.
And many of them are, again, finding that you can actually end up with a stronger set of controls, and controls which can be then enforced through the tooling. And really through this DevOps mutualization SIG, one of our goals is to develop such a shared understanding. In terms of how many of our peer banks and regulated FinTech organizations are overcoming exactly the same challenge. So, that there’s no tension, if you will, between DevOps and how DevOps gets adopted across regulated entities like ours. And really, we are hoping that this can be the shared understanding that we will document in the SIG. Can be a starting point for discussions with regulators, but also equally for discussions with some of the tooling vendors so that it can influence the type of features that the tooling vendors would then need to provide so that we can achieve the same adoption of DevOps in a regulated context.
Nati: Yeah. I want to double click on that because I think that’s really the heart of the issue. And I’m not sure that people know when they hear regulation, it’s some… especially if a developer turns off and says, this is someone else’s problem. And I’ll try to drill down into that, given the fact that I’ve been in discussion with you and others on that. Every developer is actually going through a regulated process that is automated. And if we look at the way we’re doing development, when we do a pull request, when we do commit, when we have the review of that commit the call, before we actually do the merge, and then we run the test. The actual development processes itself, which has been… I would say, developed over the past decade and even more, is automated on one hand, but also regulated.
It’s not automated in the sense that someone can click a button and then it gets into production just by doing a commit. It’s regulated in the sense that it actually goes through quite a process. But the difference is that the process of regulation is automated. It’s less friction. There is less friction and less a need for a specific human intervention in the process. So, in many ways, I think when we’re discussing the new type of regulation, that in applying regulation into an automated process, I think we’re talking about something very similar. Instead of having humans doing the checkboxes and checking things. We talk about more agile processes in which things get into commitment, and then they trigger something that then gets into another review, and then that gets into production. That process of defining that process could be a regulation.
And another thing that I think you touched on that could be a regulation, is how do you mandate a certain way to deploy a service in the cloud or in a certain environment? And how do we govern that template, for example, Terraform template? Whether it’s going to be best practices and whether it’s going to be something that I think you discussed also, is talking to the actual cloud providers and making sure that they come in with a lot of those practices out of the box. So that would be the way to influence that. So, when we talk about regulation, is this really what we’re talking about, or doing DevOps within a highly regulated business? That’s what we’re talking about or there are things that are missed here?
James: Say maybe I can… sorry Amol. If it’s okay, do you mind if I give my perspective on it?
Amol: Yeah, absolutely.
James: So, when I think about it, whenever I look upon DevOps, I know some people look at it as the technical mechanism for taking code from a developer is a laptop or PC or Mac, and then delivering it through to production. But actually, what I actually look upon is that rule 360-degree approach to agile development and delivery. Where you bring, various different people to the table, who were part of the delivery of your product. And say, DevOps, to me, it’s not just about the automation that’s involved, but it’s also about bringing the stakeholders into the conversation. And having acceptance criteria on all of the various different development stories that you’re delivering for your product toner. And making sure that acceptance criteria include mechanisms to adhere to certain things that that particular story needs to deliver as part of the delivery cycle.
And say, if you look at DevOps, which is also like the security mechanisms, you would have an acceptance criterion about all of your unit tests pass. Or maybe, SonarQube…. all of the SonarQube tests that you run on a particular set of code would pass. When you look at the regulator, it would be… are you actually developing this story according to your banking policy? And do you have BDD tests that have been applied to the code that you have written that describe the actual policy that you’re writing something against? So, in the future, when another developer or an engineer, or just some codes. That BDD tests should also pass through your DevOps toolchain. And so that’s what I’m thinking when I talk about regulation. It’s about…so you can talk about the bank’s regulation in how you apply dev ops to the building of your product.
But then, you can also talk about how your team operates against policies that are applied against your specific delivery and how you describe those policies using BDD in the same way as you would describe the security delivery of that code using other tools and mechanisms. And making sure that you’ve got representation in your team that you can demonstrate the acceptance criteria against. So that’s the way that I see it. And that’s certainly the way that a sibling project called Cloud Service Certification is applying BDD. To make sure that certain policies about how cloud services are being developed, using Terraform being tested against policies that are being created by the CDMC, for instance.
Nati: Let’s talk a bit more about this. Again, I want to put a little bit more color into what Finos is doing and how it is doing. So, taking an example and diving a little bit into it. I think we’ll give some color to it. So, maybe Amol, you can describe it a little bit more in detail about what James was talking about. The DevOps mutualization project and the BDD tests that James described. What does that specifically cover and how other organizations may benefit from that?
Amol: Sure. So, I think the DevOps mutualization special interest group is really helping many of the regulated banks by developing really a common understanding of DevOps practices, tooling, and projects. And really documenting these so that we can really map them to the compliance and assurance needs that exist. Right. And in many cases, this is a matter of really just mapping the best practices, which have been well understood in the industry. Things like the use of pull requests. Having the gating criteria for pull requests. Having peer review. Having better-automated testing. And really mapping this to internal information security and some of the even external regulatory control requirements. I think that’s really one of the main themes for the special interest group this year, is to document this approach across the various banks, because many banks are doing something very similar.
And then also, to identify opportunities for open-source projects and contributions across banks again, for things which are not quite seen as a competitive advantage, but effectively causing problems which other banks are also likely to have. Then getting the scale benefits of having an open-source project and having different contributions drive that. And then finally, really using that to influence the vendor ecosystem around DevOps and cloud, so that we can make sure that certain things that are needed as an example, the BDD testing, maybe when taking that to policy as code. So, that we can actually have some of these control elements and get described as code. And then having the vendor tools is actually enforcing those types of policies as code Gates. I think that…. that’s really what we are trying to achieve for the banks…. the member banks infinite, through DevOps utilization SIG. Equally, this is helpful for the vendors.
So, now the vendors can get a better understanding of what the requirements of large regulated FinTech organizations are. And this really is the common understanding that would be developed with the SIG, which can help vendors really improve their toolset and then use that even for other similar organizations with more stricter control requirements around their DevOps processes.
Nati: So, I think it’s a… if I summarize it, I think we’re talking about two audiences. You touched on it. One of them is the banks themselves, which need to go to that exercise of understanding how to apply regulation and having it done in collaboration with each other, I think will accelerate that learning curve or that learning process. And James, I think that it brings a question: why do we need an organization like Finos, and what does it add to this type of collaboration? Why can’t we just make the meetups or conferences and talk about that? I think you also talked about the ecosystem and influencing the cloud providers and influencing startups and vendors that want to deliver products and, not necessarily coming to withhold those processes and regulations in place. Can you describe again, why do we need an organization like Finos to do that? And why should people consider it or take part in that and when should they consider taking part in that?
James: Yeah, absolutely. Say the first thing I don’t think an organization like Finos could exist if it wasn’t for meetup groups coming together and sharing. Meetups actually, and also podcasts… Anything where people actually share materials. It normalizes the fact that industry leads and engineers, and people in the know are coming together to share their experiences. And that is the fuel for open source. But what Finos actually delivers that meet-ups find very difficult to deliver is organizations coming together in order to prioritize the issues or even understand the issues that they are experiencing. Because if you are a big enterprise bank, it’s very easy to be focused on your own internal issues and be solving those time and time again.
But if you don’t put your head above the parapet and look outside of yourself, you might think that you’re the only people who are doing that. But what you’ll actually notice, if you step out and join an open-source foundation or join a special interest group. Is that the issues that you are solving or the issues that you have solved are also things that other banks are experiencing as well. Now within DevOps mutualization, what Amol and the team are doing is really listening to the way the banks have been solving the software delivery life cycles. So, what tools are actually being used? What mechanisms are in place, in order to form a consensus of what do we have in common? And also, by speaking about it in that type of grief. You also start to form a common language. A common way of describing things that the industry understands.
So, the way that I describe dev ops, which is very personal to me. I might also be influenced by the organization that I’ve actually worked within, by coming together as a cross-industry special interest group. You actually start speaking the same language and come to a common understanding. This means that you start describing, and you start coming together, and you start collaborating in a similar way. But because we are an open-source, a special interest group, we also have a backlog. We will also have mechanisms of communication.
We have people who can help understand the priorities of the special interest group as well. And what would be the biggest thing to hit, that would have the largest return for the industry? And because we are collaborating as the industry, we will also get different banks, and different vendors, and different consultancies inputting into this solution as well. And so, you get like a real diverse mix of understanding and education and acceleration. And yeah, that’s why open-source foundations are needed versus having conferences and meetups, because conferences and meetups are projecting individual experiences. Whereas open-source projects and open-source foundations are bringing everybody’s experiences together. In order to really diversify and innovate and bring different solutions together as well.
Nati: Yeah, maybe I’ll add my own personal testimonial, I would say, why I find myself joining those conversations. What I’m getting at is representing things like the ecosystem or at least the startup part of the ecosystem. So, yeah, I think it takes a long time to really understand those concerns and regulations that an organization like Morgan Stanley is facing and need to deal with when you come to deliver a solution. And sometimes you have one shot at an opportunity to actually present it. And if you’re coming and understand the problem, the way they are described by the source, I would say. By people like them Amol and other people that are from banks, and you understand both the lingo, how they describe it, but also where are the areas and how you prioritize things. That in itself gives you… for me as a vendor, as an ecosystem player, they wait to paradise things themselves. And understand when we talk about regulation, when we talk about security, when we talk about how to name certain things, what is it actually meaning?
How do other people approach it? What are the gaps and what are the… where’s the opportunity? Is that too early? Is that mature enough? Is that a thing? So, you get a lot of that sense, and I would say that it’s not Linux… I mean, people here hear Linux foundation, they immediately think about Kubernetes and they think about, okay, do I need to put developers and code, and projects and all those high investment types of engagement? I think it’s important to note that it’s different. So, maybe James, you could say a few words about the difference between Finos and also the Kubernetes project. Both are under the Linux foundation, but I think it’s important to draw the line because it’s very different.
James: Yeah, absolutely. So, ultimately, we are a part of the same Linux foundation ecosystem as Kubernetes. And so, by coming to DevOps mutualization, or by being a part of any of the Finos projects, you are a part of the same ecosystem that delivers solutions to the industry that everybody understands. And even within financial services, we’re looking at Kubernetes and the way that we can actually automate the creation of Kubernetes across cloud service providers, that it adheres to certain regulation and policy. And so, we don’t delegate that back to the Kubernetes team. We take that forward and we look at it from…. through a financial services lens.
Now, I would say, one of the huge benefits of Finos is the…. a lot of the projects, not all of the projects, but a lot of the projects, have actually been contributed by our bank and members. So, if you rewind maybe five years, people wouldn’t have thought that innovation came from financial services. And at one-point financial services would have consumed consultants, or it would have delegated all of its back-office functions to other teams to do on their behalf. But within a very short amount of time, a lot of those external functions have come back into the banks and had lots of bright engineers, and bright people, have joined the financial services industry in order to accelerate the way that technology is actually being innovated within banks themselves.
So, it’s not just the FinTech’s who are doing these things. It’s Morgan Stanley, it’s innovating alongside Citi, and Deutsche Bank, and JP Morgan, and Royal Bank of Canada, and all of these banks have really smart engineers within them. Now, open-source is a great way to show the big projects that are coming through, but it’s also a really good way of highlighting just how smart the engineers are within banks. This is actually something that regulation and the industry just through its very nature can often have hidden. It’s a lot easier for you to be a Facebook engineer and speak at a conference than it is for you to be a banking engineer and speak in the same way as a conference. Because there are rules about what people can actually represent. Because you’re representing financial institutions that have huge liability to people’s money.
So, within Finos and within our members, not only are we bringing in mutualizing and contributing projects and also educating engineers on how to contribute and doSage can seem open source. But we’re really casting a spotlight on the community of open-source engineers from within financial services. To tip our hats and give them kudos for everything that they’re doing, because there’s a huge wave of innovation that’s coming out to financial services. And I think the people who are contributing out of the banks, they deserve to be recognized. And foundations like Finos are recognizing the projects. They’re recognizing the institutions and the organizations, but they’re also recognizing the engineers who are doing the contributions as well.
Nati: Speaking of that, maybe Amol… maybe you could describe a little bit your personal journey here into Finos. How did you find out about Finos and why did you choose to join Finos?
Amol: Sure. So, as I said, I’ve been leading Morgan Stanley and working really in the Morgan Stanley Development Environment Group now for almost a decade. We, as James said, have used many… I mean open-source tools not just software dependencies, but really across the DevOps tools chain out a big part of what we use. And more recently through initiatives like Finos, we’ve been able to actually contribute back some of our changes to the open-source ecosystem as well.
So, having worked in this space really for a decade we are seeing obviously, a big move towards using an industry-standard set of toolchains. Adopting a lot more open-source tool. And I think really, many of these…the way we’ve actually solved some of these problems. They’re not necessarily seen as a competitive advantage, and there’s an increased acceptance of… we have this… it’s likely that many of our peer banks have the same challenges and really as a fourth step to work on them, just getting a shared understanding is something that we were very interested in.
Late last year to the other participants that we have in Finos was, we were able to join some of the initial discussions around DevOps. We identified that there are a lot of common interests across the peer bank, as well as vendors in trying to gain such an understanding. And as a result of this, there was this proposal of setting up a special interest group to actually look at this problem because again, many of our peer banks have the same problem and many of the vendors want to understand exactly what is it that they can do in terms of the tools that they provide to better address these problems.
And really that resulted in the gestation of this special interest group and is…. I’ve been really excited to lead it for the past few months, because I think really, gaining the shared understanding of how we can accelerate DevOps adoption. Whilst still keeping in the controls that are needed from an information security and regulatory perspective. I think it’s a pretty interesting area and really also an area where we hopefully are going to see a lot more collaboration and contribution from many of our peer banks, as well as the vendors.
Nati: Speaking of collaboration, what is the barrier of entry here, James is that…. do I need again, to need to be…? to invest in… what type of membership? What type of contribution am I supposed to be doing here?
James: Yeah. So, there’s a really low barrier of entry when it comes to Finos. So, there’s no expectation from anybody who joins any of our projects. Whether that’s turning up to a project meeting and taking part in a conversation. Or cloning a project repo and using it locally, or installing from an external registry, or even raising a pool request. There are a couple of tasks that need to be done in order to raise the pool requests, because a part of the agreement of Finos, is that we make sure that it contributes to licensing agreements so it is adhered to.
But you don’t need to be a member in order to sign a CLA. And you don’t need to be a member in order to raise a pool request or raise an issue or even raise a feature request against a project. And that is also the same for the special interest groups as well. So, the coming together of industry minds, in order to input into what people are finding, or listen to what people are doing. You don’t need to be a member of the foundation in order to take part in that either. Because it’s open-source. Our projects are patchy T licensed, and all of our working group sessions and especially interest group sessions are all advertised on the Finos project calendar. Which is open to the industry…It is open to outside of the industry.
So, even if you’re not a part of financial services, but you would like to find out more about what’s happening inside financial services because you were thinking of joining a bank or engineering for a bank. Then Finos is a great place to get to know the community, and it’s also a really great place for people to network. And this is one of the side effects of open source. It’s a great way to find people for employment, et cetera. And so, the barrier of entry is zero. It’s a zero barrier of entry. You may need to speak to…. if you are coming from a bank, it’s probably wise to speak to your line manager or a stakeholder within the bank. Just to let them know, because you might find that your bank has a policy about sharing information that you need to personally adhere to. But that’s no stipulation of Finos.
The only thing that we will ask is, if you do join a project call or if you join a SIG meeting that you make yourself known so we can actually document it in the minutes. Because there is an antitrust policy that we adhere to, to make sure that we don’t divert off of our set agendas. And that is how we help mitigate any competition law and stuff like that. We work with our special interest group leads like Amol, to make sure the agendas are set. Anything that’s on the agenda is the only thing that we actually speak about, and we help steer people back on track if we digress. But other than that, people are free to join. The more people who join and spread the good word about the work that we’re doing the better. And I hope you found that as well.
Nati: Yeah. I can testify myself that it is. I’ve been involved in other communities like OpenStack and obviously other Linux Foundation projects. I can recommend James if you have questions on how this community works. James will be very patient with you and he will walk you through the steps into the community. And I really appreciate it. And it was very helpful for me to actually find a way in. Because joining the community is like… almost doing relocation. It’s not to that extreme, but once you do it well, you have to understand the people. You understand the dynamics. You have to understand… and it takes a lot of time when you’re entering a community to learn a lot of those things.
So, I think that the approach that you took onboarding newcomers was shortening a lot of that cycle. So, I appreciate that. Then I would recommend people to use the same. Not abuse your time too much, but at least know that this option exists. Hey Amol maybe you could say a few words about the good proxy project as a reference example. I mean, when we talk about the special interest groups and why you joined them, and that you’ve been covering that for a couple of months. Right now, for all the ones that want to maybe be part of that, maybe give them a little bit more description into the good proxy project. And how that becomes a reference to what SIG is doing.
Amol: I think I would probably defer to James for that question.
Nati: Okay, James, go ahead.
James: Yeah, I’m more than happy. So yeah, GitProxy is a really interesting project. So, the DevOps mutualization special interest group is the coming together of stakeholders and the people who represent DevOps within the financial services industry. And within the special interest group, we prioritize the topics that are relevant across the industry that we would like to solve. And one of the issues that the Citi team decided that they would like to solve is, how do we actually allow internal engineers from within banks to contribute to open source in a way that mirrors the experience of UNI who are outside of the bank contributing to GitHub or Gitlab or a Bitbucket project. But knowing that there are certain regulations and security policies that need to be checked. And certain peer reviews that need to be done, before that get committed can actually make it outside of the corporate firewall and into that upstream, open-source repo.
James: Now, the way a lot of banks have actually solved this problem previously, is by taking almost like a merit fork of a repo and bringing that into the internal infrastructure of the bank. So, for instance, if you have a project on GitHub and you have internal engineers who want to use it, then also extend it. Rather than cloning that project into another GitHub repository, which is external to your bank. You would clone that repo and bring it inside. Do all of the work that you need to do over many development cycles. Whether that’s a month, three months, six months, and you would actually be extending that project inside the bank, out of sight of the actual external repo. And so, what that means in that scenario is that the contributions that you are making internally sometimes never actually arrive or get committed back into the open-source project.
So, what Gitproxy actually does, it enables…. rather than having all of those internal compliance mechanisms running on an internal DevOps pipeline. It actually hooks your external commit and then runs all of those compliance checks within a proxy between the engineer and the external project. This means that the backlog for the project can still reside on GitHub in the open-source. And what that actually means…. So, if we go back to what we were talking about in terms of agile, you can still prioritize your backlog in the open-source community. You can raise your issues in the open-source community. You can have external people and engineers and organizations make feature requests in the open-source repo. And so, you get that community growth happening outside of your bank rather than inside your bank.
And you also say reduce the development cycle time from committing codes into…. you basically commit codes back into the external project. Rather than forking it locally within your bank, and then doing one big version release in six months’ time.
And so, Gitproxy is a project that has been contributed by CITI into Finos. It is in GitHub under the Finos organization. And so, if you go to GitHub dot com forward slash Finos or forward slash Gitproxy, you will find it there. And because it’s at DevOps…. almost like an extension, it creates a bridge between your internal software development life cycle and your external open-source contribution. It falls into that DevOps mutualization space because it’s shortening the cycle times between internal development and external open-source contribution. I hope that explains it to you Nati, and the team. They don’t have project meetings in the same way as dev ops mutualization does. It’s a project that exists and everything is synchronous through GitHub issues. And so, you would clean that project user and then communicate with the team through their GitHub issues. Rather than arrive on a WebEx or Zoom call with them.
Nati: Yeah, that’s actually an excellent example. Because I’ve been going with some of our customers and they’ve been trying to commit back to our product and it is also open source. And the process was very much like you would describe. They clone the entire code, then they have… they’re doing the stuff, and then they have a bunch of Laura’s going through that. And it takes weeks after weeks, up to two weeks. This means that in many cases, even if they can do those announcements themselves, and contribute the product. The fact that it takes so much time, they actually don’t even do it. And they avoid doing it. Which is nothing that… I think no one is winning out of that and everyone is unhappy.
James: Technology moves on too quickly and so too the whole thing about DevOps, and this is what it all comes down to. From that very first question about DevOps is the reduction of cycle time. And Gitproxy brings all of those development cycles for open-source projects, really close the developers in the same way as dev ops brings the product that the bank wants to develop closer to the customer. Because it’s all about shortening those feedback leaps… [inaudible 52:58].
Nati: Exactly. I think the Gitproxy is a very good example of the entire discussion that we’re having here on, what is regulation? How can DevOps actually help to get a lot of those regulations and processes automated shortened? As you’ve described. And I think everyone, especially in those banks probably hit that type of experience, where he was working with his peers on an open-source project, he needed to prioritize something, or we wanted to contribute something and immediately it was… okay, this is too much of a hassle I’ll forget about it. And then your friend is actually pushing his things, much faster than you are. And you again, left with a project that you are using. But then, you have to put an overlay of people and time and other things to take that and transform it into a way that will fit into the bank standards and regulation, just because you’re not able to close that loop. And make sure that it’s actually coming in the right way from the source as a result.
And I think this is the type of thing that is new here, that I think Finos brings to the table that may change a lot of those cycles. And I’m particularly very excited about just seeing it. Both because of being an open-source advocate for a long time. But I never thought that I’ll see the day that banks are actually talking about open source in an open way that I’m seeing here. And it gives me a lot of hope that we are going to see this new wave of DevOps right now that I think is coming. And I would say that maybe, one sentence around that paradigm reinvent from Amazon CEO last year. And people don’t really realize it because you usually look at the banks as the dynos zeros that are now getting in trying to be the new shiny tool.
But he was saying something very strongly. He said that if you really look at the market and as a whole, only 4% of the market is not running on the cloud, only 4%. It’s amazing. So, just to think about it, and when I’m talking about this next wave of dev ops, the next wave is this 95%. So, what we’ve seen is only 5%, but there is 95% of the untapped market that is now getting into this… trying to get into this. So, if you’re a vendor, this is a huge opportunity. If you’re a bank it actually gets you from the point in which you’re on the fence and looking aside for a lot of those things and being an active participant in a lot of those things that are happening right now. And I think it’s a very exciting time, a very exciting opportunity for a lot of reasons. And it’s a huge untapped market.
That’s how I see it as an entrepreneur. And I wanted to thank you, James. First of all, for first, sharing a lot of this information, accepting this podcast, which is in itself, by the way, speak for itself. The fact that you’re open to going to something like that, then go to the processes to do that. I can tell you I’ve been working with banks. It’s not that trivial as you may think. So, with that, I wanted to maybe do a last round of wrap up. Amol, are there things that you wanted to say here, and we didn’t have the chance to cover?
Amol: I think… and thanks again for the invitation, this was really a great discussion. I just… for the audience that’s interested in the DevOps neutralization phase. Most of the work that we do… the meeting agenda and minutes and so on, they’re all on GitHub. If you go to the DevOps dash mutualization repository under Finos organization and GitHub, you’ll see all of this information there. Including some of the key teams that the special interest group is working on. And again, you are interested in collaborating and driving some of these discussions, we absolutely look forward to your input. James describes the process early on and really, I think we can together help develop a better understanding of how we can accelerate DevOps in regulated settings like banks. And we can help provide that shared set of requirements with the ecosystem vendors around DevOps and around the cloud. So again, we would absolutely welcome everyone’s contributions, and thanks again for having me on for the podcast, Nati.
Nati: Thanks so much, Amol and James, anything that you wanted to add?
James: Yeah. So, everybody’s welcome to come and join DevOps mutualization. The community is extremely friendly and there’s no expectation that people need to contribute any thoughts at all. Especially if you’re just joining and you don’t know the people in the group. We are very friendly, come along, we’ll introduce ourselves. You will see how the existing members and the people who take part talk to each other. In the next meeting that we have scheduled this month, it’s our Unibanco. We’re going to talk about this software delivery life cycle, as we go round various different banks who have put their hands up to say that they’re willing to share. So, you may even learn how other banks are operating in that space.
The other thing that I’ll say is, if you come in and observe how Finos… how the Finos community is engaging with each other. You’ll notice… and around Gitproxy in particular. And this also happens in cloud service certification. You’ll have engineers from banks like Deutsche Bank, who are contributing software to the foundation like waltz. So, that’s the system that Deutsche bank contributed to the foundation. And then they take requirements and contributions from that West market. So, you might join Gitproxy and you will have CITI who have contributed the code. But then you have GitHub who is also helping with all of the git standards and how to advance the project. And then you’ve got Unibanco, who are taking their food inside their corporation in order to help them step into open source.
And so, we take it for granted as people who live in this type of world, that this stuff happens every day. But if you take a step back and you come in from a different angle of people who aren’t involved and then you come and see the work that we’re doing, you’ll be staggered at the amount of innovation and collaboration across the industry this is happening. So, please do come and join us, come and say hi. Like Nati said, I’m more than happy to help anybody and meet with anybody who wants to join. And I’d also like to say, thank you to all of our project leads and our SIG leads for all of the work that they’re doing. Because the foundation brings all of these communities together, but it’s actually the community that powers itself. And it would be great to have more people join from different locations and different organizations. So, thank you also Nati for inviting me to your podcasts.
Nati: Thanks to you James and Amol. It’s been a great discussion, and I’m really excited about this opportunity. I think we’re actually farming something new here. And I’m sure that’s going to be a multi discussed here and hopefully more podcasts coming along sometime later. And I really encourage people to look into Finos and I wanted again to thank Amol and James. I know it’s not that easy to open up and do those types of things. And I know it’s been a… there’s been a lot of effort to actually get a lot of the approval all around it. So, I really appreciate it. Thank you very much.
Jonny: Thanks so much, Nati. And thanks to our special guests Amol and James. Really interesting deep dive there. Okay. As per usual, all supporting materials for this podcast, that’s going to be available on www.cloudify.co/podcast. If there’s anything in particular, you feel that we should be discussing, please reach out to us at hello at cloudify.co. But in the meantime, stay happy, healthy, safe, and we will catch you next time.
Announcer: This episode has been brought to you by Cloudify, the one platform you need to accelerate, migrate, and manage your multi-cloud environment for faster deployments, optimized costs, and total compliance, head to cloudify.co to learn more.