 Hello and welcome. Welcome to my talk and talk will be about the power of cloud native in case of financial institution, the power of cloud native architecture cloud native environment in financial institution where we have the regulated environment. My name is Matta Uspruchniak. I work several years in financial institution, insurance and banking. This is our my agenda today. I speak our my talk to two parts. The first part is about the I will introduce you to the world of the regulated environment and we talk about the definition to be on the same page during this conversation. And the second part will be about the use case of cloud native in the financial institution. In banking, insurance is the same, almost the same stuff. All right. I think it's good to start from to reference definition of cloud native because it's the first talk on KubeCon today, after the keynote, it's first day. So to be on the same page, what is mean the cloud native? And I will explain, I will comment the definition the cloud native from financial institution perspective, from the bank perspective, from company who has people minus, savings mortgage. So it's very high responsibility we have in IT department to keep everything secure and secure and secure using the public cloud. We're talking about almost public cloud. All right. The first paragraph, the cloud native technologies empower organization to build and run scalable application in modern dynamic environments such as public, private, hybrid. It's mean that the cloud native technologies is universal for public, private, hybrid cloud. For us, for banking industry, for insurance industry, it's very interesting because thanks to it, we have independent from the type of the cloud, thanks to this technology. Another, the mid paragraph is more about, it's about microservices. Good micros for me, it's about the microservice architecture. We use the losing capital services system that are resilient, manageable and observable. It's about the microservices for me. The last paragraph is about the cloud native computing foundation. Six would drive adoption of this paradigm by fostering and sustaining a system of open source in vendor neutral. Open source is the nature of the independent. You can fold the code, of course it depends on the license, but you can fold the code, you can extend the code, you can use this code, library tools and so on. And vendor neutral project, so it's vendor neutral. So we like to be vendor neutral without the vendor locking. It was cloud native definition. Now it's cloud agnostic. What is agnostic? Agnostic IT, it's mean interoperability. So it's mean that cloud agnostic systems, service tools are independent from kind of the cloud. It's dependent on public, private, hybrid, and dependent from cloud provider, AWS, GCP Azure. So we build a run system and we can run in every cloud what we want, in every cloud what we want. Some experts say that truly the cloud agnostic approach uses every approach to create highly portable system. Other tech experts say things that the cloud agnostic includes the use of multiple cloud simultaneously. Everything is for me, everything is true. You can use simultaneously or you can migrate from one cloud to another cloud, but this is, from my perspective, this is very expensive to build cloud agnostic tools. And we lose opportunity to use interesting but specific cloud features, what we have in the public cloud. Some features from the AWS, features from GCP, which are specific and we lose because we need to be cloud agnostic. I think not always we need to be cloud agnostic. So that's why in real world I think I'm sure there will be trade-offs. To summarize, we have this cloud native is more about resilience, scalability using open source microservices. Cloud agnostic is more about flexibility and independence from single cloud provider. We try to find, during the presentation, try to find the common space, but in the cloud native and cloud agnostic. To be cloud agnostic. And this is the slide when I would like to introduce to financial world, regulatory world in European Union, of course. In European Union we have free authorities. We have ABA, ABA for banking sector, AOPA for insurance sector and ESMA for rest of the financial institution. Of course, every country in the European Union can have their own local national authorities, like in the Poland we have the Polish financial supervision authority. And all of the authorities they provide guidelines. A lot of guidelines we need to be compliant with them. We need to analyze and we need to take into account during the designing system or designing the immigration. This is the most important things we need to know these guidelines before we design the system to run to the public cloud, before we design to migrate system to the cloud. All right. What we have here, what we have in this guidelines, we have five key areas. First is data and system security. Data and system security, in these guidelines you can find that the most important things that we need to ensure shared responsibility between us and cloud provider. Where is the border? Where is the border? Especially including relation to threat detection, incident management, patch management, where is the responsibility between our, the client and the provider, cloud provider. Especially sometimes it should be on the contract. It should be right in the contract, the border between us and them. There are guidelines for identity access management and guidelines for encryption data, data encryption. We always need to encrypt all data, always, always. In transit address we need to encrypt all data by default using cloud provider keys. But if we will keep the legally protected data, for example, personal data, account details, transaction details, we need to use customer managed keys. We need to use own keys which we are owner. We need to use our keys and we need to, and in the guidelines you can find the requirements where we should keep this, where we have to keep these key. It need to be hardware protector keys, hardware protector in HSM. So for example in Azure it's quite easy to achieve because we have Azure Key Vault. We need to choose the premium and create key in HSM hardware protector key which we will be using for encryption of our data at rest. The second area is about the location of data and data processing. It's easy to achieve because we need to know where our data will be stored and where it will be processing. The data need to be stored and processing in Europe, European Union borders. I never leave this, this, this, this area, sorry, this area. And the third one is risk assessment. I think it's the most time consuming part of everything. We need to analyze, we need to make, we need to make risk assessment, risk analysis from several perspectives. From security, business, business continuity, legal, compliance, operational risk, and concentration risk. Concentration risk is the high-level risk. Just imagine that we need to avoid situation when all banks from one country, for example, for Poland, will keep our data in one region, in the one cloud provider. This is not safe situation because if the region goes down, we lose almost, we lose the banks banking services. And the risk assessment should be performed first before we design the system, before we design the migration to the public cloud. Access and audit rights, financial institution, should have rights to access and write, write audit. There's nothing interesting here. The last one, exit strategies. We need to have exit plan. It's important to not confuse business continuity management with exit strategies. Because BCM is not the same, so what is exit strategy? This exit strategy is long-term process, long-term to execute, we need to, we need to cancel the contract and so on. It's not for, for, for region audits, for example. It's not as for region audits, exit plan. For short region audits, of course. This is the example of, this example of guidelines for exit strategies. As you can see, here we have information that in case of outsourcing of critical, important functions, firm should assure that it is able to exit cloud outsourcing management without and due disruption to its business. So only for critical, important functions. This is quite important. And there is information that need to be still compliant with obligation and still be secure and so on, so on. But there is information for critical, important functions. This is some hatching, hatching that we use on this talk. And this exit plan should be comprehensive, documented and sufficiently tested and updated during the living of our system in the public cloud. This is additional cost, which we need to, additional maintenance, maintenance cost, which need to be, we have, because we need to have exit plan and we need to, once a while, test the plan. For example, once a year, we need to test this plan. It's important to, to make this plan, exit plan easy to execute. It's very important. Because we don't know, we don't want to spend weeks, weeks preparing infrastructure, preparing the system and run and test it. That is, we can, we can execute the exit plan. It's need to be simple, easy to execute and cheap. And additional things, in exit strategy, we have three main exit plans. First exit plan is shut down the system. But if you, if you have the important in critical, critical process functionality, we can shut down. But the second main strategy is to migrate from one cloud provider to another cloud provider. It's okay. And the third one is migrate from cloud provider to on premise, to private cloud. That's why most of the, mostly of the banks, they use the multicloud approach. So they want to have more than one cloud provider and build cloud, private cloud. Because we need to, we need to, we need to have tools where we can migrate our system from this cloud provider. All right, this is the first part of my talk about, it's more about theoretical and introduction to this, my subject. And now we talk about the use case. How we can use the cloud native things, cloud native tools and approach to build system compliant with this guidelines, with the regulation. Of course, we should start from governance. We should have some governance. We, maybe we should create some team. For example, cloud center of excellence, which the team provides the best practices. They, they share the knowledge, they, they promote the, using the open source, promoting the, using vendor neutral tools. And the team will help during the risk assessment, we have during creating exit plan. This, this, not tool, I'm sorry, the team, of course. The team will help during the creating a risk analysis and exit plan. In couple of next slide, I will talk about reference architecture, what I imagine of the cloud native and how I promote. I will focus only on design and development, not only from design development perspective, but only, but on operation infrastructure and provisioning as well. But we'll start from the design of the system. Cloud native architecture is micro service architecture, in short words. Yeah. Clean, good, micro service architecture, according to best practices, 12 factor, books, some human, some human books, block, martin follower and so on. And this architecture is built from distributed as, from distributed set of small services independent and the most important loosely coupled services, which will, this, this character, this characteristic we'll use on the, we'll use on the next slide when we talk about the exit plan. Normally, when we design the architecture of the new system, we need to design a new system or we need to design immigration to the public cloud. We need to use, we have dozens of requirements, non-functionary requirements. In case of regulated environment, financial institution, European Union, we have additional sources of requirements from the guidelines from the authorities. The first is risk analysis, risk assessment. As the output of risk assessment, we got risk, which we need to mitigate by proper design, by proper design of application, by proper design of infrastructure. Risk analysis, let's imagine this is a very big Excel with a lot of rows and every row is connected, for example, with some risk, with some characteristic of the system. For example, thanks to this risk assessment, we know that the system will process legality protected data. So, if it's legality protected data, we need to encrypt the data using customer managed key. And you need to have exit plan for this data and for the system. Good to have during this designing of the system, and another source, of course, another source of the requirements, non-functional requirements is to have exit plan, of course. Good to have during the initial phase, business owner of the system, business owner of this domain, because we can, together with the business owner and together with the risk analysis, we can determine which functionality of the system are critical and important. So, to simplify, thanks to it, we know which part of the system we need to have exit plan, because we need to have this plan only for important critical function. And exit plan must be, of course, easy to carry out because it will be repeated one in a while, and it is additional cost for us, for IT department. And the characteristic of microservices are very helpful to achieving this plan, because we know that for the system, we need to have exit plan, but not for everything, not every part of the system. Microservices built from the domain, from the boundary context, from the set of the, if we're using the domain-driven design, of course, pattern. We have set of, set of, set of microservices, and we split the problem of having exit plan to domain level. And next, we can split this problem on microservice level. So, we split the big problem to smaller problems. So, it is easier to resolve the small problem about on the microservice level to have exit plan, how we, what is the exit plan, how we can execute the exit plan for, on the microservice level. So, to, or to, I like simplifying things. So, to under simplify, let's say for microservices, that implements critical functionality. Thanks to that, we have domain-driven design, we have the boundary context, we can find which microservice, which, which collection of microservice are important for us, for its critical. So, for, for this microservice, this microservice should be cloud agnostic. That's it. For rest of the domain, we can think about if we need it or we don't need it, in the, after we execute the exit plan. That's why I recommend to use feature tools, pattern, to, to, to switch off functionality which are not important and we don't have exit plan for them. Thanks to, we can, in control way, we can switch off this functionality and migrate the system to, migrate the system to another cloud provider or migrate to the on-premise. Another pattern which can be used is SQL breaker. Thanks to it, we improve the resiliency of the whole system of, from the individual failures of the service. Microservice, in nature, microservice architecture is that one, if one service go down, the system should work, but without some part of the system. The system should work properly in general way, but before, without some, part of the system, without some functionality. So, this is, let's imagine that this is the version, this, the exit plan. We switch off part of the system because we can, because it's microservices. It's the same, the same, what ChaosMonkey does. ChaosMonkey switch, terminates some pods, terminates services and they check that the system goes down or not, whole system. So, I think this, these three patterns, ChaosMonkey, SQL breaker, and future toggles is very useful for, for this case, for cloud native, for, for, for, for using, in financial institution, when we have to exit plan, which are cheap. We are easy to execute. And another advantage of this is that you can use cloud specific features. For example, you can use a speech to text feature from the, for example, GCP cloud and you can switch off this feature when we execute the exit plan. Thanks to, thanks to it, you can use the, these cloud specific features, ready to, ready to use services. You can decrease the time to market. You can improve quality of services, but if you, of course, you need to, you need to verify this idea with the business owners, which is important, which function is important or which not, which isn't important. All right. This is about the architecture of the, of the application. Now we should somewhere build infrastructure. We need to build infrastructure when we, where we run this application. For us, it's important to use one common way to build infrastructure in different cloud. And the most important things is to use declarative and immutable way of building infrastructure. So using infrastructure as a code is the key, I think, here. Because thanks to, thanks to this that we, we have the infrastructure as a code, we can, we can basic on this, we can create, we can create infrastructure in other cloud and execute the exit plan because we need to test it. I think the most popular tools to do it is Terraform. And thanks to Terraform, we have one tool and one language, not language, but we have one language where we can build infrastructure and deploy in different clouds. Another part, another element of, of this reference is, we have the application, but we need to run on something, on runtime. We need to choose the runtime. The best runtime, which is cloud agnostic common in cloud, public, private and hybrid, is container runtime. It's simple answer. We should use container D or Docker to run, to, to create image containers which are independent from, from the place where we run. So we have the same image container, we can easy run this on the one cloud and easy run to another cloud. Thanks to it, we reduce the time of the executing the exit plan, of testing the exit plan. Another part, of course, is orchestration management because we have the container, we have the infrastructure, we need to run, we need to somebody, we need to something which orchestrate and manage on our container. Is Kubernetes is another simple answer. Kubernetes is very common and this, very common and this, and is available in every public cloud is, and you can deploy a Kubernetes on private cloud, on bare metal. And, but there is something we need to check because not every distribution of Kubernetes are the same. So we need to check if this distribution is, this distribution is certified. So CNCF is another place where CNCF help us is, they certified distribution of Kubernetes. Currently we have more than 90, 90 certified distribution of Kubernetes which we can use, thanks to it we can use almost on the same, on the same way, across the providers, across the providers. Thanks to this certification, we have consistency of API, consistency of versioning of the Kubernetes and configability. Observability, we cannot forget about observability. Observability is the base of running microservice and in the cloud native. When we think about the multi-cloud approach and thinking about the exit line, thinking about the environment, we should find the common set of tools of observability which can use on the places. So we are recommended to use Prometheus, Victor Amethis, and thanks to it our monitoring teams, they can use the same tools, they can use the same alerts across the providers, across the cloud. Another part is provisioning of application. Provisioning of application, provisioning configuration to the cluster, to the Kubernetes cluster. We have two good tools, Flux and Argo CD, we can use, and thanks to these tools, declarative tools, according which are compliant with OpenGitTops principles, we can easily deploy to one cloud, another cloud, and execute in the exit plan because the process of provisioning will be the same. So the execution of the exit plan will be standard deployment, standard deployment, will be standard deployment. So there is nothing special, there will be nothing special in the case of testing the exit plan. We can use the same tools, the same process, and we migrate, for example, air bug rolls from one Kubernetes to another Kubernetes, we can easily deploy namespaces and so on. For now, that's it. I'm faster than I think so, so I open to the question, some questions, excuse me. Mike check, one, two, one, two, hi everyone. Sorry, yeah, my question was the, yeah, so I work also at a bank and we do very similar stuff, so we find it really good, but we don't do multi-cloud, so I'm interested into the advantages that you found of multi-cloud stuff and how easy you found working with like a lot of the terraform infrastructure and things trying to build with multi-cloud, essentially over just dealing with a single provider. Yeah, interesting question. I think the biggest advantage is that if we have the multi-cloud, we can use specific features of the cloud. The cloud is the best on the public cloud. In GCP, we have, for example, speech for text, it's the best, maybe, I don't know. In AWS, we have serverless. In Azure, we have, for example, pass service for data warehousing, for example, and thanks to the multi-cloud, thanks to the terraform, we had the common things, and thanks to this approach that we tried to find the border between what we need to be cloud agnostic, what not, we can use it. Cool. So it's not necessarily that you're deploying like Kubernetes on every platform and deploying all the services and all the databases and everything. It's more that you're like picking and choosing what's going to be the best for whatever you're building. Exactly. Sweet. Thanks. That was my only question. Thanks. What are your thoughts around the sprawl of tool sets that we're seeing within financial customers? So if you just think about the kind of basic automation, like you've got Ansible, Chef, Terraform, Salt, that's how it's there, then you start to lay on, you said choose your own kind of observability tools. There's lots of them out there, and each kind of silo team starts to bring their own, and the APIs make it easy for them to integrate their own, but everyone's creating their own mini snowflakes, and if main plays within each team's lead, you're struggling to support it after that. Hard question. Ansible is all right, but it's configuration management system. I don't like it because it's not declarative. It's not immutable. So we try to not using something like that because it's immutable and it's not declarative, so it's hard to switch to another cloud. You need to rewrite all the process and play books and so on. But I think we really have this in the future because these are very good tools, but we try to not using these tools because we need to be as we can to be agnostic and keep everything in the code, and automation is the, like in the development, we have API first approach. Here we should have automation first approach and declarative according to OpenGitOps principle. Thank you. Yeah, I have a question as well. I work also in the financial industry and I would be curious to know how you're ensuring that the compliance definitions are met in your company's environments? Are you reporting on that one normally? You have a long list and need to provide that? I think the risk analysis and we have the risk we need to mitigate. If we mitigate this risk, the risk will be low. So this is for us, this is what we know to achieve, that the low risk from the risk assessment. You don't have any real time reporting on that one? Real time reporting? No, no, no. Thank you. No, not yet. The question I had was for risk assessment. The risk assessments that you do is, do you keep that, do you do that with a specific compliance framework in mind? And then question number two, how do you do the risk assessment? Do you have a risk registry that you maintain throughout the bank? And then is that expressed in some sort of machine readable format like OSCAL? About the risk assessment, we don't have a risk assessment. We don't need to gather, we don't according to ESO something. I'm not the expert in this, but according some framework to risk assessment. We have the, of course, we have the compliance teams and security team they provide for us this assessment. This is quite complex things because we need to cooperate with several teams in the banks, compliance, security, IT, legal, and so on, because we need to analyze even contract, not only from technical but from the contract point of view. I have a question. What is your cloud maturity and how much do you have your products in the cloud, in this multi-cloud system? And how many, what is your development team and operations team or cloud teams that are, what is a team size? And the last question, sorry, there are so many, last question is, there must be also a lot of these cloud specific infrastructure resources that are maybe not so easy to manage with your Terraform scripts and so on. How do you do that? All right. I'll take, all right. Currently in M Bank we are building landings only in two cloud providers and we have several applications in the one cloud and we have several applications in the cloud, private cloud, and we try to, and we are building application in agnostic way that we can deploy application to the public cloud and the private cloud using the same tools, using the same way. That's why using the observability is the same, we are using the same tools. I don't know how many developers we have but I think it's 600, 600 developers. It's quite a big company. And my previous, I work, before Bank, I work for insurance company. It's the same regulation we have and we have application in the multi-cloud in GCP and Azure and we set up everything from Terraform. But Terraform is different. The script is different. There is not, this only tool is the same. About the Cloud Center for Excellence, the team has seven person, is cross-discipline person, cross-discipline members and we have dedicated team for compliance team which they handle the contract things, risk assessment, these subjects and so on. I think maybe 20 person is involved in this. During your talk, you mentioned data location and data processing topic. How do you resolve it? Because usually it's very governed regulations and it can be dynamic. Do you have specific tools or just for each case you create something proprietary? We are using a lot of policy. This works? A lot of policy. For example, in Azure policy, we have policy that we need to, we can set up the resources only in two regions, for North Europe and West Europe. That's why we are sure that we are using only this region in the cloud by policy. Thank you. What are your thoughts on service mesh as a way to secure the workloads in your clusters in runtime? The next subject, the next phase of our development, we will be using this open service mesh because thanks to it we can, we will have always, we have encryption in transit always because without open service mesh it's hard to achieve in the cluster, in the encryption traffic between the pods. We implement this phase, the next one. Thank you very much. Thank you.