How-tos

Highly Available Applications with IBM Cloud Foundry

Share this post:

Deploy your Cloud Foundry applications in the IBM Cloud and reach your target application availability

A single instance of an application, running on any PaaS, on any cloud provider, is not guaranteed a specific availability or up-time. All cloud providers have the potential for individual application instance downtime—nothing can prevent that. Specifically, during system upgrades, it is necessary to move application instances around, so single instance apps with no secondary instances will surely be affected with downtime

Applications themselves can have problems that cause a slow down of processing, making them unable to respond quickly enough to incoming requests

It is, however, easy to make sure that your application itself does have the specific availability and up-time that you need and is highly available (HA). To properly deploy an application in a cloud environment and ensure maximum responsiveness, your app needs to be deployed in a certain (and easy) way that maximizes the chance of an instance always being ready to respond to a user request.

This article will explain how to deploy your Cloud Foundry applications in the IBM Cloud such that you reach your target application availability.

How to use this article

  • The section “Application availability deployment best practices” describes how to properly deploy your application.
  • Any unfamiliar terms can be referenced in the section “Basic cloud architecture.
  • There are labs at the end to show you exactly how to do these steps described.
  • A set of in-depth articles explains exactly how the below works at a deep level of detail. This article summarizes it, but these links go deeper if you’d like:
    • Highly available applications using IBMs Cloud Foundry PaaS — Part 1: The underpinnings
    • Highly available applications using IBMs Cloud Foundry PaaS — Part 2: In practice

Application availability deployment best practices

There are two levels of possible actions you can do to ensure a certain level of application availability. They build on each other to deliver the level of availability for which you are reaching. Each one has a corresponding SLA for your IBM Cloud Foundry application. There is also an HA Optimization that you can apply to fine-tune the environment.

HA Level 1: High application availability – Single-region

This ensures that your application has a solid responsiveness and high availability so that nothing affects the basic operations and performance:

  • Make sure your application handles multiple connects and runs as a stateless construct. See “12 Factor Apps” in the Basic Cloud Architecture section below for this description.
  • Minimally, deploy more than a single instance of your application
  • Optimally, deploy three instances of your application—that is the standard cloud deployment. Your instances will be deployed to multiple hardware-isolated Availability Zones in a single IBM Cloud multi-zone region (such as US-SOUTH or EU-DE).

SLA: The IBM Cloud SLA when you are running two or more instances is 99.95%. That is the SLA across all the Availability Zones in the Regional Hub given you have at least two instances running.

HA Level 2: High application availability – Multi-region

This ensures that your application has the highest possible responsiveness and high availability so that nothing affects the operations and performance. Now that you have implemented (or at least understand) the HA Level 1 strategy, you can take the next step:

  • Step 1 is to implement Level 1 above.
  • Step 2 is to deploy your application to more than one IBM Cloud multi-zone region and ensure that each region is deployed as Level 1 above.
  • Step 3 is to use a global load balancer. Each application deployed in each region is a separate URL target (and not connected to a master domain link) so use a global load balancer to connect the multiple regions URLs properly and spread the load over multiple regions. See “Global Load Balancer” in the Basic Cloud Architecture section below for this description
  • And, of course, IBM Cloud has a global load balancer called Internet Services that works very well with Cloud Foundry applications.

SLA: If you deploy to two regions, have two instances in each region (with 99.95% SLA each), and use a global load balancer between the regions, then the combined availability becomes 99.99% (technically it’s actually higher, at about 99.999975%, or “6 nines,” with anticipated downtime of less than eight seconds/year, but we guarantee 99.99%). So having an application scaled this way might not only help you with performance but with resiliency as well. In other words, it can handle almost any user load and can achieve near perfect up-time capabilities.

HA optimization: Scale your instances automatically depending on load

Once you have high availability in place, you can optimize that as well. You don’t need full capacity in every region; you can keep one of the regions with less application instance capacity and then turn on auto-scaling to bring up the instances to a higher level if that region needs to start handling more traffic. This “backup” region can be running less load for that apps instances, saving you money, and then can adjust automatically as needed.

Some thoughts for making sure that your number of instances changes dynamically with load:

  • Not every application will need this, but most benefit from at least having that capability watching their application performance.
  • This ensures that your application, which is now highly available, keeps up with the load of your application usage.
  • IBM Cloud Foundry has a specific capability to dynamically adjust your application instances as your usage changes over time—it’s called “auto-scaling” and it works very well for your application instance adjustments.
  • The auto-scaling for the IBM Cloud service enables you to automatically increase or decrease the compute capacity of your application. The number of application instances are adjusted dynamically based on the auto-scaling policy you define

SLA: Having auto-scaling doesn’t affect your SLA number, but it does allow your application to do more work as your usage load increases, which is very valuable.

IBM Cloud Foundry high availability labs

These labs will walk you through how to achieve each level of HA strategy with your IBM Cloud Foundry application. The labs exist in our central Cloud Foundry Lab & Tutorials. Please explore all the labs there as you like.

Next Steps

No cloud can guarantee a single instance of an application, running on any PaaS, will stay running forever. However, if you follow these simple steps to achieve an application high availability strategy, you will reach the desired uptime and availability for your critical applications.

  • Existing IBM Cloud Foundry users: Check your running applications in the IBM Cloud Foundry deployment and adjust them as you see fit to reach your desired application availability.
  • Other cloud users: If you’re unhappy with another cloud vendor and how they are handling the high availability of your critical application, check out IBM Cloud Foundry.

Reference: HA Cloud Architecture

This explains the IBM Cloud key architecture terms and how IBM Cloud Foundry interacts with and uses that architecture.

  • High Availability: High availability is a characteristic of a system that aims to ensure an agreed level of operational performance, usually uptime, for a higher than normal period.
  • 12-Factor Apps: The “12 factors” govern the best use of PaaS hosting and modern web software. Using as many of these 12 factors as possible improves your software hosted in the cloud greatly. This website explains these factors. They are the hallmark of most mature cloud-native applications.
  • Stateless Processes: Stateless processes ensure that an application instance is “stateless” and “share-nothing.” Any data that needs to persist must be stored in a stateful backing service, typically a database. Additionally, the process instance holds no “sticky information,” such as specific user information. Instead, that is referenced and passed every call. This allows the critical cloud hosting capability: instances can be added, destroyed, and infinitely scaled, making your application very resilient and flexible.
  • Availability Zone (AZ): An individual data center, separate buildings with separate power supplies, and a certain distance between them. IBM Cloud Foundry, unlike other services, does not expose Availability Zones to you as a user. Instead, it automatically uses these AZ for you. If you have multiple instances of your application, it will evenly distribute instances across each AZ automatically. The general idea here is that you, as an application owner, should not have to care about that placement. You should care about your code and let the PaaS handle the rest.
  • Regions/Region-Hubs/MZR: A place that consists of at least three “Availability Zones.” IBM Cloud has many MZRs that support Cloud Foundry applications: US-South, US-East, United Kingdom, Germany, Sydney, etc. US-South consists of 10 AZs (at the time of writing), where IBMs Cloud Foundry service is leveraging over 3 of them. More information on IBM Cloud data centers.
  • Multiple Instance Deployment: The reasons to deploy multiple application instances are resiliency and performance. Even if your application is deployed in a single AZ that is the most stable place on earth, your code might have an intermittent problem, the container in which your code is running might have a problem, or something else, and the result is always the same—your application is not responding, and you are having an outage. So only when you scale to multiple instances do you get that guaranteed response and availability.
  • Scaling: There are two types of scaling: vertical and horizontal. You need to adjust both types of scaling to properly deploy an application. An instance needs to have enough resources (vertical scaling) and you need to have enough of them (horizontal scaling):
    • Vertical scaling means increasing the amount of memory or CPU that the application can use. Factors such as user load or the number and nature of tasks performed by an application can change the disk space and memory the application requires. For many applications, increasing the available disk space or memory can improve overall performance.
    • Horizontal scaling means running additional instances of an application that can allow the application to handle increases in user load and concurrent requests and protect against outages. Running multiple instances of your application is much easier in stateless applications.
  • SLA: The only way to be covered under the IBM Cloud SLA is to be running multiple instances of your application.
    • Single Region Deployment
      • One instance—no availability specified
      • Two+ instances—SLA availability 99.95%
    • Multi-region deployment
      • Two regions with two+ instances in each region with a global load balancer—SLA availability 99.999975%
  • Global Load Balancer (GLB): A global load balancer allows you to spread your application connections amongst several hosted locations, ensuring the maximum resiliency of your application. IBM Cloud Foundry already uses a load balancer to balance traffic within a single region. If you want to use multiple region deployments, you need a global load balancer. There are many to choose from, and of course, IBM Cloud has an excellent one called IBM Cloud Internet Services. Cloud Internet Services provides reliability, performance, and security for IInternet-facingapplications, websites, and services using Cloudflare’s 150+ Global Points of Presence (PoPs).

 

IBM Cloud Offering Manager

Simon Moser

IBM Cloud Foundry Architect

More How-tos stories
December 13, 2018

Java Microservices with MicroProfile – API Documentation

To benefit from the reuse and consistency microservice APIs offer, other developers will need guidance to use your APIs correctly. With annotations defined in the MicroProfile OpenAPI specification from Java EE, it's easy to generate clear documentation.

Continue reading

December 13, 2018

Tutorial: Deploying the Jenkins Helm Community Chart on IBM Cloud Kubernetes Service

The IBM Hybrid Cloud Team has authored a tutorial that will guide you through the steps required to set up and install a Jenkins server and deploy a sample Node and React application on IBM Cloud Kubernetes Service.

Continue reading

December 12, 2018

Deploying to IBM Cloud Private 3.1 with IBM Cloud Developer Tools CLI

IBM Cloud Developer Tools CLI version 2.1.12 adds deployment support for IBM Cloud Private 3.1.

Continue reading