 My name is Mike Lewis, and I am the tech lead for Backstage at Spotify. I've been at Spotify for a while now, but the first few years I wasn't working on Backstage, but I used it all the time, and I saw the huge positive impact that it has on our engineering organization firsthand. With that in mind, it's so gratifying to now be a part of the group working to share those benefits with more people. There have been a ton of changes under the hood in Backstage over the years. I want to talk to you today about some of those changes, why we think they're important, and what's coming next. So there's a few categories that improvements to Backstage tend to fit into. The first is sharing really great internal Backstage plugins. We really believe in the value of proving new tools internally, and then sharing the benefits with others. Of course we do. This attitude that led us to open source Backstage in the first place. We do this regularly at the level of plugins too, so this applies to most of the core features in Backstage as well as many of our commercial plugins. Along with sharing proven internal tools, we also sometimes start from scratch with brand new plugins. This happened, for example, with Spotify's RBAC plugin. The last category is kind of different from those first two. So along with building dedicated plugins, we also think a lot about how we can improve the framework itself. This type of change can be extremely powerful, so it can unlock entirely new classes of plugin or completely change the experience of owning a Backstage instance. So for example, before the permission system, there wasn't a good way to solve access control across Backstage. And this wasn't something that could be solved by an independent plugin. So we built the permission system. It introduces an extensible solution for access control, allowing adopters to select a decision-making strategy and plug it in. All right, one from scratch. So Spotify's RBAC plugin provides just one such strategy, and there are others out there. When we built the permission system, we hoped that other people would join in and build alternative strategies for the community to choose. And it's been super cool to see that come to fruition over the last year. I'm excited to meet and see again some of the folks working on these alternatives here at BackstageCon today. I want to move on and talk a bit now about declarative integration. So we've heard a bit about this today. I guess I'm just going to give you my take as well. So you might have heard about declarative integration from the Backstage maintainers over the last year and a bit about it earlier today. This new core system is motivated by a desire to reduce the overhead of owning a Backstage instance. It's a total cost of ownership. So today, in my view, a lot of that overhead comes from writing glue code to integrate plugins and plug-in modules together, which results in documentation pages like the one you can see on this slide, where it's like, add this line of code here, and then this line of code here, and this line of code here, and then your plug-ins all wired up. So just to be clear, the ability to write code against the Backstage instance is foundational. It unlocks so much customizability, and this isn't going anywhere. But the glue code that you can see on this slide, another glue code like it, is not the kind of targeted bespoke code that we want adopters to spend time writing. It's repetitive, and it's distracting. So we're getting rid of it. When you switch to the new back-end and front-end systems that use the declarative integration, plugins automatically stitch together with no glue code. This makes your Backstage code base smaller, and lets you focus on your actual customization code, which brings me to what's coming next. So declarative integration brings a huge improvement to the experience of owning a Backstage instance. But we at Spotify wanted to go further and provide an option that streamlines the adoption and ownership experience even more. We're calling it Spotify Portal for Backstage. So Spotify Portal for Backstage is a brand new way of running Backstage. It's a full-featured developer portal built and designed by Spotify. More opinionated, super streamlined, and with management and configuration built in, we think it's going to be a great option for new adopters who want to spend less time in the nuts and bolts of Backstage. We want you to see for yourself whether it's a good fit for you. So we'll be offering a free 30-day self-service trial to allow you to do just that. If you want to hear more about Portal, you can scan the QR code on the next slide to get an invitation to our roadmap webinar on April 30. Thanks very much for your time today. Thank you. Any questions for Mike? Thanks for the presentation. Just wondering about backwards compatibility of older plugins and the new plugin system. Is it seamless or...? So the new back-end and front-end systems are a new way of writing plugins and integrating them into the Backstage framework, which means that plug-in by plug-in, there is a migration required to support those new back-end and front-end systems and for them to be consumable in an app that's using those things. At an instance level, though, like adopters can take a plug-in that doesn't use a new back-end and front-end systems, back-end or front-end systems, and wrap them in a way that means they can be used. So there's never a way that you can't actually use them. It's just that the ease of adoption, the ease of integration bit, only comes when the plugin owner opts in and uses the new system. Does that make sense? Yep, it makes total sense. Thanks. Great question, by the way.