New Tech Papers: Multi-Site PCF and Accelerating Software Deployment

August 31, 2017 Jared Ruckle

Just starting your cloud-native journey? Keep an old axiom in mind: experience is the best teacher. When you’re working to get better at software, learn from the experiences of other businesses.

To this end, pearls of wisdom overflow from two new tech papers:

Let’s jump right to the summaries of each paper, hot off the digital press!

Multi-Site Pivotal Cloud Foundry: Deployment Topology Patterns and Practices

Pivotal Cloud Foundry is an opinionated platform. It helps you get code running into production as fast as possible. This is an exciting proposition for teams that deploy a few times a year!

After a bit of research, executives can see how Pivotal Cloud Foundry will boost velocity. Then, an inevitable question arises.

“How do we do this across sites?”

Michael Krumpe and his co-authors answer this question with a pragmatic slant. The paper features the real-world expertise of Cloud Foundry adopters. Krumpe details the common patterns used by these leading lights.

Multi-site microservices patterns - and how to replicate backing data services - are another key topic. Thoughtful discussion and guidance are provided, including how Spring Cloud Services can simplify multi-site deployments.

And who doesn’t like reference diagrams? The paper includes many such visuals, to illustrate how the savviest PCF customers deliver superior uptime and availability. One such diagram is shown below.

PIV_WP_Multi_Site_PCF_Development_Topology_1f2_Diagram Slide 12 (1).png

Learn From Your Peers

Specific implementation details will vary. But you’re likely to land on one of three common multi-site PCF patterns, shown below. 

Deployment Pattern Benefits Other Considerations
Active/Active
  • Greatest availability; superior protection against unexpected failure
  • Flexibility and control to optimize traffic any number of ways
  • The best option for advanced microservices architectures
  • Highest CapEx and OpEx
  • Best suited for your most critical apps
  • Ensure compatibility with CI/CD processes
  • Complex application load balancing patterns
  • Most complex data management scenario
  • Address related dependencies and integration points to fully support this configuration 
Disaster Recovery (D/R)
  • Offers a measure of fail-over, without requiring a full-featured secondary site
  • Offers a DR recovery plan for essential apps
  • Practical starting point for enterprises just getting started with Pivotal Cloud Foundry 
  • Longer recovery time in the event of a failure - usually hours, rather than minutes.
  • Still requires a secondary site, infrastructure, and foundation to operate in a “passive” state
  • Minimal protection for non-essential apps
  • Requires a review of RTO/RPO SLOs for business critical apps running on the platform.
Public cloud as extension of the data center
  • Higher utilization of on-prem assets
  • Flexibility to elastic capacity on-demand as needed
  • Compliant with most enterprise InfoSec guidelines
  • Initially complex to setup orchestration
  • Keeping platform versions in sync require ongoing management

This table is a handy summary of what you’ll want to keep in mind as you advance along your cloud-native journey. Learn from the experience of other big companies!

From Months to Hours: Accelerating Software Deployment with PCF

Wrestling with a hard software problem? A classic New Yorker cartoon may come to mind.

Developers subject to endless change review board meetings may think it takes a miracle to speed up software delivery. But Brian Jimerson begs to differ.

In his paper, Jimerson explains that divine intervention isn’t needed to boost velocity. Pivotal Cloud Foundry and its ecosystem of tools have worked wonders for other enterprise teams. They can do the same for you!

Deploy Like the Cloud Natives

Jimerson starts with a study in contrasts. Consider two teams, one that deploys quarterly, and another that deploys hourly. What do high-velocity teams do differently?

Developers that use Cloud Foundry will deploy in a completely different way. The image below shows how.

 

Let’s breakdown what’s happening in this diagram.

  1. A developer makes a committable change to the source code, and tests the change locally on PCF Dev to ensure it runs properly.
  2. The developer commits the change to source control (Git or TFS).
  3. The CI server detects the change to source control, checks out the latest copy, and runs unit tests on the changes.
  4. If the unit tests pass, then the software version is built and committed to an artifact repository.
  5. The built artifact is deployed to a development space. Integration tests are run automatically.
  6. If integration tests pass, the built artifact is deployed to a review space, and acceptance tests are run automatically.
  7. If acceptance tests pass, a release engineer or product owner can choose to deploy to production via an automated deployment. Smoke tests are typically run against the production application prior to cutting over URLs.

This is a very different process from traditional deployments. Three differences are worth highlighting.

  1. A single-built artifact is deployed to all environments. It’s never rebuilt or repackaged. This may be a JAR or WAR file (for Java applications), or a DLL or web site directory (for .NET). Regardless of the unit of deployment, the same version of source code is never rebuilt or repackaged after it passes unit tests. The same versioned artifact is used for all environments.
  2. Given that a versioned artifact is never rebuilt, variable configuration isn’t packaged in the artifact. Instead, environment config is provided by the platform in some fashion. For Pivotal Cloud Foundry, configuration is provided by environment variables, or an external configuration server such as Spring Cloud Config Server.
  3. The entire process is automated via deployment scripts and a CI server. This means automated testing must be in place for each step. Traditionally, functional and acceptance testing are performed manually by a Quality Assurance department. However, this is error prone, and causes long wait times in the deployment process. Organizations need discipline to automate testing to this degree.

There’s a lot for development teams to unpack if they want to release early and often But Jimerson offers an elegant, accessible overview of what your desired end-state should be.

Operators Need Velocity Too

Finally, Jimerson shows how operators can accelerate their pace of platform deployments as well. Your organization can operate at peak velocity with a platform that’s always up-to-date and patched. Concourse for PCF - just announced - helps ops teams do exactly that. No downtime required!

Read more about the tech paper series, or peruse all of our recent white papers. Happy learning!

About the Author

Jared Ruckle

Jared works in product at Pivotal.

Follow on Twitter More Content by Jared Ruckle
Previous
Automated Machine Learning: Deploying AutoML to the Cloud
Automated Machine Learning: Deploying AutoML to the Cloud

This may be the year that AutoML enters the data science vernacular. I share an AutoML setup to train and d...

Next
React License Woes: How to Protect Your Codebases From Churn
React License Woes: How to Protect Your Codebases From Churn

Are you worried your company will force you to switch from React to another framework because of React's li...