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

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:

• Multi-Site Pivotal Cloud Foundry: Deployment Topology Patterns and Practices by Michael Krumpe, Guillermo Tantachuco, Adam Zwickey, and Chris DeLashmutt

• From Months to Hours: Accelerating Software Deployment with PCF By Brian Jimerson

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.

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. 

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!