In the previous chapter, we learned how to integrate applications deployed on Bluemix with software that is deployed on-premise. In this chapter, we will look at what capabilities are available in Bluemix to allow users to scale the applications deployed on Bluemix. We will learn to configure scaling policies on an application deployed on Bluemix, such that the application scales when under load. To begin with, we will try to understand what it means when we say scaling, and what types of scaling are possible. This chapter will cover the following topics:
- Overview of scaling types supported in Bluemix
- Creating an application that can scale
- Configuring a load test for the application
- Manually scaling your application
- Scaling your application using the Auto-Scaling service in Bluemix:
- Creating the Auto-Scaling service instance
- Binding the Auto-Scaling service to your application
- Defining the scaling policy for your application
Building scalable applications has become the de facto standard for modern web applications. Applications need to be built to scale. Scaling of applications is required when there is a need to meet increased activity within the application. Applications that scale are highly available and responsive to requests. There are two types of scaling, as follows:
- Vertical scaling
- Horizontal scaling
When applications are deployed, they use compute resources to run. These compute resources are:
- CPU (processing)
- RAM (memory)
Scaling applications by increasing the resources available to them in the same machine or physical node is called vertical scaling; this is also known as scaling up. This method of scaling is useful for applications that are designed and developed in such a way that they cannot share state or data. Less modular applications, or applications with more tightly coupled modules, usually have a need to scale within the same node or physical machine. By vertically scaling these applications, there are more resources that are attached to, or made available to, the application for use when there is an increase in load on the application.
The flip side to vertical scaling is that the applications become a single point of failure, which means that if there is a disruption to the physical node where the application resides then the entire application becomes unavailable until the physical machine is restored.
The following figure shows an illustration of what scaling up, or vertical scaling, is:
Horizontal scaling is also called scaling out. Unlike vertical scaling, in horizontal scaling, resources are added to the application by scaling the application out to another node or physical machine. The application that is scaled out to a new node gets the same set of resources to work with. To use this scaling technique, it is important that the applications are designed in such a way that the state and application data are shared across the nodes. This makes it necessary for application design to externalize data stored in memory or local file systems. Also, when applications are scaled out, it becomes necessary to have a load balancer in front of the nodes so that the application requests are routed, based on routing policies defined in the load balancer, to application instances or nodes.
The advantage of horizontal scaling over vertical scaling is that horizontal scaling does not deplete the resources of a single physical machine or node. Also, by scaling out, the issue of SPOF (single point of failure) is reduced, so applications that are designed to scale horizontally are more available and have a better failover than applications that are designed to scale vertically.
The following figure shows an illustration of the horizontal scaling, or scaling out, of an application:
While developing cloud-native applications, it is important to consider the nature of deployment on cloud. Most of the compute capacity provided on a cloud environment such as Bluemix are transient in nature, which means that an application restart or restage does not guarantee its deployment using the same set of resources. This makes it necessary for applications that are developed as cloud-native to be designed in such a way that the state between the application modules or the application data are stored in persistent stores and not kept in memory or in local file storage.
In Bluemix, it is recommended that application data is persisted in external data stores, preferably using one of the data services available in Bluemix. For persisting application state between requests, such as for session objects, it is recommended to use the Session Cache service on Bluemix. For persisting data that can be accessed easily and frequently, to give an improved performance for your web application, instead of having to go to databases or data stores each time, it is recommended to use the Data Cache service on Bluemix:
From the dashboard shown in the preceding screenshot, you can click Get started now! to view the services in the Bluemix catalog. Go to the Application Services category to view the Session Cache and Data Cache services:
Note
For details on working with Session Cache, you can refer to https://ibm.biz/BdrH8h . To learn how to use the Data Cache service, you can refer to https://ibm.biz/BdrH83 .
We will use the Java Cloudant Web Starter boilerplate to create an application, which we will use to demonstrate the scaling capabilities in Bluemix:
- From the Bluemix dashboard, go to the Compute option and click on Get started now!, as shown in the following screenshot:
- Select the Java Cloudant Web Starter boilerplate:
- Provide a name for your application. In this demo, the application name is
scalingdemo-b05307. Leave the other fields with their default values, as shown in the following screenshot:
- Click Create. This creates the starter application.