 I think it's five minutes, five minutes to 12, so let's kick it off. Very excited to be here together with my friend Kasper. We are from Luna and we are here to tell you about the paved path leading the way to compliance. First presentation, my name is Brian Lielsen. I'm a former engineer. I'm a former architect who has transitioned into executive leadership and it has always been my very great passion to bind together technology and business to create customer value. Kasper. Yeah, my name is Kasper. I work as a lead platform architect at Luna. I'm also a CNCF ambassador, community lead in the Nordics. I see a few cloud data Nordics t-shirts around, so that's nice to see. I organize the local group in the city that I live in and just try to help out as much as possible within the community, try to go out and talk about what we do at Luna as we do here today. So yeah, I think that's me. So just a little bit about what you can expect from this talk. We'll talk about what Luna is. We'll talk about some compliance requirements, the way we work, and then we'll focus in on backstabes, how we adopted it, and we'll also show a use case where we use it regarding asset management. Then we'll end off by talking a little bit about what our next plans are. So let's start with Luna, right? Who are we? Well, Luna is the 16 largest bank in Denmark. We have more than 575,000 customers across the three Nordic countries, Denmark, Norway and Sweden. And we are both a consumer bank, we are a business bank, and we are fully digital. So that means that we have no branches. We interact through our native apps and through our websites. Absolutely. Okay, great. Thank you. So aside from that, most importantly, we are also a technology company. So we have more than 113 employed in the Luna technology across 21 squads, and we do more than 100 daily deploys that are more than 400 microservices. And this is what we believe truly sets us aside from the competition and what gives us an edge towards the incumbent banks. Now, our goal in Luna technology is to fuel the growth of our company, and we do that by employing four different strategies of four different principles. Horizontal growth, because more products, more markets, more segments, we employ a domain-driven design to ensure that we have the right boundaries. And vertical scale, 10,000 customers, 100,000, 500,000, a million, 5 million customers, doesn't matter because we are event-driven. We communicate everything asynchronously. And then we employ an outsourcing principle based on domain distillation. We want to focus in on what really is core of Luna, what differentiates us, and what is more commodities that we can allow for, to have others help us with, for instance, the way we operate on top of the three public clouds. And the fourth one is the one that's really interesting for this talk, the paid-part engineering, because it has always been our key focus to make it as easy as possible to engineer in Luna. Our engineers should focus on bringing customer value. They should focus on working agile. Those 100 deploys every day, you know, that fast feedback loop to the end users. This is what really brings the value. And at the same time, we need to balance this. We need to ensure that we can demonstrate safety and demonstrate control, because it goes in the name Luna Bank. We are also a bank, so we have compliance requirements. Those requirements, you know, are based out of the DFSA, the Danish FSA, executive order of management and control of banks. And there's also an addendum that focuses in on IT strategy, IT risk policy, and IT security, you know, that really outlines on a high level how we are supposed to do our engineering. This, by the way, if some of you are not from Scandinavia, right, or Denmark, gets a lot of you aren't, right? This is based out of the European Central Bank's orders for management and control of banks. So we will hear in our talk, focus in on a specific case regarding asset management, but this is the sort of overall framework in which we need to navigate. And for us, compliance, you know, it's much more than regulation, because it's like when we have paved that path for engineers for them to move really fast. So you ride the bike down that path, and you know, as you do so, you need to have lights on, because you don't want to be stopped by the police and get a fine. But that's actually not the real reason why you have lights on, right? You just have great lights on the back of your bike to ensure that you don't get run over. And you should have a great big bright light in front of your bike to ensure that you see the obstacles way ahead. And as you move faster, this becomes ever more important. That's why we want to ensure that compliance and security is something that is baked in. We shift left on it and we ensure that we think from the very get go about these topics. And then we automate so that it's something that we can help to lowering the cognitive load for our engineers. Because when it comes down to it, we need to be able to tell our customers that they can, in all matters, trust Luna. Because if they can't, you know, it's not just a problem for us as a company. It's actually a problem for the entire society. This goes in the way we work. As you saw on the previous slide, we are squat based, 21 squats, and we work based on domains. Each squat has one or more domain for which they are accountable, 360 degrees, you know, from cradle to grave. And we set our squats together so that they have the needed skills to succeed cross functionally. And this is very important, because then we can actually work efficiently and independently. So we have more than 400 microservices built up over the course of the last eight years. And to structure that and to ensure that you don't need to hold all of that in your head, we employ domains and we have more than 90 of those. And they can be further segregated into three groups. As opposed to most important ones are the product domains, right? Cards, accounts, payments, loans, et cetera. But we mustn't forget the supporting domains. You know, we also built software for the rest of our company. So our finance department, our financial crime department, our treasury department, our customer service. And then, of course, we mustn't forget engineering domains, the products that we actually built to help cloud developer experience, data, security or partner management. And it has from the very, very get go been important for us to think platform into our engineering. We employ the principles from team topologies, where we have three dedicated platform squads servicing our 18 product squads, removing that cognitive load for them to ensure that the 18 product squads can actually work and create the real business value. This is what we call the paved path. So this is things like a same configuration default, ensuring that you always have four eyes principle, that you always have the right resource allocation based on your role that we have least privileged access and ensure that we have branch protection and sign commits. And it's also to automatically think in data operations scalability. The fact that we have logging frameworks, audit frameworks, and also automatic surveillance. But Casper, you'll come a lot more into this. Yes. And this is on. Can you? Yeah. Okay. We'll just give this one. All right. And this works. So you might all be thinking, right, but how does this relates to backstage? And we'll come back to that in a second, because we will, I will just explain a little bit about our adoption of backstage and why and how we got there. Because as you saw in the previous slide that Brian had, that was all of these different technologies, right? And let's start with a developer, Lunar, let's call this person, Spacey. We are GoShop. We do GitHub. That's fairly simple, right? We know how to do that. That's pretty simple. We also need to do some CICD. That's okay. I can manage that. But I also need to communicate with my peers, my other services, my other domains. So that's different protocols. We use all three at Lunar also. So that's okay. Now that becomes a lot. Then we have three different clouds. We have Kubernetes. We have service mesh. We need to communicate securely. There's a lot of things that I need to take into consideration as a developer. So yeah, I might be able to manage this as well, but we are shifting more and more left, right? So we are pushing more and more to our developers. They also need to monitor this stuff. They need to, well, ability is getting all these things that are things that our developers need to be pushing to our developers to take that responsibility. And they are, yeah, like this, right? They're minds that they are overburdened by all that technology thing they need to learn. So the problem is really that, yeah, that they get overwhelmed with all of this. The systems, this required knowledge in order to actually take on the required ownership. So we set out back in 2020 when Spotify released Backstates. And we saw this awesome video of how Spotify solved all of our issues basically internally. So that is what we need. So we really wanted to minimize the cognitive load on developers and provide them with clear and actionable information. And Backstage was really what we saw as this tool that could help us do that. Before we dive more into Backstage, we also need to introduce another thing that we built. It's open source. You can find it on Dunaway, a struggled GitHub. But basically back in 18, we were sort of struggling a little bit with, we thought that the real solution to Kubernetes and Dockerfiles was basically pushing everything to our developers. And you do your thing. You can manage all the YAML files and all the best practices and updating images. That's you. We quickly found out that was really a good idea. They were overburdened with updating stuff, being compliant, following all the rules that were set out by the platform team. So we built this thing called Shuttle that we, where we sort of take the control, this was our initial start to what we today would call platform engineering, right? That we as a platform took ownership and provided them with paved paths to how they should do things. But the cool thing about this in our Backstage journey was that we had this Shuttle YAML file now that defined ownership, defined the service name, it defined the domain. We had a file that we could process and we could basically put into Backstage. Yeah, just before, yeah. So this is actually how we then did this. So we could go through all of our repositories at Lunar, process this Shuttle YAML file, also process API specifications and what else that were present in the repositories and we could create components within Backstage and we could build a software catalog over all of our services. You could gather all the documentation, all the stuff that we had there and visualize it and build a catalog based on this file, which was pretty nice at that point. And it ended up looking something like this in Backstage. So this is just a component in Backstage showing that that's a readme, that we have different plugins and come back to that a little bit later. But this is sort of the end result of all of this processing. One of the other things we really wanted to do when we adopted Backstage was to, we didn't want to force developers in that. We really want them to show that there's a better way of doing things. And one of those issues that we tried to solve initially was how to set up a service because previously our developers were struggling a lot with being compliant. We rely a lot on the PR flow and we need to have certain checks. We need to copy over files. We need to set up a docker registry. That's all kinds of things I needed to do as a developer in order to get to a place where I was ready to deploy and actually provide value to our customers. So we adopted the Backstage scaffolder, which is super, super nice plugin. We can now just basically scaffold how we want the service to look like. And for developers, basically like this, I fill in a name, a description. I select my owner based on the team that I'm on in GitHub, in our GitHub organization. I select the domain. And domain is something that we control as well internally at Luna. That is a centralized repository that we sort of interact on what is that domain? Is this really a domain or should it maybe belong somewhere else? And you can specify if I want this to be released into production right at the get go. Once that is done, I click create and I get a repository. I get everything bootstrapped for me. I get everything configured. I might even get a running service in production if that's what I choose. So that was almost too easy. Another thing that we really prioritized in our Backstage journey or our adoption was also showcasing internally how could other teams contribute to Backstage because we were a small, we are still a small team and we from the get go knew that we were not going to be able to basically handle all the things that potentially could be in Backstage. We wanted developers to contribute back to our internal Backstage and create their own plugins. And one of the cool things that came out of that was basically we had another team building like a core team that does card payments, built this thing because they really needed a reconstitution service that could send, we are doing a lot of event streaming and stuff like that. So they wanted a service that could basically bootstrap another service and select different events and just run a job and bootstrap a service based on that. So they created that, which was super nice to see that that work actually sort of turned out to be a really good idea. And then basically pay paths leads the way, as Brian also talked about. We now use the Backstage Scaffolder as the default way of creating repositories within GitHub. So initially it was showing the potential and just giving them a really easy way to create repositories. And now we start to enforce that this is the only way that you can create a repository because we want to control how things are being set up and configured and make sure that everything is correctly set up in a compliant way. And what is then in this default package? If it's a Go service, you get something that looks like this. You get CI setup, you get all the GitHub configuration around branch protection on main branches, PR flow, 4I review, all of that. Code owners is configured for you. You get service ownership, all of that defined in the shuttle.yaml file. You get all the external configuration and dependencies taken care of. And you also get automatic updates because we're also using something like renovate, but to actually create PRs when things are updated. All of that comes out of the box. Of course, also security scanning and all the things that runs in the pipeline is also configured and just works out of the box. Another key aspect of our adoption was really also to integrate with these critical systems that our developers use on a day-to-day basis. And another plugin that we created for this, this was one plugin that we created internally on the platform team was around dead lettering. We wanted to ensure that whenever a service weren't able to handle a particular event, we wanted to provide a UI so that developers could easily figure out what was going on. They could recent, they could just discard that event if that was the way to solve it. So we're really trying to build in these critical systems and paths within our backstages in order to get adoption up as much as possible. So that's how we are trying to drive adoption. And it ends up like something like this. We really try to surface also really important thing. And this is one of the examples of this. This only shows if you have dead letter messages. This is a squad, a team called Aura. They in this case have 18 dead letter messages in the depth environment. So we try to surface relevant information and if that's none, that will not be a box here. And the last thing I want to touch a little bit on in our backstage journey here is also gathering insights and surface progress. We use tech insights. It's another plugin. And Brian will come into the use case in a second. But we had this use case of gathering or configuring domains on all of our different services. So we needed to add a field in the shuttle of Yammer file on all of our services. And we wanted to track that progress to see how our teams doing it because this was a team responsibility to add this field within backstage or within the shuttle of Yammer file, and then it will be present in backstage. And tech insights really give us this really nice way to track this both on a team basis so that we can actually have like a gamification between teams. But also for the team themselves, they can see how far are they in their progress. So in this case, we have squad Cassini, they're missing to or that they have one item to complete and they have completed six, five items. So they're almost there. And just to highlight and ensure that the progress is still there and they can see how far they are. So just to round this backstage adoption talk a little bit of our sort of key points in that process has really been show the potential. So initially we created a lot of mockups. We tried to visualize how could this be internally be and talk to developers getting the feedback figure out what what is the most important thing we could do now and then just take it from there. We also found out that it's really it's really great that there's so many plugins in the community, but the plugins usually don't really fit your use case exactly. So we also trying to make it fit. Maybe we change the component that would fit would fit our use case much better. One example of that was the pay-to-duty plugin where we use the base functionality of it, but we configured it in another way because we're using pay-to-duty in another way. And this way of integrating critical paths and systems has been really, really important. That is really what have drove people in there. Inner sourcing, yeah, really show how to do this because you will get a lot of things back and then basically just try to reduce friction. I think that's that's really where you can help developers and that's where you sort of get them in there. And it was you, Brian, on the specific use case here of your help. Yeah, thank you, Casco. So I mean, this is fantastic for developer adoption, but we are not done, right? Because we have a whole bank of excellent people working that we would like to adopt backstates as well. So let's dive into a specific use case here for asset management and also a little bit more. But let's start out with, you know, why at all do we need asset management? Well, the four main reasons is that we need to know, I mean, we are also a company that needs to have a certain profit. So we need to know, you know, what is our profitable assets because we need to home in and perhaps give extra focus here. And on the other side of that coin, you know, as you said, Casper, what is our critical path and what is our critical assets, because we need to treat them specifically. It's part, as we said earlier, of the regulatory requirements from, you know, the Danish FSA and that executive order. Because when it came down to it, this is about us being able to demonstrate and show not only to the regulators, but actually to our customers that we are at any given time fully trustworthy, fully compliant to handle their assets, right, because they need to trust us. So, okay, what are we actually talking about? Well, assets, that's a lot of things we have touched upon. Squads, we have touched upon domains, but there are more assets. It's also the services, the microservices we have. It's the API's. It's the processes we use. It's the vendors we have. And it's the resources, for instance, the data resources that we use. So this is a journey. I mean, yes, we started out with ensuring that we have our domains structured, visualized in backstates and getting this visualization is also something that ensures that other professional groups and engineers certainly get this information available to them. I mean, we want to do more. We want to have the internal services, microservices, if you will, and the processes as well. And this is because we needed to start out with something that really mirrors the language we have in our company. So that domain language, it's important for our engineers, but just as well for the business people to understand what are we actually talking about? And when we looked into backstage, we actually saw that, well, you know, domains, systems, resources, APIs, components, it fit pretty well into what we would like to actually showcase to all our controllers and the regulators so that they can go into backstates and actually see this is the list of the components we have. This is the spot that owns them. This is the domain it's in, et cetera. Because it's about metadata. We need to classify these assets. It could be, you know, as it we have chosen mission critical assets, highly critical or non-critical assets. And based on that, we need to annotate certain requirements. It could be authentication requirements, it could be access, or it could be availability, just to mention some. Now, this, as you can see, very clearly visible within backstates. And this is what the regulators love. We can actually show it and they can not only see it in Excel spreadsheet, you know, they can see it, they can see it live updated when we create those easy components in a matter of minutes. Boom, it's right there in front of them. This builds trust. So, as Casper said, for our critical systems, of course, we have a incident response process. We have a tree arts and issue resolution process, as I suppose many have. And this is today like a standing operating procedure. Now, it would be wonderful if I can say, well, if you in backstates put on high criticality, automatically in the page of duty is then created the business set up and, you know, boom, we are there, not completely yet, but it's doable. Right. So, this is one of the things that we really want to enhance with stuff we have done that goes beyond asset management. Is this sort of continuous compliance or surveillance where if someone, I like to say, by mistake, not malicious intent goes in and tries to change something in our AWS config or tries to access tables with sensitive information or tries to change, you know, the pipelines that the branch protection, we get automatic or we have set up to get automatic alerts that goes straight to our CISO so that again, this is about ensuring that the engineers can lower the cognitive load. They don't have to worry about this. They can just focus on creating that business value, but we have more things in line and Casper. Yes. So as Brian mentioned, we are not there yet. So we just embarked on this journey to really showcase what backstage also potentially could be, right? More than just a developer portal, it could be for everybody internally at the event session as Brian was telling you about. So what we have today is really, we have the software catalog, which is, as Brian mentioned, the software asset management. That is where we classify our different components and do all of that. We also use tech docs quite a lot. It's really nice for developers to have that documentation at the repositories where they work and being rendered as together with the components within backstage. We use the scaffolder as I showed you to make it easy to create new services. We can also create cool graphs of the catalog if we want to. So the catalog graph is there for graphing the software catalog in any way form you like. We use pay-to-duty and use that, as I also mentioned, for triggering on-call and stuff like that. We have the reconstitution and dead-letter plugins that are something that we build internally. It's unfortunately not open source as it is right now, but it's something that we build and use quite a lot within our backstage setup. And then tech insights. I see a lot of potential in tech insights and gathering insights on different things that our developers need to care about in repositories that you can specify facts and then take insights checks for these facts and surface the information. So that could be anything. We just use it in this case for domains, but it could be for all kinds of things. One of the other things that we are working on right now is really to align our internal asynchronous communication. So as mentioned we use Revit. We are aligning on avro schemas and we really want to surface also information around PII data in these schemas. So we are adding metadata around PII to our schemas. And our vision is at some point we hopefully can visualize and sort of classify all of the different PII types within backstage. Where are they stored? Where are they coming from? Who is consuming them? And where does all of this data flow between services so that we have that overview within backstage? So that is also something that we are working on. And the same goes for data. So data in databases, data schemas, stuff like that. Highlight that also in terms of PI data. Getting that information in that is something that we are really, really interested in and trying to solve at the moment. And I think the last slide, when you start with the business value perspective and the key takeaways. Absolutely. I'll be happy to. So again, this is about finding the balance between us enabling our engineers to move really, really fast. You know, time to market with no friction. Just having that fast feedback loop all the way out to the end user consumer. Daily deploys working software. And having the engineers ability to focus not on the toil of setting up, but actually focusing on the customers. At the same time, the other side of the balance, we need to continuously have compliance. And that's the real value here that we bring into backstage also for our controllers and our people working with compliance that we can show it. It's not something we say. It's something we do. And it's live updated. Huge business value here. Yeah. And from the tech perspective, right? It's really about reducing the cognitive load of our developers. I think the tagline that is on the backstage T-shirt is happy developers make happy code. And I really love that. So it's really about reducing the cognitive load. But also providing providing these paved paths for your developers. If you have these compliance requirements, try to build that into the process so that the developers don't need to spend all the time on configuring that and setting that up and potentially doing it wrong. So if it's automated, then it's probably configured correctly if you did it correctly initially, right? And backstage is really more than just a developer portal. It's for everyone within the business. I think we actually have five minutes for questions. Thank you. Nice presentation. I have two questions. How did you collect the requirements for your backstage? And how are you evaluating that is really helping your developers? So initially, when when we we showcased a lot, we spent quite a lot of time in actually both, you know, showing the video that Spotify created that this is the potential, this is the vision, but also just asking them. We did a lot of, you know, forms, what is the most interesting thing or how can we help you the most? What would be the most value to you as a developer? That's really where we started. And we the result that we got was the software catalog is really what we needed initially. They needed to see API specifications, stuff like that being rendered in a nice way and having that centralized. That was really where we started. Do you want to? Yeah, and I suppose that we can add on that this is what we're doing now. I mean, experimentation has always been in our DNA. You know, again, that fast feedback loop, it doesn't only go towards the customers, so to speak. It also goes towards the engineers. And in our case right now, it goes towards our controllers. It goes towards our compliance officers that we are out asking them, you know, what brings value to you so that we bring the two main experts into this development? I hope that answers the first question that how are you evaluating that really solve their problem? Well, I think just the showcase of that now you can create a service with, you know, entering these four or five fields and you get a service in three minutes. I think that's in itself is a testament to that. This is actually working comparing to it may have taken a developer half a day to a day to actually do this previously. So that is what we are not really tracking it in like a structured form or anything. We just try to figure out how can we help our developers as much as possible. And then, you know, that is our sort of north star that guides us asking for feedback and figuring out what is the most important thing to do. Thank you. Hi, amazing presentations. Thank you for that. I have two questions. First is what inspired you actually to build a platform like this and was a team topologies because I see the wording there. And the second question is how have you managed to convince the management, the board into investing into developer portal because this is something which I perceive is not always an easy task. So I think it's about identifying who is your customers within Luna. We have a huge customer focus, right? So it's all about creating value for the customers that actually use our bank. But when you employ team topologies, the customer, you know, the teams, the stream aligned teams that actually build those products for fantastic user experiences, creating accounts and loans and what have you, right? They are also customers towards well, towards what? If you don't have a platform team, you saw that what Casper showed, you need to have everything in your head. And that is not efficient. You know, countless theories support that the cognitive load of microservices. I mean, we have more than 400. We are only 113 in the Luna tech, right? So we needed to do something. How to convince senior management? Well, these guys, we are a technology company, right? So I think it's in our base DNA to think this in. And then, you know, hopefully there are persuasive people like Casper and myself, principal engineers, lead engineers, who, you know, phrase and show the value. And it is measurable, you know, to a heightened efficiency. Thank you. Thank you so much. I think unfortunately, we are out of time, but we will be here or if you've been thrown out just outside the door and just come talk to us. So thank you for coming.