 Hello. I'm Michael Lieberman, one of the co-chairs of the Cloud Native Computing Foundation's Financial Services User Group, along with Scott Servich. Together, we helped steward the FSUG in providing value to its members and the Cloud Native community at large. This talk is a short introduction into the Financial Services User Group. I hope to, by the end of this short presentation, to answer the following questions. What are some of the challenges financial services has in adopting Cloud Native? Why do we need a financial services user group? How does the financial services user group differ from other tech-focused special interest groups? And finally, what does the financial services user group want to accomplish? This talk will not be going over any specific tools or technologies, except as examples. The majority of this talk will be about the challenges financial services groups have in adopting Cloud Native, followed by what we're doing in the financial services user group to help adoption, in spite of these challenges, or to help FinServe groups in overcoming the challenges altogether. I'm sorry we don't have any cool tech to show off, but we're hoping we'll have some awesome deep tactical stuff to show off next conference. Here are a list of challenges financial services organizations have in the adoption of Cloud Native, which leads to why we need a financial services user group in the first place. FinServe organizations in general have some huge challenges as part of their technology transformations. This is especially true with the very fast rate that Cloud Native is transforming the technology landscape. FinServe can't just adopt new technologies, architectures, and ways of operating in just any arbitrary way we want, due to our obligations to regulators. We not only need to understand the tech, we also need to understand the implications our adoption of the tech has. We also need to understand our obligations to those we have contracts with, as well as the countries and regions we operate in. FinServe organizations also worry about risk to the reputation we have with vendors and other partners, because FinServe has many of these customers, sorry, many of these companies as customers. There are also additional other third-party risks, which I won't get into detail here. Given that many of our organizations are large enterprises with thousands, if not tens of thousands, if not hundreds of thousands of employees, it can get complicated navigating the myriad obligations we have. One part of a company's adoption of a particular tool or technology could have wide-ranging impacts to other groups in the organization or to the organization as a whole. Regulators often want to see unified organization-wide approaches to adoption, which can complicate a given team or departments of adoption of these cutting-edge tools, technologies, and patterns. Many financial institutions have existed for decades, if not hundreds of years. Decisions made years ago still impact us today. This leads to challenges around how the organization defined its business in the past and whether that is compatible with how we adopt Cloud Native. This isn't to say we won't adopt Cloud Native if it isn't compatible with a decision we made in the past. This just highlights how we need to be cognizant of these challenges and also in how we might need to not just transform technology in terms of software and servers, but our organizations themselves in order to adopt these new patterns of operating technology. Along with our complex enterprise environments, financial services companies often have enormous amounts of legacy technology. It is not something that will go away overnight and inevitably our Cloud Native footprint will have to live alongside our legacy footprint for a very long time. We are not saying there should be an expectation that will deploy monoliths as containers and call it a day. It means that our Cloud Native applications and microservices will need to operate and integrate with our monoliths. Our new and transformed software will need to live alongside these legacy IT systems that have a long history potentially going back decades. Think mainframes that though might have been patched and updated still have a legacy dating back 40 or 50 years. Financial services companies have a lot in common with each other in terms of many of the aforementioned challenges. With that said, our various organizations have approached these problems differently from each other in the past. We will most likely continue to approach these problems somewhat differently due to the history and legacy of our organizations. This means there is no panacea that will work for us all, even if there are areas we can collaborate. With that said, the more we do collaborate, the easier it will be for us to solve these problems more generally in the future. In addition to all the challenges already mentioned, one of the biggest is organizational. As part of our technology transformation, we also need to help bring stakeholders along for the ride and help them understand how Cloud Native is not just a pet project of some manager, but a different way of operating that lowers technology costs and increases velocity of delivery, not just of features and products to customers, but in compliance of new laws and regulations. I will now talk to some of the examples of the challenges from the previous slide that highlight why we need a financial services user group. I can't talk about some specifics due to the both sensitive nature of some of the topics as well as individual organizations approaching the challenges their own way. Data segregation and security is a huge challenge for financial services organizations. Whether it's GDPR or other laws or regulations, customer data security is paramount. When approaching the use of Kubernetes and other Cloud Native technologies, we often approach it thinking about data security first. Our approach to data security inevitably constrains how we use Cloud Native technologies. Given the enormous footprints many of our institutions have, it's not good enough to just have some sensible defaults and call it a day. We need to figure out ways to take our enterprise data standards and policies and map them onto Cloud Native tools. We can't just take best practices wholesale. We need to figure out ways where we can prove those best practices aligned with our compliance requirements. It doesn't matter if we have fancy automation that provides policy as code and layer seven IM controls around access, if we haven't transformed our own internal rules around one to one firewall policies and other layer three requirements. A similar challenge is around separation or segregation of duties and concerns. This challenge has multiple parts. Due to the wording and interpretation of regulations, it leads to confusion about what counts as segregation of duties. A simple example of this is the person who writes software can't be the same person who deploys the software. Depending on who you talk to, that might need to be literally different people on different teams or just different roles. Contemporary approaches view the above challenge as the person who is writing the software can't sign off themselves on a deployment. In addition, another team would be responsible for defining the standards and policies by how things are allowed to be deployed in the first place. What I just mentioned though is up for interpretation by both our internal risk and audit teams as well as our regulators. However, if every deployment no matter how minor requires the engagement of a dedicated release team, you can imagine that diminishes key benefits of cloud native like speed and ease of deployment. The internal bureaucracies of financial services organizations complicate not just the implementation of cloud native deployments, but the adoption of cloud native practices. These bureaucracies historically have involved a lot of manual paperwork for everything from from procurement of a physical server to the application of a patch. These bureaucracies need to be transformed. Cloud native adoption loses a lot of its benefits if you end up having to fill out a ticket each time you need to scale up a Kubernetes pod. As cloud native pushes for the adoption of newer architectures and patterns like microservices, it also forces financial services to rethink the interface between business and technology. When it comes to compliance and audit, the scope by which we define what a service and application is is usually too broad when adopting cloud native. Often our systems are defined not as microservices, but as monoliths. As mentioned earlier, some of our systems are still in mainframes. In the past, FinServe has defined services quite broadly. And our processes have adopted those definitions. An application can be defined by its IP address, its database and other infrastructure components. Whereas with a microservice, you would expect it to be defined more in terms of functionality. In adopting patterns like microservices, we also need to transform the processes and tools by which we define what our systems and applications are in the first place. Most of the aforementioned challenges are the impacts of legacy decisions. At the time of decision to design a process application system, et cetera, in a certain way might have made sense. However, now those decisions impact not only how we approach cloud native, but also in how we make new decisions in general. It can be difficult to build the new world while still being constrained by the rules of the old. Those of us in the financial services user group are not the only ones who run into challenges in adopting the new technologies and modes of operating. There are vendors we have years of history with that struggle. There are partners we integrate technologies with that are also behind. In addition, some of our fellow financial services organizations, not just the ones who are part of the FinServe group are behind or haven't even started their cloud native journey at all. This impacts those of us who are already in the middle of our journey as we have obligations in how we integrate technologies with other companies. We also need to show to vendors and others that cloud native is being adopted so that we can provide incentive for others who haven't begun their adoption yet. None of the challenges, as I mentioned, are considered in a vacuum. We recognize that Kubernetes and other cloud native tools provide some primitives for securing systems and data. However, the issue isn't in building secure apps. The issue is in providing mechanisms for policy and governance by which FinServe can apply their business opinions and requirements onto cloud native technologies while not warping the purpose of cloud native or ruining the benefits. To be perfectly clear, the issues are rarely in the technical challenges in adopting cloud native, but in transforming our organizations and the financial services industry as a whole to be quicker in adoption of new technologies and patterns. FinServe organizations have to balance between transforming the business to better adopt the new patterns and all of its benefits while still maintaining compliance to our various regulatory legal and legacy requirements. That leads us to the goal of the financial services user group. Even though we have a ton of challenges and specific problems that exacerbate even our collaboration, we still are driving towards reaching our goal of solving the shared challenges financial services has in the adoption, implementation and use of cloud native tools and technologies. This makes our special interest group different compared to many of the other tech focused ones like the service mesh special interest group. Our SIG is here for collaborating on challenges at the intersection of both cloud native and financial services. If you have a specific service mesh question, you would probably go to the service mesh SIG. If you have a question on how you might approach the use of service mesh with regards to rewriting an application originally written for a mainframe, you would ask that at the financial services user group. So we look to achieve that primary goal from the previous slide through a few different ways. Financial services user group members are able to talk freely about the challenges we have, at least generally. This allows us to help each other navigate the CNCF landscape and learn about tools, technologies and approaches other members might not have considered. It seems like every few weeks there is a new cloud native tool or project worth investigating. Not all of those projects or tools are suitable for financial services adoption, at least yet. With that said, each of us individually can't perform all the assessments ourselves, but together we can help point each other in the right direction of projects that should be investigated more thoroughly. We also regularly invite the maintainers of these projects to our meetings to give demos and have in depth discussions regarding FinServe specific requirements and use cases. Werner Vogels from Amazon coined the term undifferentiated heavy lifting, which I think is an apt metaphor for the shared challenges many of us in FinServe have. Though many of us are bound to different compliance requirements from a regulatory body, there is still a lot of common problems that are shared. Even just coming together to collaborate on general approaches is a huge help for us. We regularly discuss the challenges we might have had in the adoption of a tool and how we might have generally solved it. You shouldn't expect us to all come in and say Istio or open policy agent is going to work for every FinServe company. However, you can get useful information on how we might have approach service mesh and policy and policy as code and the challenges and how we overcame them in adopting both the concept and the tool. We might have been able to communicate, sorry, we have been able to communicate with open source project maintainers as well as vendors who are focused on cloud native and we have been able to describe some of the common problems we have with regards to adopting cloud native. Sysdig and Falco is one example of that. They have also expressed the desire to work with our group closely to better understand our challenges and use cases in order to better provide us not just with features that help us maintain compliance, but also with features that help us prove compliance. I can't stress that enough. It is not adequate for us to just say this tool is NIST 800 190 compliant, but we need to be able to audit the tools and aggregate aggregate data coming from them. We want to work with vendors and project maintainers in order to help build that understanding out. We also are looking to hire engineers who can help us transform technology at our organizations. With that said, there's not many engineers clamoring to work on mainframes or legacy enterprise Java applications. Engineers want to work on the cutting edge and both collaborating with the open source community and communicating our cloud native journey helps us in getting the word out that our organizations are working on the latest and greatest. Even though many members haven't been able to contribute directly to the community through code, our discussion and interaction with vendors and open source project maintainers has allowed us to provide meaningful feedback on our use cases and challenges. We are working to help each other be a bit more open and hope to collaborate with other partner foundations like the FinTech open source foundation, also known as FinOS, in order to figure out ways to help transform our organizations to be a bit more open source friendly. Most of us engineers working at financial services organizations do want to contribute back to open source. But as mentioned earlier, a lot of our internal processes and policies need to be transformed first. In addition to the general challenges we have as technologists working in financial services, there are some specific practical problems we run into as financial financial services companies trying to collaborate in the CNCF community. Tools that the CNCF uses broadly like Slack, GitHub and Google docs are often blocked at some of our organizations. This makes it hard for us to not just to collaborate with fellow financial services user group members, but the CNCF and tech community at large. Due to legal risks and obligations, it makes it difficult for many of us to take official stances on the tools, technologies and architectures in cloud native. As mentioned earlier, some of our enterprises are enormous and none of us want to inadvertently misrepresent a relationship with a project to render. The previously mentioned challenges also make recording of the majority of our meetings a no-go. This makes it also harder for us to share demos and talks with both fellow financial services user group members who missed a meeting or with the broader cloud native computing foundation. Here are some examples, sorry, some example topics that we've had round table discussions, demos or talks on. Kubernetes and other cloud native tool-based multi-tendency is a huge issue for financial services as our regulatory and legal requirements mean we need to be careful in how we implement data segregation. I can't get into too many details but there are concerns around layer three versus layer seven security controls. There are concerns in how we define our applications and systems making it difficult for us to adequately define our data segregation rules in a way that works in cloud native tools. In the majority of environments we have segregation of duties and we don't allow developers to have direct privileged access to our Kubernetes clusters. Most of us need abstractions to restrict what developers can do within our environments. We are looking at some projects out there like the open application model. For those who don't know what the OAM is, it's a project that seeks to provide a platform agnostic specification for defining what a cloud native application is. This fits in with our need to define a business level abstraction that can easily translate into cloud native configuration as code. We also have discussions on how we can use and contribute to open source given all of our myriad obligations and concerns. This includes some discussion on how each member views using open source as well as general approaches a member might have in contributing back to the community. We also regularly discuss cloud native security in general and topics like supply chain supply chain security specifically. As you can imagine given our need to keep customer data and our intellectual property safe and secure, security is a common topic for us in our meetings. Supply chain security is a good example. As mentioned earlier, one of our challenge is not just in securing our software and systems, but in ensuring we can audit and prove that it's secure as well. So what are some of the best, what are some of the big next steps for us? Well, some of the big next steps for us from a deliverable perspective is we want to write a white paper. We have multiple potential topics, but most likely it will be focused on the challenges and approaches financial services take in implementing cloud native. This will help inform project maintainers and vendors on our high level requirements. This will help groups that haven't worked on financial services use cases or requirements in the past. This will also help fellow FinServe companies that aren't part of the FSUG or CNCF at all. The more we communicate our requirements, use cases and challenges, the more aligned we will be to adopting cloud native and helping shape the projects to fit our needs. We also want to work with the CNCF and other organizations in developing standards and best practices. This includes working with FinNOS and potentially government entities like NIST in maybe setting some best practices around adopting already clearly defined standards like NIST 853 and 800 190. Doing this helps our internal stakeholders aligned to industry standards over developing custom rules. For the next KubeCon or cloud native conference, we want to show off our work on the things I just mentioned. And so that's that. We hope that you've gotten some value from attending this introduction on the financial services user group. And maybe we have convinced a few of you to start joining our meetings. Obviously we're looking for other financial services companies to join our meetings. But also we're looking for vendors and project maintainers who are interested in, you know, better understanding financial services use cases. So the meetings happen the third Tuesday of every month at 2 30 GMT. Feel free to reach out if you want an invite to the group. Even though we still are looking for new tools to help us collaborate. We currently still are using Slack, a GitHub and Google Doc. So just be aware that might be a challenge depending on, you know, your organization's policies around using those tools. So yeah, anyway, I'm now going to open it up for questions from the from the group here.