 Okay, so my name is Pradh Dut. I work for SAP Labs in Bangalore. And we'll be talking about auto sleep and how we can probably save a little bit of money using it. So this is a Cloud Foundry community project. We collaborate with Orange on this, Orange Labs. And so first version of it was already developed by Orange, which already supported a couple of use cases. Then we joined hands with them and we developed something more that we wanted to enhance it with. So yeah, let's just go ahead. So yeah, what does it do? What is this service? So it basically automatically puts in active apps that are running in your space to sleep. And it also wakes it up. There is also an auto wake up feature that allows you to wake it up as soon as it is being accessed. So how many of you here have seen this 2016 talk from Guillaume from Orange? He's there. So Guillaume from Orange is the one who developed the first version. So has anybody seen the first talk? Okay, so then I'll also include a quick recap of it. And yeah, we also have the source repository here if anybody wants to try it out. It also has instructions on how to install it and use it. Okay, so the target users, who are we developing it for? So at the end of the day, we have to save resources. So platform operators, org managers, even space developers can use this, install it in their own respective custom spaces and then bind the service to their apps. It comes with a service broker of its own and use it to bring down apps that are inactive. We'll just see how it works. So it's not only about the space developers, also application developers. For example, if you are in a current situation where you do not have much memory or CPU available and you want to work with a lot of apps, then you could probably bring down a couple of apps and bring up a couple of them which are more active that you're actively working on basically on them. So please stop me in case there is any question at any point in time. Okay, so what are the features? So this slide talks about the features that were already there in the first version. So it already has a service broker. How do you create a service instance? You basically do a CF create service auto-sleep. Default is the name of the plan that is inbuilt and give the instance name. If you do this, then it already comes with a predefined set of default values for the configuration that you see below. For example, there is something called an idle duration. There is something called exclude from auto-enrollment. Then there is something called an auto-enrollment and the secret. So what is idle duration? Which is more or less the important part here. So you can configure a service instance to bring down apps that have been idle for the last 24 hours. So that's the default timeout. So which means if you create a service instance, all the apps that are bound to the service instance will be brought down if they are inactive for 24 hours. You can of course provide an idle duration that is more or less than 20 for us. I'll include into the demo. Then exclude from auto-enrollment. You can use patterns to exclude say apps that you do not want to be enrolled into auto-sleep. For example, you have an app called sales order app and you can just put a pattern there called sales order star or something like that, which will ensure that this app is not monitored by auto-sleep. Then auto-enrollment standard and force we support to variance. I'll come to that as to how. And we have a secret that works along with the forced version of auto-enrollment. I'll also show you what it is about. Okay, so let's do a quick demo of how it works. Okay, so I'll just create an org. So what I'm going to do is I'm going to create an org, create a space, and I'm going to have some apps in that space. So let's create some space because without a space we cannot really push an app. So I have a demo auto-sleep org. I have a space called dev. Oh, it's dev, okay. That's weird. Let's delete that. Okay, so let's also target that. And what I'm going to do is I'm going to just push an app into this space because I want to monitor that app and I want to see how auto-sleep works without the app. So I'll just quickly push a simple Chinese app. All it does is pushes out Chinese characters. Why I'm using it is because it's very easy to push. It takes only a couple of seconds for it to get loaded so I can do a demo with it. Okay, so what I've done is I've created an org, I've created a space called dev, and I have pushed an app called simple dev to this particular space. Now what I'm going to do is I'm going to use auto-sleep to monitor this app and I'm going to see whether I can bring it down or not. So now let's, using the service broker of auto-sleep, which of course should not be there right now because, it's already there, it's enabled for all orgs, great. So if you look at this, CFCS auto-sleep default, sleep one is the name of the service instance that I have, and I have provided an idle duration of 30 seconds. If I don't provide an idle duration by default, it'll be 24 hours and our demo will go on for a day. We don't want that. So I've provided an idle duration of 30 seconds. What it means is auto-sleep will monitor this app and will bring down any app that has been idle for the last 30 seconds. So I did that, so I have a service instance called sleep one that I've just now created using the service broker. Now what it'll internally do is it'll monitor all apps that are there in this particular space. The service instance monitors all apps that are there in this space and bind itself to them. So if you look at bound apps now, you see that the simple dev app has already been bound to this particular service instance. Now what next auto-sleep will do is it is going to start monitoring this particular app for any activity. So what we have said is please bring down any app that is inactive for the last 30 seconds. So which means the simple dev app that we have pushed has actually been inactive for the last 30 seconds, so it has been stopped. So now what happened was auto-sleep actually looks at all the logs that are there for this particular app. It also looks at events for those apps. So when we deploy auto-sleep into its own org, we configure auto-sleep with a user, with a cloud controller admin scope. This user has the right to poll for the logs of all apps that are bound to it. Basically it can poll for all the apps that are there in the cloud front instance. It also looks at the events of that particular app and if there is any kind of inactivity, which means there are basically no logs, no events, nothing, which means this app is not being used by anybody and it will just bring it down, which it did. Now of course what a developer can do is that he can obviously go unbind the auto-sleep service instance from this particular app and then start work because at a certain level it is irritating for him. So I as a space developer or an org manager would just go and create a service instance. My developer would just come, delete the service instance and continue to work. So which means it doesn't serve the purpose. So that is where the forced auto-enrollment feature comes into play, that is this. So now if I create a service instance with forced, what happens is you cannot really delete this particular service instance. So quickly going to that. So what I'll do is I'll unbind this. Unbind this and I will also delete this service instance because I'm going to create a new one. Yeah and what I'll also do is I'll bring up the app which has been brought down by auto-sleep anyways. So now I do not have any more service, yeah please. The idle duration is also the polling time. So which means if I have configured the idle duration is 30 seconds, auto-sleep will poll the data for this app from the Cloud Controller or from the LogGator for every 30 seconds. So you obviously in a, sorry? It will also poll. Yes. It will also poll. So if I push now along with the simple dev, another simple test or something like that, it will also bind itself to that particular app and also start monitoring that. So of course in a production environment you wouldn't have the inactivity period as 30 seconds. You will probably have it as 12 hours or 24 hours or something like that. So yeah, okay. So now let's create a service instance with auto-enrollment as forced. Now when I create a service instance of with auto-enrollment as forced, I also have to pass a secret which was there in the slide. So this secret is a mandatory parameter that we have to pass with forced. So if you pass the secret as with, sorry, the secret along with the forced auto-enrollment, what it'll do is it'll create another service instance which is different from the one that we created before because a developer cannot really delete this particular service instance until he gives the secret along with it. So which means a forced service instance cannot be deleted until he knows the secret and all developers would know it only the person who's created this service instance would actually know it. So now for example, if I go there, of course it'll bind itself and it'll also stop the app. Now the beauty here is if I do a CF, say unbind and I do a sleep one and I do a, it'll actually throw me an error. So it's no where I can run away from auto-sleep anymore. So if the app is inactive for the idle duration amount of time, it will be monitored and it will be put down to sleep. So no developer can actually override this feature, this behavior anymore. Now how do I get rid of it? Now of course there might be situations where I need to delete the service instance because I would want to also delete the space and the orgs along with it. So in that case the only way to do is is to update the service instance to standard by providing the secret. So I'm going to convert this forced service instance to a standard service instance and then I'm going to delete it. No, because he wouldn't know the secret. The secret is going to be known only to the person who's created the service instance, not to anybody else, exactly. So if I have created the service instance only I will know the secret by which I can update the service instance. Okay, so this behavior is already there in the autosleep service instance from the first version so we haven't yet reached org enrollment. So now what we wanted was, we wanted to enhance this with another feature called org enrollment. So which means, so currently with this feature said we are very, very dependent on developers or space developers to actually create service instances on their own, bind it to their apps and then help save the amount of money that we want to, but it ain't happening because no developer is going to do that. I mean we all know developers are lazy. So what is the problem that we're trying to solve with org enrollment? So yeah, so we have a problem that org manages to their face, which means so developers of course consume resources relentlessly. So if I give you 10 gigabyte of space you will push 10 apps and use all of it. I mean no matter whether an app is actually running or app is actually used it will continue to run forever. This is what we see in a lot of Cloud Foundry platforms. Of course all platform operators like SAP and others face this problem anyways and we tend to consume a lot of money on that. So we need a way by which we can curb this usage of resources and send those resources to apps that really need them. Another use case that we have basically in SAP is we have a trial org that we roll out to developers for trying out stuff. Now they create an app, they try out stuff, they understand something and then they leave. The apps are running there forever. I mean it's like, I mean just imagine one, so we have around 4,000, 5,000 plus spaces in the trial org. If every space has at least one app which is taking one to two GB of memory just superimpose that to the money part of it and then you have so much of money not being, I mean just being wasted. So we wanted to somehow solve that problem within SAP. And that is where Autosleep comes into picture. So what we did was okay, we have this org enrollment feature where an org manager can actually come and enroll a particular org with Autosleep. So it's not at a space level anymore. We take an org and we give it to Autosleep and say monitor this org. So what Autosleep will do is it'll take that particular org, it'll start monitoring all the spaces in that org including ones that are newly created from time onwards and start demonitoring of course or deleting threads for spaces that are deleted and create service instances in them, bind them to all those apps and start bringing them down. So I mean in our platform, when we actually did this exercise, I mean within almost within one to two days almost more than 70% of the apps were actually down and we had put the idle duration of 24 hours. So which means almost 70% of apps in our trial org of more than 4,000 plus spaces were actually not being used. So yeah, so how does this work? So of course, as I said, the solution that we have is org enrollment. So we don't have a CFCLI yet. So when I'm going to demo, I'm going to use Curl to actually fire the rest APIs and enroll the org. So yeah, so once I do that, Autosleep will start monitoring all the spaces in their apps. It will create service instances automatically and these service instances are of a special kind. So for example, if I create a service instance, a developer deletes it. For example, he doesn't want his space to be monitored after the idle duration period of time. I will come back and I will recreate the service instance again. So you cannot really run away from Autosleep by once I roll this out into the platform. I'll come back to the parameters after the demo. Let's just quickly go into a demo. Okay, we already have a space. We have an app. Let's restart this app anyways. Okay, so what I'll do is maybe I'll create one more space called test. So normally in an org, you'll have a dev space, you'll have a test space, you'll have a prod, you'll have hotfix, you'll have a lot of names, a lot of different spaces. I'll just create two spaces for the purpose of the demo. So let's say I create one more space called test. Yeah, of course, there are no apps there. So I'll push the same name. I'll rename the name to simple test so that I can actually push it. Okay, so I have a dev space with a simple dev app. I have a test space with a simple test app. I mean, of course, this is not a production scenario. In production, you'll have probably one space with around say 10 apps, 20 apps and so on and so forth. Okay, now next what I'm going to do is I'm going to enroll this org. The org which is demo Autosleep with the Autosleep service. So we still, so this is still development in progress. We still do not have the service broker or the CLI updated to use this feature. So what I'm going to demo it with is a curl command. So basically I'm going to fire the rest API directly right now. So before that, I also need the space, sorry, the org ID. So let me pull out the org ID from here so that I can actually use the ID to enroll. Okay, it just seems like the org ID. So if you look at this curl command, I'll quickly also explain what the curl command is. So the curl command also takes the same parameter. So out of this curl command, we will of course wrap it up at a CLI. Currently, we have this rest API safeguarded by the basic authentication of the broker user and password that we have already for a service. So what I'm going to do is I'm going to enroll this particular org which is nothing but the rest API called enroll.org slash the org ID. And I'm passing an iteration of 30 seconds and the state called enrolled. So which means what I want to do is I want to enroll this particular org with auto sleep. Okay, it returned me a response back saying that it's been taken care of. So let's go to the dev space. It actually enrolled the correct org. Oh no, the org view ID is different. I enrolled the wrong org. So you wouldn't really have to do all these things because once the CLI is in place. So now what I've done is I've actually enrolled the org that I really want to monitor. So what you've now seen is I went into the dev space and what auto sleep did was it created a service instance of its own into this particular space. And what the service instance is going to do is it will start polling all the apps in this particular space, bind itself to that space and basically more or less do what the previous service instance that we manually created did. But what you now don't have to rely on is to tell individual developers to basically create service instances on their own and help you save some money. The platform operator can actually force this particular feature into the platform for orgs like, for example, the trial org where you have a situation which you want to deal with. So if I go to the test space, I have a simple test app which is now bound to the service instance that was automatically generated in this particular space and if I, sorry, if I look into that app, it has been stopped. So now this service instance that has been created is not of a forced kind. Why it is not of a forced kind is because developers should of course get the chance or the opportunity to be able to delete the service instance and delete the space because we cannot really let the space remain there if the developer doesn't want to. But if I now go ahead and delete this particular service instance, what auto sleep will actually do is it will recreate a new one as long as the space remains. This has been built into the service. Of course, there are some more features to it. So let's now come back to the features that we are building into it. So there is a state parameter which we saw that we used as enrolled into the org. There are two more parameters to that which we call back office opted out and back office recursive opted out. So back office opted out means if you enroll an org with the status enrolled and you want to now move out, you don't want that org to be enrolled with auto sleep. You update it with the state as back office opted out. Now back office opted out means that all service instances that were created by org enrollment when you enroll this org will not work anymore. But individual service instances that were created in spaces by developers will continue to work as they normally did. But if you do not work, want auto sleep at all to work even for service instances that were not generated by auto sleep, the parameter that you have to use is back office recursive opted out. So if you do that, then auto sleep is just stop monitoring this particular. For example, you want to do some maintenance activity or some performance test for which you do not want auto sleep to really come in and meddle with your work. So for say two or three days in a week, you do not want org enrollment to work. So you just update the parameter with back office recursive opted out and it will continue to, and it will stop monitoring the org. Once again, after your work is done and you want to monitor again, update it to enroll and job done. It'll again start monitoring all the apps in that space, including any new spaces that have been created in this particular time that was, that org enrollment was not there. Okay, idle duration of course is defaulted to 24 hours and you can give any time you want. Then comes auto enrollment. So standard force, there's a transient opt out. So transient opt out is the one that we use for org enrollment. So what it allows is, it allows you to temporarily opt out of org enrollment by creating a service instance of that type, which means you can actually delete the service instance. But if you don't delete the space after the idle duration amount of time, it will recreate a service instance there and start monitoring again. So you cannot run away from the system. Of course, exclude from auto enrollment. You can also configure spaces or apps that you do not want this particular org enrollment to monitor. So you might say, okay, I don't want the dev space to be monitored because I'm running some performance stuff or I'm doing some development, but the prod space and the test space can probably be monitored. So you can just put a pattern there. Okay, so we have been running this our internal tri-org landscape. We have been using this on 4,000. So we have a trial org, which has 4,000 plus spaces with 5,000 plus apps. And as I said before, when we enrolled this particular org, we had almost 70% of apps just brought down with an idle duration of 24 hours. I mean, it was amazing. What we, so the rest of the next three points actually deal with some open items or some problems that we have with this. So auto sleep also comes with an auto wake up feature. So which means once an app is put to sleep, you want to access that app again and it'll wake that app up. So it's automatic, but the way this feature works is you have to enroll or register a wildcard proxy with the auto wake up app, which a public service provider like SAP cannot do because the wildcard proxy is something that we use in our private spaces. We cannot really use it for a public spacing service. So which means we do not have auto wake up right now. So once an app is put to sleep, the developer has to manually wake it up. Of course, we had a discussion with Route Services team, including Shannon. There's a discussion that you can also see in CFDef where so we wanted to see if Route Services can actually help us intercept traffic to an app that is put to sleep and help us wake it up. But unfortunately, Route Services right now do not support this. So if an app is put to sleep or it is stopped, Route Services cannot help us intercept any traffic to that app, which means we cannot also leverage Route Services to build auto wake up. So which means basically auto wake up is one big question mark right now for a public service provider like SAP. Of course, now if you expose a service like this on your public platforms and developers start using it, I mean, you will cut into your revenue generation to a certain extent because apps will be put to sleep if they are not used. So I have to decide whether they want to do that or not. So we in SAP still do not run this on a public facing pass. So customers are still not exposed to this particular service. And then there is also an argument that there is a feature called, or service called auto scaling that is already being developed. SAP is already a part of it. And the argument that people give is if I can bring down or if I can scale down my app using auto scaling to one, should do I really want to make it to bring it down to zero. I mean, the counter argument is right there. If you have a space, if you have 4,000 spaces and 5,000 apps, one single app with one GB, you already are hitting the roof. So it's up to the provider to decide. But yeah, there's still discussions going on here and there if you see a convergence point between auto-sleep and auto-scale at some time coming together, don't know the use cases are still different from my personal point of view, but yeah, something that is being discussed. Once again, what's missing today? Okay, HA, high availability. So auto-sleep today still runs as a singleton. If I scale this particular app for more spaces, it won't work because both instances will start monitoring it. So HA is a problem which we will solve and there are stories to fix it. We still don't have a dashboard for org enrollment. For space, for the already existing services instance, we'll still have a dashboard, but for org enrollment, we don't. We don't have a CLI plugin for org enrollment yet. Notifications is also not inbuilt. For example, when I sleep or wake up an app, there is no notifications yet. And of course, that I've already discussed, auto wake up on public cloud providers. So somebody like SAP still does not use it on the public facing pass, but it helps us save money on our internal landscapes. At the end, these are the contributors. So started by Orange. Guillaume is here. If anybody wants to bug us with questions, please. And from SAP, three people are contributing to it. That's all I have. Any questions, I'll take them. Cool. Thank you.