 Simplifier Cloud Adoption process. And at the same time, accelerate our cloud development cycles for the developers who are building their capabilities on the cloud or were looking to build their capabilities on cloud. We'll also share some insights on how backstage helped us in reducing our workload time of the developers to build their capabilities on cloud and also talk about the unifying experience that the developers were able to get because of the implementations that we did on backstage for our specific use cases. So there are two stories that we want to speak about when it comes to cloud enablement. There were a lot of different pathways that the developers had to go through when they're looking to move to cloud within booking. And over time, when we were simplifying this process for the teams, we wanted to make it easier for teams to come to cloud, be it from whichever coding background you are, just make it simpler for teams to start using AWS or any other public cloud for that matter. And these are the two tales that we want to speak. So these were the two core narratives that we found with the adoption journey within booking. And this is where we want to bring some more teams around these two specific areas. So cloud enablement. So for context, I joined booking about close to two years ago as a senior technical program manager. And one of my key objectives was to modernize our cloud adoption process. At that time in booking, moving to cloud wasn't easy. We did not have an easy way to get into cloud. It was a heavy onboarding process. We had a lot of processes and frameworks to adhere to. And what that meant was that there were a lot of stakeholders that needed to be addressed. For a developer who's looking to build a service or who's looking to move his application from on-prem to a cloud-native service provider, they had to go through a lot of steps, a lot of regulations to address. And that wasn't that straightforward because of the multiple stakeholders that we had. Booking being a large travel industry company, we were also security first, which meant that there were a lot of rigorous security and compliance regulations. So if you had a new service or something new that came up in the industry from any cloud provider or a new way of doing things, it would need to go through a certain rigorous process of validation within booking.com by our internal teams before it gets opened up for every developer to basically use it. You can think of it from anything that AWS launches or any other cloud provider like GCP launches. If there's anything that needs to go in, it needs to go through our validation processes. We have security as our core pillar. And I guess when you're looking at cloud for that scale, you need those kind of validations as well in. And not to forget the data governance bits, like GDPR regulations. You'll have SOX compliance. So if you are moving something about customer information on the cloud, you need to be mindful of how that journey looks like. So these were some of those problems that we were observing. And also in booking, we had developer journeys. Like there were many different use cases. There would be proof of concepts. We are always evolving. We are looking to be the first in market. So we're building on capabilities that perhaps are not there in the industry. So the developers needed that avenue to build it. It could be proof of concepts. It were working in isolation. And those are not some things that you would get on cloud by default, at least in booking. You need to go through a certain set of frameworks to make sure that that's all enabled. And lastly, we had to scale up. We had to find a way where we could do the same level of rigorous process when we went from a few, few projects a month to more than 100 projects a month moving to AWS or GCP or any other cloud provider for that matter. So these were our few of the problems. We see a few forms around. We had a number. We had to remove it. But yeah, it was what it is. But before we talk about how Backstage helped us solve some of these problems, let's also discuss about how Backstage was being used at booking.com back then, about two years ago. Honor, do you want to do the honors? Yes. So hello, I'm Honor. I'm a software developer in booking. And I've been with booking for two years, I believe. We joined it roughly at the same time. So we jumped into the same problem, solving the same problem. So our problems in clouds, like Barat gave you some context of the scale or the things that we needed to solve. But how we solved it was a bit of a question, like what are we going to use? And then we realized that we actually have a Backstage in booking. Well, it's called something different than Backstage to start with. But a couple of things you might need to know about me before I continue. I'm really bad at keeping speaking notes. So I might off track, but I will try to keep it in the median. So I looked through our internal communications and meetings. So and I could track this back to 2021. I believe there was a meeting where we had a problem to solve in booking. And that problem, I believe, will be familiar to a lot of people in here. We had a bunch of tools lying around. In a bunch of places, they all had different UIs. They all had different user experiences. They were integrated because they were all working together. Yes. But from the user perspective, that's the key point here. From the user perspective, they were not. For a user, for anyone in our ecosystem to do something, they needed to visit a lot of tools, a lot of spaces to actually continue. And in that meeting, that problem was being discussed. And in that meeting, booking, being booking, we had our own toolings. We discussed to have something called SHIVA. And SHIVA was a reliability platform. And other stuff, but the two key points that I could extract from those notes was there were two requirements. First, Uniform UI and UX. And the second one is a plugin-based system to move forward. And you just fast forward a couple of meetings a month, maybe. And then you see that guy in the middle. By the way, that's how I imagine the open source community always having fun, having parties. So someone looked at the market, and so there's a backstage. There's this thing called backstage. And said, yeah, the two things align. It's Uniform UI and UX, if you build it right. And yeah, it has this plugin-based system. So why don't we use it? So this is, I believe, how the backstage was introduced in our ecosystem. But I'm looking at two people who know more than me here. I hope I'm right. But I can back this up with documents. So from here, when we joined, we had the backstage up and running. We had the service directory, our project management, and dependency management system in place, and implemented in backstage as well. And we had a bunch of other plugins that we had already available for us. But I also want to mention one thing that I would like to touch at the last slide as well. When I was preparing this presentation, I thought, OK, how we use backstage to solve these problems, right? What we did with it. But also, in our story, it is what we did to it as well. Because at this initial stage, it wasn't the backstage you know. We didn't have the software catalog and anything that comes with it. It was just the UI part, the app part. But we didn't have a backend that was supporting it. But this is, I believe, the resilience or the simplicity of backstage. It even works without having those core functionalities. At least it worked for us. And we had our way, I believe. I would like to mention that as well. So from that meeting onwards, we said, OK, we will be building plugins. We'll be extending the core functionalities we have. But there was a heavy emphasis on build your own, because we couldn't just get the open source plugins into it because of that lack of core functionalities. If you come back to our two tails, this is where we joined, where we jumped the ship. So there's a backstage. There is no software catalog. There's nothing to support it. But we do have our own search directory, which is a really nice tool we have in-house that's replaced, kind of, that provided the software catalog capabilities to us. And we had a bunch of plugins in there. So on the one hand, we were dealing with the onboarding and the golden path. So we were identifying the processes, what we want to do, what are the stakeholders, who we want to be working with us. But on the other hand, we knew from the start, like with the scale, you can't just identify processes and just leave them manual. You need to just make them built in your systems, in your own environments. So for that one, I don't know if you noticed, but I like drawing. Like these are from my own sketches. I like to sketch our own problems, the problems we face in our working environment. So these are just a couple of them. But for each one of them, we identify the process. Then we identify the stakeholder to work with. Like it can be security. It can be compliance. It can be deployments, whatever you can think about. Then let's say, OK, we want to solve this problem. But how to solve this problem? And then it was backstage. Like, OK, we have the core project. We extended it. We called it a cloud project. We created a new layer on top of it. And then we reached out to these stakeholders and said, hey, we want you to build plugins. Like, this is the best part of it. You can just extend our functionality. I don't want to go in there, or I don't want to get requirements from you and build on my own. You can just build it. And we will be composing these individual plugins or individual extensions in a narrative that we think will solve our problem. So this is the way we approached it. And right, it says, composition of well-defined and bounded tools. And I believe that's at the core of the backstage. And it really helped us in our journey. Oh, yeah. OK. And yeah, these are some showcases, right? By the way, these comic strips are not yet copyrighted, right? These can be taken if they want. So what we saw in those comics or on those themes were about some of the questions or some of the things that the developers had to go through. And our first iteration of what we build on backstage is screenshots of these we used to call them plugins. So what our intention behind this was how we can transfer, how we can translate the business requirements or the processes that a developer had to go through and transfer them or transform them into a process which is on backstage. And the teams can use it for their adoption journey, for their onboarding journey to cloud. So we had something called for self-service, which we used to call as build day one. What that meant was that the teams can come to the backstage portal. They could come on one of the widgets that you see here. And they could just click on one of the buttons and they will get an account provisioned. In parallel to that, the intention was that all the other steps and all the other journeys that they had to traverse, which would be security compliance. It would be around data governance. So all of those processes were translated into one or the other plugin on these screens. And the developer would have the flexibility to just provision the account. But once they got the account, they could in parallel own the process themselves and go and process those requests to the relevant stakeholders that were involved. So the problems that we were referring to in the beginning of having too many stakeholders, having a complicated process of adoption, while making sure that we were doing everything that we need to do to be at the industry standard level that we are, it needed a process where it would be empowering the developers to actually own that journey by themselves. So we also created a security narrative and a shared responsibility model for the teams. So once you get an account, once the developers were able to create the accounts, they could start or navigate through their journey to the other teams, which would be security compliance. What we did with Backstage was we also integrated this with something like ServiceNow. So the teams would be able to use Backstage to integrate their approvals and their process and journey to move to production and deploy their services on live systems using Backstage and then going through a specific plugin which would then integrate with ServiceNow. And then they would be able to navigate their entire journey using that flow without needing a dedicated team that would guide them through those journeys. These are some of the plugins that we have. Honor, I think you have a few more that you want to run us through. I have a few more. Like I actually had to cut down the list. But I believe the gist of it is what we're trying to say. Like these are cloud-raised problems, not specifically for Backstage. This is just, Backstage was the platform we sold for it. So I was also thinking, like, why not any other platform? Like, we could just build our own app. Like, just put a React or Angular there. Just plug in your own systems, your authentication, and people will be able to do this. So for that, I believe my question, my answer was the culture that came with it. Because like Backstage is out there. It's maintained by a lot of people. I believe some of them are here as well. It's just this sense of community. And we were able to replicate part of it in booking when we were talking about the Backstage. Because it just gives you the freedom, I would say, from planning. Because if you have something, if you think you can solve a problem, this ecosystem is really good for it. You can just start owning a plugin. Of course, there's preconditions to it. But if you can just fire your use case, you can just start building it. And from that, at every stage when we were building a plugin, and not just for Cloud, I believe for Backstage, we have a bunch of other more. Like, the last thing I can think of is what was it, insights, where someone just plugged in the tags from JIRA in Backstage for the things like, hey, help needed. Like, there's this core library. I want this functionality on there. If you follow the normal procedures, it takes a long time. But if you can just tag your JIRA, take it with a certain Backstage something, or we call it B Stage. We even changed the name. But if you can just tag it, it will be visible in the Backstage. And this just is one example of that freedom. Like, somebody solved a problem, and they wanted to solve it. And our approach to it, that replication of the sense of community actually allows us to build more and more. And every time, when I look at the results, they're just better than we initially thought, that's a trend, like, every time. I want to talk about the library, for example. That was like a huge problem for us, just because we had multiple documentation sources. I believe that's also common in our sector. We had docs.booking.com, which is like an in-house solution we have. We have wiki confluence. We have GitLab, readme files. We have Drive, for some reason. And then somebody at certain point said, hey, this is too much. I can't find anything I'm looking for. And then build search.booking.com on top of it. But the result is, when you search for cloud, for example, in our use case, it's just everything. Like, any sketch that somebody wrote that includes Cloud Word in it, any team that onboarded two years ago and had different processes to follow, everything altogether. So we created a workforce around this, saying, yeah, we will make documents better again. But that was search.booking.com, right? Like, that was the initial thing that sold us. Then this group came up with, hey, I will be the plug-in in the same environment. I will own the process from end to end. And I will just maintain a manual index, which sounds awful. Like, hey, no, don't do it. How are you going to maintain the manual index? But that solves the problem in a really simple manner. And if you keep track of the ownership of those entries, then you can send, on a cadence, hey, is this thing still up to date? And it was just like, yeah, they took that. They build it. It's a plug-in now. It's working. It's good. And it just solved the problem. So these kind of stuff we were missing, not we were missing, I think we would miss if we bought, for example, an off-the-shelf system that needed certain things in place that had certain ways of doing stuff. So backstage is just the flexibility, I guess, if that makes sense. OK. So to summarize, what we mentioned in the beginning, we had a problem to solve. We were looking at how we can leverage any tool for that matter to simplify our adoption requirements. And we had backstage with us. And what you saw on the previous slides with those plugins and those screenshots, we internally refer to it like a portal. And all of those plugins and all those screens were like an amalgamation of the actual cloud journey for a developer who needs to build their services on any of the cloud providers, and also not just build new services, but also migrate their existing workloads to an actual live production system. So by using the capabilities of the UI of backstage, just the UI at that point in time, we didn't have the software catalog and other capabilities. We were able to solve a very serious business problem for us, which was going on and on. So that gave us what it actually helped us with, that we were able to unify our user experience. We could get all the different stakeholders that were part of the cloud journey within booking to actually follow the approach that backstage does in terms of ensuring that everybody is working from a centralized place and making sure that we have one source of information. So those things helped us to ensure that there was a more wider acceptance of how we want to do this journey to cloud. And backstage was the first step for us to make sure that that worked. And from there, I think, we have bigger plans now. And Anna, you want to talk about them as well? This is the fun part. I believe this speaks to the resilience and simplicity of this idea. We used it without any of the core functionalities. But it did survive. It did prove value. And we want more. And for that, I believe this year and the coming years, we will be introducing the software catalog. As I said, tools that we build internally, they're also good, really good. So we don't want to replace them that often, because search directory works. And it does what it needs to do. But we will be, I believe, in the first phase, we'll introduce a shadow software catalog. So we will map everything we have to the format or the things that the backstage will accept in its core. And then from there, once we have the software catalog, we will have more at our disposal. Like, we will be able to use majority of the community-driven plugins. And we will be able to just absorb them in. Also, in the same sense, we will be introducing the software template. We have a huge bootstrap program running at the moment. Idea is basically like this, one of the core functionalities. We had a go at it at our own terms, in our own terms. So we have a rough idea what we want to do. But we will be also introducing that to backstage to serve our customers. And also, the search is really nice. We will be having the search as well. So in our story, this is the category of this case study. So we are talking about our own experience, like how we used it, how it helped us. But also, with its simplicity, it did survive us using it the way we did. Now we are going to use it in a proper manner. We will be introducing the core functionalities it needs to fully expand. That was a story. Thank you for listening. Thank you very much. Is there any questions for that? Before I take the question, can I just do one quick shoutout? So we have one person from our backstage team at booking. We were trying to get three people for the talk. We couldn't get the approvals in place. So a big shoutout to Simba, if you can just join us on the stage as well. And Gindra as well, please. We don't have one. We have two. Tim, picture. Yeah, I actually love your journey. My question is, though, in your ecosystem, because it seems kind of similar to our case, where you have multiple teams that provides through the backstage UI and the Backster Core functionality their own plugins. How you make sure that everything is according to the standard. So I mean the code quality and also UI slash UX quality. And what is your release model? So when you make a release of the whole backstage instance that you provide, how you make sure that all those plugins actually come in line with the proper way and proper manner, properly tested, and everything? Yeah, that's hard. So to start with, our motto was, automate everything you can. Because if you just leave it to the subjective interpretations, it's really hard. So we have for the basic linting and the code styles, we have a sonar instance somewhere. So for that stuff, we have the automation. But on the other hand, we have two stage approvals. So we say plugin owners own their own code. So they do their code reviews. They do their own repositories. No, we have a single repository. So we just have in the code owners, this folder belongs to these people. So after the initial approval, because in there, they will be testing their own functionality and we don't know about what their functionality is. As a second stage, we have what we call backstage reviewers at the moment. And those are, I believe, us reviewing in a more abstract level, hey, this is this in line. But the UX, you also asked about the UX. That's the hardest part, because that's really what we've seen as a trend was when you live at this outside of UX, everybody who wants to show something, everybody who has the data just starts building a plugin. So at the end, you have a bunch of plugins that are not really connected to each other. So now we have a new initiative called Engineering Portal. We are actually leveraging our time spent on this. So we have enough volume of plugins. Then we can just now, at this point, say, OK, we have this bunch. How does each plugin lands in the user journey? What are the user journeys to start with? So we have an initiative to align them. And at the end of that, one of the artifacts we want to have is the UX guidelines. So up until now, we didn't have it, which has pros and cons. It just enables more flexibility and gives more freedom, which I was always up for. But at a certain point, I believe if you have enough volume, then you can just look back, look at the examples, and continue on it. So following on that, so from your perspective and your experience, would you rather focus, if you would start again, would you rather focus again on allowing all the teams create the holds of their own plugin, or would you rather advise to create some plugins that can be used by multiple teams? So would you still go with the externalized development of plugins created by the specific teams? Or rather, would you like to create those functionalities for them inside of your own provided plugins as a platform owner? I would go as the way we did, enable people to build stuff. Because that's where you gain a lot. It's just different perspective, different opinions. But we did have one rule, I believe, if you build a plugin that should be used by the entirety of the company, you just don't get to build a plugin for your own. So anything you build, it should be usable by other people. Any other questions? Hi. From your perspective, when do you think we should start thinking about migrating to backstage? I mean, what size is suitable? I mean, do we need to, for example, have 100 microservices or 10 people of the team? Thanks. Like my own personal answer to that is at the time where people start complaining. Because how much is much? I've seen systems with 20, 25 components, I'm talking about the UX and system components were perfectly, and everybody was used to it. But again, in my own experience, you notice it because people start talking and start complaining. And at that point, I believe, making the change then also justifies itself. And it doesn't feel like a push. And I believe what we had when we had initial discussions, like people were complaining. And then we took action. No, I just wanted to add a little bit. As he said, we started with backstage because it was not only for the users. It was also for us that maintaining many different services in one company is also time consuming. And as a team, in the beginning, our team only had ownership over multiple services. We had multiple UIs that we needed to maintain. So that was the initial idea when we started thinking, what if we had all of them somewhere? Since all of these services, they are not by their own. They also communicate with each other. So that's when we thought about, hey, what if all our internal tools in our department, they can be at one place. It would be a lot easier for us to maintain. It would be a lot easier for users to find these tools because sometimes people, they don't know that there are some services that we have already in the company. And I think it was more organic in that sense. When we initially used backstage, it wasn't mandatory for anybody or nobody necessarily had to use it. So it was organic. Developers were just using it. And when we reached to a point where, for cloud adoption, for instance, we started using capabilities to highlight those processes, it kind of garnered a more unified response. Like, teams wanted to use backstage because it gave them a more developer-centric experience. And that's how it progressed for us. All right, guys, thank you very much. Thank you very much for the presentation. We'll go to the next one.