Book Image

DevOps Culture and Practice with OpenShift

By : Tim Beattie, Mike Hepburn, Noel O'Connor, Donal Spring, Ilaria Doria
Book Image

DevOps Culture and Practice with OpenShift

By: Tim Beattie, Mike Hepburn, Noel O'Connor, Donal Spring, Ilaria Doria

Overview of this book

DevOps Culture and Practice with OpenShift features many different real-world practices - some people-related, some process-related, some technology-related - to facilitate successful DevOps, and in turn OpenShift, adoption within your organization. It introduces many DevOps concepts and tools to connect culture and practice through a continuous loop of discovery, pivots, and delivery underpinned by a foundation of collaboration and software engineering. Containers and container-centric application lifecycle management are now an industry standard, and OpenShift has a leading position in a flourishing market of enterprise Kubernetes-based product offerings. DevOps Culture and Practice with OpenShift provides a roadmap for building empowered product teams within your organization. This guide brings together lean, agile, design thinking, DevOps, culture, facilitation, and hands-on technical enablement all in one book. Through a combination of real-world stories, a practical case study, facilitation guides, and technical implementation details, DevOps Culture and Practice with OpenShift provides tools and techniques to build a DevOps culture within your organization on Red Hat's OpenShift Container Platform.
Table of Contents (30 chapters)
Free Chapter
2
Section 1: Practices Make Perfect
6
Section 2: Establishing the Foundation
11
Section 3: Discover It
15
Section 4: Prioritize It
17
Section 5: Deliver It
20
Section 6: Build It, Run It, Own It
24
Section 7: Improve It, Sustain It
27
Index
Appendix B – Additional Learning Resources

Existing PetBattle Architecture

The initial PetBattle architecture was pretty basic and revolved around deploying application components running in a single virtual machine (VM). The initial architecture had three major components: a JavaScript frontend; a Java-based backend, providing an API and a database; and a single instance of MongoDB. Nothing here was too exciting or complex but hidden inside was a minefield of technical debt and poor implementation that caused all sorts of problems when the site usage took off.

The issues with this architecture seemed to include:

  • A monolith—Everything had to be deployed and scaled as one unit, there were no independent moving parts.
  • Authentication and access control were non-existent.
  • Tests? Unit tests? But seriously, there weren't many.
  • It required a lot of data maintenance as everything was stored in the database.
  • Bad actors adding inappropriate images to our family-friendly cat application.
  • Fragile...