 So this session is around Autosleep. Autosleep is a new service, a new open source service that we have developed to automatically suspend inactive application after a given amount of idle duration and then it gets restarted automatically when there is incoming traffic. So let me introduce myself. I'm working at the range. For those that don't know, range is one of the largest telco operators in Europe, and in Africa. It's present in 24 markets with more than 240 million subscribers. And here is the Autosleep team. So I'm working as the product manager on this project, and Benjamin and Arnaud are the developers. They're going to be here today, so I'm representing the whole team. So let's start with why would Autosleep be interested to you? Why would you care? And maybe we can do a short poll on how much of you are not yet using Cloud Foundry? Pretty much. Just a few. Okay. Who are more on the service consumer side, so pushing apps and operating apps, okay. And so I assume the rest of you are operating Cloud Foundry. Keep your eyes, your hands raised if you're on-prem, okay, most of you, and public. Just a few. So Autosleep will help you save money, hopefully. And for those of you that operate public Cloud Foundry instances or private, you might as well do good for the planet and save some computing power and avoid getting the global warming worse. So let's detail that a little bit more. So we'll go through service consumers and service providers. So for service consumers, Autosleep can be deployed both on-prem, on private Cloud Foundry instances and public. So those application teams, they would get their application automatically stopped. So the total app duration for their app would be smaller. So they would have a smaller invoice at the end of the month, you would save cash. For platform providers, you'd be able to handle the same load, the same workload for your application teams, but with a smaller number of DA sales, adigo sales on DA. So you'd be able to shut down some DM and shut down the associated hypervase, so to save some RAM. And some service provider might be able to use this to provide some free or cheap deals, because it's more affordable. You need less computing power to run some applications. You might ask what kind of workload would that be suitable to run against Autosleep? So we think immediately about non-prod, but how much is non-prod? Is that very small proportion or is that large? It's hard to get precise figures on that. Fortunately, I tried, but I didn't find it that much, except a friend at Recreation that published their proportion. In their case, it's 44% non-prod. So you can think, especially in the early adoption phase of platform risk, that should be significant. So what's in non-prod? Maybe the yellow words and the tutorials that every newcomer comes in, they push the yellow words and they forget about stopping those apps. So this would obviously benefit from Autosleep. Hackathons and Spike, one-shot apps that you develop and you forget about stopping would be a good candidate. With actually in a range specific case, we need to ask some API stuff for a wide range of APIs just to discover the APIs and get some step response. So that was one motivation we had. Some other use cases include saving docs or tools, and obviously non-prod version of the apps we are deploying on Cloud Foundry would benefit from that. They don't need to be up all of the time, they could be started on demand when traffic comes in. Would that also fit some production workload? It's not yet clear, because there is still a penalty impact, latency impact when the app is waking up. Depending on the technology, the app might take some seconds to 30 seconds to start. So the production workload needs to be able to cope with that. Maybe some service brokers that could respond within 90 seconds could be legible, but maybe the community will find some example of production traffic that would be suitable. So how do you use Hotosleep to save RAM and to do good for the planet? Let's see that. So Hotosleep is exposed as a service broker so that it's discoverable in marketplace. And once an app is enrolled with Hotosleep, it would get stopped automatically upon inactivity and then waken up automatically when there is back some traffic. So this is the work in progress, I'll detail the status on that. And let's detail each of the points a bit. So for the exposition as a service broker, we need an app to be enrolled. So an app enrolled would be managed by the Hotosleep. So to enroll an app, we bind it to an Hotosleep service instance, basically. And there is different rule mode. The first is regular opt-in. So a user comes in, create a service instance in the space, and then bind its app to the service instance. But you might think if the user forget about stopping the app, would they think about binding to the Hotosleep to save RAM? So we also support auto-enrollment. So a second mode in which every application within the space would be automatically enrolled, and this would be make it noticeable by user because the application would be bound automatically to this Hotosleep service instance. They can still opt out. So to opt out, they can unbind from the service instance, meaning I don't want to go to sleep anymore, stop dealing with my app, or they could name the app against a regular expression exclusion pattern to escape from auto-enrollment. In some case, we want to prevent something to escape from Hotosleep. For example, in the case of free tiers or cheap tiers, we want to make it harder for them to consume more, but we still want them to be able to work effectively. So in this forced enrollment mode, they would be able to opt out, but only temporarily, only for a short amount of time. And then the app would be re-enrolled automatically. We have a dashboard to check the enrollment status and the idle duration. And then the app is stopped on an activity. So the activity is measured by the logs that the application produce, and the logs that the go-router produce for the app. So any traffic received from the app would keep the app active. CF events would as well contribute to the activity measured. So if you update an app environment variable, or you scale it, that's evidence that you have activity on your app. So the app is not considered inactive. And then the auto-waking app and sleeping app when incoming traffic comes in. So while the app is starting up, we currently return a 403 status code to the application. We'll see after that we have planned to improve that. So let's go with the demo. I don't really trust my ability to do a demo with jet lag. So I recorded the demo. You have to trust me that I draw the same way. Okay. So I have split my screen into four parts. On the upper left I have some simple application. I hope you are able to read. So active app, hello world and production no sleep. And I'm sending some traffic in a call loop every one second. And on the lower right, I will be deploying auto-sleep. So this is a regular Java application. So it's pushed using the Java build pack. It requires a cloud controller account with permission to act on the application in every space. And a MySQL database. So there's two parts in auto-sleep. The auto-wakeup and the auto-sleep broker. So this is a push for auto-wakeup. So nothing special around that. And then the push about the broker. And then we will define a wildcard route that will help us restart the application when there is traffic coming in. So we create a wildcard route for any of the domain to which the enrolled apps are mapped to. And we map this wildcard route to the auto-wakeup. So auto-wakeup app will receive any off-hand traffic sent to those routes. So when I stop that, should receive some traffic, the auto-wakeup would receive the traffic instead. So let's then expose this in the marketplace. So I'm deploying on the Pivotal Web Service public cloud boundaries using a space code. And now we have the auto-sleep appear in the marketplace. Cool. So we've seen how to deploy an auto-sleep. So let's now use it. So we'll create a service instance in this space. So that's the second space, a space where my app are deployed. And as arbitrary param to the auto-sleep create service instance, I'm passing the idle duration, how much time, the number of seconds. So the PT 20 seconds. After 20 seconds of inactivity, the app would go to sleep. An exclusion pattern and the enrollment mode. So let's start with standard. And let's ignore the secret for now. I should have removed that, actually. So, OK, it's refreshed on the upper left. So I see my auto-sleep service instance. And soon I should see two applications that would automatically be bound. Yeah. So Active App and Hello World are now bound. And production no-sleep was not bound because it's covered by the exclusion regular expression. OK. So what about stopping, sending some traffic? Or maybe we'll have a look at the dashboard before. Yeah. So let's have a look at the dashboard. So this plays a dashboard role, opened up in a web browser. So the dashboard will tell us which apps were unrolled. It reminds us of the idle duration configured that the user might not know. It might be an admin that created the auto-sleep service instance. So they can check the idle duration. They can check the exclusion pattern. And they can see those two apps being unrolled. And for troubleshooting purposes, they can check which last logs were collected and the last Cloud Foundry events associated to their apps. So basically checks that the activity measured for the app is consistent with what they expect. So let's stop the loop which is keeping the app up. So I'm not sending traffic anymore to Hello World. So I should see Hello World within 20 seconds stop. I have to mention, and in this case, this is a very simple app for the sake of this demo. It's the static build pack, so they are starting pretty quickly. We'll see that afterwards. So Hello World, has that stopped yet? Yeah, it's stopped now. Cool. And the dashboard reflects the same thing. So we'll do the same thing with ActiveApp. I'm stopping traffic for ActiveApp. An issue boost out. Yes, I can mention as well that we are still lacking authentication on the dashboard. So that's part of our backlog to authenticate the dashboard so that we don't leak sensitive information on it, including the logs. Could be an issue. Yeah, so ActiveApp is also stopped. Cool. So let's try to have those apps wake up. So let's send some traffic back again to Hello World. So it's going to take some seconds, one, two seconds, because it's a static build pack. It's just an engine X process. It's pretty quick. Yeah. So the auto wake up application with the traffic and started the Hello World app. Let's do the same thing with the ActiveApp. Yeah, it started again. Cool. Okay. So maybe we can have a look at the opt out. Let's try to opt out. Let's say this is getting in my way to do my work. I don't want Autosleep to manage any more ActiveApp. So I'm opting out. I'm unbinding. And if I stop sending some traffic for, okay, if I stop sending some traffic for this app, it will not start anymore. So yeah, the dashboard is reflecting that the app is excluded from it's not enrolled anymore. It's ignored. And it doesn't stop. Cool. So we've seen deployment for now, auto enrollment. I think we'll have a look at the first enrollment now. So what I'll do now is that I will unbind the rest of the apps and I will delete the service instance. And I will start with a fresh and new scenario. Okay. So it's unbinding the world. And deleting the service instance in sequence. And now we look at the first enrollment mode, which is typically for free or chiptures. So in this case, I'm only changing the enrollment mode and I'm passing that to first. And what I'm telling, I'm also providing a secret. This secret is used by the Autosleep. Typically in this use case, an admin would create the Autosleep service instance and the team using the space wouldn't have access to this secret. So that they are not able to switch back to standard enrollment mode. So we've seen that those two apps, ActiveApp was autobound. And I'm simulating the case where a team wants to escape from Autosleep. So they try to opt out. So they do opt out for a short period of time, but they automatically get re-enrolled after a short duration. So basically they cannot escape long from Autosleep. We need to leave them the ability to unbind because they might want legitimately to delete their app. If they want to delete their app, the CLI would unbind the service. So if we were to refuse the unbind, we would enable them to delete their app. So that's why we find this solution about letting them to temporarily unbind. If they try to delete the service instance, it tells that in forced enrollment mode, they cannot delete and they have to switch back to standard. To switch back to standard, you need to provide a secret. So if an admin doesn't want a team to go back to standard mode, it keeps a secret secret. So let's do that. The admin is switching back to standard enrollment mode by providing the secret. And now the team would be able to opt out and delete the service instance to delete the space, for example. If I'm lucky enough, I shouldn't have not mirrored my screen. Sorry about that. Okay. Cool. So that's about it for the demo. Let's switch back to slides. So what is also sleep? What component is it made of? Let's look at the architecture. So it's split into, as we've seen in the deployment, in two parts, the Autosleep core, which is exposing a service broker and a dashboard UI, and the wake-up proxy. By the way, the slides are on sked.org where you see the schedule, so you can have access to them right now if you want. And so when an admin creates a service instance, the Autosleep core is receiving the message and then using the platform API, it's scanning the apps into space, binding them automatically, then fetching dialogues to check activity, and after the idle duration, it would stop the app. Once an app is stopped, it doesn't receive traffic anymore, so the traffic that are directed to this route would go to the wildcard routes that we have configured and bound to the auto wake-up proxy. And so the auto wake-up proxy receives this off-end traffic from the GoRouter and would start the app. Once the app is started, it releases the request that was received. If there is other requests in between, we currently return a 503. In the future, we plan to buffer all this traffic so that there is less impact for the sleeping applications. And both are sharing states using MySQLDB. So originally, we were thinking, we were designing to use route services instead of wildcard proxy. You might have seen that in the session abstract. Unfortunately, we discovered a bit late that it's not feasible currently. The route services don't receive traffic when they are mapped to an app which is stopped. So there was discussion with Shannon, the PM of the routing project, to explain this. So if you do have some similar use case, please voice it to Shannon so that this can help prioritization to prioritize this support, which is not yet in the roadmap and might help some other use cases. There are quite a lot of advantages to go with route services instead of wildcard route. Maybe I can detail those a little more after if I get somewhere in time. So wildcard route is feasible for now. It's not idle, but at least it's working for now until we get this feature prioritized by the routing team. So what are potential future improvements we are thinking of? We do need to order the auto wake-up part so that it's able to scale to install it as a cluster. We'd like to queue traffic during restart so that it's very transparent to the clients. They would see a delay in response but they wouldn't see some extra 503 status, especially when you're setting API. They don't like really much to get some extra status. We'd like to work on high availability and load balancing for the service broker itself. I mentioned authentication to dashboard and checking permission. We are considering packaging as a Bosch release and a PCF time so that it can be used anywhere. We have some teams working considering PCF as well so that they're useful for them. What would be nice is to be able to have any application in any space and any org being automatically enrolled. Currently, an admin needs to create a service instance in each space so that would be a nice feature to have auto enrollment for any space and org within a Cloudflare instance. Another stuff might be to have more fine-grained policy for autosleep, such as excluding the business hours and potentially notifying users when the application is put to sleep with an email notification. So some learnings that we made during this project. So we find the service broker create, read, update, regular lifecycle is very powerful but sometimes respective in terms of user experience. We have to tweak a bit. You've seen the... to switch from standard to forced enrollment mode to switch with arbitrary time into the update. So that's kind of an awkward user experience. We are heavily relying on the CFJava client for this service. So there is an ongoing re-implementation using Reactive. It's great. Thanks for Ben Hell, our teams for this. It's really solid. It's been distracting for us because it's stretched over time in terms of a calendar. So we might have picked V1 if we had better visibility on the roadmap initially. But otherwise it's really a great effort and I know Benjamin has been contributing quite a while to it. And yes, I discovered bit late the constraints about reading service. So you know it now. In terms of suggestions, I made some suggestions for enhancement to the service broker API. So one first suggestion is to be able to propagate the identity of the caller. So if we were able to know that it's an admin that is requesting to delete a service instance, then we would grant this request. For our space manager, we would refuse. So both being able to propagate the request to identity and as well, its permission is OathCops. And maybe to have this requester delegate this permission so that we don't need a Cloud Fund Reaccount which has permission or hold space, but the user could delegate their permission for the other SIP to act on their behalf. So there is a proposal spec around this. I can have a look. Another proposal is to try to find a way so that it's easier to get custom UI for services. So one interesting idea that was suggested by Ben Laplange is the service broker actions. Basically to have the service broker in its catalog return some metadata, so describe some additional verbs that it would like to expose to users. So in this example, it's small to see maybe. There is a new actions declared by this broker set mode and the CLI would propose these actions to the users built in without deploying a custom plugin. Another way that we can provide custom UI for services is by providing a custom plugin, but this currently also requires users to install it. So maybe another suggestion could be that the CLI by interpreting some metadata into the catalog in this metadata, you would have the repository endpoint and the name of the plugin and it would automatically prompt the user into installing this custom plugin from the service so that the user doesn't have to follow the doc to find the right plugin. So in terms of user experience, it would be maybe more flexible because you can define some top commands in this context. Okay, so let's wrap up. So yes, this is a work in progress. This is open source. It's on GitHub. So please test it. Tell us what you think. Report some bugs. We had already a number of enhancement suggestions and feedback. If you have new ideas as well and ever best, if you have an ability to contribute to enhancement, it would be great. We hope as well that this could provide some inspiration for automating some tasks that platform providers can have and while keeping... providing some control for users to control this automation for exposing data to the service broker. So we didn't need to put the application to sleep. By exploding it as a service broker, we provided the ability to opt out and to configure the idle duration. So I think we have about maybe one minute if there is question, comments that you have. Okay, thank you very much. Thank you for your time.