Getting Ready to cf push? Great! Now, Think About These 5 Things Before You Write a Line of Code.

We often say that cf push is the most magical command in cloud.

When you cf push your application code, Pivotal Application Service automatically:

• Uploads your application code

• Determines and installs the correct runtime and middleware to run your application

• Sets up a route (or URL) for your application

• Creates a load balancing entry for your application

• Creates SSL termination for your application

• Creates health monitoring and logging subsystems for your application

• Starts your application in a healthy state with the desired number of instances

• Binds any backing services needed to your application by injecting the service credentials

These tasks take days in traditional IT shops. With cf push, it’s done for you instantly. No wonder developers from all industries are flocking to PAS.

In our work with scores of enterprises, we noticed that the most successful PAS adopters get their dev teams ready to cf push in similar ways.

Here’s a quick summary of the most important things you should consider as you ramp up on PAS. (Want more details? Check out my new whitepaper based on these best practices.)

1. Need High Availability? Then Create an Instance of Your App in Each PAS Availability Zone.

The platform offers built-in features to achieve a highly available (HA) app. Most PAS adopters want their apps online and serving traffic, no matter the load.

While in development, you had no reason to run more than one instance of your app. In production this changes.

With this in mind, at a minimum, your app should have one instance of your app running in each availability zone. Most PAS production deployments feature 3 AZs; your app manifest should specify at least 3 instances. And that’s all you have to do!

PAS will take care of distributing your app appropriately, keeping it running during OS updates, and other platform events.

Curious about the HA features in PAS? Check out this talk:

2. Create an App Playbook to Prepare for a Disaster

The worst strategy is to not have a strategy at all. No one wants to think about what to do in a disaster, until they are in one. Then they are kicking themselves for not being better prepared.

However, you’ve just done your organization a big favor by running your apps on PAS, a modern app platform. PAS gives you many of the capabilities you need to deftly handle a disaster. Why? The product gives you so much definition about the life cycle of your app.

That said, let’s spend a bit of time thinking about what to do when the unthinkable happens.

Start by considering the dependencies your app has, and how the app would perform if those dependencies didn’t respond. Think about your app’s data store, and what would happen if that store vanished. These answers, and the respective contingency plans, become your app playbook.

A few other questions worth pondering:

• How will I be notified of a disaster?
• What is the playbook for my app in this event? Should I turn on a a single instance in DR foundation? Or maybe I should include a flag in my build pipeline that needs to be set to push app to the DR foundation?
• How long does it take for my app be available in DR (ie: startup times)?
• What will my app do about data store?
• What will my app do about active sessions?
• When should I consider a circuit breaker pattern using Spring or Steeltoe with PAS-managed Spring Cloud Services to minimize impact?

All of this needs to be thought about ahead of time. PAS gives you all the tools to accomplish high availability. But it’s up to you to implement them appropriately. Want to know how companies like yours implement multi-site HA and DR? Review this whitepaper for best practices and an explanation of common patterns.

3. How Available Should Your App Be in a Disaster? Use Tier Ratings!

Your company may have the concept of tier ratings. An app, system, or hardware is rated based on its recovery time objective (RTO), recovery point objective (RPO), and mean time to recovery (MTTR) characteristics. Tier ratings give everyone a common ground to define how available their app should be and how involved their disaster recovery strategy should be. It’s common to have a rating system from 1 to 5, where 5 is the highest.

Pivotal Application Service will have the highest rating, a 5, in our example. PAS achieves this rating because it provides the best recovery times in the event of a disaster. (PAS can span multiple data centers and it includes backup and restore capabilities.) As such, your app has the potential to have a similar rating.

Choose Your Data Store Accordingly

It’s perfectly acceptable for your application to have a low tier rating. After all, each app will have its own business requirements. Often times, your application’s data store will dictate the tier rating. With that mind, let’s take a look at common data services for PAS and how they might affect your app’s tier rating.

If your app is a tier 4 or tier 5, then you should consider Pivotal Cloud Cache (PCC). With its GemFire heritage, PCC is an excellent data store for tier 4/5 requirements. Why? The product offers WAN replication. That means your platform engineers can configure data to automatically replicate to a DR foundation. When you need to use a cache - and need a high tier rating - PCC is a great option.

Services like MySQL and Redis make sense for tier 2 and tier 3 apps. These options offer high availability, though data replication between PAS foundations isn’t automated. (Pivotal has lots of options for you to consider in the Services Marketplace.)

Side note: It’s perfectly acceptable for your application to have a low tier rating. After all, each app will have its own business requirements!

4. Prepare Your App to Perform Under Heavy Load with PCF App Autoscaler

Earlier we mentioned that you need to run at least 3 instances for any app to achieve high availability. This is only part of the picture! An app can be available but have terrible latency which renders it unusable.

So what’s a developer to do? Prepare your app to perform under duress with PCF App Autoscaler! The PCF App Autoscaler is a built-in feature of PAS, and it’s available for every app.

Use PCF App Autoscaler to configure and manage scaling rules for apps.

Binding the Autoscaler service to your app is trivial (you bind to it the same way you bind to any other service). Once this is complete, simply configure the rest of the settings. The minimum count is most likely to be 3 (one for each AZ). What about the maximum count? It will depend on the overall quotas configured for your Org.

5. Modernize Your Thinking

We’ve discussed a number of pragmatic things you can do to be more successful with PAS. Let’s finish up with a few important points.

You own the app through its entire lifecycle.

Your platform engineering team makes sure you stay above the value line. (They do this by providing you PAS in the first place.) You should never be spending time setting up servers, configuring network settings, or capacity management.

PAS is in place to boost developer productivity. It’s here to help you go faster, which in turn helps the business grow. Embrace this and adapt to new and better ways of doing things.

And finally, deploying a change to production is a non-event. It should be done during business hours. Get your nights and weekends back!

Ready to cf push? Pivotal Web Services gives you a full-featured cf push experience in minutes. Want to read more on this topic? Check out the full Developer Primer, Speed Thrills: How to Harness the Power of CI/CD for Your Development Team, and From Months to Hours: Accelerating Software Deployment with PCF.

Take your cloud-native skills to the next level, and attend the cloud event of the year: SpringOne Platform.

About the Author

David is a part of the tech marketing team within VMware Tanzu, bringing a focus to .NET-related technologies. He has been writing C# for as long as it’s been a thing. In his spare time he enjoys breaking things, only to fix them. Prior to VMware, David had a wide-ranging background, from making things go fast to building computers to writing bad code.

Follow on Linkedin More Content by David Dieruf