Perfect. Welcome to the Asos Tech podcast, where we're going to be sharing what it's like to work at an online destination for fashion loving 20 somethings around the world. You may have bought some clothes from us, but have you ever wondered what happens behind the screens? Hi, I'm Lewis. He him. And I'm a principal software engineer at Asos. In this episode of the Asus Tech podcast, we're talking about service templates. It's something that I'm really excited about. I think it's going to have a real big impact to Asos, and hopefully a lot of people find it interesting. So we've got a number of engineers here today from Asos Tech that have all been involved in the service template projects have been working on, so I'm going to get them to introduce themselves. So first over to Chris.

Hi, I'm Chris Newark. My pronouns are he, him. I'm a principal software engineer here at Asos. I have been here for just over ten years now, and I predominantly work with our payments domain. I think a kind of side interest of mine at Asos is very much on developer experience, which is what we're trying to improve and solve with service templates.

Hi, I'm Steph Sheeha. I'm a lead software engineer in the stock and fulfillment platform, and I've been at Asos for two and a half years.

Hi, I'm Tim Heehim. I'm a lead software engineer at Asos, and I've been at Asos for about five years now, and I work within the PayTech domain.

Hi, I'm Tristan. My pronouns are hee him. I have been a senior software engineer at Asos for one and a half years now. My team domains is about pricing, which mainly focus on making the prices available to the customers.

Awesome. Thanks, everyone, for introducing yourselves. So we like to normally do an Icebreaker on the Asus Tech podcast just to get people relaxed. They get to maybe know a bit more about you. Today's Icebreaker is going to be what's your favorite place in the world and why? So it could be anywhere you've visited, somewhere you've lived. So I will kick it off and I think for me, somewhere that I visited 1015 years ago, which is a Yosemite National Park in California. Beautiful, beautiful place if you haven't been. Lots of natural beauty, like crystal clear water, massive sequoia redwood trees, which I thought were amazing. I think it just made me feel very peaceful and relaxed. So one day I want to go back there, so that's me. Who wants to go next?

So I think my favorite place I've been to about ten years ago, I did something called the Mongol Rally. So it involved driving a beaten up Nissan Micro all the way from here, England, to Mongolia, Ulampatar, and the tail end of that was about seven days driving through Outer Mongolia in just complete nothingness. And yeah, it was incredible.

Did it?

My two brothers, lots of fun, lots of craziness. But yeah, it was amazing.

That sounds awesome. And that could be a whole podcast episode in itself.

I'm sure we really shouldn't have let Tim go first.

Oh, no, mine's definitely crapped compared to that.

I did the North Coast 500, my brother, about a year or so ago in a little catering seven.

Oh, lovely.

That was fantastic. But that sounds amazing. Your trip to Mongolia. Wow. Okay.

Tristan I've been always loving to be near the seaside, enjoy the sunshine and be playing around in the beach. And so I think the place I have the most interesting experience from my hometown, we very close to a beautiful beach. That's the place that I enjoyed most.

And where is that? Tristan.

It's in Vietnam.

What's the town called?

Von Tao. Yeah.

Okay.

Quite hard to pronounce it.

Yeah. Great, thanks. Okay, Steph.

Yeah. This is a difficult one for me, so I've been to a few places and, you know, experiencing culture and different food, but I think my favorite place is probably Hong Kong. I've got some family there, so I think that's always going to be really special to me.

Awesome. Yeah. Never made it to Hong Kong. Would love to go there one day.

Chris so, for me, I think it was fairly easy one. I went to Costa Rica on my honeymoon and it was the best couple of weeks I ever had. So much wildlife, so much to see. We traveled around a whole bunch of places. We managed to spot all four types of monkey that are native to Costa Rica as well. Desperate to go back at some point soon, but I'm actually going to Yosemite in a couple of weeks time. Lewis so maybe that might pip the post and become my new favorite place.

Yeah. Fantastic. Cool. Thanks, everyone. So today we're talking about service templates, so I'll first hand over link to Chris to give us a bit of an explanation about what they are.

Sure. So I think to talk about why we're doing service templates and what they are, it's probably worth talking a little bit about where Asos has been in their tech journey. It's probably fairly familiar to a lot of organizations out there. We did a typical process, moving from a monolith to microservices, and alongside doing that, one of the things that we embraced was team autonomy and allowing teams to pick the right tooling and processes for the software they're building because they know best about what's needed for what they're producing. And one of the outcomes of that is even though we had general guidelines in place and some preferred technologies at Asos, the services that we were ultimately building were fairly similar, but we were starting to see fragmentation and slightly different ways of solving similar problems. To try and address that, we've been looking at building service templates. And service templates are best described as kind of having three main parts to them. Those three parts are what we refer to as the chassis chassis is solving runtime problems and they'll often be non functional things that teams care about in their services. This might be authentication, telemetry, health checks, security hardening, that sort of thing. It's stuff that's really important to their services, but is not necessarily the main thing they want to focus on. The second part is the service template itself. So this is the thing that can scaffold a new service for a team. It will scaffold your entry point, wire up the chassis that we've just talked about, and give you additional things that your service might need such as build pipelines and deployment pipelines. Let's use the Net Templating engine to do that. But other people might be more familiar with Yeoman which is a very popular JavaScript engine for scaffolding code bases and services. And then the third part of service templates is automation that we put around it. So Templating is great on its own, but we want to make sure there's a really good developer experience that comes with it. So we put in place a bunch of automation to make it really easy to get started with a new service. To do that, we actually make use of Backstage, which is something that we've had up and running at Asos for a while. And they have some really useful features there that helps out.

Backstage is like an engineering portal, right? That you can add a lot of your own plugins. And I think the Templating is a feature, it provides out the box. You can run your own templates for services, right?

Yeah, exactly. The Heaven module software templates, which is perfect for this. It allows us to create a nice user interface around the process so engineers aren't having to pull together scripts and run command lines to scaffold this service.

Great. And I guess what kind of kicked all this off really? How did it all start and what were the first steps that you went down to kind of try and get this running and implement this?

So I think we started pretty small. We knew this was going to be a big problem, so we wanted to keep it focused on solving one thing at a time. We started off with focusing on just one type of service that we build at Asos Web APIs, and specifically even Net Web APIs because that's a common language used to build backend services Asos. And we focused on aggregating knowledge from engineers that were already here, from services that we've already built and trying to bring them together into a single template. So we really started off with just that template that can scaffold a new service with best practices that we've already developed and then just look to build on it from there by including as many engineers in the process. As we could and also try and understand where we don't want to go too far and step on the toes of engineers and teams and the problems they're trying to solve.

And I guess what's the experience like of executing the template?

We started quite early with the service template and using it and quite often when you need to spin up an API, there is a lot of this scaffolding you have to do and pulling in various different libraries, whether that's telemetry compression, making sure you've got the right headers. So having all that dealt with worked really well for us, relatively small team and saved time. So to get started, it meant that we could just spin it up and it goes off. Creates the repo in GitHub, and then from there, fairly quickly, actually, once you've kind of covered off some of the basics in that new repo PR, Policy Branch protection, that kind of thing. You can actually just start writing the implementation. Which was a big win for us.

We talked about the service template scaffold, zero project. What other things did you get out the service template?

It gave us a build, test, publish, DevOps pipeline. So straight away we could build the actual solution in DevOps which we use for our CI CD and then from there, yeah, it would publish a container which actually that's another thing it gives you. It also provides a docker file so it's ready to go from that point of view as well. So it's another thing you don't have to build.

So once you've got that container, then you can potentially deploy that somewhere as well.

Yep.

At this point it has an AKS pipeline built in, so when you create it, you've got the build, test, publish pipeline and then from there it also deploys to AKS, which is kind of fast becoming or actually is our preferred compute option now in Asos.

And I think that's something that we definitely evolved over time. When this first started, what you got out the box was much more limited and we've just been adding more and more over time. So the deployment pipeline is something that has come on more recently and part of the automation is that it will create the pipelines for you. And we've always had this kind of initial goal for service templates, the North Star, which is we want teams to be able to put in the simplest bit of detail about their service, kick off the automation and then within a short period of time it is running in the cluster ready for them to start testing and adding to we're almost at that point now.

Yeah.

As Tim said, teams can just get on with solving their business problems straight away and not having to worry about all this extra stuff around the edges.

What were the other design goals that discussed in the early stages?

So I think the primary design goals were to one, we wanted to build things that teams actually needed and used, so we didn't want to put in any additional functionality or code config that the majority of teams would not care about. We didn't want the first thing that teams did was to open up their repository and then delete a load of redundant code that they don't want. So that was a very important thing from the beginning, which relied heavily on us talking to engineering teams and getting feedback from them. We wanted to build it like a product for our engineering teams and part of that is building something that they want to use. It's often difficult in large organizations to roll out any new technology or approach. So it was really important for us that we built something that the teams loved and it really benefited them alongside the functionality. In choosing very selectively what goes into the service template, it was really important for us to have really good documentation so engineers didn't have to constantly come and ask us how to use this thing. And we wanted to also be really responsive and receptive to changes and feedback so we would take on board feedback from engineering teams. But it was really important to allow teams to contribute back as well. We wanted to run our service templates as an inner source project within Asos. Part of that was making sure we were also very responsive so if teams were raising issues or pull requests or feature requests that we quickly responded to them and made them realise that this was something to help them, not hinder them and not get in their way.

Great. And steph, Tim, Tristan, your engineers have been using the service templates and also contributing. What was your initial thoughts when you first heard about it?

I think for us, we're in the process of migrating our services across from cloud service to AKS, and the more recent project is one of our APIs, which deals with sort of reservations and allocations of stock. We had an old solution on cloud service, on net framework. We took that as a really good opportunity to actually go this template's available, we're going to give it a go, we're going to see what works for us, what doesn't work for us. And I think just off the bat, really some of our other projects that we did build and deploy on one pipeline. So I think that caused some confusion off the bat, like how do these pipelines work? And actually once we realized that they were split across two different pipelines, that kind of made sense. It was just a change of how we worked with some of our original projects that we've got. And because in our platform we had our own templates built up so switching over to something like an Asos core template was different. But I think it's the right approach because if we've got our own templates within our own platform, there's always got to be someone within the platform that's got to have the time to maintain it. Whereas this way we've got a whole Asos tech team really behind it, it's.

Worth calling out as well. That Steph said many platforms already had their own templates in place, but again, there was still fragmentation at that platform level. Each platform would have a slightly different way of solving similar problems. So this has been a really good opportunity to unify some of these templates and hopefully bring a lot of revaluable consistency across the services that will be based on these templates.

So really, it sounds like we're trying to bring all the best practices. Maybe what we feel is the best way, which is debatable, isn't it? But the best way of doing things and maybe the most common way across asos pulling that all into a central place that was really easy for teams to get access to, benefit from, and to follow that same approach. So we get some consistency as well across teams, but also trying to learn from each other, I guess, as well, right? Because we've got a lot of engineering teams at Asos. Some maybe have more expertise in areas than others, and vice versa. So I guess trying to bring all the expert knowledge that we have into a single place that everyone can benefit from sounds like one of the key benefits as well.

Check out the Azos Tech blog for more content from our Azos Tech talent and a lot more insights into what goes on behind the screens at Asostech. Search Medium for the Azostech blog, or go to Asos Tech for more. As I've mentioned, we want this project to be run as an inner source project. We don't have a dedicated engineering team behind maintaining our service templates, nor do we think that that would necessarily be the best way to do it. Oftentimes, if you are a central team building something like this, you're not experiencing the problems that your users are having, users being the engineering teams. So it's really important that a lot of the contributions and feature requests is coming from our engineering teams who are delivering value to our customers every day. As such, we heavily rely on contributors who raise pull requests and work with the small maintaining team to improve the templates. Tristan, for example, brought in a whole brand new template. We'd started with the Web API, we moved on to work service, and the maintaining team would not have been able to do that on their own. It was something that Tristan was able to do with others at Asos to solve a problem that was specific for his team.

Tristan, how did that come about and what made you decide to create a new template based on what we've done with the Web API template? Yes.

So for my team, it was quite an exciting journey and thanks to the support from Chris and Lewis. So regarding the contribution, pretty much a step by step process for my team. So my motivation started from a great tech develop session presented by Chris about six months ago regarding how to become a service template maintainer. That's where I learned about the purpose of the service template and the potential benefits that I can offer to my team. Soon after them, I came back to my team and then convinced the team that this service template should be the way to go when the problems that we have experienced, like we didn't really have the capacity to maintain some of the libraries that we developed for our own team. Mostly non functional, and we had to do a lot of reinventing. The wheel, for example, the AKS deployment pipeline. In order to convince the team to use service template, I also had to combine the service template initiative with my team main goals. So my team were in the process of migrating all of our services from service fabric to AKS and there was lots of boilerplate code along the way. So that's where I tried to convince the team to let me invest the time and effort on the service template.

So I guess this kind of maybe came around at the right time for your team where you had a big piece of work to deliver. Did it allow you to just kickstart and get quickly moved over to AKS? I guess you had to learn new technology kubernetes we're talking about here. So probably a lot of new things for the team to learn at the same time.

Yes. So back when to the time that we started migrating our services to AKS, we came across a lot of problems that already solved by different teams and some of the problems, we have to figure them out by ourselves. And then when I learned about the service template, I realized that all of those problems, most of them have been solved out of the box worse.

So just allowing you to kind of focus more on delivering business features, improving the products that you own as a team, not having to worry about, like you said, common problems, I guess, that many other teams already solved.

Yes.

Great. And so yeah, at Asos, we have a number of common libraries that we share across teams for a lot of these cross cutting concerns and non functional requirements. So, yeah, the service template brings those in together, I guess to allow you to kind of discover those as well.

Just those alone, to be honest. Saves so much time having them all wired up, ready to go. Even things like authentication, headers, compression, all the packages are there that do the hard work.

So we had these service templates with build deployment pipelines. They would scaffold your project, we would launch them from backstage. So we kind of had like a one click deployment, really, that would scaffold a new project, put it into a GitHub repo and give you build and deployment pipelines. Where are we at now after that? Where have we got to?

So we are now considering ourselves our first stable version, there was a reasonably long process of back and forth with the engineering teams. Things were changing quite quickly, which meant that we wanted to make sure that teams that were using this service template knew what they were getting involved with. They were involved with a pre release process. There may be changes happening to these templates quicker than we would normally like. So we feel like for our Web API template, we've hit that stable version and we're now more comfortable that we're not going to be making drastic breaking changes to the template going forward. So what that allows us to do when we have a stable version is dealing with a second problem that is common to service templates, which is template drift. Anyone who has built a template before to scaffold any form of service will often know the common problem, which is you create a service based on your template at one point in the year and then three months later when you're coming to create a new one, you might have added new features to your template, changed how things work, and all of a sudden, you've got two services that were built from the same template, but now look quite different because of how that template has evolved over time. We wanted to try and solve that problem too, so that we weren't just helping engineering teams right at the beginning of a project where they're scaffolding a new service, but we're also helping them by pushing out improvements to their template over time and making sure that we're maintaining this consistency across the services that's really adding value. So we built some automation which controls our upgrade process. Because we're running the template project like it's a product, it means that we're managing versions and controlling what changes are coming into the template and what cadence. And then we can push out these changes to individual services via a fairly simple pull request system on a particular cadence. Might be monthly. We will push out a pull request to each service based on the service template to give them changes to the service template and keep them up to date.

So, yeah, how did you find this upgrade process?

Yeah, I think we found it quite difficult purely because I think we were like, we were one of the very, very early adopters of the service templates and throughout that time things had changed quite a lot. So I think one of the main parts that caused us some grief around our pipelines, we'd already set up our pipelines based on the original templates, which I think if I remember publish was in a separate pipeline. So we had build and test in one, publish on a second one, and deployment on a third one, something like that. And I think in the process of all of that, we'd actually tidied up the pipelines and made it sort of work for us. And the upgrade looked great when we actually got through the PR, worked out what had changed, but we did have to make some tweaks to our pipelines to make it work. I think there were a lot of common variables added in, so things like Azure Container registry, AKS variables that we hadn't set in our original templates and were introduced as part of the new ones. So there were just some little configuration pieces we had to do. But I think because this was the first ever update PR we've got, I think that was probably where the big changes came in. I think if we sort of did the PRS on more of a monthly basis, things wouldn't move on so much and teams wouldn't end up with a really big PR that they had to go through, work out what changed.

Yeah, no, it totally makes sense. I think in software engineering we're always trying to look at doing frequent small amounts of change, right. Lots of little small things is generally good. You don't want big huge PRS, but when you are, iterating on something new. I guess there's potential for a lot of things to change as you learn.

And I think that the initial pain that st teams had from changes to service template, we learned a lot from, and it has changed how we build and distribute some of the functionality within the template. For example, way back at the beginning, we thought it would be a good idea to distribute some of the runtime functionality that was part of the chassis. We would distribute that as source code for teams. And quite quickly from feedback from teams, we realized that was a very bad idea and there's a reason why packages and NuGet packages exist. So we pushed all of that functionality into a package and we did the same for our pipeline templates. Basically, as much as possible, we wanted functionality to be behind a versioned package so that hopefully in the future, the upgrades that we're pushing out to teams these PRS are just bumping version numbers on template files or on mugat packages or on a net tool. So that is something that we learned really rapidly and I think has drastically improved how we build our templates now.

Yeah, sounds like a good lesson learned there.

I was going to say we did.

Go in the payment space. We went really earlier on the template just because of timings, really. We had a use case for it and we wanted to get going. So we had a version that still had those protected files and we just took the hit. We knew there'd be changes and we knew we'd have to kind of manage that first upgrade through. So in the end, which I think is a bit of a testament to the newer version of the template now we just copied across the implementation, so we spun up two new repos, copied across the code, dropped the old ones. Once we are then on that major version, the last upgrade that came through was actually quite seamless. So I think now, as Chris said, we're on that major version, the changes are much more manageable.

Yeah, makes sense.

The idea of fully documenting our templates as well extends into this upgrade process. So it's really important that the pull requests that we are sending to teams have lots of great information on them and point teams towards documentation for what has changed. We want it to become very simple and easy and just pick, approve and merge it. But we don't want it to become a mindless process. We want to make sure that teams understand what is changing in their service, what new functionality they can take advantage of and not have this template be a black box to them.

Great. And I think another thing that was great about the upgrade pull request that we send out is that we started to call out contributors by name, what bug fixes they've sold or what new features they've added. I think that was really great.

Yep.

Steph, Tim and Tristan are all on the latest upgrades.

Yes, they are top contributors. Definitely keep that going. So we talked about this upgrade process. How do you find contributing back? Was there any issues with it?

I think the biggest shift for us as a team is when you kind of come across something in the template that maybe doesn't quite fit is you have to try and validate. Is that unique to your team or have you found something that would be beneficial to the wider community? And then that's normally a conversation with Chris or yourself. Lewis and then if it sounds like something useful, you raise it in as a GitHub issue. You fill out some detail on kind of what you found and how maybe you go about fixing it and try get a consensus amongst maintainers but also just wider users of the template, see if it would be of use and then you can go on and make the change yourself. Raise a PR and get it merged. And I think that part has been really quick actually. I was surprised initially when we were starting to use it. You'd think that'd be quite a long process, but I think sometimes we were getting changes in kind of same day from finding them to being able to raise the PR, to merge it and then move on, which was I think a real positive when you're trying to commit to people, it's definitely the way forward.

Yeah, it makes sense. So I guess how do we balance allowing teams to put in their own specific requirements but also have these standard cross cutting concerns in the template?

I think it allows a lot of flexibility, test execution for instance. You can decide at what point you want to maybe set up some extra variables or run a few extra steps. Not everything we do is pushed. Back into the template but at least there's hooks and things like that that you can plug into as a team and carry out the more bespoke elements.

So yeah, allowing you to execute your own specific custom steps in pipelines maybe or figuring the code. I guess we maybe have to make this quite configurable.

Yeah, I think nearly everything is even going all the way back to the core packages. So whether that's telemetry and changing the sampling settings, extra headers you need to add that kind of thing, it's all there in config so you're not completely locked in on how things work.

I think it's important that we make things configurable purely because certain teams might not want all of the built in packages and I think maybe some of the initial service templates forced you to use packages that you didn't really want or you didn't want to use. It was locked in a way that you couldn't make any changes to it. So for example, like API documentation, it was locked to the default setup. You couldn't define version twos and version threes on it. But no, I think the process has been pretty good. We've got a good group of maintainers who are willing to listen to what's not working within the teams and trying to find a way forwards with it so that we're not introducing breaking changes for other teams. It's about sort of moving forwards in a way of making something that is then configurable for all teams and it doesn't then affect other team services as well.

I think that does also call out what the maintainers are there for. So the maintainers are not experts in every single aspect of building services at Asos. What we are trying to do as a maintaining group is control the process of contribution and not much more. So as steph alluded to there, we want to make sure that we're bringing in things that aren't breaking, changes that are things that can be opted out of and that's the expertise that we're bringing to this. In no way are we trying to say this is the one way to do this thing and this is the right way because we've said so. Half the time we don't even know. We have to go and find the experts within Asos to talk to them and say what is the best way to implement something like this?

Awesome. So with all the changes going in regularly from contributions outside the maintainer, group improvements and bug fixes, how do we communicate that to engineers within Asos tech and how do we make sure that people are aware of what's going on?

Yeah, sure. So we have a monthly sharing session that's run by the Maintainers Group for service templates, and it's open to all engineering teams at Asos. And it's just an opportunity for them to find out what's changing, what we're discussing what might be coming up and is there to make sure that the engineering teams aren't surprised by what is changing within their services and they're not surprised by what might appear in the next upgrade. And hopefully it's an opportunity to foster the community around service templates and get more people involved, more contributors, more maintainers, and generally just make the service templates better.

Yeah, sounds good. So when we're building anything Asus, I think one of the things that we really try to focus on is measuring what we're doing. Did we think about that when we were building service templates? About how we could see if it was successful? How do we know if we're actually doing the right things?

Yeah, so the main measures of success for service templates at the moment are around adoption. How many teams are choosing to use this? As I said, we're not mandating this on teams. We're not forcing them to use it. We want them to choose to use it because it's better for them and it's valuable. So we are keeping track of the number of teams who are onboarding onto our service templates. And also we are reporting on how quickly teams are merging in any upgrades that we push out. If we're pushing out these upgrade PRS to all these services and they're sitting there getting stale for weeks, it's a sign that we're doing something wrong, the upgrade is too difficult or that it's not valuable. So we are keeping track of a number of metrics like this to make sure that we're still adding value and that we're heading in the right direction.

Yeah, that sounds great. So it sounds like the service templates have kind of started to stabilize, at least for the Web API template. Where is it going next? What kind of things are we looking at adding and what's the direction?

I think a couple of things for me. So when we took on and used this template, what we were missing was a provisioning pipeline. In the end, we've added our own into our service. However, it would be good to see that be a part of the central pipeline, just so we've got like a standardized, consistent way across all of Asos on how we do that. And I know we're also using Net Seven, so we're not far off from Net Eight general availability. So that would be good to see how that upgrade goes with using this template.

Yeah, Donna is a great shout because we're hoping that's the perfect example of how template can solve boring problems for our teams. When a new version of Net comes out, all of our engineering teams have to go and put something on their backlog to upgrade their services. Hopefully we can do this upgrade in one place, push out the change to all of our services, and teams can just click approve after a cursory glance for the PR and they're not having to go through much effort. Bit of dumb.

I think the big thing for me that I'm really keen on is trying to get monitoring alerting in there. It is something we have to do on every service we spin up. So Web API, worker service, there's a standard set of alerts and dashboards we normally have to go off and create. Certainly brilliant if that's one less thing as a team we have to build every time. I think Utopia is really you can create it from backstage and then get started with your implementation and not have to worry about all these other things on the periphery that they are just a time sync for the team really, whether that's deployment pipelines or creating alerts. I think also ongoing on the upgrades is things like security vulnerabilities that come up quite often in various different packages.

Are we looking at things like dependable.

Maybe for that literally in version 1.4 coming out next week?

So I think along with adding more features and flavors into the service templates, we should also try to gather more feedback from the team. Like we try to understand the possible pushbacks for the team when they try to adopt the service template or some reasons like just doesn't fit their current workflow or it doesn't provide the features that they need or just simply because they're not confident in how to use.

Yeah, definitely.

Yeah. To Tristan's point there on going to teams that aren't adopting the service template, it is going to be really important in the future because all the work that we do on service templates and the benefits it brings is basically amplified by every new service that adopts it. So we really want to go on a process of talking to as many platforms as we can, find out why they're perhaps not using it right now. Is it because they just haven't had the opportunity or because it doesn't work for them and really listening to them and feeding that back in so that hopefully we can get really good penetration across our services and just get massive benefits from the work that's going on on Templates 100%.

Think what's been quite unique in all our scenarios is that we're using a template for a fresh project. And I think what would also be interesting to see in the future is how do we get teams who already got running services, stable services, how would we get them to migrate over to using a service template?

I believe that's something that a few teams have done.

Yes, but it's very early stage, it's a really good point. It's something that we need to put effort in to make much easier for teams and without it, it might take literally years to get some services onto the service templates because you might have to wait for their eventual replatform cycle. So yeah, it's something that we definitely want to get better at.

Fantastic now, I guess for people listening to the podcast that work for Asos and maybe they've heard of service templates. Maybe they've never heard of this kind of concept before. What have we learned that we could maybe share with them about if they wanted to try and start this in their own companies or projects?

I think the main piece of advice for me would be to treat these service templates like a product within your organization and your engineering teams are your customers for it. You probably won't get very far if you try and dictate to teams how their services should work and forcing them to use your standardized approach. So it's going to be really important to talk to your teams, understand their needs, build your service based on their requirements, don't build in features and functionality that aren't valuable to the majority of teams, and just take a gradual process. It's going to take time to work out what's right, what's not right, processes that work and the processes that don't work.

As you said, Chris, it's really important, I think, to start small and try and get some people using the template as early as possible. I think it was really useful to start getting people using it and then that kind of it grows from there and you get more maintainers more people using it, and the feature set grows with it as well.

I think that's it. I think it's when you create a service template, you have to have an engineering team try it out individually. We'd all have ideas on how we'd want a service template to look like, and that probably go into different directions. So I think until you get an engineering team to actually try it out, see what works, see what doesn't work, I think that's been where it's worked out for us, especially when we've now got more and more teams getting involved. We can then see what works for one team, it doesn't work for a different team. How do we make this configurable?

Has it actually ended up with people kind of getting to know the colleagues that they didn't normally work with and kind of improving relationships between engineers to think as well?

I think it's helped within our team, especially some of the mid level associate engineers who may be quite focused on just the team. It gets them talking to other teams, other engineers, other principal engineers in completely different domains, because if you've come across an issue, you'll raise it on GitHub and there'll be some discussion that follows, and then it's normally that engineer gets to actually solve the problem as well. So I think it's really helped, hopefully.

Maybe learning from each other and kind of seeing how other teams do things as well, which is always surprising sometimes, how different teams can work.

Yes, I found that this initiative really helps encourage the sharing and learning culture across the teams.

Thanks everyone, for your time today to talk about the service templates project and the benefits we've found and how you've contributed to that project. It was really great to hear about all the learnings that we've had along the way and hopefully people listening can actually learn a bit about this kind of initiative and maybe try this out on their own companies or their own software projects. Yeah. Thanks, everyone, for your time.

Great, thanks.

Thank you.

Join us next time for more stories and insights from behind the screens at Asos Tech.