 Good morning. We'll be talking about the project application autoscaler, which is a production-ready cloud-native service to autoscale your application. Did you ever heard of application autoscaler project? Anybody? Yes, you are using application autoscaler? OK. So maybe you will get in-depth knowledge of how to use and how to deploy kind of thing. OK. So application autoscaler project is a cloud-funded incubator project. It is a collaborative project. Earlier started with Fujitsu, SAP, and IBM. After Fujitsu exits, it's being managed by IBM and SAP. So we have multiple developers from both SAP side and IBM. I'm Tanmay. I'm Tanmay Pal from SAP. And I have with me Rohit from SAP and Ingle from IBM China. From the project perspective, we have three different repositories. One is for the core project, which is app autoscaler. As autoscaler is deployed as a boss release, so we have different repositories for this. And also, we have a CLI plugin to actually handle different autoscaler operations. So we have different repositories for that. And if you want to contact with us, we can just post a message on our Slack channel, or you can drop a mail in the CFDeb list. We have a few more sessions. So we'll try to actually clarify all your queries here itself after the session. But yeah, we have a project office hour from 2.10 to 2.40. At the runner's cycle, the foundry, you can come and we can just clarify your queries. Also, we have another session called autoscaler. Bring your own metrics, which is advanced versions of the autoscaler session from 3.30 to 4.00 at Singapore. So you can just come maybe if you're interested. What will be your agenda? We'll be trying to give you an idea of how to consume autoscaler service. So from a developer perspective, how you can use autoscaler service to scale up or down your application? As well as if you want to deploy autoscaler service to provide the capability of autoscaling on your cloud platform, you can just get some idea here. We'll have a small cool demo and future roadmap. With this, I will hand over this to Rohit for further details on how you can consume autoscaler application. Thank you. Hi. So yeah. So as you can see, you can scale an application on Cloud Foundry with or without autoscaler. So why use autoscaler? Even with autoscaler, you need to understand your application's user's pattern, because every application is a different application. So you need to know how much your users are, how many requests you are getting. Those details you need to know. So you need to do some performance analytics on your application. Then only you can use autoscaler. Now, what benefits comes with autoscaler? Without autoscaler, you'll have to monitor your application. Whenever a certain instance occurs, let's say the throughput is too high for application instances to take, then you'll have to manually scale it up. And whenever it is too low, you have to save money, cost, and so you scale it down manually. And again, you have to keep monitoring. With autoscaler, you can tell all this in a simple policy and rest. Autoscaler will do the job of monitoring and scaling it up and down whenever, when and as it's needed. So let's see what a policy is. So autoscaler policy has two types of rules. The first one is dynamic rules. And dynamic rules supports standard metrics, which are memory used, which is memory consumed by the application instance in megabytes, memory util, which is again memory consumed by the application instances, but it's in percentage. Next is response time. Now, this is in milliseconds how long your application container takes. And the last one is throughput. It's in response per second. So responses per second. So you can use this. Apart from this, you can also use custom metrics. So whatever your application has, sometimes some certain metrics you want to use to scale your application up or down. Now, I'll not talk much about custom metrics, since we already have a dedicated session to it, so you can attend that. And autoscaler monitored your applications instance-wise. All the instance metrics gets collected by autoscaler. Then it aggregates those metrics. And the scaling will only happen when your aggregated metrics is above certain threshold or below certain threshold. So let's see how we define it. So on the right-hand side, you can see we have something called in the top instance min count and instance max count. So you always tell autoscaler how many minimum instances you want running and how many maximum instances you want running. Between these only autoscaler will move it up or down. It will not go beyond this. So you will not have your billing shock. So then comes the scaling rules. So scaling rules is for the dynamic. And you can see it's an array, so you can provide multiple scaling rules. The first one we can see, so there's a metric type. So you tell what type of metric you want to monitor. Here, the example says throughput. You can have response time as well, memory used. Or if you choose any other name from this four, that will be considered a custom metric. And then the operator. So you tell how it is above the certain threshold or below certain threshold. Then for that, you need to tell which operator. It can be greater than, greater than, equal to, less than, less than, equal to. Then there's threshold. So this is the number where you define what is the threshold. So 500 MBs, then you write 500, or 50%. Then you write 50 over here. The next is adjustment parameter. So what happens when the memory, your application, let's say, crossed 500 MBs? What do you want to happen? So here we say, plus 100%. You have 10 instances running. You say it plus 100%. Autoscaler will see at that time. It will make it 20 instances. If you have 20 instances running, it will make it 14 instances. You can also use absolute numbers. So let's say plus 5. So if you have 20 instances running, and that event occurs, autoscaler will only do plus 5. Then you will have 25 instances running. So you have two choices over there. Now you are seeing there are two more parameters. Those are highlighted. So these are optional parameters which allows you more control over application autoscaler policy and how you want your application to be scaled. So the first is bridge duration second. Now what is bridge duration second? So your application's aggregated memory or metric can be above certain threshold for a minute time, very ignorable time. But autoscaler will not consider that. So what autoscaler tells you, you can define a certain time period through which your application's aggregated memory has to be higher or lesser lower. So it has to be during that time. So the bridge duration here, it's 60 seconds depending on your application. You can have it 300 seconds, 400 seconds. It's up to you, but the minimum is 60 seconds. The next is cooldown seconds. Now the cooldown second is very important since every application is a different application. So a Java application will take more time to start up than a Node application. Node application starts in few seconds, whereas a Java application can take a couple of minutes. So autoscaler will start your new instances, but that new instances will take some time to normalize your aggregated metrics. So you might want to have a cooldown period. During that period, even when the threshold is higher, then defined in the policy, autoscaler will not scale. Autoscaler will wait to take your, it will take consideration your cooldown period and wait for your metrics to get normalized. And then again, it will start scaling. So next, you have, this is the second time of, second types of rule, which is schedules. So as with applications, you can have certain situations. Let's say your finance application, which at the end of the month or at the beginning of the month might have heavy uses, but throughout the rest of the month, it will be more or less idle. So you might want to override the global instance min count and max count. And so you can do that by using schedules. Now schedules, since it's schedule, you need to have a time zone. So you define a time zone, and then schedules are of two types, recurring schedules and specific date schedules. So recurring schedules, as the name says, it can be repeated over weeks or months. So here you can see in the example, days of week it says, you can have days of months as well. And for the recurring schedule, you tell start time and end time, and which days of the week or days of month you want it to be executed. And then you tell instant min count and instance max count. Now this instance min count and instance max count will override your global instance min count and instance max count. So let's say your application was generally defined scaling five to 10. It was moving using dynamic scaling rule between five to 10. But during the schedule, you can have the schedule for, let's say, 50 to 100. And at the end of the month, it will be moving between 50 and 100 because your application uses is very high during that time. So you can do that. And then in the last, you can see initial instance min count. Now this is very important. Let's say before the schedule started, you had 10 instances running and the schedule says 50 to 100. So it should directly go there. But so at that time, you can tell initial instance min count is 60. So auto-scaler will make sure that when the schedule starts, you have 60 instances running and it will let them dynamic scaling rules take care and let it move between 50 and 100. And there's one other situation. So you can have 120 instances running and initial instance min count 60. Since you have 120 instances running, it is, and you are using auto-scaler. So it is assumed that you might have a heavy load at that time. So auto-scaler will not scale it down to 60. In the other scenario, it will do, but when it is higher, it will not do that. So next is how you can operate auto-scaler with CLI. I'll let Ying take over. Hello, is that okay? Okay. So just as Rohit explained, the scaling policy is essential for all-scaler. So after you create a scaling policy, you must attach the policy to your application. Yeah, otherwise all-scaler won't start work for you. That is very important. Yeah, if you have multiple applications and you want to attach, and you want to share the same policy, then you must attach the policy to the different applications separately. It's very important that when you are doing a blue-green deployment, when you, if you have a scaling policy defined on the blue one, when you roll out to the green application, you must attach the policy to the green application since the blue and green are different. Yeah, so let's talk about how to attach the policy to the applications. If the all-scaler is offered as a service in the marketplace, is offered as a service in your platform, then the most simplest way to attach the policy is to through the CF-bund-service command, and then you can apply the policy file as an additional parameter with slash C and attach the policy JSON file. And also if you want to have more advanced operation with app all-scaler, you can install the app all-scaler plugin from the community plugin repo, and then you need to define the API endpoint of the all-scaler server, and then you can play with attach policy, detach policy, and then retrieval the policy, metrics, and history. We will have a demo for that later. Okay, just now we introduced how to use all-scaler from the end user point of view. Now let's just do a little deep dive. That is the architecture diagram for the all-scaler backend. All the things in this box belongs to the app all-scaler backend. It has a service broker which is compliant with open service broker APIs so that you can create a service instance and ban the service instance to your application with the policy. And also it has an API endpoint to response to the CURD request, register from the UI dashboard or the CLI. It has a metric forwarder which is used to accept the customer metrics reported from your application, and then it will forward the metrics to the log aggregator. Then the metric collector component will get, will fetch these customer metrics and standard metrics from a log aggregator and do aggregation and trigger scaling action. All this stuff is a part of each deployment. You can deploy multiple instance of these ones. Most of them is working in the active-active approach and only a few, for example, the operator that is a housekeeping component is working as a master's layer. Okay, just now we talked about to offer all-scale, sorry, in fact, just now I mentioned all-scale could be offered as a service in the self marketplace, but in fact, we support to offering approach. The first one is offered as a service. Then for the provider, you need to deploy or scale up or release with the default template, nothing to change. Then for the end user, they need to create a service instance or a water scale and then bind the service with policy. And also anyway, they can still use the CLI. Yeah, one, it is offered as a service. We will ensure it looks like a service. That means you can only attach the policy after the service binding is created. And when you unbind the service, the policy is deleted. All the policy lifecycle is limited within the service lifecycle. And in another way, we can offer all-scale as a building application experience. That means for the end user, once they push an application, they can use the all-scale CLI to attach the policy directly without creating service instance or unbind service. If you want to provide the all-scale capability as a building experience to end user, then during the deployment, you need to change the wearable service offering enabled from true to false to disable the service offering approach. Apple Scaler has a both release to deploy it. But anyway, first of all, you need to have a co-founder deployment first. And then I just get above it. We have some different deployment options. Just now we talked about how to enable the building experience. And along with the latest self-deportment, we also have some additional ops file to enable the push DNIs. And anyway, this stuff is still in development. You currently will offer it as ops file. But given the latest self-deportment is completely remove the console-related things, we also deployment a new one to make the push DNIs enabled by default. So if you need to deploy the push release, please refer to the latest data document to have the most latest one. And also along with the FISO approach, you can generalize all the all-scaler push release to launch it, to deploy it on the Kubernetes. In fact, we already contribute, we already pull request to our latest final release to the SUSE SCF repo. So if you install SCF from the SUSE repo, you can get Apple Scaler installed by default. And also on the IBM Cloud Foundry Enterprise environment, you know, most of you maybe learn it from the keynote, from timing yesterday morning. On that environment, in later this year, we will offer out-scale as the building experience on that environment. So let's have a try. We can have a demo on the CFI environment. First of all, this is the CFI environment. I deploy, sorry. This is the CFI environment I deployed in. Yeah, it is not the final release version. It's already run for a few days so that I make sure it is stable version to launch the demo. Anyway, I hope it won't broke. Here, we deploy all the Cloud Foundry component as a port on Kubernetes, and also with the all-scaler component. Yeah, you can see we only launched three ports here. In fact, we put the API server source broker inside the all-scaler API port, and we put the metric collection and event generator into the metrics port, and the scaling engine, scheduler, and all the other stuff into the actor port. So it is a compact installation. Now, here in my CF command line, I didn't install CF, I installed the all-scaler plugin. Let me install it. And after that, you will see more command over here. Currently, I already launched in the CFI environment, and just before the session, I already pushed a demo application. It is a simple Node.js application. It didn't do much more things. I just want to, yeah, it is that. I just want to try out the throughput policy and to add workload to it to trigger the scale out and scaling. Okay, that is the app. So now, let's just see whether... Yeah, in fact, I didn't attach any policy to the application or Node, so you will get an error since there is no policy defined, and I will try to attach a policy for that. Let's just retrieve all the policy again. Okay, here is the policy. I define a throughput as a metric type, and I limit the upper threshold as 20, since running the low-time strategy didn't want to make my mic crazy. So with this 20 threshold, it's easier to be scaled out. And then scale in, when it's less than 10, it will be scaled in. I also have a schedule here, but anyway, maybe it won't be triggered now. Now, I will add a workload. I would like to add workload with the AB test tool. It will driven 50,000 requests in total, and with 16 can carry to user to the application. And it will take a little time to run the low-test and to trigger the scale out. And in the meantime, I would like to ask Ruhi again to introduce the all-scale offering on the SAP. Hello. Yeah, so we have Autoscaler running on SAP Cloud Platform for over a half year now. And we went GA with Autoscaler last year during FCOM in December 2017. And as with all things SAP Cloud Platform, Autoscaler is also available on all different ESes, AWS, Azure, OpenStack, and GCP. There's also dashboard support for Autoscaler. And by the end of this month, there will be custom metric support for Autoscaler on SAP Cloud Platform. So you can try that. And switch to another window. Is that too small? Sorry. I can make it larger. Also scaling metrics. Let's see. It's true. Again, you can just see how many metrics is already collected. Yeah, it already collected some of the metrics. And let's just see. I guess it's not enough time. It didn't have enough time to scale out yet. Oh, perfect. It's already scaled out from one to two. Yeah, since I defined to adjust to scale out to the double size of its original, currently it's scaled out from one to two. And with the action at 100% instance about the original, according to the threshold, it exceeds the upper threshold. And okay, the load test is done. Let's just see. But maybe the, yeah, since we are doing scaling is based on the aggregation metrics. So the aggregation metrics will be scale, will be decreased in a more graceful way. So it will may take a few minutes, a few longer time to scale in. But it will really, it will help to your application to make your application stable. Okay, but anyway, we have another exacting application so that I can show what happens this is leading application with a schedule defined. Okay, here you can see how, okay. Here it's trying to scale out from one to 20. When a schedule is triggered to fulfill the minimum instance of count. And then it's scaling, since there is no workload, scaling, scaling, scaling, scaling out until it reaches the minimum limit one. Okay, that's all for the demo. And let's talk about how to, and let's talk about the real map. In the future, in the later, in the later months days, we will add the community version of the UI dashboard support for Allscaler. You may have a look on this nice chart. This is a metric chart for the Allscaler. So we will add the, contribute this code to the community so that you have a community version of the Allscaler UI dashboard. And also currently we are collecting metrics from our lab aggregator with the V1 API and we will switch it to the V2 API to align with the latest stress. And also we are considering to add a single deployment to support the Allscale for multiple cloud foundry environment. That is useful if you have, as a service provider, if you have multiple service cloud foundry instance and you don't want to install Allscaler in each of them. So you can have a single site of Allscaler deployment and then to scale different applications within the multiple cloud foundry. Yeah, that's all for the real map. Yeah. Thank you very much. We'll take some questions because this is lunchtime, I guess. But we should be able to do a few questions. Anybody? For the team? That's why. Only short question. You have also further boundary conditions. For example, the amount of Diego cells. For example, if you have a landscape with only 20 Diego cells and you scale up, do you also take that, the amount of memory and storage, storage that didn't partner, memory and CPU from the Diego cells into account? No, it's not considered. So you can only scale as much as your space or quota is. But it's distributed over the space. So you need to make sure the quota you are getting from your account has sufficient memory, is providing you. And the rest is the CF deployment. Yeah, if you exit the memory quota, you will get a failed message when you retrieval the scaling history. So where you see the scaling history, there you will see failed because not enough quota in your org or space. One more question. Anybody? No? Well, thank you. And I guess good, check it out, right? Yeah, thank you. Thank you. Thank you.