Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2019 (Barcelona), 24 May 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: From COBOL to Kubernetes: A 250 Year Old Bank's Cloud-Native Journey - Laura Rehorst

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Keynote: From COBOL to Kubernetes: A 250 Year Old Bank's Cloud-Native Journey - Laura Rehorst, Product Owner - Stratus Platform, ABN AMRO Bank NV & Mike Ryan, DevOps Consultant, backtothelab.io

Adopting Kubernetes in an enterprise setting is challenging enough. Doing so in the highly-regulated banking industry presents further challenges. In this presentation Laura Rehorst (Product Owner - Stratus Platform, ABN AMRO) and Mike Ryan (DevOps Consultant) will share some of the lessons learned during ABN AMRO's Kubernetes adoption, discuss how Kubernetes accelerated the bank's Digital Transformation, and demonstrate parts of our Continuous Compliance infrastructure.

The technical part of the presentation will include demonstrations of how Open Policy Agent is used in CICD pipelines and Admission Controllers, our process for automatically repaving infrastructure to protect against Advanced Persistent Threats, and how our ""compliant by default"" approach allows us to move fast (without breaking things).

https://sched.co/MRzj

A

Hey good morning, everyone I'm Mike I'm part of the team at ABN, introducing the cloud native strategy, and then it says today we're going to show off a little bit of the work. We've done talk about some of the business decisions we made, which led us here and show how we're using OPA for compliances code and finally share a few of the lessons. We've learned in this journey. Hi.

B

And I'm Laura already mentioned I'm product owner of team at ABN AMRO and before we start talking about our journey towards containers, I first would like you to show you some figures, so yeah understanding of what we are dealing with.

B

So if you're number Bank is active in the financial sector and that's highly regulated, but also highly competitive. So that means as a bank, we need to find a balance between delivering software fast, but also in complete compliance. A secure way.

B

We have around 20,000 employees, foreigners plus development teams and as development teams are either creating or maintaining applications and FSA applications. We are running around 3,000 applications within the bank. We all do this.

B

According to agile principles, and some time ago we started implementing DevOps also it started our journey through our CI CD and we also are following a hybrid cloud strategy, so we're using AWS assure, but we also have applications running on Prem, so I hope that gives you a little picture of what we has to bank with challenges we are facing so now our journey.

B

So what we've seen in the market is that people started using containers, so we started investigating it as well, I. Think of the benefits that will be there for us as a bank.

B

So I'll share some of the reasons with you. The first of them was increased development speed, so spinning up container is way more fastest, but then spinning up virtual machines. Besides that, it also gives our developers flexibility.

B

So that means that and container you should be able to run it anywhere if this should be on assure or on AWS at guess and flexibility, but also us, as a company gives us flexibility, because we are less dependent on our cloud providers because we can move it's it's portable, then a unified environment and with this I mean the challenge that the developer can face.

B

When you are creating your software locally, then you want to deploy it to the next environments, test or acceptance, and it fails because in because of inconsistencies between the environments, we all know with the portability of the containers. It should run the same on every environment, then, from a strategic point of view. It is also cost efficient, because containers are cheaper than virtual machines and an external influence is that our suppliers, they deliver software and we see more and more happening that they deliver the software into containers to us.

B

So the next thing that we've seen is that our first team started using containers and it's pretty cool, so they started experimenting and after some point they started facing challenges because we are bank, so we have a lot of responsibilities so what's actually secure and what are best practices.

B

And, besides that, if you look at the cloud native landscape, you see there are a lot of options. So what do you need to choose? And you can imagine that if you have three hundred teams within former teams that I want to use containers at a certain point, if they were all select your own tools, you will end up with multiple licenses.

B

So there is that we need to come up with clear guidance. So we don't want to restrict our developers, but we give them some guidelines, so they can experiment between those boundaries.

B

Also, we want to give them features that they can consume easily. So we don't want to gives them all extra work. We want them to focus on their applications and that we take the rest that we will take care of the containers and kubernetes part. We want a uniform way of working because we are an enterprise. So that means that if there's no uniform way of working and everyone starts doing their own thing, you won't be able to control what's happening and then last but certainly not least, we want the teams to share the knowledge.

B

So when a team already started using containers some time ago, they have a lot of experience. It would be a shame if they would not share it with new teams, because then they will have to reinvent the wheel again. So therefore, we say share knowledge and your best practices.

B

So, in order to do that, we have created a team, a team with a with a mission and the steam is called SCOTUS and if you actually look up Stratis definition on Wikipedia or Google you'll see the following definition: it's low level clouds and it's a metaphor for our team, because we closely collaborate with development teams, so we are lowly above the development teams and also again the uniform base that we think is really important.

B

I already mentioned Stratis really the mission, because we need direction and also communicates this direction towards the whole and towards all the development teams. My colleague Mike will tell us more about this whole mission. Thank.

A

A

Okay, so we have four main goals within Stratos team. The first is to provide easy to use platforms. Kubernetes is fairly easy to use, but with the bank we have some extra requirements, so we need security, compliance and things built in. So that is our definition of easy to use. Security is a super important thing.

A

A common mantra in the startup world is move fast and break things, but in the banking industry, if you move fast and break the wrong thing, your boss's boss's boss's boss ends up in front of a government regulator having to explain why that thing broke, and that's really something we want to avoid portability across clouds is important for a couple of reasons, primarily strategic.

A

We love AWS, we love azure, but you weld your containerization strategy into one cloud provider with no route to extricate yourself in the future. It's not a smart strategic decision.

A

Reusable software components is actually my favorite part. I could spend the whole talk talking about this one little section. This is the mantra of the Stratos team. So if you ask 400 development teams to design a wheel, you will end up with 400 slightly different shaped wheels. Some of these will be triangles, so this is something we really want to avoid. So we provide lego for DevOps teams to accelerate the application delivery. So, for example, we have impressed code modules for deploying kubernetes clusters.

A

We have reusable pipeline modules for building containers, delivering them to kubernetes clusters and we have helm charts for common components such as EFS for persistent storage, alb ingress and so on. One of the services we want to offer the teens is compliant by default, so all of our modules are built according to our internal compliance rules. This means, if a developer takes our modules off the shelf and uses them with a sensible default configuration, their infrastructure will be compliant by defaults.

A

Of course, the application still has to go through the review process, but having all of these homogeneous modules in place means a lot of the work is already done.

A

So, as Laura says, we have 400 development teams, so if we can regularly achieve even 1% efficiency gains in a cumulative fashion, this makes the return on investment for the Stratos team very compelling.

A

So to take a look at how compliance and governance rules are built into the platform we realize in a large enterprise, the tooling is only a actually kind of a small part of the equation. Most of the challenges come in fitting it into the organizational structure. So within ABM we have some platform teams who specialize separately in AWS and agile. These teams have a lot of expertise in their respective areas. So, if we're not working very closely with them, then we you run the risk of reinventing wheels ourselves.

A

Do take a little bit closer look at the stack. This is what our stack looks like at the moment. It's obviously a work in progress. Continuous improvement is the name of the game here in terms of pizza. As a service, we didn't want the three-course add menu, but we also didn't want to sit at home baking dough. So we took this middle ground approach where we took the best-in-class tools on an aliquot basis, so you see we're using AWS eks and as your aks.

A

This is because we very quickly decided we wanted to use kubernetes, but if these cloud providers can give us a managed kubernetes service which is certified compliant, then our team doesn't need to become experts in managing @cd clusters, which is lets us deliver a lot faster, so I'm going to do a very brief run-through. I'm sure this is gonna, be familiar to everybody here, we're using helm for package management.

A

We got a bit ahead of the curve and we've already stripped out tiller I do not want Ella in my kubernetes clusters, so our CI CD servers run helm in Tillis mode. We've not yet selected a tool for persistent storage, but we know that will be supporting so selecting something that follows the CSI standard, we're currently using so no tied Nexus for our docker image registry. This is something that we already had in place so building.

A

On top of that means we didn't need to go through the procurement process of selecting and implementing a new door registry in the security area. We have twist lock for build and run time scanning of our containers. Colleagues, Dominick and Weber gave an interesting talk and the twist lock session on Monday so check that out on YouTube we're using vote for provisioning secrets in conjunction with the cloud provider, secrets, management's, tooling and we're using OPA in our pipelines and in our cluster to enforce our compliance rules.

A

Abn already had a mature spunk infrastructure, so we decided to just send a lot of our cluster data Splunk. So we can reuse the compliance dashboards.

A

Now going to dive in and just take a little look at one of our example pipelines so again, I'm sure this will be familiar. This is a standard application pipeline that is used within the bank, not just for docker eyes applications, but just generic application pipeline. We are looking at the Java version, but we also have Python and other languages as well.

A

The second pipeline. This is our docker specific pipeline, where we're actually building an image and running through security checks with twistlock. So at this point we're doing the image vulnerability scanning and in the previous step, we're looking more like for vulnerabilities in dependent packages and so on. The final part of the pipeline is the cloud delivery part. This takes the docker artifact that we built it runs your home jart and your desired kubernetes resources through our OPA policy checks and if everything passes it gets delivered to the cluster.

A

So putting all of this together, we essentially have three pipelines where the output of one is the input through another, and this is a good example of our Lego for DevOps approach.

A

So if you're using Python, you can simply swap out the first part of the pipeline and use the Python version and if, in the example here we're deploying to eks, but if you're deploying to IKS on as your swap out the last part of the pipeline and if other container runtimes start to really gain popularity on docker, then we swap out step two and developers. Don't really need to think about the actual container runtime.

A

They don't need to worry about the pipeline, so much everything is sort of plug-and-play and finally, if an application needs to be moved from one cloud to another, the developer just needs to swap out the last part of the pipeline. Obviously assuming their app is truly portable, which most aren't.

A

Now take a very quick look at what we do with OPA, so full disclosure- we have not finished building all of this. Yet this is the vision of where I want to get us to, rather than where we are today. So everyone's familiar with infrastructure is code. I think OPA lets us do compliance as code, so we get all the benefits of the software development workflows. We know and love pair programming all requests code review, but for our compliance rules.

A

So these are things that we, as developers and engineers, tend to take for granted and view as the obvious way of doing things, but these methodologies have not always been ready available to our colleagues in compliance teams, but now we can use guitars in our compliance management, which is pretty cool. We use semantic versioning for our policies, so we can instantly see which policy version is applied to a kubernetes cluster. When a new policy version is released, we can see who's updated and who hasn't, because we have change locks for differences in policies.

A

We can see how aggressive we need to be in pushing people to upgrade, and all of this gets fat fed back into the compliance dashboards I mentioned. So we have full visibility over the compliance state of clusters and applications.

A

Now, if the pipeline fails due to non-compliance, we can give the developer detailed, contextual information about the issue and how to fix it. So one thing we check, for example, is within ABN internet-facing load balancers are not allowed. Everything needs to go through our private network. So if a developer attempts to create a public facing load balancer in their tariffs or module, they'll get an error. Something like AWS 0 to internet-facing load balancers are not permitted.

A

Aws 0 to is a named compliance rule, so the dev can go and look that up in confluence see why the rule is in place and how to move forward in a compliant way. This fast feedback and rich information minimizes the compliance overhead, or at least the frustrations felt by the developers. If developers run into an opaque, brick wall. That just says no, no not allowed they get frustrated. So, by giving this early feedback, we can reduce local even remove this frustration.

A

There are two rules in the world of internet dating number, one is be attractive and number two is don't be unattractive and our approach to compliance is similar. We make it very easy for developers to be compliance and we make it very very, very hard to be non-compliance. We still have quite a way to go before we get there, but this is where I want to get to with our compliances code implementation.

A

Underhand back over to Lara, so she can talk a little bit about where we're going to next. Thank.

B

You Mike so I want to share a bit about a road map. It's already told you about the stratosphere team that was created, so there was about like six months ago and what we have agreed upon there is that everything we're gonna do we're gonna, do it in a legal fashion. So that means we're gonna wait work with iterations, so we can feel fast collaborate closely with the customers and really deliver value. And then we started moving forward.

B

We really started creating some prototypes experimenting and that in q1 end of q1 we delivered our first MVP, which was eks completely according to rules of a banana Bank and regulations for our developers, and we imported the first three workloads.

B

So our next step- and our next goal- is to abort more teams and improve what we have now. Also the compliance this code. We will extend so it's really working in iterations and start to extend everything so I'm actually quite proud. That is such a short time. We in a highly regulated sector. We have achieved so much already, but it's also, of course, because of the offerings of CN CF.

B

Now not an interesting part. I want to share some lessons learned with you.

B

First one is to keep focus, so we said we really need to keep focused on the MVP, because it's such a fast changing landscape, new tools are popping up newer, great regulations. Everything is popping up and if you don't give focus, you will not deliver the delivered MVP, then a follower, holistic, holistic approach. So technique is one thing, for example Cuba Nettie's, but that's that's actually not the hardest part in an enterprise. You really need to take care of your governance, so a big enterprise.

B

You have a lot of teams and departments departments responsible for security for compliance, but you also, if your cloud provider, departments and there you will need to collaborate and you need to define responsibilities to make sure there are no gaps there.

B

Then we think of platform capabilities over just selecting tooling. So what you meant here is that we closely collaborates with the development teams and there we see what they actually need. So they they show us and they tell us what tooling will be best for them well capabilities, and then we will select the tooling that will fit best for them. I already mentioned iterations is very important, so we can feel fast and move forward and last, but certainly, not least in our case, is to automate things.

B

So automation will help you to prevent mistakes that would have been done manually, but it also helps you to scale up. If you don't automate, you want to be able to scale up so therefore, we recommend that you start automating as soon as possible. Actually when you already start doing your MVP, but if you haven't start automation, yet my colleague always says it's never too late to automate so with this I would actually like to wrap our wrap of our talk and thank CNC I. Think you can forgive us this opportunity to share our story.