 Hello everyone and welcome to the showcases and deep dive section and we're in the sysops channel Showcases and deep dives brought to us by just after midnight and doghouse. So thanks. Thanks team for your support But today we're with Chris Croucher and Dave Ganley talking about driving sustainable change with Drupal And I'll hand over to you guys to take it away from here Great, thanks Dave Good to see everyone. Thanks for thanks for joining our talk if you've chosen picked us out of the five. That's great. Good choice. I hope So my name's The co-founder and CEO of a company called just after midnight We're a 24-7 support and managed cloud partner to brands and government organizations and their Digital agencies and and I am joined by one of our very close digital agency partners Dave Ganley Who is technical director at the works and we're partners and collaborate on a number of clients and Today we we're going to talk you through a couple of stories. So This is really a short talk spoken through the lens of a couple of customers that we share And both of them are Driving significant change in their organizations changing their thinking around how they solve problems and making use of Interesting technology to be more useful and connect data in the new organizations and achieve better outcomes both of them Handily rely on Drupal for scaling their content operations is a key part of their stack which we like So I'm just going to Talk you a little bit through our thinking and with both of these customers and why we picked them to talk about today They're both united by a couple of things really Both of them required new digital platforms That's why we ended up talking to them together the works in fact were engaged by them first to talk to them And then we came into the picture not long after And both of them needed new digital platforms that were going to enable this change agenda Both of them also share the fact that the platforms that they intended to launch a business critical They both have audiences which are significant audiences in fact, which are using the platforms Outside of normal business hours. So they are considered Always on platforms and increasingly so as they evolve and enrich those platforms over time Which they'll continue to do into the future And in both cases when we engage we've assessed their needs as Many of you will do with your own customers if you're working with them you're your own internal teams And we've obviously considered how we can help them reach their goals and work through the challenges that they have in order for us to get them there We quite like to look at customer needs through various lenses to really understand The priorities of the customer and any gaps that they've got In various areas and one of them one of the ways in which we can do that And when we in our business and cloud often look at things is through things like the AWS Well-Architected framework, which some of you might be familiar with It's quite an accessible framework and it's really for planning and assessing cloud-based application workloads For those of you that are unfamiliar with it, it's essentially a collection of best practices For designing and operating cloud-based workloads that It's published by AWS, but actually really you can use the framework to Assess any kind of cloud Workload regardless as a provider So in both of these customers what we found is they both shared significant gaps In the areas of operational excellence So the operations side of running these digital platforms, which often is neglected And also reliability So let's turn first I guess to our first story Looking at that operations pillar Through that lens And that that customer is containers for change In Australia we go through somewhere in the region of 10 billion drink containers each year Which is just mind-boggling given the population And containers for change is actually a brand that operates two schemes In Australia, there's two successful container deposit schemes in Australia that operate both in Queensland And also in Western Australia And the organization hopes More widely in other states too. There are other similar schemes that already operate in other states So there is this competition in the market And the contracts to operate the schemes are tended by the state governments and they come with some pretty robust service level arrangements Upon the companies that are managing the schemes and the people behind containers for change in Queensland and WA Just one of those organizations So customers if you're not familiar typically deposit individuals like people like you and me deposit containers via Industry partners of the scheme managers who are often local organizations charities community groups And commercial organizations who operate in local sub our local suburbs In order that you can drop your containers depots bag drops vending machines pop-ups And get paid or donate the money to charity And to give the big picture From a digital perspective the containers for change delivery model is actually quite complex And the model for the whole scheme is quite complex And there are many organizations that come together in the scheme That need to interface in order to achieve the outcomes that are intended by running the scheme in the first place And these diagrams just give you a kind of picture of a couple of different journeys This second one is really just one of many business processes in this case one that enables Small organizations to sign up as an operator and operate container refund points And as a result of having these complex business processes, of course, those of us in digital can see lots of opportunity And that's what this client is trying to this customer is trying to realize And in part putting Drupal at the centre of that as well So organizationally as you can imagine Digital is really the central enabler for many of these goals here The organizations that are operating under these schemes and the wider waste management community are under a lot of pressure To become more digitally mature And frankly they have to compete with each other and they have to compete for contracts to operate these schemes as well So many of them including Containers for change are all focused on getting people to refund points Growing the number of those that are available for people to go and deposit containers Enable people to really easily get cash or donate to charities that Are offering to recycle these materials and pass them to the organization for recycling And empower local organizations change makers schools, for example a good example of local organizations And then recruit and operate with industry partners So lots of different use cases lots of different organizational goals All of which digital has quite a big role in connecting lots of data lots of silos lots of applications And that's where this customer is at the moment Organizationally When we met this client for the first time and understood their brief You know their brief to us really was look we operate in an environment where we have very robust slas imposed on us by the Through willing the contracts to operate these schemes in each state um They have a long term agenda to change but they are like many organizations still if you like behind the curve Technology change is slow They still have those silos and separate applications and some in some cases. They still have some Quite siloed ways of traditional ways of working that don't lend themselves to a rapidly changing environment um They also have in this particular case a lack of Internal digital experience in particular around things like cloud delivery And of course their customers Don't just work in in fact many of them work during business hours and we'll do the They're recycling for example at the weekend. We'll try and find a container refund point on a sunday afternoon When these services need to be up, but the customer is not at work So they've got a kind of an availability challenge So what we represented with there's a brief by the client that said that these key capabilities were really critical So um the works needed to deliver a new modern for a customer facing website first and foremost um one that um provides a unified platform for both states Um to operate within um a site that initially will integrate with some existing third party platforms They currently for example have oracle portal in place, which um essentially operates to manage some of those business processes I spoke about a moment ago Um not great from a UX perspective to be quite honest and so The longer term intent was to involve The the Drupal plant the Drupal based modern customer facing website once built Um to start bringing in some of the capabilities and functionality that currently sit with an oracle portal and then phase the portal Um and make the Drupal site the uh the front of house and the place where many of those processes are sat Um an interface to APIs uh inside the business Um the two priorities I'm going to focus on here really um were about ensuring the platform is cost-effective But highly available as some of you will know if you ever get asked by customers or your internal organization Make it highly available. I don't want any downtime other than 100 availability Um those those words often fall just before Um and here is the very small budget to do it Um and that was not entirely uh dissimilar to the situation Here we had a we had some budget constraints, but we also need to put in a platform that was highly available Um with that there were some quite tough 24 seven um requirements as well um and requirements to provide critical instant support That go beyond um you know just your sort of Have a developer by the bed um scenario if you like Um The measures of success were fairly clear There was quite a few criteria laid out but these were the obvious ones um had to meet 99.95 Availability target and that was at an application level not just at the hosting level which you know you often see Um people hope that their website will stay up just because the hosting is up but the application itself has to not fail to that degree too Um client satisfaction scoring um including web experience scoring needed to be over 70 on the um net promoter scoring Which is pretty damn high um and also other measures were put in place things like performance um website performance scoring so assessing Um response time of the website and translating that into something called Apex scoring Um to continually measure how satisfied users are in the performance and speed of the platform Um so initially when thinking about that first operational concern which was really about the current platforms We've got to have decent 24-7 support Um whoever managed the hosting we found was going to need to support the infrastructure 24-7 of course which is pretty normal most managed service providers do that But this customer given the availability targets on the application wanted the app supported to that level too And I guess this was the moment where Dave um and the team at the works had to have a bit of a robust conversation with the client Say hey look we're a great agency we're really into our UX and our Drupal and our technical capability Um but we like many agencies don't you know we don't offer a 24-7 support operation that is anything more than developer with a phone by the bed Um and that wasn't enough for this customer so it's one of those scenarios where you've got a customer that just needs to be able to Have confidence that all full stack of issues are going to be dealt with in or out of hours Um they had an integration with Oracle which we the works we're integrating with which does have 24-7 product support It doesn't have custom support on their implementation of it so there were some gaps there Um and equally they didn't have themselves in their organization a unified incident management service desk For for this kind of multi-stack environment where we've got various technology sitting in place Um so that was something that we needed to consider and look at how we provide that and that was one of the reasons that um The works came and talked to just after midnight as well Um concern too of course was the agency won't be available out of hours typically other than leaning on Dave and his team's goodwill Um which probably not going to be good enough and I think Dave's here to sigh of relief when um The client agreed to pay for some proper support Yeah, they must be paying on silent now Yep um the um the key requirement here was to be able to remediate uh application issues roll back if necessary even Um at two o'clock in the morning if there was an outage or simply report to the client that there was a priority one outage Or functional issue because one of their apis that they managed had gone down so providing support for things We collectively were not necessarily responsible for delivering Uh which was an interesting and uh challenging concept Of course first and foremost um prior to extensively planning out the support model was In knowing that we need to provide something quite comprehensive We in particular the works spent a lot of time um thinking about the design of the reliability of the platform There's no point just designing anything you like and hoping the support will deal with any problems We wanted to start out on the basis that we design out any potential for incidents to happen Knowing that some could but trying to eliminate um the obvious So we built something that um you know met the client's budget but gave as much reliability and flexibility to respond to changing customer needs as possible So AWS you know a trusted choice obviously flexibility for us to scale the architecture from what is currently a partially multi-region solution to what will become a fully highly available architecture over time Um we did look at uh or rather the works did also look at with with the client uh platforms like our queer pantheon some other managed platforms In this case they were ruled out because of the custom nature of the support requirements and also because the customer wanted the flexibility to Own their own solution later on migrate out of it potentially um and build out other workloads in the same account And also some basic things like being able to control their own maintenance windows which can be harder to do on some managed platforms And depending on what you're paying them what you're buying A containerized approach was used in this case some of you that are familiar with those logos will know that um that's um the Amazon EKS logo So we're using Kubernetes along with Argo and the reasons for those things are I guess for many of you self-explanatory Self-healing properties of a containerized solution ease of deployment near zero or zero downtime for deployments In particular because this customer now had a large um and committed backlog where there would be regular releases and there still are Um from the support perspective wanted real ease of rollbacks so our team in support are onboarded and able if necessary Um albeit last resort to perform a rollback without the development team available to us at the time and they can touch on how we do that in a second Um and actually one of the nice things is that the customer themselves is now convinced enough that they are beginning to adopt containerization for other apps in other programs of work that we're not engaged with So we've given them quite a bit of confidence there Um the heart of the solution from a support and operations perspective was really the principle that the client should never have to call to raise an incident if there is a support issue We wanted to be first to the punch every time Um so in partnering with the works what we really did was look at two dimensions Um how on the left hand side if you like is the things that send signals that tell us that something might be wrong Um and that isn't just a human being who phones up and says hey I can't use the CMS today Um something's not working in fact we'd rather know until be telling them before they wrap phone us It's about monitoring the entire stack and setting up your alerting properly so you can see for those of you that are familiar with some of those platforms A list of essentially tools that we're using to monitor various different metrics on the solution all the way through the stack from infrastructure up to the application layer Um to continually identify whether this thing is healthy or not Um and where we can spot the train coming down the track before it hits the car Um and if the train's hit the car deal with it Um and on the right hand side it's really a if you like a little laundry list of things that we we did and we would typically do in setting up a proper support operation Um establishing run books run books are a living breathing if you like document that you maintain for your support teams Both those that are involved in communicating and managing incidents but also those technical people who are helping resolve them Um they're informed by the development team and the customers and stakeholders Um to make sure that there is clear communications and escalation process that everyone knows what to do on a Sunday afternoon at 3 o'clock when there's no one else available Um things like training um prior to launch are important and also ongoing updates as and when Significantly enough features are released that there's a change to the application that would dictate that the support team needs to understand something more than they do about the application or the infrastructure already Um and then looking at how incidents are communicated um having things like service status service status pages for stakeholders that need to know um what the status is if they think there's an issue Um and providing a data flow out of the support operation through reporting back to the stakeholders to say hey this incident happened yesterday this is why it happened This is how it was dealt with this is what um the root cause of it um and here is some information if you like for your developers to go problem manage and and remediate so it doesn't happen again Um and we find you know in particular containers of change have really valued that um and it has built a tremendous we've built a tremendous amount of trust with them because when we have um had fortunately the only occasional Um incident most of which are related to um third party services that they currently control and so unfortunately will be phased out at some point we've been able to respond quickly but also Provide ongoing communication through an incident so everyone understands where things are um and then provide useful information to resolve it and prevent future incidents from happening Um so building that sort of confidence and trust in the solution has been really valuable through using um thinking about that operations and support side Um how do we do it better than I guess a normal managed service provider might do um or their own internal team could have done um we knew that we had And the works knew they had to choose a solution where it wasn't the phone by the bed scenario um we knew we had to do better around monitoring than just you know the customer Initially their their typical inclination was it'll be an AWS we can run a few monitors on the infrastructure and everything will be cool Um given the whole stack we really wanted to monitor right the way to the top we want to monitor what's going on application level as well so that we know if customer experience is impacted Not just whether the servers are up or down or a database service is available to us or not so having me with alerting um looking at metrics that drive customer satisfaction was quite important So one of the things we do is real user monitoring and so looking at across all pages of the site what's the performance like um what our users actually getting a decent experience when they're visiting the site If not why not report on that so that they those little bugs if you like can be squashed quickly um and then making sure on the right hand side we're operationally ready Um one of the things we do really regularly with Dave's team at the works um is business hours to out of hours agency and support handoffs So when there's a flurry of activity there's quite a lot of change that happens on this platform regularly um we're doing handoffs between our teams when when relevant not for every day Um if there's an incident in play or if there's major changes that happening um the teams have short punchy handoffs um to make sure there's good knowledge shared between those teams And that's that's really been invaluable for time I think I'm going to wrap up there and we'll move to story two um which really focuses a little bit more on the reliability and technology lens rather than thinking about operational support Um so some of you may have heard of an organization called Goodman Fielder some of some Goodman Fielder are um about 45 owners of about 45 food brands across Asia Pacific Part of a big multinational called Wilmar Hope Headquartered in Singapore multinational foods and shipping business basically and there's probably a few brands that you'll recognize here these are the Aussie ones Um these brands are the first six to move onto the new platform that the works have implemented and Jam manages the cloud hosting for and provides app support around And this is not going to surprise anyone it's quite traditional use of Drupal um managing marketing websites um which is easy right Um so their their kind of solution goals if you like are pretty obvious um if many of you've worked with organizations like this you will know Their needs are fairly simple um but can be they can be challenging particularly when you've got a very non-technical marketer audience So supporting campaigns across you know all their brands and all their geographies is number one um making sure everything is super easy to use um by infrequent users and Giving them a solution that would enable them to get into new markets or launch new brands really quickly um we'll touch on the challenges in a moment and why that's important Um the fourth one is probably the number one actually the most important point um in that um what we found when we started working with um Goodmans was Like many clients they've been out buying everything and implementing lots of things in different ways in different parts of the business Um they've got a big cupboard full of skeletons um they had about six cms's that we uncovered um in the organization and that's the ones we found Uh all with their own sites their own hosting that they're paying for and so they want to consolidate that down to one platform um but multi-site Um one of the challenges in working with an organization like this also is that they operate on a kind of brand by brand budget approach Each region each each country um even down to Australia and New Zealand of course um has their own budgets their own constraints they often put budget in pots per brand Um so that was a bit of a constraint so when thinking about you know what's it going to cost to launch that new bread brand in New Zealand They want to know how much is the hosting going to cost just for that bit um there isn't an idea of a central funding model um it's distributed and it's putting money in the pot So how's that going to work and how are we going to make it cost effective um they themselves as an organization were starting their own cloud migration journey Bringing things from traditional infrastructure to cloud but they were quite limited in their own skills in their own IT teams So we're looking really to the works to provide cloud capability as well as um the capability around UX and content platform delivery Um and they not dissimilar to containers for change they were very scarred by some previous challenges they've had with uptime and reliability on their platforms Um in many cases unnecessarily um but um you know mud sticks once you've had some issues with downtime there's a lot of nervousness in the organization and they certainly had that They've had some issues where you know lots of money has been spent on marketing campaigns driving traffic to sites which have subsequently fallen over that money has been wasted Um so clearly they were looking for that not to happen again um so that was a really important point I'll just hand over to Dave now and maybe Dave you can just talk us through just the kind of capabilities that um the works needed to deliver and to solve their challenge So the client wanted a single CMS for the implementation uh and they came back and said oh and it cannot be WordPress So whichever one she'll call that um and that's partly because a lot of their current implementations are WordPress to the degree where some of the individual sites are actually on two or three WordPress instances We're all subdomained out um so yeah Drupal was obviously the logical choice for them um due to the nature of their business they're obviously you know rolling out new campaigns which require new features Um and those those features have to obviously you know be available to all brands so the more brands we add the more you know features we're rolling out across those Um they're going to be adding new brands all the time um and ultimately if we have one CMS um it's a you know a single a single source to maintain Um especially as the number of brands grow uh they wanted uh obviously high availability like everyone else uh but it comes with down to money Um and obviously the more more brands they're putting in there the higher the risk of the being downtime Um and then they just wanted you know the the out of our support the you know the critical instance stuff um which you know we were engaged jam to do Same very very similar technical solution to containers for change it's on Kubernetes uh using Argo um tools for deployment and workflows and build So we um from an architecture point of view we chose again we chose AWS of course in this particular case could have been Agia frankly um that Client in this case was performing some wider migration to AWS there was a preference to go there so they can bring it all under one roof later Um the containerized approach obviously really was very much about um self healing um solution where possible again quick deployments zero downtime Easy rollbacks um and um just being able to push features out super fast particularly given that um you know that we've got a lot Potentially you know if there are 45 brands end up in it which might be a bit of a dream for now but and that's hopefully where it will go somewhere similar Um giving them that kind of cost effectiveness there's going to be a lot of stakeholders who are going to want probably minor changes made but that's a lot of changes when you Look 45 sites um so having a solution that we can push those changes out just routinely super fast super fast cadence continuously is what we were looking for And uh also scaling containers um on a per brand basis um we all know it happens you know someone so on runs a marketing sort of push delivers a whole load of traffic um And you know the the sites will auto scale uh to take on that demand without without affecting the other ones That's right So um we opted for a singular code base for maintainability but not a Drupal multi site um solution they're all per instance um we use the the other challenge we had was um And the brief was oh look it's it's one theme it's got one set of features you know there's going to be products there's going to be uh recipes there's going to be articles And of course as soon as you start digging in there you go oh actually they're all different colors to start with and they all have different logos And you know this has got a range of products whereas this has just got products so we ended up with these um I suppose drift from the ideal of one theme One set of features so everything's managed um using config splits on a sort of feature set basis um and that's all triggered um you know from the Manifests up so that we can specify um environmental variables and they obviously then change the configurations um we've got a theme switching uh on a per brand basis Like because they are different colors they have different logos and we realized there's obviously there's a lot of repetition um so we use um customized to build our Manifests on a per brand basis due to the similarities between them but it also means that um if we need to take a single site ahead for for some reason when we don't want to do a sort of Across brand rollout we can do that because we can just adjust a single manifest and then it will you know auto deploy that um yes Some features go out all in one go but there's our on a staggered approach and so we use our go as our basis for um all of our sort of DevOps tools Um I don't know if many people have explored it but it's you know definitely worth looking at um and because there's a use there's a UI to it as well Um for the likes of jam they can log in and easily do a rollback um on a sort of known working state where it doesn't need any it doesn't need a technical person to do it So it can be done by by a producer or a product manager Yeah excellent that's good so we'll just wrap up there we'll drop a couple of the I guess our final takeaways um so just picking up that kind of Operational excellent piece first I guess the takeaways that we leave you with um three three points of view um one you know we don't think you can fake it when it comes to SLAs When when you are presented with a um either an internal or an external customer um that talks to you in the in the terms of containers for change Speaks to us which we're really around you know tell us about your SLAs what's your support operation look like we were never going to get away or the agency was never going to get away with saying Don't worry Mr Customer there'll be a dev available at the weekend and David just switches mobile on and of course Dave would never have turned all the alerts off that I get really annoying pesky Um but you know that we know that's what will happen so we encourage anyone thinking about addressing a customer where these are challenges to think about the scenarios for potential incidents Put yourself in the shoes of getting that call on Friday night at 10 o'clock from the customer who has finally spotted their sites been down for three hours and they've got a big campaign or And something going on that day where we know what are you actually going to be thinking who are you going to want at your disposal to be able to just jump in and solve what is currently an unknown problem And communicate with the customer as well to let them know and give them confidence someone's dealing with it Um the second thing I guess is that um a lot of people in our line of work ask us you know what are you going to do if there's a code problem in the middle of the night The truth is you should be engineering reliability in and it is very rare for a support team to need to fix code issues in the middle of the night Um those level of issues tend to manifest themselves generally not always but generally not long after deployment if not immediately Um and so many of the issues that need to be dealt with at an incident level not an underlying problem but an incident level Um can be dealt with by people who have been well briefed and are working off comprehensive and useful information and have been trained on the technical solution But that equally do not have to be the and that is possible and and that's that's something to consider but of course engineering for reliability in the first place So that the only scenarios really are initially are about containing the incident and recovery until you can get the the surgeons the developers on it if you like only business hours Uh is a better way of thinking we think um and lastly um considering more than just basic reactive monitoring I think a lot of organizations tend to have this illusion that Um if they've bought into a management platform uh or just a hosting solution the hosting providers on the hook for the 24 7 support And in many cases what we see is customers who have been burned there because their solutions fallen over and the customer at some point gets told by their internal team or the supplier Well the servers agree into everything's good but their application is still down So when you've got this kind of complex stack it may be that you really think about application supports and also um more and more intensive monitoring than just is it up It's a server green uh is the application responding um thinking more about monitoring those layers Leveraging data that comes from those tools getting ahead of incidents preempting them before they happen so you don't have to incident manage You're actually incident preventing Um and then back to that reliability pillar and actually a little bit of operations here as well um they've just dropped a couple of um recommendations in here too Yeah so um you know the nature of containers means you've got a very known environment um it works locally as well as you know on stage in on production Um I keep telling clients it's like uh having a laptop you can take it to any room uh and work on it and it's still the same laptop Um and it also means that you know it's a very scalable thing because we can we can bring up a lot more containers and very quickly should we need to meet the demands of high traffic Um I think that the actual sort of the delivery system for deployments is a really important area You know don't rely on pushing manifests manually um for things like Kubernetes you know use a user system um the Argo CD system you know if a manifest failing it doesn't get deployed Um but it also means that it's really easy for um non-technical people to do to log into UI and do a rollback to a point in time Um and then you know the container solution is always beneficial in terms of you know cost you can have the scaling element to it Um you can also you know in a UAT cluster you need to make you know additional namespaces to do some testing of new features that you don't want to you know implement a UAT namespace It's easy to do and you don't you don't have to bring on more resources for it so there's a lot more flexibility in there and you know things things that we all like to try you know the canary releases and stuff like that It's a lot easier to do Yep great staff well thank you for listening and just have a little look in the Q&A and just see if we've got any questions there Um just have a little look so we've got a question from Andrew Chapel um probably one for you Dave um do you deploy the same container you use locally to the production platform Uh not locally no there's a slight difference in there that the builds manifest the same in terms of the ducker files um but we use Lando for local development um so yes but no Right good stuff um okay let's just see what else we've got here Okay another question here oh yeah okay what level of involvement is um required from the client's IT team in implementing a solution like this that's a good question Uh clients um yeah uh in both these two examples uh the client's responsibility basically stopped at IT team stopped at uh DNS level changes and one of them actually even just said we'll move our DNS to uh to jam and you can do that the whole lot so uh so very little um which is good um because we can we can move a lot quicker um and obviously they approve the overall uh architecture of the um the setups but um they tend to stay pretty hands off and I'm not sure if that's because they are containerized solutions and there's um it feels like a lot of people ITD teams are still catching up on that Yeah there's a um certainly in one of these customer scenarios there's a skills gap um which uh is is an issue but so there's a there's a tremendous I mean in containers for change um as a result of seeing the value in this solution they are you know more convinced than ever in terms of a technical leadership perspective that containerization is um something that they need to um be doing and to them they're now beginning their journey along that path and I think that's um it's obvious for many organizations but a lot's still stuck in the past and haven't quite got there yet and the value we've obviously big advocates for it uh last question um was uh how much downtime have you had since launch I will happily answer that um from the point of view of the infrastructure and the application the infrastructure that we manage in the in the in the application that the works built zero um downtime which is awesome um there has been um a small amount of um availability um issues um caused by uh performance issues rather should I say not so much availability caused by integrations with some third party legacy services uh API is basically that uh the platform for containers have changed in that case depends on and um the good news is that we we actually monitor the endpoints for those APIs even though they're not ours to to look after um the reason we monitor them is just we don't provide any remediation because we have no access to those third party platforms but we do the comms with the client to let them know that their customer experience is impacted and um that we've reported the incident because we can act on their customers behalf and report the incident to the provider log a ticket with them and track that through and until the incident is solved which has added quite a lot of value so that their own uh resources don't have to do that particularly in out of our scenarios um and um I think that's the end of the questions um so thank you anything else from uh anyone before we wrap up