BTP & Integrationadvanced

BTP Cloud Foundry Part 3: Lifecycle, Service Bindings and Configuration

Key takeaway

Operate Cloud Foundry apps: scaling instances and memory, health checks, logs and events, service bindings vs service keys, user-provided services, environment variables and zero-downtime (blue-green) updates — with troubleshooting of crashes and binding issues.

Explanation

📌 KEY POINTS
✅ Scale horizontally (instances) or vertically (memory) with cf scale.
✅ Health checks restart unhealthy instances; cf events and cf logs explain crashes.
✅ Service bindings give apps credentials; service keys give external clients credentials.
✅ User-provided services inject external credentials the same way as managed services.
⚠️ Setting secrets with cf set-env stores them in plain app environment — prefer bindings or secure stores.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 covered deployment. Now operations.

━━━━━━━━━━━━━━━━━━━━
▶ 1. SCALING

Instances, memory, disk.

━━━━━━━━━━━━━━━━━━━━
▶ 2. HEALTH & LOGS

Health check types; logs; events.

━━━━━━━━━━━━━━━━━━━━
▶ 3. BINDINGS VS KEYS

App credentials vs external client credentials.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CONFIGURATION

Env variables; user-provided services.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ZERO DOWNTIME

Blue-green deploy (e.g. cf deploy --strategy blue-green).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Scale an app to 2 instances.
Create a service key for a test client.
Simulate a crash and analyse events.

✅ CHECKPOINT: you can explain the crash cause from events and logs.

Code example

ABAP Code

===== OPERATIONS =====cf scale my-app -i 2 -m 512Mcf events my-app | cf logs my-app --recentcf create-service-key my-xsuaa test-key && cf service-key my-xsuaa test-keycf create-user-provided-service ext-api -p '{"url":"...","apikey":"..."}'cf deploy app.mtar --strategy blue-green ===== CRASH CAUSES =====Out of memory (exit 137) | failed health check | missing binding | startup error in logs

Real project scenario

A production app restarted every few hours. cf events showed out-of-memory crashes after a new release. Increasing memory temporarily and fixing a memory leak in a caching module resolved it.

Common mistakes

Secrets in env vars.
No health checks.
Ignoring events.
Service keys shared widely.
Downtime deployments.

Best practices

Bindings for secrets.
Proper health checks.
Check events/logs.
Limit service keys.
Blue-green updates.

Interview angle

Questions: "Binding vs service key?", "How do you troubleshoot a crashing app?", "How do you deploy without downtime?"
Strong answer: scaling, health/logs, bindings/keys, configuration, blue-green.

Practice this lesson

Quick check

1. Which cf CLI command is used to bind an existing service instance to a deployed application so that the application can access the service's credentials at runtime?

2. An application deployed on Cloud Foundry needs to read the credentials of a bound service instance at startup. Where does the platform typically expose these credentials?

3. Which cf CLI command allows a developer to stream real-time log output from a running application for troubleshooting purposes?

Interview questions

1. A production Cloud Foundry app crashes intermittently and a rotated credential broke another app. How do you operate CF apps reliably?

Answer it in your own words first, then compare.

2. A production issue is reported in Cloud Foundry. What would you check first, and how would you troubleshoot it systematically?