IBM Cloud Docs
Scaling, high availability, and traffic management

Scaling, high availability, and traffic management

When your app is deployed to Code Engine, it is accessible and available for tests and even production. Because Code Engine provides a serverless platform for containerized workloads, most of your runtime details are managed automatically by Code Engine. You can, however, control many of the details.

Scaling your app

When working with Cloud Foundry, you might have setup and used the autoscaling feature, which enabled you to automatically add and remove app instances, depending on performance metrics or date and time. In contrast, Code Engine autoscales your application by default. Code Engine scales an app up to 10 runtime instances (by default) and down to zero (meaning that the app does not consume any resources when not in use).

You can edit these settings within the limits and quotas of the Code Engine. A max scale of 0 (zero) scales your app to the maximum possible, if necessary while a min scale of 1 keeps at least one instance of your application running. By adjusting the concurrency and request timeout, you can tune the autoscaler to your needs. For more information, see Configuring application scaling

High availability

For aspects of high availability (and disaster recovery), Cloud Foundry and Code Engine are similar.

  • Follow best practices for handling concurrent requests.
  • Make sure to have at least two or even three instances of the app up and running.
  • Run app instances in the available zones of a multi-zone region (MZR).
  • Use a global load balancer (GLB) in front of app instances deployed to multiple MZRs for high availability on a global level.

Traffic management and rolling updates

To keep your app available when deploying a new version on Cloud Foundry, you use special CLI command options for rolling updates or zero-downtime deployments. With Code Engine, the rolling updates are performed automatically. After the new app revision is ready, the traffic is moved from the old app to the new revision.

Performing blue-green deployments and gradually moving traffic from the old app to the new revision required some manual intervention in Cloud Foundry. With Code Engine, you can use the capabilities built into its underlying Kubernetes and Knative layers. The blog post, Blue-green deployment with IBM Cloud Code Engine and Knative, shows how the Knative CLI command to update the app so that the traffic is configured to split between revisions. Given an app named bluegreen and two revisions rev-old and rev-new, the following command splits the traffic 80/20 between them.

kn service update bluegreen --traffic rev-old=80 --traffic rev-new=20

By adjusting the assigned percentages, you can test new code version with some traffic first and, when your code is ready, run the revision in production.

Next steps

  1. Just starting your migration? Check out Getting started.
  2. Compare Cloud Foundry terminology with Code Engine.
  3. Try out Code Engine with a local build tutorial.
  4. Does your application use service bindings? Check out Migrating your service bindings.
  5. Scaling, high availability, and traffic management (current page)
  6. Find Code Engine equivalents to Cloud Foundry commands.
  7. Still have questions? Try the Migrating Cloud Foundry applications to Code Engine FAQ.

Other information